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

IT>Linq 2 SQL — это имплементация Linq провайдера для конкретной базы данных, а именно для MS SQL Server. Т.е. один из вариантов применения, не более того. Хотя многим при поверхностном взгляде кажется, что это и есть тот самый The Linq.

Дык, нас никто не заставляет читать данную запись поверхностно. Давай почитаем внимательнее, а не только оглавление, в котором написано Linq 2 SQL. И видим, в частности, вот это:

Yet, I was not really setting out to create a whole full-blown ORM system. I just needed something to kick the tires of LINQ with, a ‘mock’ LINQ provider if you will.

И как мне это надо "по-правильному" понимать?

G>>THE ORIGIN OF LINQ TO SQL,
G>>Читаем дальше здесь.

IT>А ты почитал вторую ссылку, которую я тебе дал? Там рассказано почему так получилось, почему в борьбе добра с Хейльсбергом, победило вовсе не добро.

Не вопрос, сейчас почитаю.

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

G>Ну, и что теперь делать будем? Будем креативно толковать текст, или, может быть, перейдем на обсуждение личности автора блога?

Будем думать головой и составлять своё собственное мнение, а не читать пресрелизы и делать из этого далеко идущие и к тому же хрен-оспоришь выводы.

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

G>И как мне это надо "по-правильному" понимать?

Понимать, что Linq поддерживает SQL в том числе, а не только. А при более детальном рассмотрении оказывается, что как раз поддержка SQL хоть и имелась ввиду, но делалась по остаточному принципу.

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

VD>>Ты же перескочил на обсуждение второстепенной темы и не понял того, что я тебе пытался сказать.

G>Хорошо, попробуй еще раз. Что ты хотел сказать?

ОК. Перейди по этой ссылке

Автор: VladD2
Дата: 11.11.09

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

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

Так же более простым для меня будте язык с поддержкой исключений и дженериков, так как он позволит упростить мне мой код.

С другой стороны слово "простой" может являться синонимом слову "примитивный" (не одерживающий чего-то). Именно в этом смысле ты и использовал данное слово. Только забыл сразу об этом упомянуть.

Так вот более примитивный язык не является более простым в использовании и уж точно не является более удобным. Конечно есть примеры и обратного, когда перенавороченность приводит в купе с элементами шифрования приводит к ужасным последствиям (APL, J). Так что во всем важен баланс. Но отсутствие некоторого набора фич 100% делает язык более сложным и менее удобным.
К таким фичам относится: Автоматическое управление памятью, типобзеопасность, потокобезопасность, поддержка ФВП.
Эти фичи вроде как есть в Гоу.
Но этим списком требования не ограничиваются. Кроме него еще нужны: дженерики/параметрический полиморфизм, исключения (или иной механизм автоматизации обработки ошибок), вывод типов внутри выражений (тел методов), паттерн-матчинг.

Вот когда это все появится в Гоу, то можно будет говорить о Гоу, как о современном языке. Ну, а будет ли он при этом простым, зависит от того насколько его разработчики смогут добиться баланса и на какие компромиссы пойдут (ради достижения своей цели).

Пока что я вижу ряд удачных выборов в дизайне языке. Самым удачным выбором мне кажется использование утиной типизации при применении интерфейсов. Вопрос только в том можно ли это решение реализовать эффективно.

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

Ген, зря ты тут в адвокаты полез. Гапертон не прав по полной программе (об этом ниже) и сейчас выкручивается, чтобы только не дай бог не признавать своей не правоты.

И вообще, что это за позиция у тебя? Заметь ты лезешь всюду где кто-то спорит со мной. Ну, право это же уже в глаза братается. Ну, будь хоть чуточку объективным.

AVK>>Все притензии предъявляй себе — притягивал то ты.

ГВ>Да ты что?!

Не поверишь, но это так на 100%. Только ты не то выделил. Давай-ка удалим лишее:

ГВ>

VD>>Скажем я могу в C# 3.0 просто и удобно написать "запрос" к данным с помощью LINQ-а, а в более простом (в смысле примитивном) C# 2.0 не могу. Так какой же из этих вариантов проще?

G>>Если идет речь о простоте выразительного средства, то есть языка — то разумеется тот, который без LINQ. Учитывая, что LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД. И представляешь, в гугле при разработке веб-приложений как-то обходятся без РСУБД.

ГВ>Основная мысль выделена: Влада попросили отцепиться. И кто что тут притянул?

Основная мысль действительно теперь выделена. Гапертон просто не понял о чем идер речь. Ну, не знает он что такое ЛИНК. Начитался какой-то ерунды написанной в русской википедии из который вообще ничего понять нельзя и высказал мягко говоря утверждения не соответствующие дейтсвительности.

По существу вопроса он тоже не прав, но это уже вопрос второй. В бутылку полез именно он и именно по повоуд ЛИНК-а.

Дело в том, что ЛИНК — это очень универсальное решение не привязанное ни к каким конкретным задачам (и тем более прикладным). К источнику данных ЛИНК тоже не привязан. Им конечно может быть и РСБУД, но может быть и ХМЛ, и просто список объектов. По сути ЛИНК базируется на библиотеке ФВП (точнее она и есть одна из главных составляющих самого понятия линк) и синтаксическом расширении языка позволяющем замаскировать обращение к этой библиотеке ФВП под запрос очень похожий на SQL (но им не являющийся).

В общем-то ситуация банальная. Ну, с кем не бывает? Не знает человек технологии, и что? Ну, ошибся. Ну, поправили тебя. Делов-то?! Ан нет. Уважаемый Гапертон развил по этому поводу натуральный флэйм, проигнорировал все ссылки, доказательства и просто чужие мнения и начал заниматься словесными упражнениями доказывая, что не он начал спор, а его видите ли к чему-то принуждают. И что он мол высказал мнение.

Такое мнение называется заблуждением (если мягко выражаться). А такую настойчивость в его повторении бессмысленной упертостью (тут уже и мягкого выражения не подберешь).

И высказано это "мнение" было не просто так в рамках общего повествования, а в качестве аргумента в пользу тезиса, что наличие ЛИНК-а усложняет язык.
В Гугле, видите ли, не используют РСБУД. А кто об этом вообще спрашивал или говорил? Это "аргумент" основанный на полном не понимании приведенного примера. И как можно было о чем-то там продолжать говорить если Гапертон сам ушел от темы при этом выдвинув целых два утверждения не соответствующих действительности?

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

KV>Супер, пасиб. А теперь, не затруднит ли тебя объяснить, что делают в теме, посвященной новому языку программирования: элементы психоанализа, упоминания таких терминов как "фобии", "диагнозы", "психика", "мозговедение" и т.п.?

Дык. Очевидно — это такой неявный намек модераторам, что тему поря сливать в КСВ, а ее участников в баню.

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

AVK>>Все притензии предъявляй себе — притягивал то ты.

G>Ложь. Первым упомянул VladD2. Потом в разговор влезли "эксперты".

Я упомянул ЛИНК как фичу языка упрощающую решение задач на этом языке. А вот ты начал притягивать за уши разные ошибочные аргументы из которых следовало...

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

N>Здравствуйте, Воронков Василий, Вы писали:

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

G>>>сдается мне первое что всплывет, это будет именно работа с реляционными источниками данных, самый распространенный из которых — РСУБД.

ВВ>>Ну я вот не использую ни linq2sql, ни linq2entities. Не срослось. А вот, скажем, linq2objects использую постоянно. Не потому что он "мега-рулит" и на нем можно писать рей-трейсинг. Просто *удобнее*. Все. РСУБД при этом поблизости нет.
ВВ>>С помощью какой магической комбинации слов тебе нужно объяснить, что ты не прав?

N>Гапертон таки прав тут, хотя и объясняет это... мнэээ... временами своеобразно. Любое новое средство подобного рода несёт в своей истории, своём синтаксисе, особенностях семантики и т.д. среду, в которой оно возникло, а среда определяет причину. Да, использовать LINQ стали тут же не для РСУБД; но возникло оно именно как средство работы для РСУБД.

И все-таки он не прав, как и ты. Вот, например, интервью с Erik Meijer, создателем LINQ. Отрывок:

The idea of LINQ is to solve the "impedance mismatch" between the different data models. Look at the 3 prevalent data models: Objects, XML and Relational Data. Programmers have to struggle with that daily when they write programs, mess around, querying relational data, doing some computations, then exposing the XML, and then vice versa. This is a problem that I wanted to attack when I moved from Academia to industry. There are several ways people try to attack this problem traditionally, and one is by saying: "Let's take one of this data models and take them as the uber model". You can say one popular view is XML, and say "Oh well, if we can make everything look like XML, then all the problems are solved". Or if we can make everything look like objects then everything is solved.

I believe that's a dead end because there will be more data models in the future, it doesn't scale. Imagine that tomorrow a completely new data model comes out, and you don't know if you can still map that to XML or Objects. The secret is to look at what mathematics has to offer you to solve this problem, and then try to translate this into something that normal programmers can understand. The way I explain it is like when you are designing a car. If you drive a car, you should know nothing about how the engine works, it should go smoothly; but if you are designing the car you have to know everything about physics of the engine and spark plugs and things like that. This is the same when you're designing this framework. We're using this theory from mathematics saying: "Can we abstract over any data model?" If once we can make it work for any data model, then you've solved the impedance mismatch, because then you are not dependant on any of these data models anymore.

Как ты можешь заметить идей было обстрагировать любой источник данных чтобы можно было работать единообразно. И говорить что "возникло оно именно как средство работы для РСУБД" неправильно.

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

N>И ирония тут в том, что функциональщику это видно сразу — потому что он видит множество других вариантов сделать то же, может быть, немного менее эффективно или синтаксически сложнее. Например, священная троица map-filter-reduce существует в любом ФЯ и во многих приближающихся отдельными чертами. В то же время list comprehension — уже более сложная конструкция, в Питоне и Эрланге она есть, а в Перле — нет. "Это уже звоночек." И то, что в C# не пошли этим путём, а пошли через нынешний синтаксис LINQ — показывает, кто, как и зачем вводил: это были именно РСУБД'шники, и вводили фичу для себя.

А кроме эмоций к этому можно что-то подкрепить?
Аргументы? Ссылки?

Меж тем ЛИНК в своей базе это и есть map-filter-reduce + оставшиеся функции за хаскелевской библиотеки работы со списками.

Ты прав, в том, что в основе идей линка лежала идея интегрировать в язык обращение к БД. Прототипом ЛИНКа был как не странно HaskellDB. Но HaskellDB — это встроеный в хаскель DSL. В Шарп его встравил один из тех кто догое время работал над хасклем. Посему он выбрал очень прямолинейный путь — в дотнет была включена библиотека аналогичная хакселевской библиотеке работы со списками, а синтаксическое расширение встроенное в Шарп и Васик просто переписывало код в вызовы этой библиотеки. Такой подход назвали query pattrn.
А вот для прозрачного доступа к СУБД пришлось более серьезно расширять язык. В язык встроили поддержку неявного преобрзования типов для лябд. Это позволило реализуя query pattrn указывать не только методы получающие лямбды, но и методы получающие АСТ.
Причем, в отличии от ХаскельБД в ЛИНК изначально заложили поддержку разных источников данных и в первую очердь ОБЫЧНЫХ объектов.
С базами данных работают не все и не всегда. А вот со списками объектов, все и всегда.
В результате ЛИНК стал в первую очередь библиотекой функций высшего порядка по работе с коллекциями.
И это было одной из целей создателей линк-а. Так как это было первым случаем встраивания фич функционального программирования в мэйнстрим-язык.

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

VD>А кроме эмоций к этому можно что-то подкрепить?
VD>Аргументы? Ссылки?

Ты сам далее приводишь достаточно аргументов к тому, что я сказал.

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

N>>Гапертон таки прав тут, хотя и объясняет это... мнэээ... временами своеобразно. Любое новое средство подобного рода несёт в своей истории, своём синтаксисе, особенностях семантики и т.д. среду, в которой оно возникло, а среда определяет причину. Да, использовать LINQ стали тут же не для РСУБД; но возникло оно именно как средство работы для РСУБД.
ВВ>А давайте вы для начала объясните, почему вы вставляете эту буковку "Р" в РСУБД, и как именно она связана с LINQ-ом?

Потому что заимствован SQL. SQL — далеко не лучшее решение для произвольного преобразования данных: в нём достаточно кривых решений в семантике и вследствие этого в синтаксисе. Чтобы автор подобного решения, обладая опытом работы с ФЯ, выбрал SQL как источник подражания, есть два варианта:
1. Выбор был сделан фактически из маркетинговых соображений, с прицелом на то, что это быстро приведёт к новому средству "широкие народные массы" программистов "внутреннего ПО", для которого работа с базами и именно с РСУБД является почти основным видом деятельности.
2. Выбор является исходной базой решения.

Первое, по всем известным мне источникам, не соответствует реальной истории. Значит, второе.

ВВ>Можно даже издалека начать. Какое именно отражение буковка "Р" находит, скажем, в T-SQL?

Насколько я его могу понять, самое прямое: в любом случае он работает над данными в реляционной модели. Или же есть какой-то другой секретный T-SQL, который не гуглится.;)

Для меня отграничение реляционных баз существенно потому, что работать приходится... мнэээ... с чем угодно, только не с ними. В самом развитом случае это Mnesia, но часто на практике ещё что-то более извращённое.

N>>И ирония тут в том, что функциональщику это видно сразу — потому что он видит множество других вариантов сделать то же, может быть, немного менее эффективно или синтаксически сложнее.
ВВ>А зачем делать "то же", но "немного менее эффективно или синтаксически сложнее"? :???: В целях мазохизма?

Я говорил про _видит_. А не про финальный выбор. Для которого SQL дань привычке, а не качеству результата.

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

G>>И как мне это надо "по-правильному" понимать?

IT>Понимать, что Linq поддерживает SQL в том числе, а не только.

Это я и так знаю. Ты с чем споришь-то вообще, интересно?

IT>А при более детальном рассмотрении оказывается, что как раз поддержка SQL хоть и имелась ввиду, но делалась по остаточному принципу.

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

Я, кстати, спросил тебя, как мне надо понимать цитату, которую я привел. Зачем удаляем цитату? Зачем отвечаем не на заданный вопрос, а на какой-то выдуманный? Вот цитата, возвращаю на место.

Yet, I was not really setting out to create a whole full-blown ORM system. I just needed something to kick the tires of LINQ with, a ‘mock’ LINQ provider if you will.

Также выясняется, что твои опровержения основаны на косвенных доводах (слишком сложно нового SQL провайдера добавить, или что-то вроде того), факты — на ссылке, что еще один человек на то же жалуется. Остальная группа доводов — якобы введение книжки, которую я привел, содержит специальное вранье для индусов (все либо тупы и обчитались рекламы, и в LINQ не разбираются, либо злодеи, стремящиеся обиндусить весь мир — мировой заговор просто какой-то).

Извини, не могу я тебя "по правильному" понимать. Слабоваты доводы-то у тебя, понимаешь? Не получается у меня с ними согласится при всем желании. Придется вам всем это как-нибудь пережить теперь. Ибо мне окончательно надоело переливание из пустого в порожнее по поводу LINQ — я уже давно не чувствую в этом разговоре совершенно никакой практической пользы, а теперь — просто устал. Спасибо за конструктивную беседу.

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

G>>Ну, и что теперь делать будем? Будем креативно толковать текст, или, может быть, перейдем на обсуждение личности автора блога?

IT>Будем думать головой и составлять своё собственное мнение, а не читать пресрелизы и делать из этого далеко идущие и к тому же хрен-оспоришь выводы.

Ну вот я составил свое собственное мнение. Уже давно. Прессрелизов не читал. В чем проблема? С твоим не совпадает?

Что ты статью-то, что я привел, не комментируешь? С твоими выводами неудобно стыкуется, да? Дык оставайся при своих, я не против, и замнем для ясности. Отличный вариант, не находишь?

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

Y>И все-таки он не прав, как и ты. Вот, например, интервью с Erik Meijer, создателем LINQ. Отрывок:

Y>[q]
Y>The idea of LINQ is to solve the "impedance mismatch" between the different data models. Look at the 3 prevalent data models: Objects, XML and Relational Data.

И тот факт, что наибольший "импеданс", как по силе, так и по распространению, заставляющий людей вообще дергаться в данном направлении, возникает именно при работе с реляционными данными, разумеется надо проигнорировать, ибо никакого отношения к делу он (к доказательству нашей неправоты, разумеется) не имеет. Правильно?

Если выкинуть работу с реляционным источником из списка, то вся обозначенная проблема становится достаточно несущественной и незначительной, чтобы не расшибаться в лепешку ради специальной поддержки специального механизма в языке.

В отличии от проблемы параллелизма, к примеру. Которая в последнее время становится достаточно существенна, чтобы стоить такой поддержки.

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

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

Повторяю:
Какое именно отражение реляционность структуры данных находит, давайте упростим задачу, в SQL92 (он отлично гуглится вместе со спецификаией). Как именно реляционность повлияла на этот язык? Что в этом языке свидетельствует о его "заточенности" для работы именно с реляционной структурой? Почему вы подчеркиваете, что речь именно об Р-СУБД, а не какой другой.

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

ВВ>Извините, но вы на мой вопрос не ответили.

Ответил.

ВВ>Какое именно отражение реляционность структуры данных находит, давайте упростим задачу, в SQL92 (он отлично гуглится вместе со спецификаией). Как именно реляционность повлияла на этот язык? Что в этом языке свидетельствует о его "заточенности" для работы именно с реляционной структурой?

A table is a multiset of rows. A row is a nonempty sequence of values. Every row of the same table has the same cardinality and contains a value of every column of that table.<...>The row is the smallest unit of data that can be inserted into a table and deleted from a table.

Не уверен, что это оригинальная спецификация, но такое ограничение уже достаточно определяет характер БД.

ВВ> Почему вы подчеркиваете, что речь именно об Р-СУБД, а не какой другой.

Для другой SQL не годится или годится с тяжёлыми натяжками. (Да, можно придумать искусственный случай без натяжек. Но это неинтересно.)

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

N>Потому что заимствован SQL.

Я правильно понимаю что этому тезису тоже не будет дано обоснования?

Если так, то все твои слова не более чем домыслы которые никому кроме тех чью позицию ты пытаешься защищать не интересны.

Тезис же этот разрушается о простейшие примеры. Линк отлично обрабатывает иерархический XML, списки объектов и ООБД.
Все сходство ЛИНКа с SQL заканчивается на наличии одинаковых ключевых слов (причем полного соответствия нет).

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

VD>Ген, зря ты тут в адвокаты полез. Гапертон не прав по полной программе (об этом ниже) и сейчас выкручивается, чтобы только не дай бог не признавать своей не правоты.

Не, Влад. Если бы хоть кто-то из активных защитников LINQ попробовал написать хоть что-то подобное в 2000-2001 году для C++ (я не сказал — реализовать CRUD), то я ручаюсь, половины бы возражений Гапертону даже не появилось. Для справки — я пробовал, даже более или менее успешно. И пришёл ровнёхонько к тем же выводам и моделям, что и создатели LINQ. Да, такая система впоследствии действительно превращается в обобщённый отобразитель всего повсюду... Далее см. LINQ с его плюрализмом источников данных.

VD>И вообще, что это за позиция у тебя? Заметь ты лезешь всюду где кто-то спорит со мной. Ну, право это же уже в глаза братается. Ну, будь хоть чуточку объективным.

Я вижу только разный характер доводов, поверь. Измени свои способы аргументации, и я тебе торжественно обещаю — моя реакция поменяется соответственно. Это, Влад, скорее у тебя позиция пристального наблюдения за мной — а мне где уж там успеть за потоком твоих мыслей, чтобы в каждый спор с твоим участием соваться.

AVK>>>Все притензии предъявляй себе — притягивал то ты.
ГВ>>Да ты что?!
VD>Не поверишь, но это так на 100%. Только ты не то выделил. Давай-ка удалим лишее:

Твоя объективность, как непосредственного участника прицитированной дискуссии вызывает острые сомнения. Так что, давай-ка мы ничего перевыделять не будем?

VD>Дело в том, что ЛИНК — это очень универсальное решение не привязанное ни к каким конкретным задачам (и тем более прикладным). К источнику данных ЛИНК тоже не привязан. Им конечно может быть и РСБУД, но может быть и ХМЛ, и просто список объектов. По сути ЛИНК базируется на библиотеке ФВП (точнее она и есть одна из главных составляющих самого понятия линк) и синтаксическом расширении языка позволяющем замаскировать обращение к этой библиотеке ФВП под запрос очень похожий на SQL (но им не являющийся).

+1. А дальше-то что?

VD>В общем-то ситуация банальная. Ну, с кем не бывает? Не знает человек технологии, и что? Ну, ошибся. Ну, поправили тебя. Делов-то?! Ан нет. Уважаемый Гапертон развил по этому поводу натуральный флэйм, проигнорировал все ссылки, доказательства и просто чужие мнения и начал заниматься словесными упражнениями доказывая, что не он начал спор, а его видите ли к чему-то принуждают. И что он мол высказал мнение.

VD>Такое мнение называется заблуждением (если мягко выражаться). А такую настойчивость в его повторении бессмысленной упертостью (тут уже и мягкого выражения не подберешь).

А у меня вот точно такое же впечатление сложилось: что вы любой ценой добиваетесь "признания своей неправоты", даже когда собеседник прямо говорит, что его самого это совершенно не колышет.

VD>И высказано это "мнение" было не просто так в рамках общего повествования, а в качестве аргумента в пользу тезиса, что наличие ЛИНК-а усложняет язык.
VD>В Гугле, видите ли, не используют РСБУД. А кто об этом вообще спрашивал или говорил? Это "аргумент" основанный на полном не понимании приведенного примера. И как можно было о чем-то там продолжать говорить если Гапертон сам ушел от темы при этом выдвинув целых два утверждения не соответствующих действительности?

Утверждения Гапертона, на мой сторонний взгляд, сводятся к одному: "от...итесь!" Извини мне мой французский.

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

N>Для другой SQL не годится или годится с тяжёлыми натяжками. (Да, можно придумать искусственный случай без натяжек. Но это неинтересно.)

И можно навскидку привести простейший и достаточно ходовой пример такой базы — это работа с БД таймсерий. Возникает задача много где, в частности при обработке котировок в финансовых приложениях. Джойнов практически нет, зато присутствуют нетривиальные агрераты по времени.

Одна из причин — ни один из запросов на простом SQL92 выразить нельзя, даже простейшие 5-минутные агрегаты, по причине наличия странных агрегатов "open" и "close", а также невозможности указать в group by принцип группировки с выравниванием на начало торговой сессии.

Толку от "реляционного" взгляда на мир в данной задаче — ноль, по причине отсутствия времени в реляционной модели в явном виде. Как и от разного рода comprehensions и прочего.

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

ГВ>Не, Влад. Если бы хоть кто-то из активных защитников LINQ попробовал написать хоть что-то подобное в 2000-2001 году для C++ (я не сказал — реализовать CRUD), то я ручаюсь, половины бы возражений Гапертону даже не появилось. Для справки — я пробовал, даже более или менее успешно. И пришёл ровнёхонько к тем же выводам и моделям, что и создатели LINQ. Да, такая система впоследствии действительно превращается в обобщённый отобразитель всего повсюду... Далее см. LINQ с его плюрализмом источников данных.

Поверь на слово, ты просто не понимаешь о чем говоришь. Не хочешь верить, разберись в вопросе.
Право — это уже даже не смешно.