Обсуждение

Beta базируется на определённой философии (вплоть до отсылок к Аристотелю в документации). Это же верно и для Smalltalk. Но в случае Java или UML первична интеграция готовых решений. И образ мышления, соответственно, в одних случаях порождает решения, а в других сам является порождением среды вокруг определённого языка. Различия не только в ‘Scandinavian School’ vs. ‘U.S. School’.

В апрельском выпуске Communications of ACM 2010г. поднимается этот вопрос: собственно "программирование" является только маленькой частью того, что сейчас связано с IT. Предлагается брать ITIL за основу новой структуры того, чему нужно обучать современных айтишников. Понятно, что это "от философской безысходности". Проблема, как мне кажется, не столько в "что в языке первично", а в том, как вообще подходить к конструированию языков, отвечать на вопрос "что есть язык" и "что в языке должно быть отражено и для чего". Философски эта проблема решается осознанием разницы programming/modeling-in-small и programming/modeling-in-large, я неоднократно об этом писал. Проект FONC в VPRI адресует эту же проблему как "масштабируемость": языковые решения, которые пригодны на уровне "около ассемблера" и равно на самом высоком уровне описания задачи. Так что проблема осознана, и не так фатальна. С проблемой работают.

Беда в том, что с тех пор ООП стало именно ООПрограммированием, но не ООМоделированием или ОООнтологизированием. Хотя классики ОО подхода различали ООАнализ, ООДизайн и ООПрограммирование. Я раньше не втыкал разницу между ООАнализ и ООДизайн. Потом воткнул, но реально конечно из программеров почти никто ее не втыкают. В частности, теоретики выделяли такое понятие как ДиректДизайн, т.е. когда объекты выявленные на этапе анализа напрямую преобразуются в дизайн (ну и из этого генерится ОО код в нужном языке). Т.е. такой директ дизайн, несмотря на удобство, полностью убивает различие между анализом и дизайном. Т.е. по сути анализ (= моделирование) есть лишний этап. Конечно, это какое-то следствие более глубокой проблемы.

-- описывать (т.е. моделировать) архитектуру системы, постепенно переходя от архитектурных (принципиальных) описаний, связывающих функцию и конструкцию к конструктивным описаниям, достаточным для изготовления. Этот "постепенный переход" можно делать мозговыми усилиями людей, а можно выполнять "автомагически" -- и тогда говорят о "трансформации моделей", но можно говорить и о программировании. В принципе такая система есть. Т.е. существует универсальный моделер, на котором можно моделировать архитектуру, а потом превращать ее в реализацию. Тока я боюсь, что Вас он не устроит :). Современные Higher Order Logic системы именно так и построены. На них и софт и железо можно моделировать. Только они весьма сложные, ну и графических тулзов моделирования а ля УМЛ там нет. Ну и прочее, т.е. это академические тулзы, хотя их промышленно тоже юзают.

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

Я вот сегодня все утро размышляю, так ли мне самому нужен графический язык? И отвечаю примерно так же, как авторы BETA: мне самому может оказаться удобней с текстом (в котором все DSL представляются единообразно), а графика нужна только для объяснений экспертам-предметникам (хотя люди в BETA говорят, что еще и программистам-новичкам для освоения данного конкретного кода программы), им разношерстные графические DSL удобней. Насчет Higher Order Logic я согласен, но это же относится и ко всему остальному -- железо и функциональным софтом моделируют, и объектно-ориентированным, и модельным... Универсальность в моделировании, думаю, связана с мультипарадигмальностью. Причем эта мультипарадигмальность, скорее, свойство одного языка, а не просто возможность сочетать разные языки. Пока мультипарадигмальность есть в объектно-функциональных языках типа SCALA и функционально-логических типа Curry. Кей-пиуматровские люди экспериментируют с объектно-функциональными языками, добавляя к ним логический язык H, но я пока не понимаю этого способа работы. Мне кажется также, что универсальность моделирования в легкости многоуровневых описаний -- и пока какой-то хоть как-то развитый язык для этой многоуровневости я нахожу только у суперкомпиляторщиков (ибо им приходится говорить про идентичность программ разной структуры, и нужно было разработать язык для описания инвариантов исполнения кода разного уровня "переваренности" компилятором).

А я ХОЛ поминаю как раз в силу его способности описать любой формализм. Т.е. он может служить связующим звеном между любыми парадигмами. На нем можно описать любую структуры и доказать эквивалентность преобразований туда/обратно. При этом, это есть минимально мощный по выразительности механизм, потому что функциональные языки (да и объектные) изначально higher order, т.е. там передаются функции в качестве параметров (в объектно ориентированных передаются объекты у которых может быть переопределены методы, т.е. по сути тоже higher order). Из мультипарадигмальных наиболее мульти- является Mozart/Oz там и функционалка и объекты и огнраничения и логика.

Как я понимаю авторов BETA, альфа-язык сегодня по факту процедурно-стеково-регистровый. Не знаю, насколько оправдано вводить ХОЛ как бета-язык ("промежуточный для связи парадигм"), а уж затем только мультипарадигмальный гамма-язык типа Oz. Как я понимаю, Oz весьма экспериментален и эклектичен. О мультипарадигмальности в части ее реализации в одном (как в Oz) или множестве (как в Language Workbenches) языков сейчас очень много споров.

В Language Workbenches нужен базовый язык (формализм я бы даже сказал), и соответственно он определяет общие свойства воркбенча. HOL тут наиболее выразительный формализм, следовательно Воркбенч на ее основе будет наиболее выразительным. Правда потенциально, ибо на реализацию выразительности будут затраты. Зато всегда можно (затратив определенные усилия) транслировать одну парадигму в другую. Собсно, транслировать-то можно хоть на Си, вопрос в кол-ве усилий (и багов). А HOL позволяет сертифицировать трансляцию, т.е. можно хоть как-то управлять такой неимоверно сложной штукой как Воркбенч: в общем случае, сложность растет квадратично от кол-ва языков). А если есть верификация, то путем трансляции через промежуточный язык получаем линейную сложность.

ЗЫ Если нет верификации, то трансляция через промежуточный язык есть очень error-prone процесс, трансляторы годами отлаживают.

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

Сейчас промежуточным "языком умолчания" для всех этих воркбенчей является Java (Eclipse modeling framework, JetBrain MPS, Whole Platform и так далее со всеми остановками). Как я понимаю, есть попытки сделать workbench над логикой: это плагины Protege, а также более специализированные TopBraid и NeOn. Появился также iRing (для ISO 15926), но он существенно заточен сейчас под OWL, хотя оригинальная модель данных там HOL. Но я что-то немного знаю работ, в которых сначала какие-то императивные процедуры переводят в HOL, а только потом транслируют на ассемблер -- и пытаются затем отладиться, передавая информацию выполнения ассеблера в HOL, а оттуда "переводя" на язык исходного императивного представления. Что-то в этом кривое видится... Мне кажется, что при наличии мультипарадигмального изначально и полностью рефлексивного языка (типа языка функциональной логики) в качестве "промежуточного" перед "ассемблером" жизнь должна становиться легче. Хотя люди в VPRI вообще идут другим путем, и "выворачивают наизнанку" реализацию языка, делая ее расширяемой -- хоть на HOL, хоть на ассемблерные вставки...

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

HOL тут выступает не совсем как промежуточный язык, а мета-описание промежуточного языка :). Проблема в том, что в Жабу можно транслировать разными способами. Т.е. сама жаба построена на ОО парадигме, и уже с функционалкой не очень вяжется. А тем более с логикой. Ведь декларативка не требует какого-то жесткого алгоритма выполнения, в отличие от императивки. Т.е. декларативка может быть оттранслирована разными способами (бесконечным кол-вом). Грубо говоря, трансляция декларативки - это сама по себе суперкомпиляция. Ибо декларативка задает модель вычислений, а не сам алгоритм. Ну а описанием этой модели вычислений, подходящим как для функ-, ОО- так и для логических парадигм как раз ХОЛ и является. Условно говоря, мы императивные алгоритмы транслируем в модель этих алгоритмов. А (чистая)декларативка уже сама по себе есть модель. Далее эти модели как-то преобразуются: упрощаются, специализируются. А потом их уже можно генерить код (тоже в любой архитектуре). Вобщем, я предлагаю Workbench рассматривать как мультипарадигмальный суперкомпилятор :). Где фронтенды для разных языков транслируют программы в промежуточный ХОЛ-формализм, который трансформируются под нужные цели (тоже с помощью ДСЛей), а потом генерится целевой код (опять через ДСЛи). Т.е. фронтенды, бэкенды (кодогенераторы), оптимизации - это все специализированные DSL.

Оно понятно, что "обратная трансляция" -- только некоторые преобразования программ (оптимизационные) типа криптографических преобразований: туда легко, а обратно трудно :) Гарантировать что-нибудь в компиляторах-дебаггерах-оптимизаторах-частичных оценивателях и прочих исполняющих механизмах как раз нетривиально. Хотя именно для них это весьма и весьма нужно.

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

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

а) ну я для иллюстрации идеи :). если суперкомпиляторщики не считают это суперкомпиляцией, это ничего не меняет. Собственно, я суперкомпилятор помянул, ибо решил что Вам так понятнее будет :) б) а это не так важно, внутренний или внешний ДСЛ. Т.е. внутренний все равно на базе какого-то языка. А вот эти базовые языки надо транслировать в формализм, т.е. тут в принципе можно сделать отдельный трансляционный ДСЛ. Хотя может смысла и нет, действительно.

Я вот прямо сейчас пытаюсь разложить описание деятельности на основе ситуационной инженерии методов на ряд DSL. Самые интересные при этом картинки -- где можно наблюдать взаимодействие групп описаний пары заинтересованных сторон с разными их DSL. Например, если для архитектуры (функции-конструкция или цели-средства) добавить язык обоснований (аргументы), или указывать чьи требования (добавить позиции к целям). А их видимо лучше в одном интернал ДСЛе делать. На СКАЛА это вполне можно сделать.

Там ведь непонятно, что вычислять при этих описаниях -- это онтологические описания, объекты-связи-аксиомы :) Поэтому самое адекватное было бы описывать в ISO 15926, по ходу дела доопределяя шаблоны (с аксиомами). Но инструментария для этого нет. Родным языком для всех этих представлений (в литературе) является язык стереотипов UML. Так что, если бы не моя брезгливость к UML, мне бы помог любой редактор UML, поддерживающий стереотипы. К тому же меня больше интересует "пользовательское представление" -- то ли графика в стиле тамошних "полуUML" нотаций (в традициях OMG-метамоделирования), то ли графика в стиле ISO24774, то ли просто текст... По большому счету, это онтологическая работа, но для онтологических описаний вообще ничего хорошего не придумано еще -- причем преимущественно в нечитабельных людьми представлениях (типа как OWL-в-XML). Поэтому у меня затык полный: языка нет, метамодели плохо совместимы, описательной парадигмы толком нет, предпочтений людей-пользователей нет :)))