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

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

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

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

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

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

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

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

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