Здравствуйте, gandjustas, Вы писали:

_>>Ну и если говорить об автоматизации этого (чтобы не писать дважды), то и генерация проекции по типу и генерация типа по проекции делаются элементарно в статических языках с базовыми возможностями метапрограммирования и в любых динамических языках.
G>Про динамические языки речи нет. А "возможности метапрограммирования" в 90% случаев и означает цитирование кода

В 100% случаев "возможности метапрограммирования" в статических языках используются для другого — для compile-time выбора специфической реализации для специфических типов. Такое "вычисление" порой само является достаточно сложной программой, но её нет в бинарнике.


G>Есть таблица t а одной колонкой типа a, какой тип будет у проекции таблицы t, состоящей из (a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a...) ? Количество колонок может быть любое и не ограничено сверху разумными пределами.

Для конкретной компиллируемой программы выводимый тип кортежа всегда известен.


_>>Задавать в коде деревья выражений, которые потом будут интерпретироваться в рантайме умеют во множестве языков с незапамятных времён.
G>Назови хотя бы три из них. Чтобы статически типизированные что чтобы "деревья выражений" задавались тем же кодом что и сам язык без дополнительных приседаний.

Любой МЛ-подобный язык, типа того же Хаскеля.
И вообще любой язык с реализованными в нём замыканиями.
Только и это не обязательная фишка, а лишь бонусная к удобству, можно и без замыканий.


_>>Причём для этого в языке совершенно не требуется наличия той рефлексия-подобной штуки, которую подразумевал тут ты.
G>Рефлексия в каком-то виде все равно будет.

Разве что в compile-time.
В бинарнике типы стираются.


G>Ты же не сможешь проверить корректность дерева выражения относительно sql если не имеешь в дереве выражений информацию о типе.

В рантайм этого и не требуется, если компилятор обеспечивает строгую статическую типизацию.


_>>Тут подходят любые статические языки, имеющие элементы метапрограммирования, плюс большинство динамических языков. Т.е. в реальности выбор очень большой.
G>Да-да, назови хотя бы парочку (динамические не интересуют), ну чтобы можно было написать типа такого:
G>

G>from x in t
G>where t.Category.Priority==1
G>select {
G>  StartDate =  x.StartDate.Date,
G>  EndDate = x.StartDate.Date + x.Duration / 24
G>}
G>

В современном С++ можно что-то типа такого:

auto y = select(
    filter(t, [](auto x){ return x.Category.Priority==1; }),

    [](auto x){ 
        return tuple(
            field(StartDate) = x.StartDate.Date,
            field(EndDate) = x.StartDate.Date + x.Duration / 24);
    });

Гуглить "named tuple", это довольно популярное игрище.
https://github.com/duckie/named_types/tree/master/test
http://vitiy.info/named-tuple-for-cplusplus/

В "более функциональном" языке можно было с более простым синтаксисом лямбды сделать...
Только причём тут любой из мейнстримовых языков?
Обсуждаемое давно есть в не-мейнстримовых специализированных языках в достатке.


G>Тут и проекция, и соединение, и выражения над элементами кортежа.

Там даже есть сложение и деление!


G>Работа этого кода опирается на возможность цитирования и ad-hoc типы.

На костыли оно опирается.
Ср-вами самого языка не реализуемо, поэтому приходится добавлять в язык "специальные конструкции".


G>Покажи аналог на другом языке без ad-hoc типов или цитирования без потери типизированности или выразительности.

Можно и без ad-hoc типов, объявив тип результата заранее.
А можно и трусы через голову одевать.


G>Про тяжеловесные не надо расказывать. Они — раковая опухоль всей индустрии последние 20 лет. Я уверен что нет других "паттернов" или "технологий" кроме ORM

Он уверен. ))
ORM — это костыль над костылём.
Сейчас всё чаще обмениваются сообщениями известного типа и ORM не нужен.


G>А легковесные orm это не orm, а мапперы рекордсетов на объекты.

Рекордсеты — это динамическая хрень.
Любой маппинг из него тоже динамический.
Смысл это вообще обсуждать в этом топике?


_>>Правда не очень понятно зачем ты вообще об этом заговорил, т.к. все эти решения занимаются грубо говоря трансляцией кода некого языка в sql запрос, в то время как vdimas вроде как говорил о выкидывание самого sql из этой схемы. Правда я не очень вникал что он предложил на замену, но в любом случае все эти ORM и подобные им решения в таком случае будут не у дел.
G>Да, заметно что ты не вникал и мозг не включал.
G>Давай по порядку:
G>1) Чтобы выкинуть sql надо договориться о формате передачи запросов.

Ты проблему пока не озвучил.


G>2) Вряд ли vdimas хочет чтобы он был текстовым, иначе вряд ли бы он этот разговор вообще затеял.


Текстовое представление работает замечательно, оно скармливается компилятору, как скармливаются IDL, protobuf или просто h-файлы.
Бывают и не текстовые представления, типа typelib.

Только какаяя нафик разница — текстовое будет описание или не текстовое?
Ключевое тут в автоматизации распространения описания типов м/у частями системы.
А в каком именно виде — дело десятое.


G>3) На стороне языка должно быть средство генерации запроса в бинарном виде

Это вообще дичь какая-то.


G>желательно на основе типов и выражений самого языка.

Это и есть "просто программа", остальное — забота компилятора.


G>То есть для того кто пользуется orm или linq мало что изменится, но типа как "повысится эффективность".

Это всё тоже мимо, бо не нужно.


G>Но эффективность по факту упирается не в текстовый SQL, а в средства языка по формулированию сложных запросов к базе и скорость дисков.

Эффективность сегодня упирается в динамическое построение вариантов планов запросов и оценку их эффективности.
Само представление планов запросов динамическое, оценивающий код сверху плана интерпретирующий, схема слишком тормозная и слишком прожорливая к памяти.

_>>На самом деле как раз производителям СУБД это сделать довольно просто. Тут больше проблема в миллионах "пользователей", знающих только SQL (и там не только программисты, но и админы, аналитики и ещё много кто) и вряд ли желающих переучиваться на что-то иное даже ради некого повышения эффективности работы БД.
G>Просто сделать что?

Что обсуждается.
Уже давно сделано.
Не на том уровне, как хочется, но заметные подвижки есть.


G>Добавить еще один формат запросов? А зачем? Кому он нужен? Каким образом он добавит эффективности?

В типизированной системе "формат" каждого запроса уникален.
Это просто некое типизированное сообщение, PDU.


G>Понимаешь что амортизированная стоимость парсинга текстового запроса равна нулю?

И? На выходе всё равно получается его AST, которое необходимо интерпретировать в рантайм и это всё жутко тормозит.


G>В целом, кроме некоторых аспектов синтаксиса, sql довольно хороший язык.

С этой точки зрения Фортран тоже неплох.
Был.


G>А протокол взаимодействия программы с базой на основе генерации sql запросов — довольно хороший способ работы.

Часть прикладного кода живёт в самой БД, часть в сервере приложений, часть на клиенте.
Языки реализации всех 3-х частей часто разные.
Никакой проверки на правильность "состыковки" схем данных при передаче от уровня к уровню нет.
Все несостыковки вылазят уже в рантайм.
Сие убого донельзя.