открываем встроенный туториал (C-h t) и проявляем совсем немного усидчивости и внимания.Нужна ещё сущая мелочь. Абсолютная память. Поскольку я таковой не обладаю, то запоминание этого безумного количества шоткатов мне не по силам. И emacs, увы, не для меня.

Детский сад. Единственный стимул к развитию своего профессионального уровня — перестать прикладывать усилия. Инфантилизм какой-то.

Может, конечно, что-то и получится, в конце концов, есть же такая вещь, как спасительная интуиция. Но я не готов поставить на нее.Тогда к чему эти разговоры о сложности проекта? Хорошее исследование на тему планомерности и интуиции провёл А.С. Пушкин. Вы найдёте изложение результатов в произведении «Моцарт и Сальери», вот прям начальный монологи Сальери как раз об этом.Впрочем, возможно вы попутали дилетантизм и интуицию. Хотя вряд-ли. Название статьи уж очень красноречивое. Так знайте, за пределами ремесленичества есть ещё очень многое, очень.Вот, например, та-же проблема измерения и выводов из этих измерений. Ну померяли вы некоторые параметры. А как из них получить интересующий вас вывод? Как эти параметры влияют на результат? А вдруг нелинейно? А вдруг они влияют друг на друга, в системе есть обратные связи? Даже в простейших случаях обычно получается система нелинейных уравнений, нерешаемая математически. Без интуиции в ней никак не разобраться. Но можно формально намерять и пускать пыль в глаза. Пылится хорошо, до тех пор, пока опыляемый не прочитает нечто вроде Мифический человеко-месяц.

Codekana blog " On the Speed of Light, Innovation, and the Future of ParsingУ парсинга просто нет будущего.

Maxim Yemelyanov: Очень аргументировано. Особенно подкупает сам подход. Следуя ему, мы легко поймём, что проблем в программировании вообще нет, надо только правильно организовать код в своей голове и файле.Боюсь только, что эта степень максимализма выдаёт вашу лёгкую неопытность.

Леша Маслов: Ты совершенно верно всё написал. Преобразования текста в AST — это парсинг. И пока текст не закончен, распарсить текст (преобразовать его в AST) нельзя. А нужно. Так как IDE в процессе набивки текста должно тебе предоставить определённый сервис, вроде подсветки синтаксиса, автокомплита, или фоновой компиляции и пр. Чтоб это сделать, IDE надо догадаться, что имеет в виду программист, пока набивает текст, а не как парсер компилятор, который имеет дело с уже набитым и законченным текстом. Поэтому парсер IDE намного сложнее, завязан на конкретный язык и синтаксис, и требует сложных изменнений и длительной отладки при изменении синтаксиса.Этих всех проблем можно избежать, если использовать структурный редактор. Ему не надо догадываться, где будет стоять закрывающаяся скобка} или что-то в этом роде. Ему сразу говорят — будет блок. Он создаёт блок (внутреннее представление, узел AST дерева), отображает его (рисует {и}), а между ними уже человек вбивает что ему надо. Такой редактор не будет менее удобен, чем старый добрый текстовый редактор, просто он будет немного непривычным для нынешнего поколения программистов. Так же, как непривычно для людей, привыкших делать отступы для первой строки параграфа вставляя несколько пробелов, делать отступ в Word-е двигая ползунок мышкой или указывая его в диалоге свойств параграфа.Что до валидности текста в Word-е, то это несколько сложнее. Вот невалидный XML текст [b] bold [i] and [/b] italic [/i] . Его написать в тексте можно, но он не может быть отображён во внутреннее представление (если это XML DOM). Так Word и не даёт прямого доступа к своему внутреннему представлению. Он позволяет тебе только давать внешние коммандны — этот кусок текста выделить как bold, этот кусок как italic, а внутреннее представление он меняет сам, на основе комманд. Это позволяет ему иметь всегда валидное внутреннее состояние. Приблизительно ту-же технику будет использовать и струкутурный редактор кода программы. Код программы не всегда будет валиден с точки зрения языка программирования, но внутреннее представление (аналог AST) у программы будет всегда валидным.

Леша Маслов: Нет, в IDE ты редактируешь именно текст, и именно он и есть программа. Word не парсит документ, он реагирует на нажатие твоих кнопок, и меняет внутри себя документ. У него один документ, и много способов его показать. А вот IDE на лету строит альтернативное внутреннее представление, и с его помощью делает все эти фокусы с автокомплитом, рефакторингом и пр. Но у него уходит много сил и на этот парсинг текста — ведь ты его ещё набиваешь, он невалиден. И много сил на синхронизацию текстового (основного) и дополнительного (AST) представлений. Ведь любой из них может поменяться (или человек введёт текст или рефакторинг сделает IDE) — и надо синхронно изменить второй. А теперь сложи эти две проблемы вместе — ты набиваешь текст, его не только надо понять (хотя он ещё не закончен), но и надо решить — обновлять AST или подождать... Пишут много кода, кое-как оно начинает работать, и тут бац — новая версия C# или Java. Наша песня хороша, начинай сначала. Собственно, о проблеме парсинга в той статье и пишут. Так вот, её не надо решать методом парсинга. Заодно решается куча других проблем, появляется возможность мета-программирования уровня Lisp-а, но для любых языков, свободное расширение этих языков, создание DSL и embedded DSL. А в перспективе и возможность писать код программы компьютером.

Леша Маслов: Ты и в Word-е не текст пишешь, а редактируешь внутреннее представление документа.Так и тут, ты нажимаешь кнопки на клавиатуре, как-бы текст набиваешь, но при этом ты создаёшь/удаляешь/редактируешь узлы и их свойства.Конечно, будут и специальные кнопки, как в Word-е есть специальные кнопки форматирования текста.Конечно, атрибуты узла можно будет редактировать и в виде диалога, как в Word-е ты редактируешь свойства параграфа в отдельном диалоге.Это уже конкретная эргономика. Одно место будет удобнее редактировать так, как будто-бы это текст. Другое через диалог, или ещё что-то в этом роде. Как удобнее, так и сделают.

Леша Маслов: В чём хитрость-то? Как нарисуешь, так и будет выглядеть. У меня AST явовского кода выглядит как ява. Специально так настраивал, поскольку привык к этому синтаксису. Но тот-же код можно отобразить и в Pascal-подобном виде, и в ML-подобном. Вот есть у тебя AST узел

Ты говоришь, рисовать его, например, как

или так

или ещё как, и видишь на экране соответствующее изображение.Понятно, что это немножно сложнее, надо ещё форматирование (пробелы, переводы строк, цвета и шрифты, скобки для выражения и пр.) рисовать, поэтому спецификация отображения намного полнее, чем то, что я написал. Но ничего невозможного в этом нет. Кстати, эта спецификация выглядит почти так-же, как я написал, потому как она не текстовая, а хранится и редактируется в виде дерева, и аттрибуты (цвета, шрифты, стиль) можно редактировать или в отдельном окне, или делать fold/unfold для видимых элементов.Конечно, проблемы есть. Как были проблемы 20 лет назад с WYSIWYG редакторами. Их, тогда, собственно и не было. Использовали TeX или подобные системы форматирования. Но как-то же справились, сделали Word и прочие WYSIWYG редакторы. Так и структурные редакторы для исходного кода программ сделают. Сейчас делают — MPS (JetBrains), IP (Intentional Software), ну и SymADE. Есть и другие, менее «масштабные». Сделают в конце концов. А вот у парсеров будущего нет. Конечно, текст не пропадёт совсем. Ведь и TeX не пропал, с появлением Word-а. Просто текст будет редактироваться в текстовом редакторе, как и сейчас, а попытки «напиши парсер, который угадает, что на самом деле пишет программист» будут просто не нужны. И 90% программистов будет работать со структурными редакторами, как и сейчас 90% людей пишут в Word-е, а не TeX-е.

Как ты AST нарисуешь, так и будет. Вот, я сейчас понемногу, в демонстрационных целях, делаю IDE для Ant-а, на базе SymADE.Вот как оно выглядит на экране (как в XML ты и сам себе можешь представить): http://mkizub.livejournal.com/

Леша Маслов: Вся его заметка в блоге — о героическом парсинге кода, когда он ещё не дописан до конца (в процессе редактирования). Вот только зачем героически парсить невалидный текст в AST, если можно редактировать прямо AST. MS Word не занимается парсингом вручную редактируемого текста (с разметкой форматирования, вроде XML). Ты просто вбиваешь в документ свой текст, по ходу дела указывая, где у тебя список, или сноска, или подчёркнутое слово. Тебе кажется, что ты редактируешь текст, а на самом деле ты редактируешь некое внутреннее Word-овское представление документа. И это представление тебе Word рендерит на экране.

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

Основная проблема при актуализации этой потенциальности — освоение как идеологии, так и чисто практических приёмов и навыков работы в MPS. Что достаточно сложно сейчас, при том небольшом количестве документации, отсутствии учебников и просто знакомых которые могли бы помочь советом.

;) А в отношении роли MPS в реализации новой парадигмы (способа) программирования есть замечания, или в целом вы это описание считаете верным?

Тема многоэтапного метапрограммирования не раскрыта. Вообще не сказано, что это за зверь. Поэтому наезды на MPS за отсутствие этой самой многоэтапности выглядят совсем странно. Что имеется в виду по гомогенностью мета-программирования тоже загадка.Что до нерасширяемости (и как следствие — ограниченности) — берите аналогичное open-source решение и расширяйте до упаду.Ну и раз вы знаете как не надо мета-программировать — скажите как надо. На вашем блоге есть только примеры на lisp (scheme?). Вы к этому зовёте? А что делать тем, у кого проект уже на мегабайты исходников, и им хочется за счёт мета-программирования облегчить себе дальнейшую разработку? Переписывать всё с нуля на лисп? Не смешно.Что позволяет MPS, так это иметь DSL сразу интегрированный в IDE. Сам по себе DSL может значительно облегчить работу программиста. Естественно, DSL имеет смысл писать только для больших проектов, для мелких быстрее взять язык общего назначения. Но с другой стороны, IDE тоже значительно облегчает работу программиста, и именно для больших проектов. Делать DSL без IDE — это, как правило, не окупается. Что-то вы получаете и что-то теряете, не говоря уже о затраченной работе и времени.MPS предлагает решение, в котором DSL уже интегрировано в IDE, и вы ничего не теряете в производительности и удобстве работы.А что вы можете предложить в качестве альтернативы?

Это то же самое, что сказать, что компилятор C как таковой понимает только printf, но не понимает my_printf. Вы путаете стандартную библиотеку и язык. И, как верно заметил Владимир, кроме языка есть еще «окружающий его способ мышления».Я не понял этой аналогии. Компилятор С не понимает, что такое printf. Он понимает, что такое «вызвать метод с переменным количеством аргументов». Каковым и является printf.В современных компиляторах С/С++ есть расширение его функциональности, которое анализирует аргументы функции printf и выводит предупреждение, если они не соответствуют строке формата. Эти компиляторы понимают функцию printf, но всё так-же не понимают функцию my_printf.Если написать (не знаю, возможно ли) printf на С++ темплейтах — то компилятор всё равно не будет понимать printf, он будет понимать только темплейты.Чтоб среда программирования понимала что-либо, в ней должен быть код, который работает с этим чем-либо. Анализирует, трансформирует и пр. Этот код должен быть либо встроенным в компилятор/среду, либо быть плагином, либо среда должна быть обучаемой.Стандартная библиотека к пониманию кода компилятором отношения не имеет. Она имеет отношение к умению программиста пользоваться данным языком/средой программирования.Как вам удалось прийти к такой оценке? Мне вместо

class BinaryExpr {  Operator op;  Expr left;  Expr right;}

надо будет хранить

class Property {  Symbol sym;  Node data;}class Node {  Property[] properties;}

Народ, я совсем не хочу сказать, что Lisp не плохо подходит для мета-программирования или в нём невозможно сделать то-то и то-то.Я хочу сказать, что для этого вам в Lisp-е надо реализовать свой DSL, и с ним уже работать. Но вы уже будете работать с этим DSL, а не с Lisp-ом как таковым.Можно написать (binary-expr (operator +) (left a) (right 2)), но для Lisp-а это ничего не значит, это просто данные. Значение этим данным будет придано вашим кодом, вашей реализацией DSL-я, а не Lisp-ом. Единственное, что понимает лисп как таковой, это (+ a 2), и всё.Когда я написал, что «смотрел на лисп» — я не имел в виду поиск компилятора. Я имел в виду идеи по реализации мета-программирования.Ну перейду я на lisp с java, и буду хранить дерево кода в виде s-expression — что это изменит? Мне всё равно надо будет написать код, который будет манипулировать этим деревом. Ну сделаю я к декларации аннотацию, по которой моя среда будет делать в редакторе auto-completion, но мне для этого надо всё равно писать код в редакторе, который будет эту аннотацию (конкретно эту) искать и использовать. Будет этот код написан на java или на lisp-е — никакой разницы. У меня нет auto-completion out-of-box в lisp-е.Но может я не правильно понял, что вы имеете в виду под «посмотреть на lisp». Что там ещё можно смотреть, кромеа) какие заложены идеи, иб) использовать его как реализацию языка программирования? Как реализация, он мне точно не подойдёт. У меня сейчас код проекта занимает при компиляции 100Mb в RAM и компилится полторы минуты. На лиспе это будет гигабайт и десять минут (при использовании компилятора, а не интерпретатора).

Чем отличается синтаксис от семантики — это понятно (формальными методами описания и анализа операционной семантики тоже владеем).Не забудте, пожалуйста, рассказать, что Вы, при этом, подразумеваете под семантическим деревом (а то в интернете и литературе есть очень много разных и противоречивых определений).Ну, у меня достаточно нечёткое понимание, чем отличается синтаксис от семантики.Семантика — это значение. Значение может быть (его можно иметь) только для чего-то и кого-то. Скажем, фаза луны может иметь значение для астролога, а для программиста она значения не имеет. Те формальные методы, которые вы упомянули — они придают значение, семантику. И это значение имеет место быть только с точки зрения данного формального метода.А я семантику в SymADE не фиксирую. Соотвественно, фиксированного значения узлы дерева (код программы) не имеют. Это значение появится только когда вы примените к этому коду какой-то алгоритм, который и придаст ему значение. В отличие от, скажем, «семантического web-а».Поэтому под семантическим деревом (графом) я понимаю просто набор данных, удобный для анализа и работы с ним компьютером, очищенный от промежуточной информации.С другой стороны, синтаксис — это прежде всего удобство для передачи данных или их формального представления. То есть тоже, как и семантика — удобство для чего-то. Разница, получается, только в том — для чего удобный. Поэтому я и не могу провести чёткой границы между синтаксисом и семантикой.Лучше я на примерах попытаюсь показать, что я имею в виду.Скажем, в семантическом дереве у нас не нужны (как правило) комментарии, всякого рода import-ы, не нужны даже идентификаторы — мы уже ссылаемся на нужные данные. В нём невозможно нарушение некоего набора ограничений (он типизирован) и так далее.Синтаксическое дерево в SymADE можно получить из семантического с помощью некоего «проектора». Они служат удобству обмена данными или редактирования или просто являются специфическим view семантического дерева.Например, семантическое дерево можно отобразить в набор синтаксических узлов соответсвующих XML-ю. С целью, например, сделать дамп в XML формат. Или с целью поискать в дереве что-то XPath-ом. Или с целью трансформации этого дерева средствами XSLT.Например, семантическое дерево можно отобразить в синтаксическое с целью удобства редактирования или просмотра определённой части информации. Скажем, выражения удобно редактировать как список идентификаторов, констант и операторов. Или аннотации/метаданные (скажем, как в Java или C#) — их может быть удобно отображать в специализированном виде. Скажем, семантически права доступа (private, public, protected, etc) — есть просто аннотация к классу или члену класса. Или throws в java — это тоже аннотация, что такие-то исключительные ситуации могут возникнуть в методе. Но их удобней/принято отображать не в виде @access (PUBLIC) или @throws (IOException). Достаточно сложно написать «отображатель» кода, который семантическое (удобное для компилятора) дерево будет напрямую рисовать в конкретном синтаксисе (java). Удобней и проще сделать проекцию семантического дерева в другое (синтаксическое) и уже его рисовать и редактировать. Так-же этот проектор может автоматически преобразовывать ссылки на декларации в виде простых имён или квалифицированных имён (в зависимости от того, imported это имя или нет) и так далее.Проекции работают в обе стороны. То есть, после того, как мы сделали проекцию нашего семантического дерева в дерево XML (DOM) и изменили данные в XML — автоматически изменения передаются в семантическое дерево. И изменения в семантическом дереве автоматически передаются и меняют дерево DOM. Можно и наоборот, проецировать синтаксическое дерево в семантическое, что и происходит при редактировании синтаксического дерева, когда вы вставляете (paste) кусок синтаксических данных в код. Или когда вы сделали проекцию в XML, сделали дамп в текстовый файл, а потом читаете этот текстовый файл и из полученного DOMа воссоздаёте семантическое дерево.Но вот в таком виде SymADE будет работать с деревом/графом кода.

Но возможность трактовать DSL-и внутри системы как LISP-деревья (хотя концептуально они как бы не являются LISP деревьями) позволяет применить гомогенное метапрограммирование внутри системы, чем в разы сократить сложность разработки/поддержки и даже обучения.Не понимаю как, как их можно «трактовать».Понятно, что они — лисповское дерево. А если я программирую на Java — то они объекты Java. И так далее.Но я не могу трактовать объекты Java как код программы на Java.А чтоб трактовать DSL как лисповское дерево — оно и должно быть лисповским деревом, иначе оно просто данные, такие-же, как объекты в Java.Считаете ли вы «кодирование понятий индеском» единственным способом записи DSL в виде S-выражений? Конечно нет.В Lisp-е данные и код имеют один и тот-же формат, они не отличимы. Потому менять код программы мы может точно так-же как менять данные. Это и порождает возможность мета-программирования в Лиспе. Но поскольку Лисп-машина интерпретирует запись программы как дерево с узлом «операция» и под-узлами «аргументы», то единственный способ создать код — это использовать индексированние аргументов. Точно так-же как при вызове методов в C мы пишем foo (x, y, z) — аргументы понимаются по их позиции, индексу, функция не переставляет аргументы как ей удобней (не интерпретирует это как foo (z, x, y)).Мы можем в лиспе a+2 записать как (+ a 2) — тогда это будет исполняемый код. А если для удобства работы DSL-компилятора этот код записать как (binary-expr (operation +) (left a) (right 2)) — то это уже просто данные, это не исполняемый код. Можно их «выполнить» написав какой-нибудь (eval-expr (binary-expr (operation +) (left a) (right 2:), но точно так-же можно «выполнить» и DSL в виде Java-объектов.Фактически, если вы не используете обращение к узлам дерева DSL-я по индексу — то вы уже создали свой DSL язычёк для работы с DSL. Это может даже не рефлексироваться, поскольку создание DSL-ей в лиспе очень легко делается.Какие проблемы возникают? Очень просто. Их даже невозможно унаследовать — это или фиксированные списки (массивы) где понятия индексированы, либо уже что-то более сложное — хэш-таблица, объект и так далее, но это не лисповское дерево кода. Ну и остальные прелести — если я добавил новый атрибут, то все индексы поехали, и надо править всю программу. И загрузить старый код уже нельзя и пр.Что же даёт такую лёгкость в определении новых DSLей в лиспе? Её даёт тот факт, что вы не описываете полную семантику новых понятий. Вы описываете как новое понятие трансформировать в существующие понятия. И всё.Зачем нужно мета-программирование? Чтоб облегчить разработку программ. Но это только один из способов.Как ещё разработку можно облегчить? Есть несколько путей.а) Создать более высокоуровневый язык (DSL — частный случай). Тогда за счёт работы с более высокоуровневыми абстракциями программу писать и сопровождать проще. Компьютер автоматизирует трансляцию с высокоуровневых абстракций в низкоуровневые. б) Облегчить работу программиста (IDE — частный случай). Компьютер выполняет множество рутинных операций (по редактированию, по анализу кода, поиску связей в проекте, компиляцию в бэкграунде, рефакторинг и многое другое), автоматизируя этот аспект создания программы.в) Облегчить проектирование (UML — частный случай) г) Облегчить анализ констрайнтов (статическая типизация — частный случай) И так далее."Окончательным решением" этой задачи (автоматизации программирования) является, очевидно, написание кода самим компьютером. Устранение кодировщика. Человек (программист) формулирует задачу, и в диалоговом режиме её передаёт компьютеру, а тот внутри себя чего-то думает, и выдаёт исполняемую программу.Так вот, чтоб это «окончательное решение» вообще стало возможным — надо, чтоб компьютер умел, мог, имел возможность манипулировать семантическими понятиями. В том числе и создавать и менять их. Компьютер должен «понимать», что значат те или иные действия в программе.Это не искуственный интеллект, это не создание новых знаний. «Понимать» — не значить уметь творить. Впрочем, это отдельный большой разговор.При мета-программировании в лиспе вы даёте компьютеру ровно одно понимание вашего нового семантического понятия — он его может сконвертировать в другие (уже имеющиеся) понятия. Задать такую конвертацию — сравнительно просто. Именно поэтому мета-программирование в лиспе так просто. И вообще оно очень просто (если есть в языке или другом средстве программирования возможность трансформации одних понятий в другие).Но чтоб добиться настоящего понимания компьютером этого нового понятия, чтоб он мог им свободно оперировать, и в конечном итоге — автоматизировать кодировние — надо задать очень много информации об этом новом понятии. Как минимум на порядок, а то и на два порядка больше, чем просто трансформация в другие понятия.Скажем, что умеет «умное» IDE в отношении имеющихся в языке программирования понятий? Оно их умеет отображать, оно умеет автокомплит и прочую помощь в редактировании, оно умеет рефакторинг, оно умеет анализ на потенциальную ошибочность и так далее. Но зато это позволяет облегчить процесс кодирования.А гипотетическая среда разработки, которая сможет сама кодировать программу — должна содержать ещё больше информации, ещё больше «понимания» для каждого узла дерева. Зато она максимально облегчит процесс кодирования.Я думаю, что отчасти процесс описания понятий в MPS вам показался таким переусложнённым именно по той причине, что вы должны задавать намного больше информации об узле, чем это вам необходимо (по сравнению с лиспом). И это так и есть, особенно если вы пишите этот DSL для частного использования. С другой стороны, если этот DSL действительно пользовать много — то вложения в информацию внесённую в MPS со временем окупятся. (другая часть проблемы — отсутствие у нас навыков, и даже документации по работе с их системой).Есть ли способ решить эту проблему? То есть можно ли сделать среду автоматизации программирования, которая не требовала-бы внесения большого описания для временных и частных понятий (как в лиспе — задал трансформацию и всё), и в то-же время позволяла задавать их в полном объёме для широко используемых (как в IDE и даже больше)? Я верю, что есть. И этот способ — поэтапное задание информации о новых понятиях.То есть такая среда должна позволять, например, просто описать новое понятие в виде «имя» и «набор атрибутов», выбрать один из стандартных способов его использования — и на этом всё. Стандартный способ — это либо трансформация в существующие понятия, либо дамп в XML (если мы делаем язык для описания какой-то конфигурации), либо интерпретацию (evaluation) себя как выражения и так далее.Среда должна сама худо-бедно суметь отобразить это понятие, помогать в редактировании (вроде автокомплита), обеспечить реализацию стандартных способов использования (трансформацию, интерпретацию и пр.).А уже потом она должна позволять, по мере надобности, дополнять «понимание» собой этого семантического понятия.Удобное отображение. Рефакторинг. Отношения с понятиями более высокого уровня абстракции. Частные случаи реализации и т.п. и т.д.Особо продвинутая среда программирования сможет в будущем складывать эти описания в некую «базу знаний» и делать из этой базы «выводы». В конечном итоге она станет настолько полной, что сумеет сама писать конкретный код на основании диалога с программистом. Но это ещё очень не скоро, конечно.Про разделение синтаксиса и семантики — попозже напишу.

В таком случае это не гомогенное мета-программирование, как я его понял. Вы работаете с лиспом, генерите дерево лиспа, и из него генерируете IL. А что вы делаете, когда в дереве лиспа используются contionuation-ы? Их в IL не запихнёшь, там совсем другая структура.Что до лиспа в плане tree rewriting. Конечно я смотрел в его сторону. В итоге он мне не подошёл.Он сам по себе — компромис. Узлы в его дереве представлены как списки, и понятия кодируются индексом в этом списке. В (/ a 2) первый элемент кодирует операцию (деления), второй кодирует левый аргумент и третий правый аргумент. Аргументов не может быть больше 3, это ошибка (операция деления не определена). То есть семантическая часть богаче того, что записано в данных. Это приводит к куче проблем при работе с новыми семантическими понятиями (у компилятора). Для него лучше бы представить это как «BinaryExpr (Operator op, Expr left, Expr right) », но подобный многословный синтаксис будет крайне неудобен для программиста. Вот этот компромис между удобством для компилятора и удобством для программиста в лиспе и решён таким образом.А поскольку я изначально делаю IDE с возможностью произвольного отображения дерева, то у меня самой этой проблемы нет. Я могу отображать дерево с любой степенью детализации. Могу и как (/ a 2), могу как BinaryExpr (/, a, 2), могу как /12. И точно так-же я могу отображать код, который занимается трансформацией дерева. Альтернативные варианты (вроде квази-цитирования) мне тоже не нужны.Конечно, такой подход имеет и свои недостатки. Точнее, один — надо отказаться от текстового представления программы. Даже автоматическая генерация парсера и pretty-printera не помогут, поскольку в дереве могут встречаться практически любые узлы. А у не-текстового представления есть громадный недостаток — неудобно редактировать код. Точнее, не то чтоб совсем неудобно. Это больше похоже на работу в старом vi (или совсем старом edt с pdp11), при редактировании вы оперируете не текстом, а словами, фразами, постоянно переключаетесь между разными режимами редактировния. Для редактирования декларативных DSL — это не большая проблема, после небольшой практики оно так-же удобно, как редактирование текста (а теоретически — даже более удобно). Вот с выражениями — проблема. Она и в MPS есть (практически нерешённая). Я нашёл хороший вариант её решения — однозначность преобразования между деревом и списком обеспечивается заданным приоритетом операторов, и можно «на лету» преобразовывать выражения в список и обратно в дерево, для удобства редактирования. Это достаточно хорошо работало у меня, хотя и не без проблем. Эти проблемы, и ещё некоторые, привели меня сейчас к идее полного разделения семантического и синтаксического деревьев. То есть это два отдельных дерева, и синтаксическое генерируется из семантического когда нужно отобразить особо изощрённым образом этот код, или для удобства редактирования и т.п. Такой себе projection из одного дерева в другое, при этом они остаются связанными, и изменения в одном автоматически (или специальным кодом) транслируются в другое дерево. Над чем я сейчас и работаю.Как закончу — так это и будет публичная бета-версия для SymADE. И ещё надо доделать IDE, чтоб можно было полностью его на самом себе разрабатывать.Релиз будет когда документация будет написана: (

Почитал про гомогенность. Я бы так сказал — предвзятая точка зрения. С большим числом необоснованных (и вообще говоря — ложных) утверждений.Only homogeneous systems can be multi-level — с чего бы это? На MPS разве нельзя создать язык, который будет генерировать программу на другом языке, из которого будет генерироваться программа на третьем языке? Only in a homogeneous meta-system can a single type system type both the meta-language and the object-language -, а кто мешает использовать одну и ту-же систему типов для разных языков в MPS? Больше того, гомогенная мета-система вынуждает использовать только одну систему типов, а MPS позволяет использовать разные. (я не очень знаю нынешнее состояние дел в MPS, позволяют ли они это сейчас практически, но теоретически к этому нет никаких препятствий).И так далее.В конечном итоге у гомогенной среды мета-программирования есть фатальный недостаток, который я упомянул в первом ответе. Она привязывает вас к определённой среде исполнения. Будь то Forth, Lisp или что-то подобное. Её нельзя использовать для другой среды исполнения, и это фатально. MPS, SymADE — позволяют отвязать мета-программирование от языка/программы/модели исполнения. Это мета-программирование как таковое. Вы его можете применить к чему угодно, к любому языку.мы говорим о различной расширяемости. Возможность поправить исходники компилятора — это совсем не та расширяемость языка программирования, которая нужна реальным его пользователямУ пользователей разные потребности, кому-то нужна большие возможности, кому-то нет. В одном неплохом языке программирования вполне было достаточно #define-ов. Многие сейчас считают, что и template-ов достаточно. Кто определяет границы возможностей, предоставляемых пользователю? Вы склоняетесь к гомогенному мета-программированию, и тем самым накладываете огромное число ограничений, но вы их не замечаете. Вам для работы вполне достаточно, и вы считаете, что именно это реальным пользователям и надо.В моей работе я сталкиваюсь с двума достаточно различными типами задач. Первая — это расширение языка, на котром пишу код. Дополнительные проверки, генерация кода, более удобный синтаксис и так далее. Эта часть задач отлично решается в гомогенной среде. Собственно, именно с этого я и начинал, и до сих пор считаю, что возможность расширения языка (в том числе и создение embedded DSL) — это более правильный путь решения для бОльшей части проблем решаемых мета-программированием, чем LOP подход. Но сейчас я пишу IDE, и всё больше превалирует другий тип задач, который требует создания отдельного, ни на что не похожего, не имеющего ничего общего с основным языком DSLя. Это чисто декларативные языки, их даже компилировать ни во что не надо, это скорее удобные языки для описания определённой конфигурации. Скажем, тот-же язык для задания отображения и редактирования узлов дерева. Или по работе я сейчас использовал SymADE для создания удобного редактора для километровой конфигурации хранящейся в XML-е. Или я сейчас работаю над bidirectional отображением одного дерева в другое (чтоб разделить семантическое и синтаксическое деревья программы). В них ничего не надо генерировать или компилировать в исполняемый код. Это банальная конфигурация. И для этих задач LOP работает много лучше eDSL.Я так полагаю, что Сергей Дмитриев пришёл к своим идеям LOP и MPS из проблемы написания IntelliJ IDEA. Вы и я пришли к мета-программированию из проблемы кодогенерации и расширения/адаптации языка под конкретную задачу. Но в жизни нужно и то и другое. Поэтому я не считаю возможным решать за пользователей, что им нужно, а что нет.В случае MPS, она, к огромному сожалению, меркнет на фоне недостатков (стоимость разработки и сопровождения самих DSL в переусложнённой среде) — ага, мне тоже их IDE не нравится. Я так и не смог понять как в ней работать. И всё это помноженное на отсутствие внятной документации и возможности покопаться в исходниках, чтоб понять если что не понятно. Но я читал отзывы одного парня, который устроился к ним на работу. Он пишет — да, входить тяжело, но когда рядом сидит специалист и всегда может помочь — то это как-то восполняет недостаток в документации. А когда уже войдёшь и освоишься — то работать в MPS очень легко и просто. И я ему верю — когда ты уже знаком с этим энным числом необходимых (и достаточно простых) DSLей, специально заточенных под решение этих задач — то дальше решать эти задачи уже просто и легко.В случае же метапрограммирования, Вы можете объявить подмножество вашей прежней среды разработки как target платформу. — этого я совсем не понял. Зачем мне выделять подмножество, если мне наоборот надо расширить функциональность? Может я не так объяснил...Вот я пишу компилятор. У меня постоянно стоит задача tree rewrite-а. Заменить одни узлы дерева на другие. Иметь возомжность пройти по всем дереву и найти нужные узлы. И так далее. Понятно, что задачи специфические, и никто базовый язык под них не приспосабливал. Мне хорошо — я пишу на своём языке, компилятор от которого у меня есть. Я взял и добавил нужные синтаксические и семантические понятия, генерирую кучу кода, мета-программированием решаю свои задачи.А как быть людям, у которых тоже большой проект (на java или c# или вообще на С), и которым тоже хочется вставить кодогенерацию, дополнительные проверкии и вообще задействовать все прелести мета-программирования? Вот одна контора (в которой у меня друг работал) настолько замучалась с null pointer exception в яве, что написала свой почти полноценный компилятор, в котором было практически одно расширение — доказательство на уровне языка, что нулевой указатель не попадётся.Вот этим людям — им как быть с мета-программированием? Вот совсем простой пример. Раньше не было в Java enum-ов. Предположим, кому-то они тогда очень понадобились. Задумали они использовать мета-программирование, и определить такое понятие как enum, и зажить счастливо. Не хотите enum-ы, возьмите pattern-matching. У них уже есть десятки мегабайт кода. На java. И если бы у них был этот pattern-matching, размер кода сократился бы в несколько раз, и они бы смогли и дальше над ним работать, а не мучаться багами.

За изменением синтаксиса, который как китайский, следить не нужно — его можно настраивать под себя.За вводом новых понятий, разумеется, следить надо. Но чем это принципиально отличается от слежения за вводом новых понятий и соглашений в большом проекте? Ты точно так-же не сможешь взять исходники большого проекта и сходу их все понять и начать исправлять и развивать дальше. В любом случае тебе надо будет выучить API, структуру проекта, особенности реализации, внутренние соглашения проекта.Но одно дело, когда эти внутренние соглашения существуют лишь в мозгах разработчиков (даже если они есть в документации — поди найди их в ней), а другое дело, если среда разработки содержить знания об этих соглашениях и умеет контролировать их соблюдение, и наконец — просто поделиться этим знанием с человеком, который только начал работать над проектом.