Текстовый юникс-вей vs запросы к БД.

[metaclass]

Когда vitus_wagner в очередной раз толкает у себя в ЖЖ глобальные идеи на тему "как нам обустроить IT" там всегда всплывает ключевым аспектом unix-way в его аспекте "используем множество мелких программ, увязывая их через текстовый ввод-вывод".

Я же постоянно там на это отвечаю, что счетаю нужным увязывание сделать строго типизированным, чтобы быть уверенным, что это дело не поломается, когда в какой-нибудь мелкой утилите поменяют формат ввода или вывода.
И там же у vitus_wagner как-то было обсуждение, как этот подход скрестить с GUI-программами, потому что у них другая модель, не текстовый ввод-вывод, а ожидание событий от пользователя.

Вот сейчас сижу смотрю на свою почту в Mozilla Thunderbird и понимаю, что мне не хватает там возможности сделать запрос типа "все непрочитанные письма из всех ящиков с сортировкой по дате и отметками к какому из проектов оно относится".

Т.е. если по хорошему, то в любой гуманной проге работающей со большими объемами структурированных данных, подобно реляционной(не обязательно, главное наличие схемы/типов/структуры) БД, должна быть вкручена некая консоль с REPL, где можно было бы на ходу пилить запросы, сохранять их для будущего использования, итд.

Я в самодельном фреймворке, на котором основано несколько штук наших оперденей, сделал похожую вещь - она уже 5 лет используется на полную катушку, вплоть до того, что можно разрабатывать новый функционал вообще не открывая средства разработки - прямо в рабочей проге. (про одну из возможностей Firebird на которой это построено, будет отдельный пост).

Сейчас в бзодотнетовском варианте хотелось бы сделать то же самое, только еще более навороченное, с запоминанием промежуточных результатов, итд (похоже на натуральный REPL, типа GHCi или F# консоли), но это надо мозг расшевеливать будет сильно.


Т.е. основная идея: текстовый unix-way это конечно очень хорошо, но хочется статической типизации.

Comments

[thedeemon.livejournal.com]

>текстовый unix-way это конечно очень хорошо, но хочется статической типизации.

В PowerShell MS так и сделала.

[kurilka.livejournal.com]

У К. Эллиотта есть про типизированый unix-way - http://www.youtube.com/watch?v=faJ8N0giqzw
Правда примеры там скорее игрушечные...

mail

[codovstvo.blogspot.com (from livejournal.com)]

Учитывая что thunderbird хранит базу писем в стандартном формате, можно по идее прикрутить стандартные программы, например mail.

[zmila.livejournal.com]

Т.е. если по хорошему, то в любой гуманной проге работающей со большими объемами структурированных данных, подобно реляционной(не обязательно, главное наличие схемы/типов/структуры) БД, должна быть вкручена некая консоль с REPL, где можно было бы на ходу пилить запросы, сохранять их для будущего использования, итд.

аналогично.
во многих прогах очень чешется не тыкать много раз мышкой в разные места, а просто натайпать сделай мне то и то.
недавний типичный пример: мр3-плеер на базе мозиллы, довольно интересный, но сильно не хватает в нём клавиатурной навигации и вызов комманд из консольки.

[plumqqz.livejournal.com]

Я же постоянно там на это отвечаю, что счетаю нужным увязывание сделать строго типизированным, чтобы быть уверенным, что это дело не поломается, когда в какой-нибудь мелкой утилите поменяют формат ввода или вывода.

Что делать при текстовом увязывании более-менее понятно, если "мелкой утилите поменяли формат ввода или вывода" (с чего бы, кстати?)

Что делать в строго типизированном случае, если поменяли строгие типы, понятно тоже - ничего не делать. Потому что бестолку.

http://plumqqz.livejournal.com/11502.html

[metaclass.livejournal.com]

В нетипизированном случае может быть такая ситуация: так как мы ненавидим копипасту, все проекты разделяют где-то 70% кода. И если человек работающий над одним проектом, решит что нужно таки устроить рефакторинг какого-нибудь модуля, то другие проекты могут поломаться, при этом часто это можно будет обнаружить только в рунтайме, т.е. тестированием, захватывающем нужный путь выполнения. И не всегда это будут ошибки, по которым что-то вообще понятно.

А так оно сломается при сборке у нас, что гораздо проще поправить, чем копаться в мегабайтах логов с продакшена без возможности посмотреть, что же там у пользователей на самом деле происходит.

[plumqqz.livejournal.com]

Ничего не понял.
Вот у нас есть команда, выдающая в stdout список файлов. Мы ее решили тайком отрефакторить, поменяв без объявления войны вид ожидаемой выдачи. Все разлетелось, как выяснилось при тестировании.

А в другом проекте тоже есть команда, выдающая список объектов типа "элемент списка файлов". Мы ее решили тайком отрефакторить, поменяв без объявления войны тип "список элементов списка файлов" на "список элементов списка обыкновенных файлов". Все разлетелось, как выяснилось при тестировании.

Что-то не могу найти различий. Общее есть, а различий - нет.

[metaclass.livejournal.com]

Нет, во втором случае разлетится при сборке, а не при тестирование и не при использовании.

[kiryl.livejournal.com]

При сборке чего? Вы предлагаете собирать скрипты в одну монолитную фигню?

В скриптах одно из основных преимуществ -- это возможность позднего связывания компонентов. В какой момент времени вы предлагаете делать проверку типов?

[metaclass.livejournal.com]

В наиболее ранний возможный момент. Если это некий софт - то при сборке, если это набор наколенных скриптов - в момент их запуска (а не через 5 часов работы в дебрях вызовов где-нибудь).

[kiryl.livejournal.com]

"в момент их запуска" потребует создания и поддержки некого подобия ABI и его версионирования для компонентов, со всеми вытекающими последствиями. Т.е. подмена одного компонента другим потребует непозволительных для скриптования усилий.

К тому же eval и ему подобные вещи станут невозможны.

[metaclass.livejournal.com]

eval никуда не денется, просто валится он будет при попытке его выполнить на невалидном наборе скриптов.

[volodymir-k.livejournal.com]

Идея например COM в том, что в реестре регистрируется библиотека типов, предоставляемых объектов, и при запуске скрипта на выполнение бейсиком делается попытка разрулить все вызовы методов объекта в программе (на этапе скажем синтаксического анализа и перевад в байт-код), и если будет структурная ошибка, то сказать прямо сразу, а не через например 5 часов необратимых операций.

Версионирование интерфейса происходит и без того достаточно редко, а версионирование реализации (багфиксы) имеют слабое отношение к такому же для интерфейсов. Иногда бываит, но чаще нет.

[plumqqz.livejournal.com]

При какой, прости господи, сборке?

[metaclass.livejournal.com]

Сборка, то бишь build.

[plumqqz.livejournal.com]

Что за страсть все прибивать гвоздями.

[denisioru.livejournal.com]

В том же аутлуке - labels, search folders.

-================<;>~

[(Anonymous)]

Строгая типизация в текстовом потоке данных сделана уже давно и в том-же Thunderbird mailbox.
Текстовый блок предваряется MIME-заголовком.
Точно так-же сложные объекты путешествуют из приложения в приложение в OS Plan9.
Сканер /dev/scanner -> image/png -> OCR -> multipart MIME (image/png+ text/plain) -> Text processor
Всё через пайпы которые юзер зацепляет не в командной строке, а милой менюшке, стандартной для любого приложения.

[slonik-v-domene.livejournal.com]

>Т.е. если по хорошему, то в любой гуманной проге работающей со большими объемами структурированных данных, подобно реляционной(не обязательно, главное наличие схемы/типов/структуры) БД, должна быть вкручена некая консоль с REPL, где можно было бы на ходу пилить запросы, сохранять их для будущего использования, итд.

Господи, мы-то столько времени отрывали все эти бэкдор-консольки, а тут их опять возрождают.

[metaclass.livejournal.com]

От чего отрывали?

[slonik-v-domene.livejournal.com]

Отсобственных разработок.

[metaclass.livejournal.com]

А зачем, удобно же?

[slonik-v-domene.livejournal.com]

Затем, что два интерфейса для управления одной сущностью - уже слишком много.