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

G>Что ты понимаешь под "полной абстракциией" ?

Чтобы писать код не задумываясь о деталях реализации ORM. Сейчас таких ORM нет.

G>То что можно больше написать не означает что выразительность выше.

Как раз таки означает.

G> Иначе получится что самый выразительный язык это perl, в нем почти любая последовательность символов будет корректной программой.

Перл элементарно транслируется в банальный плоский С. Так что негодная у тебя аналогия. Проблема не в транслируемости конструкций, а в том что вполне осмысленные, нормально выглядящие и работающие на linq2objects конструкции на SQL фик переведешь.

G>SQL (на примере TSQL) умеет, а Linq нет:
G>1) CTE и рекурсию

СТЕ сама по себе линку просто не нужна. А поддердка рекурсии — вопрос конкретных провайдеров, которым просто никто не занимался всерьез.

G>2) ranking-функции и агрегаты с partition

Это вообще не проблема.

G>3) MERGE-оператор

Тоже не проблема.

G>4) PIVOT\UNPIVOT

Опять же вопрос конкретного провайдера. Выразительных функций линка хватает за глаза.
При этом есть несколько моментов, которые действительно несколько фигово в линке выражаются по сравнению с сиквелом. Но ни один из них ты не упомянул.

G>>> Linq создавался как раз чтобы не сильно отставать по выразительности от SQL.
НС>>Это ты сам придумал?
G>Нет, об этом Мейер говорил.

Эрик? Ссылку можно? А то я немножко на эту тему с ним общался, и ничего подобного не услышал.

НС>>Он то расказал правильно, а вот ты понял его как то странно, судя по всему.
G>А ты тогда о чем говоришь?

Я, кажется, вполне понятно написал. Любая ОРМ, если попытаться от нее абстрагироваться, приведет к leaky abstraction. Без вариантов. Что тебе в этом утверждении непонятно?

G>Различия в СУБД не позволяют эффективно построить один API для любой СУБД. А Linq в этих случаях как раз и используется как генератор СУБД-специфичных запросов.