Мне тоже не сильно нравится термин, но за неимением ничего лучше пользуемся. Это тупой перевод с code generation. DSL вообще лучше не переводить, а то получится какая-нибудь ПОЯ. По поводу шаблонного кода — я пожалуй не соглашусь. Язык может быть вполне ничего и позволять разные возможности абстракций, но заворачивание в абстракции может сильно усложнить код. А в шаблонный код прост.
Вы явно в теме :) Правда я не использую xml, а пишу обычно свой синтаксис, который более читаем, но по смыслу получаются похожие вещи. «чудовищные возможности по массовой модификации» — я рассматриваю это как плюс. Проблема тестирования конечно стоит. Есть соблазн сгенерировать тесты, но это бессмысленно, для автоматического кода нужны ручные тесты. Я обычно полагаюсь на качество тестирования генератора. Пишу тестовые файлы на DSL с максимальным покрытием граничных случаев. И пишу ручные тесты для них. Если эту часть хорошо протестировать, то дальше можно считать что правильный генератор выдает правильный код. Правда тут еще может быть зависимость от ручного кода.
Да, про опыт. В первом проекте написал DSL для бизнес-настроек системы. Из DSL сгенерил схему хранения, сериализацию в сетевые объекты, всякие контейнеры, утилитные функции, таблички, редакторы на гуе. У нас в проекте куча разных языков, и от этого полезность генеренного кода повышается. Это был первый опыт. Потом я вошел во вкус и предложил расширить DSL до описания всех данных и всех потоков данных в системе, и соответственно сгенерить всю низкоуровневую ерунду, а рукописный код выкинуть. Не дали :) Но пока план остался, думаю в следующем году доделаем. Во втором проекте сразу пробил DSL. Написал синтаксис, потом взялся за генераторы. Так как предметная область немного другая, и язык охватывает больше аспектов, то пришлось попотеть в плане написания кодогенераторов. Первую версию выкинули :) и написали новую. Но сейчас просто сказка в плане удобства дальнейшей разработки, весь низкоуровневый код генерится и легко меняется. Третий проект — тут уже без вопросов. DSL, кодогенерация, и немного рукописного кода. Все три проекта живые и продолжаются.
1) Нам не нужно описывать всю реальность, нам надо выделить существенное и отбросить несущественное. Поэтому нам нужны абстракции.
2) Я как раз про специальное решение для конкретного случая
3) «Кодогенерация — круто» — согласен, «но только на начальном этапе» — на любом
4) все делать и не обязательно. Задачи делать «все» не стоит.
Это вообще просто. Синтаксические ошибки проверяет xtext. Кроме того есть возможность написания кастомных валидаторов, которые прописывают дополнительные ограничения, которые сложно выразить формальным определением языка. Этим свойством я активно пользуюсь. Например определена некая сущность у которой есть поле типа Enum (A, B) и второе типа список (чего-нибудь). Из предметной области мы знаем, что если в первом поле A, то в списке должно быть только один элемент. Такое сложно выразить в формальном определении языка, а добавить валидатор просто, да еще понятную подсказку в эклипс вывести. Ну и естественно тесты. Без них никуда.
«Вкратце, он говорил о сложной поддержке и рефакторинге кода DSL» — наверное не соглашусь. На DSL описывают высокоуровневые объекты из предметной области. Если предметная область не меняется, то DSL тоже сильно не меняется. Конечно, в процессе разработки добавляются некоторые атрибуты, но это скорее развитие, а не рефакторинг. Грубо говоря, мы увеличиваем (или уменьшаем) детализацию, до той степени которая нам нужна. Что касается кодогенераторов, то тут те же правила, что и для обычного кода — модульность и покрытие тестами — легко рефакторить, макароны — сложно.
Да, MPS — это, так сказать, конкурент Eclipse Xtext. Я пробовал его тоже, но не пошло. Есть две проблемы. Первая — очень сложно писать кодогенератор, все совсем не очевидно и запутано. Второе — редактирование AST напрямую. Без среды это не сделать никак, а одна из фишек DSL, что файлы могут редактировать даже люди, далекие от программирования. И заставлять их ставить идею — это слишком.
По второму пункту. Я думаю сделать несколько практических постов на каком-нибудь интересном примере.
2) Я как раз про специальное решение для конкретного случая
3) «Кодогенерация — круто» — согласен, «но только на начальном этапе» — на любом
4) все делать и не обязательно. Задачи делать «все» не стоит.
По второму пункту. Я думаю сделать несколько практических постов на каком-нибудь интересном примере.