Где кончается SELECT?

Тема, которая сегодня неожиданно возникла, удивила и заставила задуматься о вещах, которые ранее воспринимались совершенно утилитарно.

Ну кто не пользовался оператором SELECT? - Все пользовались. А вот где он кончается и начинается следующий? ;-)

То, что я скажу далее — очень спорно, об этом нигде (в известных мне местах) не говорится, и далее следует исключительно мнение автора, т. е. моё личное.

Предложил своим студентам попробовать FireMonkey

Программа для V-го курса предусматривает разработку интерактивного приложения с использованием Delphi. Там "многоходовая комбинация", фактически, разработка прототипа информационной системы, на примере которой иллюстрируются реальные задачи. Построение элементов управления по метаданным БД, динамическая компоновка форм из фреймов, загружаемых отдельно, стыковка окон (docking) содержащих представления таблиц на рабочем столе (вкладка, подобно вкладке браузера) и интерактивная установка отношений master-detail меду ними, сохранение и загрузка рабочих столов через фабрики...

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

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

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

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

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

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

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

О Fluent-интерфейсах

В контексте недавно состоявшегося обсуждения (здесь, и ранее, здесь) у меня возникли основания порассуждать для себя об области применимости fluent-техники.

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

Но достаточно быстро стало понятно, что техника подходит не для всего на свете.

Собственно, «крайние» мысли на этот счёт изложены ниже.

Собственно, вопрос. Не стоит ли смотреть на fluent-технику как на DSL?

Она выглядит как DSL и правила работы с ней напоминают правила работы с DSL.

Только DSL в контексте существующего языка.

Вероятно, это не просто увидеть, поскольку обычно DSL реализуется средствами другого языка.