Призрак ходит по Европе

Заболел, не могу спать, в голову лезет муть всякая - теория категорий в применении к оптимальным тактикам выкашивания противников на Uptown TDM. Там уровень такой прямоугольный, блин, с базами в противоположных углах, у меня всегда на больную голову или во сне это ассоциируется с диаграммами коммутации.

Так вот, о чем это я. В массах в последнее время витает некая идея. Вкратце я бы ее сформулировать: "встроить правильную СУБД с преферансом и гимназистками прямо внутрь рунтайма функциональных языков" и поиметь на халяву сразу множество вещей.

Во-первых, уйти от долбаного SQL, который чем дальше, тем больше расползается в разные стороны в разных СУБД, но при этом не потерять ничего из его функциональности и лаконичности.

Во-вторых, иммутабельность вообще не помешало вынести бы на уровень базы данных. Я уже просто не упомню, сколько раз мне приходилось делать версионность объектов в базе, т.е. при изменении сохранять предыдущую версию. И это при том, что сами сервера(нормальные, само собой) внутри используют версионность для поддержки транзакций, снапшоты там всякие и сегменты отката и предыдущие версии записей и сборка мусора. Для изменяемых объектов (в опердени, например, первичка в текущем рабочем периоде) придется выставлять некий фронт-енд, где можно менять объекты невозбранно, а потом по факту завершения работы с ними спихивать в неизменяемые.

В-третьих, можно наконец-то будет использовать вывод типов и метапрограммирование и прочие навороты для того, чтобы делать нормальную миграцию системы, при изменении структуры данных(схемы БД). Просто база не даст закомитить DDL-транзакцию, если при этом что-нибудь сломается и типы не сойдутся.

И в четвертых, можно будет использовать метациклические модели для данных, т.е. можно будет в описание типа объекта впихнуть дополнительные поля и использовать их для всякой там кодогенерации.
При этом, как я себе представляю нормальный интерфейс к этому - и изменение структуры данных и работа с данными должна делаться в некоем двумерном интерфейсе. Обычной таблицы, честно говоря, не хватает - например, непонятно как в ней отобразить корректно список объектов какого-нибудь алгебраического типа с несколькими конструкторами разной структуры.
Т.е. выглядит примерно так: подключаемся к базе, открываем таблицу "описания типов", лезем в тип, добавляем поле, конструктор, чорта лысого, пытаемся сохранить, оно нам показывает список функций, которые сломались, делаем для них адаптеры, для перехода между версиями типа пишем функции миграции, сохраняем. Потом открываем интерфейс к множеству объектов типа (в точно таком же виде, как работали только что с множеством описаний типов) и работаем с ним.

Двумерный интерфейс нужен по той причине, что линейное писание кода уже не соответствует задачам. У нас практически все структуры данных - дву- и больше-мерные, результат на экране тоже двумерный(если не трехмерный и выше), а мы до сих пор используем инструменты с одномерным текстом.
Причина непопулярности другого подхода в том, что дебилоиды с UML-инструментами загадили мозг людям, у них сразу отказ от текстового исходного кода ассоциируется с мучительным мышевозением в Rational Rose. Хотя можно же сделать нормальный клавиатурный интерфейс, с переходом к мыши, только в случае необходимости.