ФП, 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 с хаскелем в качестве внутреннего языка, я немедленно его снесу и постараюсь забыть об этом кошмарном сне. Даже джаваскрипт был бы лучше.

[metaclass.livejournal.com]

Это-то то меня и останавливает.
В реальном промышленном проекте, кажется, дело идет к использованию C# + генерация кода на нем из DSL, короче, практически как в Visual Studio для редакторов GUI и сделано.

[a-konst.livejournal.com]

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

[metaclass.livejournal.com]

Если бы. Последние посты в ru_lambda и ru_declarative хорошо иллюстрируют нежелание адептов понимать реальные потребности приземленных разработчиков.

[a-konst.livejournal.com]

некоторых адептов.

в то время как твои высказывания почти всегда несут в себе заряд всеобщности.

[metaclass.livejournal.com]

А, это да, частными случаями мыслить не умею :)

[vp.livejournal.com]

Это не мельницы, это нормальная попытка обощить задачи, которые возникают раз в день. Метод первого обобщения, безусловно, известен - зоопарк кодеров, которые будут писать 1 форму на 1 сущность влоб с жетским кодированием чего-то, а потом будут все это сращивать перекрестными зависимостями. Но мы ж такого не хотим, как бы 2008 год на дворе :) На самом деле, хочется развития в программистской индустрии, что касается обсуждаемого вопроса.

Re: Ответ на ваш комментарий

[a-konst.livejournal.com]

ну то что дальше, особенно под катом, выглядит вполне адекватно, я скорее пошутил :)

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

[psilogic.livejournal.com]

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

[metaclass.livejournal.com]

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

[sergiej.livejournal.com]

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

[metaclass.livejournal.com]

Если бы дело ограничивалось одной жабой...
Тут зоопарк языков блин. Да и количество фреймворков под жабу превышает всякое разумение, что-то в языке черви окопались видимо, раз их так много.

[sergiej.livejournal.com]

А то что ты предлагаешь не есть очередной фреймворк??? Даром что не на жабе.

[metaclass.livejournal.com]

Ж-па, и ведь точно :)

[sergiej.livejournal.com]

Раз их так много, значит язык удобный, и понятный.

[metaclass.livejournal.com]

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

[sergiej.livejournal.com]

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

[golosptic.livejournal.com]

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


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

[familom.livejournal.com]

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