mayton,

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

mayton,

на мой взгляд, в лиспе нет особой разницы между DSL и фреймвоками. В Java иногда напрягает, что нельзя переопределять операторы как в C++ или что нет расширений классов как в C# или что для Stream API нет синтаксиса как у LINQ, и приходится писать больше кода. Но, с другой стороны, какая разница какой синтаксис используется. Наверное x + y выглядит лучше, чем x.add(y), это может быть важно для пользователей, если они сами пишут какие-нибудь скрипты или спецификации. А для разработчиков в принципе не так важно.

Хотя, я конечно зря смешиваю эти понятия. DSL без специфического синтаксиса это уже не DSL. Мне лично удавалось продвигать только стандартизированные DSL типа OCL, QVTo, MOF M2T. И то, с трудом, люди скорее готовы использовать JavaScript или Lua. Потому что для JavaScript много вакансий и специалистов. Один фиг, что из этих специалистов ровно ноль человек писали какие-нибудь преобразования моделей на JavaScript, и опыт во фронте или в бекенде им никак не поможет. А специальный DSL для преобразования моделей осваивается за день и позволяет делать всё гораздо проще, не позволяет писать лапшакод.

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

Вряд ли получится вау-эффект... У меня была такая задача (я её описывал уже немного выше).

Нужно было сделать редактор моделей данных, который поддерживает разные нотации. В нём можно рисовать ER-модель, UML диаграммы классов, Anchor-модели и т.п. Чтобы всё это работало было нужно следующее:

1) Entity-классы с JPA-аннотациями для хранения моделей
2) Java-классы для работы с моделями (реализуют интерфейс org.eclipse.emf.ecore.EObject), они по структуре похожи на Entity-классы, но лучше их не смешивать
3) Мапинги 1->2
4) Мапинги 2->1
5) DTO-классы с Jackson-аннотациями. У этих классов только вертикальные ссылки на дочерние DTO классы оставлены как ссылки. А горизонтальные ссылки заменены на поля, хранящие идентификаторы объектов, на которые ссылаемся. Это нужно потому что JSON-документ - это дерево, а не граф и (де)сериализация существенно упрощается, если горизонтальных ссылок нет. Конечно можно попробовать всё это объединить в одних классах, но получится жесть, проще всё это разделять
6) Мапинги 5->2
7) Мапинги 2->5
8) JavaScript-классы для самого редактора диаграмм, которые умеют (де)сериализироваться в JSON

Сами схемы данных описывались на языке Xcore - это гибрид Ecore и Xtend. Вот, пример, xcore-файла из другого проекта. Там ничего особенного, этот язык позволяет описывать классы, интерфейсы, наследование, атрибуты, ссылки, операции. Конечно же никакие JPA-аннотации, Lombok аннотации и т.п. в этих Xcore-файлах не нужны, они добавляются кодогенераторами в зависимости от того какая именно это ссылка (один-ко-многим, многие-ко-многим) и т.п. Автоматически добавляются всякие аннотации типа @JsonSubTypes и т.д.

У меня было 50 Кб этих xcore-файлов. 100 Кб шаблонов на языке Xtend для генерации кода. И из всего этого генерилось 3,5 Мб исходников (пункты 1-8).

Один плюс такого подхода, что пишется просто меньше кода, не нужно писать однотипный код. Те же JPA или Jackson аннотации обычно пишутся по какой-то одной схеме и их проще сгенерить, чем проверять что где-то не забыл что-то добавить.

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

Ещё одна штука, которую я делал в этом проекте - это описывал грамматику разных языков, например, SQL на языке Xtext (это тоже своеобразный DSL типа языка описания грамматик в ANTLR), и потом генерил из неё JavaScript-код для парсинга, сериализации и автодополнения SQL-выражений на клиенте.


В Лиспе я думаю, что подход был бы примерно такой же. Я описал бы схему данных без всяких аннотаций и т.п. Определил бы какой-нибудь макрос типа define-domain-class, который получал бы на вход название класса, перечень атрибутов с типами, ссылки на другие классы с указанием множественности и обязательности, может быть операции какие-нибудь. А внутри этого макроса уже спрятал бы всякие вещи для сохранения этих данных в базу, сериализации в JSON и т.п. Что-нибудь типа: