Призрак ходит по Европе
Jan. 15th, 2010 03:05 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassЗаболел, не могу спать, в голову лезет муть всякая - теория категорий в применении к оптимальным тактикам выкашивания противников на Uptown TDM. Там уровень такой прямоугольный, блин, с базами в противоположных углах, у меня всегда на больную голову или во сне это ассоциируется с диаграммами коммутации.
Так вот, о чем это я. В массах в последнее время витает некая идея. Вкратце я бы ее сформулировать: "встроить правильную СУБД с преферансом и гимназистками прямо внутрь рунтайма функциональных языков" и поиметь на халяву сразу множество вещей.
Во-первых, уйти от долбаного SQL, который чем дальше, тем больше расползается в разные стороны в разных СУБД, но при этом не потерять ничего из его функциональности и лаконичности.
Во-вторых, иммутабельность вообще не помешало вынести бы на уровень базы данных. Я уже просто не упомню, сколько раз мне приходилось делать версионность объектов в базе, т.е. при изменении сохранять предыдущую версию. И это при том, что сами сервера(нормальные, само собой) внутри используют версионность для поддержки транзакций, снапшоты там всякие и сегменты отката и предыдущие версии записей и сборка мусора. Для изменяемых объектов (в опердени, например, первичка в текущем рабочем периоде) придется выставлять некий фронт-енд, где можно менять объекты невозбранно, а потом по факту завершения работы с ними спихивать в неизменяемые.
В-третьих, можно наконец-то будет использовать вывод типов и метапрограммирование и прочие навороты для того, чтобы делать нормальную миграцию системы, при изменении структуры данных(схемы БД). Просто база не даст закомитить DDL-транзакцию, если при этом что-нибудь сломается и типы не сойдутся.
И в четвертых, можно будет использовать метациклические модели для данных, т.е. можно будет в описание типа объекта впихнуть дополнительные поля и использовать их для всякой там кодогенерации.
При этом, как я себе представляю нормальный интерфейс к этому - и изменение структуры данных и работа с данными должна делаться в некоем двумерном интерфейсе. Обычной таблицы, честно говоря, не хватает - например, непонятно как в ней отобразить корректно список объектов какого-нибудь алгебраического типа с несколькими конструкторами разной структуры.
Т.е. выглядит примерно так: подключаемся к базе, открываем таблицу "описания типов", лезем в тип, добавляем поле, конструктор, чорта лысого, пытаемся сохранить, оно нам показывает список функций, которые сломались, делаем для них адаптеры, для перехода между версиями типа пишем функции миграции, сохраняем. Потом открываем интерфейс к множеству объектов типа (в точно таком же виде, как работали только что с множеством описаний типов) и работаем с ним.
Двумерный интерфейс нужен по той причине, что линейное писание кода уже не соответствует задачам. У нас практически все структуры данных - дву- и больше-мерные, результат на экране тоже двумерный(если не трехмерный и выше), а мы до сих пор используем инструменты с одномерным текстом.
Причина непопулярности другого подхода в том, что дебилоиды с UML-инструментами загадили мозг людям, у них сразу отказ от текстового исходного кода ассоциируется с мучительным мышевозением в Rational Rose. Хотя можно же сделать нормальный клавиатурный интерфейс, с переходом к мыши, только в случае необходимости.
Так вот, о чем это я. В массах в последнее время витает некая идея. Вкратце я бы ее сформулировать: "встроить правильную СУБД с преферансом и гимназистками прямо внутрь рунтайма функциональных языков" и поиметь на халяву сразу множество вещей.
Во-первых, уйти от долбаного SQL, который чем дальше, тем больше расползается в разные стороны в разных СУБД, но при этом не потерять ничего из его функциональности и лаконичности.
Во-вторых, иммутабельность вообще не помешало вынести бы на уровень базы данных. Я уже просто не упомню, сколько раз мне приходилось делать версионность объектов в базе, т.е. при изменении сохранять предыдущую версию. И это при том, что сами сервера(нормальные, само собой) внутри используют версионность для поддержки транзакций, снапшоты там всякие и сегменты отката и предыдущие версии записей и сборка мусора. Для изменяемых объектов (в опердени, например, первичка в текущем рабочем периоде) придется выставлять некий фронт-енд, где можно менять объекты невозбранно, а потом по факту завершения работы с ними спихивать в неизменяемые.
В-третьих, можно наконец-то будет использовать вывод типов и метапрограммирование и прочие навороты для того, чтобы делать нормальную миграцию системы, при изменении структуры данных(схемы БД). Просто база не даст закомитить DDL-транзакцию, если при этом что-нибудь сломается и типы не сойдутся.
И в четвертых, можно будет использовать метациклические модели для данных, т.е. можно будет в описание типа объекта впихнуть дополнительные поля и использовать их для всякой там кодогенерации.
При этом, как я себе представляю нормальный интерфейс к этому - и изменение структуры данных и работа с данными должна делаться в некоем двумерном интерфейсе. Обычной таблицы, честно говоря, не хватает - например, непонятно как в ней отобразить корректно список объектов какого-нибудь алгебраического типа с несколькими конструкторами разной структуры.
Т.е. выглядит примерно так: подключаемся к базе, открываем таблицу "описания типов", лезем в тип, добавляем поле, конструктор, чорта лысого, пытаемся сохранить, оно нам показывает список функций, которые сломались, делаем для них адаптеры, для перехода между версиями типа пишем функции миграции, сохраняем. Потом открываем интерфейс к множеству объектов типа (в точно таком же виде, как работали только что с множеством описаний типов) и работаем с ним.
Двумерный интерфейс нужен по той причине, что линейное писание кода уже не соответствует задачам. У нас практически все структуры данных - дву- и больше-мерные, результат на экране тоже двумерный(если не трехмерный и выше), а мы до сих пор используем инструменты с одномерным текстом.
Причина непопулярности другого подхода в том, что дебилоиды с UML-инструментами загадили мозг людям, у них сразу отказ от текстового исходного кода ассоциируется с мучительным мышевозением в Rational Rose. Хотя можно же сделать нормальный клавиатурный интерфейс, с переходом к мыши, только в случае необходимости.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-01-15 04:22 am (UTC)no subject
Date: 2010-01-15 04:33 am (UTC)no subject
Date: 2010-01-15 04:33 am (UTC)no subject
Date: 2010-01-15 05:44 am (UTC)no subject
Date: 2010-01-15 05:59 am (UTC)no subject
Date: 2010-01-15 06:23 am (UTC)no subject
Date: 2010-01-15 06:06 am (UTC)Только вот, реализовать это поверх существующих языков очень сложно.
Может быть, поверх Agda ещё можно,
она самая простая из современных.
+1
Date: 2010-01-15 08:48 am (UTC)no subject
Date: 2010-01-15 08:17 am (UTC)no subject
Date: 2010-01-15 10:48 am (UTC)no subject
Date: 2010-01-15 08:22 am (UTC)no subject
Date: 2010-01-15 08:35 am (UTC)а раз не массово - значит сдохнет, не родившись
no subject
Date: 2010-01-15 08:38 am (UTC)no subject
Date: 2010-01-15 10:49 am (UTC)no subject
Date: 2010-01-15 10:50 am (UTC)no subject
Date: 2010-01-15 10:56 am (UTC)Там нет концептуальной целостности в идеях. Т.е. задумка была хорошая "давайте сделаем объектную БД", судя по всему, достаточно теоретически это не проработали и получилось нечто узкоспецифическое и продаваемое исключительно паровозом с уникальным софтом, который купили бы вообще с любой БД.
no subject
Date: 2010-01-15 03:58 pm (UTC)no subject
Date: 2010-01-15 11:46 am (UTC)Такое есть уже почти 20 лет, и называется k/q/kdb+. Иммутабельности там конечно никакой нет, да и не нужна она там. Зачем делать какие-то откаты, когда можно писать b:a+1, где a и b -- таблицы :-) Правда, назначение видимо несколько иное -- time series в основном, и сложные ADT там совсем не нужны. (А нужны ли они вообще? :-))
no subject
Date: 2010-01-15 11:57 am (UTC)А при чём тут функциональное программирование, берете сорцы компилятора FreePascal и вставляете мост к БД, чтобы на этапе компиляции оттуда выколупывал и проверял. Можно даже проще: по БД тулом генерить юнит с определением типов + режим строгой типизации.
Прогон про "версии" и "транзакционную память" как-то совсем грустно. Объект истории сущности не сводится к сущности, иногда всё сложнее.
"подключаемся к базе, открываем таблицу "описания типов", лезем в тип" -- напоминает мне мои попытки 1998 года делать аналог Borland Database Object Repository. Тогда всякая УМЛ-щина была модна, метапрограммирование и т.д. Сделаем в БД таблицу метаданных -- хотя сама БД уже хранит таковую -- но она без бизнес-смысла, а мы с оным. Потом появится желание к свойствам "полей" добавлять структурированные атрибуты, на атрибуты ещё атрибуты, и закончится тем, что надо остановиться.
По большому счёту проблема в стремлении "всё обобщить", при этом не представляя себе точно это "всё". Стандартная рекомендация: скромнее надо быть, решать ограниченную текущую актуальную задачу.
Всё это бурчение (Вас, ЗАбиватора и т.д.) мне напоминает о зимней депрессии. Средство против -- вино с шашлыками, девушки, танцы, упражнения со штангой. )))
no subject
Date: 2010-01-15 12:07 pm (UTC)Вообще идея эта является обобщением нескольких актуальных задач, но решать ее "частично" не имеет смысла - фигня получится (уже пробовал несколько раз), а решать целиком - можно сдуреть, там для начала нужно перекопать всю мыслимую и немыслимую теорию.
А 600 функций просто не сломается, если будет использоваться метапрограммирование и вывод типов. Сломается, скажем, "вывод на печать" какой-нибудь никогда не используемой ведомости, если мы захотим рефакторить таблицу удалением поля, которое только в ней и используется. Сейчас такое отслеживать меня просто удалбывает.
no subject
Date: 2010-01-15 01:00 pm (UTC)А проекция структур различной размерности на одномерный текст -- это и есть та самая декомпозиция, namespace-ы, код в различных модулях и т.п.
И если сейчас в голове достраивается n-1 измерений, то будет достраиваться n-2. Несущественный выигрыш при больших n.
При этом существует годами проверенный и вылизанный набор инструментов для автоматизированной обработки одномерного текстового потока, и иногда он весьма полезен. При переходе к двумерному представлению мы этих инструментов лишаемся, а новых -- не получаем.
Так что ИМХО пользы от такого гипотетического перехода получится меньше, чем неудобств.
no subject
Date: 2010-01-15 01:06 pm (UTC)В данном случае, под двумерным я понимаю множество объектов, где по вертикали - объекты, а по горизонтали - структура их типов.
no subject
Date: 2010-01-15 01:04 pm (UTC)Ты MPS от JetBrains видел?
no subject
Date: 2010-01-15 01:07 pm (UTC)no subject
Date: 2010-01-15 03:09 pm (UTC)Это означает написание embedded XPath/XQuery, а втыкать его в строгую систему типов тяжко.
no subject
Date: 2010-01-15 06:10 pm (UTC)no subject
Date: 2010-01-17 11:03 am (UTC)http://hackage.haskell.org/package/TCache
Для ООЯ:
http://www.garret.ru/databases.html