ФП, OpenSource, GUI, IDE и промышленная разработка бизнес-софта

[metaclass]

Последние дискуссии на сабжевые темы показывают, что сторонники OpenSource и адепты ФП в упор не понимают необходимости в GUI, и, соответственно, в IDE.

И это при том, что сущность изготовления гуя и методики работы в визуальных дизайнерах разных IDE сред весьма хорошо ложаться на комбинаторы в ФП, автоматический вывод типов и статическую типизацию, а так же метапрограммирование.

Тем не менее, существующих вариаций этих фич функциональных языков недостаточно.

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

При разработке таких систем чаще всего получаются либо ужосы в стиле 1С, Abacus Financial и прочих - "встроенный язык", "встроенные дизайнеры документов", "свой язык запросов" либо системы, у которых настройка сложнее, чем написать тоже самое с нуля, либо гибрид того и другого(типа SAP).
В итоге обычно поверх обычного языка программирования и обычной БД реализуется новый язык программирования, новый язык запросов, новый генератор отчетов, причем теоретическими моделями там даже не пахнет, повторным использованием уже существующих языков тоже. Явный оверкилл. Причина: клиенты хотят сами донастраивать систему в "удобном" виде. После этого появляется новая категория "программистов" - "ABAPеры", "1С-консультанты", "Настройщики ERP", так как клиенты не связанные с IT это осилить не могут.

Идеальный вариант - сделать в достаточно мощном языке общего назначения DSL для описания документов, их GUI и печатных форм (все сплошная декларативщина, причем даже бизнес-логика в большинстве случаев описывается простыми правилами). Но это потребует обычных программистов, так как, несмотря на встроенный DSL, - это все-таки писание кода в виде линейного текста на обычном языке. Хорошо подходит для случая "сами написали, сами внедряем" или для OpenSource-проектов. Распространенной промышленной реализации такого подхода не встречал.

Поэтому хорошо бы было сделать что-то вроде трехступенчатой схемы - есть ядро системы на обычном языке, есть на его основе набор стандартных решений для отраслей, есть настройка его под конкретного заказчика. И вот второй и третий этап нужно делать доступным как программистам-любителям текстовых редакторов, так и дизайнерам-рисовальщикам-собирателям систем из кубиков в RAD-средах.
Но чтобы это все равно оставалось кодом на обычном языке, без реализации поверх него еще нескольких языков. Чтобы проверка и вывод типов, обработка ошибок, и тому подобные функции использовались от базового языка, но при этом структура исходника была заточена под решаемую задачу - т.е. это должен быть DSL - типа подмножество "язык для печатных форм" "язык для описания GUI" и чтобы вспомогательный код генерировался автоматом или, как минимум, писался один раз и использовался везде где надо.

В моем воспаленном мозгу возникают картины чего-то типа "несколькоступенчатый компилятор хаскеля, с библиотеками для реализации DSL, с автоматической генерацией скриптов создания и обновления БД, версионностью исходников и прикрученной к нему IDE, которая является неотъемлемой частью итоговой системы, причем IDE реализована на самой себе"

Comments

[1ceheart.livejournal.com]

Все это в целом звучит правильно, но дьявол, он в деталях реализации. Можно взять замечательный язык, написать замечательные библиотеки и получить в итоге автокад и автолисп. Вообще проблема внутренних языков и сочетания текстового ввода с GUI - она же не ограничивается миром бухгалтерии, в каждом первом CAD это тоже так или иначе нужно, а в CAM внутренние языки это просто норма жизни, и, разумеется, везде все говно. Самым кошмаром, конечно, был какой-то электронный CAD с перлом в качестве внутреннего языка. Очень удобно.

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

Поэтому хаскель это конечно замечательно и хорошо, но если я увижу CAD с хаскелем в качестве внутреннего языка, я немедленно его снесу и постараюсь забыть об этом кошмарном сне. Даже джаваскрипт был бы лучше.

[a-konst.livejournal.com]

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

[psilogic.livejournal.com]

То, что ты говоришь, это специализированная библиотека (на базовом языке) под определенный круг задач.

[sergiej.livejournal.com]

Как бы это сказать, чтобы не обидеть...
Ну как бы все так и делают, это лет 10 назад когда писали САП занимались ерундой создавая кривые языки "супервысокого уровня". Теперь делают ядро + рабочий стандартный набор реализующий ядро + флаг в руки любому клиенту который желает всё что не ядро обрабатывать под себя напильником.
Переход произошёл когда поняли что джава достаточно проста для "тупых" клиентов и достаточно сильна для "умных" разработчиков ядра.

[golosptic.livejournal.com]

Но чтобы это все равно оставалось кодом на обычном языке, без реализации поверх него еще нескольких языков. Чтобы проверка и вывод типов, обработка ошибок, и тому подобные функции использовались от базового языка, но при этом структура исходника была заточена под решаемую задачу - т.е. это должен быть DSL - типа подмножество "язык для печатных форм" "язык для описания GUI" и чтобы вспомогательный код генерировался автоматом или, как минимум, писался один раз и использовался везде где надо.


Как говорится, откуда уплыли - туда и приплыли.
Эта схема не особо отличается от мейнстрима советских АСУшных разработок.
Знать, не дураки эти делом занимались.

[familom.livejournal.com]

Вам наверняка будет интересно: http://en.wikipedia.org/wiki/Xmonad