Куда может завести "свой DSL". Часть 3. Резюме.

Как я сказал в предыдущей части, неразрешимых проблем с языком не было. Более того, его пытались даже использовать для написания триггеров уровня приложения, целей экспорта данных из наших систем в другие.
Но шло это всё с большим "скрипом", поскольку "отчётная заточенность" языка давала о себе знать на каждом шагу.
Внимательный читатель сразу вскинется: "Позвольте! Так и должны быть проблемы! Ведь DSL в силу своей domain-specific совершенно не предназначен для решения задач из другой предметной области!" и, возможно, в запале добавит: "Для другой предметной области нужен другой DSL!"

Куда может завести "свой DSL". Часть 2. Язык.

Предыдущую часть истории я закончил словами о том, что язык удовлетворяющий предъявляемым к нему требованиям был создан.
Правда, я забыл упомянуть одну существенную деталь.
Мы стремились к тому, чтобы язык был простым.
Это было действительно важно, поскольку мы и сами не хотели усложнять себе жизнь, и пользователю хотели дать инструмент и "монстра" создавать не хотели.

Куда может завести "свой DSL". Часть 1. Контекст.

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

Здесь, думаю, следует оговорится, что я имею ввиду, когда говорю «свой собственный» DSL.
Нет, речь идёт не о текучих интерфейсах и не о всепроникшем XML.
Речь идёт о настоящем языке, для которого реализован собственный интерпретатор, или построенного на базе приспособленных для этой цели Forth/Lisp.