![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Призрак ходит по Европе
Заболел, не могу спать, в голову лезет муть всякая - теория категорий в применении к оптимальным тактикам выкашивания противников на Uptown TDM. Там уровень такой прямоугольный, блин, с базами в противоположных углах, у меня всегда на больную голову или во сне это ассоциируется с диаграммами коммутации.
Так вот, о чем это я. В массах в последнее время витает некая идея. Вкратце я бы ее сформулировать: "встроить правильную СУБД с преферансом и гимназистками прямо внутрь рунтайма функциональных языков" и поиметь на халяву сразу множество вещей.
Во-первых, уйти от долбаного SQL, который чем дальше, тем больше расползается в разные стороны в разных СУБД, но при этом не потерять ничего из его функциональности и лаконичности.
Во-вторых, иммутабельность вообще не помешало вынести бы на уровень базы данных. Я уже просто не упомню, сколько раз мне приходилось делать версионность объектов в базе, т.е. при изменении сохранять предыдущую версию. И это при том, что сами сервера(нормальные, само собой) внутри используют версионность для поддержки транзакций, снапшоты там всякие и сегменты отката и предыдущие версии записей и сборка мусора. Для изменяемых объектов (в опердени, например, первичка в текущем рабочем периоде) придется выставлять некий фронт-енд, где можно менять объекты невозбранно, а потом по факту завершения работы с ними спихивать в неизменяемые.
В-третьих, можно наконец-то будет использовать вывод типов и метапрограммирование и прочие навороты для того, чтобы делать нормальную миграцию системы, при изменении структуры данных(схемы БД). Просто база не даст закомитить DDL-транзакцию, если при этом что-нибудь сломается и типы не сойдутся.
И в четвертых, можно будет использовать метациклические модели для данных, т.е. можно будет в описание типа объекта впихнуть дополнительные поля и использовать их для всякой там кодогенерации.
При этом, как я себе представляю нормальный интерфейс к этому - и изменение структуры данных и работа с данными должна делаться в некоем двумерном интерфейсе. Обычной таблицы, честно говоря, не хватает - например, непонятно как в ней отобразить корректно список объектов какого-нибудь алгебраического типа с несколькими конструкторами разной структуры.
Т.е. выглядит примерно так: подключаемся к базе, открываем таблицу "описания типов", лезем в тип, добавляем поле, конструктор, чорта лысого, пытаемся сохранить, оно нам показывает список функций, которые сломались, делаем для них адаптеры, для перехода между версиями типа пишем функции миграции, сохраняем. Потом открываем интерфейс к множеству объектов типа (в точно таком же виде, как работали только что с множеством описаний типов) и работаем с ним.
Двумерный интерфейс нужен по той причине, что линейное писание кода уже не соответствует задачам. У нас практически все структуры данных - дву- и больше-мерные, результат на экране тоже двумерный(если не трехмерный и выше), а мы до сих пор используем инструменты с одномерным текстом.
Причина непопулярности другого подхода в том, что дебилоиды с UML-инструментами загадили мозг людям, у них сразу отказ от текстового исходного кода ассоциируется с мучительным мышевозением в Rational Rose. Хотя можно же сделать нормальный клавиатурный интерфейс, с переходом к мыши, только в случае необходимости.
Так вот, о чем это я. В массах в последнее время витает некая идея. Вкратце я бы ее сформулировать: "встроить правильную СУБД с преферансом и гимназистками прямо внутрь рунтайма функциональных языков" и поиметь на халяву сразу множество вещей.
Во-первых, уйти от долбаного SQL, который чем дальше, тем больше расползается в разные стороны в разных СУБД, но при этом не потерять ничего из его функциональности и лаконичности.
Во-вторых, иммутабельность вообще не помешало вынести бы на уровень базы данных. Я уже просто не упомню, сколько раз мне приходилось делать версионность объектов в базе, т.е. при изменении сохранять предыдущую версию. И это при том, что сами сервера(нормальные, само собой) внутри используют версионность для поддержки транзакций, снапшоты там всякие и сегменты отката и предыдущие версии записей и сборка мусора. Для изменяемых объектов (в опердени, например, первичка в текущем рабочем периоде) придется выставлять некий фронт-енд, где можно менять объекты невозбранно, а потом по факту завершения работы с ними спихивать в неизменяемые.
В-третьих, можно наконец-то будет использовать вывод типов и метапрограммирование и прочие навороты для того, чтобы делать нормальную миграцию системы, при изменении структуры данных(схемы БД). Просто база не даст закомитить DDL-транзакцию, если при этом что-нибудь сломается и типы не сойдутся.
И в четвертых, можно будет использовать метациклические модели для данных, т.е. можно будет в описание типа объекта впихнуть дополнительные поля и использовать их для всякой там кодогенерации.
При этом, как я себе представляю нормальный интерфейс к этому - и изменение структуры данных и работа с данными должна делаться в некоем двумерном интерфейсе. Обычной таблицы, честно говоря, не хватает - например, непонятно как в ней отобразить корректно список объектов какого-нибудь алгебраического типа с несколькими конструкторами разной структуры.
Т.е. выглядит примерно так: подключаемся к базе, открываем таблицу "описания типов", лезем в тип, добавляем поле, конструктор, чорта лысого, пытаемся сохранить, оно нам показывает список функций, которые сломались, делаем для них адаптеры, для перехода между версиями типа пишем функции миграции, сохраняем. Потом открываем интерфейс к множеству объектов типа (в точно таком же виде, как работали только что с множеством описаний типов) и работаем с ним.
Двумерный интерфейс нужен по той причине, что линейное писание кода уже не соответствует задачам. У нас практически все структуры данных - дву- и больше-мерные, результат на экране тоже двумерный(если не трехмерный и выше), а мы до сих пор используем инструменты с одномерным текстом.
Причина непопулярности другого подхода в том, что дебилоиды с UML-инструментами загадили мозг людям, у них сразу отказ от текстового исходного кода ассоциируется с мучительным мышевозением в Rational Rose. Хотя можно же сделать нормальный клавиатурный интерфейс, с переходом к мыши, только в случае необходимости.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Только вот, реализовать это поверх существующих языков очень сложно.
Может быть, поверх Agda ещё можно,
она самая простая из современных.
+1
no subject
no subject
no subject
no subject
а раз не массово - значит сдохнет, не родившись
no subject
no subject
no subject
no subject
Там нет концептуальной целостности в идеях. Т.е. задумка была хорошая "давайте сделаем объектную БД", судя по всему, достаточно теоретически это не проработали и получилось нечто узкоспецифическое и продаваемое исключительно паровозом с уникальным софтом, который купили бы вообще с любой БД.
no subject
no subject
Такое есть уже почти 20 лет, и называется k/q/kdb+. Иммутабельности там конечно никакой нет, да и не нужна она там. Зачем делать какие-то откаты, когда можно писать b:a+1, где a и b -- таблицы :-) Правда, назначение видимо несколько иное -- time series в основном, и сложные ADT там совсем не нужны. (А нужны ли они вообще? :-))
no subject
А при чём тут функциональное программирование, берете сорцы компилятора FreePascal и вставляете мост к БД, чтобы на этапе компиляции оттуда выколупывал и проверял. Можно даже проще: по БД тулом генерить юнит с определением типов + режим строгой типизации.
Прогон про "версии" и "транзакционную память" как-то совсем грустно. Объект истории сущности не сводится к сущности, иногда всё сложнее.
"подключаемся к базе, открываем таблицу "описания типов", лезем в тип" -- напоминает мне мои попытки 1998 года делать аналог Borland Database Object Repository. Тогда всякая УМЛ-щина была модна, метапрограммирование и т.д. Сделаем в БД таблицу метаданных -- хотя сама БД уже хранит таковую -- но она без бизнес-смысла, а мы с оным. Потом появится желание к свойствам "полей" добавлять структурированные атрибуты, на атрибуты ещё атрибуты, и закончится тем, что надо остановиться.
По большому счёту проблема в стремлении "всё обобщить", при этом не представляя себе точно это "всё". Стандартная рекомендация: скромнее надо быть, решать ограниченную текущую актуальную задачу.
Всё это бурчение (Вас, ЗАбиватора и т.д.) мне напоминает о зимней депрессии. Средство против -- вино с шашлыками, девушки, танцы, упражнения со штангой. )))
no subject
Вообще идея эта является обобщением нескольких актуальных задач, но решать ее "частично" не имеет смысла - фигня получится (уже пробовал несколько раз), а решать целиком - можно сдуреть, там для начала нужно перекопать всю мыслимую и немыслимую теорию.
А 600 функций просто не сломается, если будет использоваться метапрограммирование и вывод типов. Сломается, скажем, "вывод на печать" какой-нибудь никогда не используемой ведомости, если мы захотим рефакторить таблицу удалением поля, которое только в ней и используется. Сейчас такое отслеживать меня просто удалбывает.
no subject
А проекция структур различной размерности на одномерный текст -- это и есть та самая декомпозиция, namespace-ы, код в различных модулях и т.п.
И если сейчас в голове достраивается n-1 измерений, то будет достраиваться n-2. Несущественный выигрыш при больших n.
При этом существует годами проверенный и вылизанный набор инструментов для автоматизированной обработки одномерного текстового потока, и иногда он весьма полезен. При переходе к двумерному представлению мы этих инструментов лишаемся, а новых -- не получаем.
Так что ИМХО пользы от такого гипотетического перехода получится меньше, чем неудобств.
no subject
В данном случае, под двумерным я понимаю множество объектов, где по вертикали - объекты, а по горизонтали - структура их типов.
no subject
Ты MPS от JetBrains видел?
no subject
no subject
Это означает написание embedded XPath/XQuery, а втыкать его в строгую систему типов тяжко.
no subject
no subject
http://hackage.haskell.org/package/TCache
Для ООЯ:
http://www.garret.ru/databases.html