alex55555,

я и пишу о формализации знаний в виде моделей и на DSL уже какую страницу

mad_nazgul,

Isabelle HOL написана ML. В итоге все логические теории, написанные на ней, сводятся к этому ML коду, который сводится к машинным инструкциям, которые сводятся к электрическим импульсам в процессоре. Но человек, который пишет эти логические теории не обязан всё это знать, он может быть математиком, а не программистом.

Хотя, в Isabelle HOL можно делать вставки ML кода, и здесь я совершенно согласен с идеей о "дырявости абстракций". Ещё там могут быть проблемы с производительностью, для решения которых нужно понимать как всё работает внутри. Но это опционально, я пользовался ML вставками только один раз для теста. И несколько раз переписывал функции, разбивал типы данных на несколько более простых из-за того, что Isabelle HOL неявно формулирует и доказывает кучу теорем и это сильно тормозило.

Но согласиться, что абстракции совсем не нужны я тоже не могу. На том же SQL проще добавить несколько хинтов, чем писать запросы на ЯП. Хотя над SQL ещё куча абстракций - разные ORM, LINQ и т.п. И, вот, где начинаются настоящие проблемы :) Я, например, хлебнул с Hibernate, который выдаёт неадекватные исключения, по которым невозможно понять что не так. Или с XPO, который отправляет много мелких запросов и это очень тормозит при плохом канале.

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

mad_nazgulНужны. Просто вместо одного программиста будут нужны два.
Первый пишет кодогенераторы, второй пишет на птичем языке ФЛК.

Для примера можно плосмотреть на SQL.
Помниться SQL продвигался, как инструмент, для которого программисты не нужны.Хорошо, пусть будет два. Всё равно это лучше, чем тысяча программистов, тестировщиков, аналитиков, РП у каждого участника взаимодействия. Здесь вариантов всего два:
1) Нормативка на русском и каждый участник реализует её как понимает и своими силами
2) Нормативка на русском + формализованная нормативка, из которой автоматически делается несколько реализаций под разные стеки технологий. Автоматически, потому что на написание и сопровождение этого кода никто ресурсы тратить не будет. А формальная спецификация - это уже не код, она более компактная, более долговечная, понятная для предметников. Под разные стеки, потому что навязывать один стек технологий никто не может.

Варианта, что нормативка сразу реализуется в коде нет.

mad_nazgulУниверсал - это тот кто все делает одинаково плохо.Постоянно слышу эту фразу. Очевидно, что если он плох во всём, то уже автоматически перестаёт быть универсалом :) Ещё я слышал фразу, что талантливый человек талантлив во всём.

Это всё штампы. Людям удобно загонять себя в рамки. Причём, многим людям мало поставить на себе штампик "программист". Нужно добавить ещё штампов: middle, senior, full-stack и т.п. По-моему нужно заниматься тем, что интересно и не придумывать искусственные ограничения.

alex55555,

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

serge79y,

Посмотрел историю SDL:
1976 - 1-я версия с графической нотацией
1980 - пересмотр языка
1984 - текстовая нотация
1988 - формальная семантика

История UML:
1995 - 1-я предварительная версия
2005 - пересмотренная 2-я версия
2015 - полное текстовое представление (к сожалению не человекочитаемое) для моделей, включая диаграммы
Формальной семантики нет до сих пор. Точнее есть очень много разрозненных работ по формализации отдельных видов диаграмм, но стандарт достаточно неформальный.

Интересное совпадение, что у SDL эти шаги были длиной в 4 года, а у UML - 10 лет. Наверное в 2025 можно ждать полную формализацию UML :)

Я понимаю все эти вещи насчет человеческого фактора. Ровно для этого я и писал статьи на хабр по MDD, чтобы продвигать эту тему. По тому же OCL мне достаточно дать человеку ссылку на статью , чтобы он быстро вник. Если бы я дописал все статьи, которые планировал, то никакой катастрофы с моим уходом с этого проекта не было бы. Её и сейчас не будет, потому что основные вещи описаны.

Насчёт неформальности UML и связанных языков типа OCL. Это проблема и чтобы исправить это я написал формальную спецификацию OCL . Чтобы хотя бы OCL был формальным. На самом деле это делали и до меня ещё в 2014 году. Но прикол в том, что ни я, ни разработчики OCL в этой спецификации нихрена не понимают. Она сильно оторвана от реализации, фактически они сделали альтернативную реализацию OCL на Isabelle HOL.

Моя спецификация OCL уже сильнее оторвана от Isabelle HOL, потому что у меня используется deep embeding (типы данных, синтаксис и т.п. явно определены как алгебраические типы данных) вместо shallow embedding (ни типы, ни синтаксис как таковые не определены, вместо этого используются типы базового языка (Isabelle HOL), а выражения OCL транслируются в выражения Isabelle HOL). Но с другой стороны, она всё ещё слишком оторвана от реализации. А разработчики вообще видят формальную спецификацию OCL так . И теперь я ломаю мозг как скрестить ежа с ужом, чтобы получилось что-то среднее и понятное всем.

Короче история действительно повторяется, люди занимались тем же самым с SDL ещё 30 лет назад. Но я бы не сказал, что в MDD нет вообще никакого прогресса. Огромное количество разных DSL. Инструменты для визуальных языков моделирования: Eclipse Sirius, JetBrains вроде тоже что-то делает, куча рисовалок и т.п.