LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 11.11.09 16:57
Оценка: -12
Здравствуйте, VladD2, Вы писали:

G>>Простой, практичный, и удобный язык. Это в наши времена — большая редкость. Люди давно забыли, как делать простые и удобные вещи, и перестали из ценить. А зря.


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


Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.

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


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

18.11.09 15:35: Ветка выделена из темы Go — новый язык от гугла
Автор: Курилка
Дата: 11.11.09
— WolfHound
Re[21]: Исправлена ссылка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.11.09 21:29
Оценка: +3 :))) :))) :)))
Здравствуйте, kochetkov.vladimir, Вы писали:

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


Это традиционные RSDN-овские "соль и перец по вкусу".

Схема беседы в ФП:

— Рассказ про новый тул;
— В ответах рассказы про похожие, непохожие и рядом не стоявшие тулы;
— Взаимные обвинения в незнании всех тулов;
— Взаимные выяснения отношений типа "логика vs. эмоции — кто кого заборет" с элементами психоанализа и требованиями аргументировать эмоции;
— Разбор предыдущих сообщений с перекрёстными ссылками "кто что сказал" и анализом психоанализа;
— Развешивание предупреждений от модераторов и признания во всех споривших в том, что они совершенно не заинтересованы друг в друге;
— Новая волна спорщиков, примечания, дополнения, частные признания во взаимной незаинтересованности.

Здесь как раз 5-6-я стадии. Nothing personal, just tradition.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[36]: Кстати
От: yuriylsh  
Дата: 26.11.09 02:26
Оценка: 278 (9)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Если тебе не надо об этом думать — никто тебя не заставляет. Просто скажи, что тебе не интересно это обсуждать и выйди из обсуждения. Только какой смысл при этом встревать с опровержениями высказываний других? Ты считаешь LINQ универсальным средством, введённым MS ради заботы о малых сих — нет проблем. А я этого не считаю и поддерживаю разными +-*/ тех, кто высказывается в таком ключе, вот и весь спор. Переубедить меня сможет, вполне вероятно, письмо Билла Гейтса, датированное 2001-м годом, где будет написано: "...we need to implement functional programming for our customers, are you know somebody good in functional languages development?" Если у тебя завалялось такое, то я с удовольствием соглашусь с твоими доводами. Если нет или потёр случайно — ну извини, я продолжаю считать, что первопричиной разработки LINQ явился OR-импеданс. Это просто, понятно и лишено обоснований с привлечением иррациональных соображений.


До Билла Гейтса достучаться думаю не так легко, а вот до Erik Meijer у меня получилось. Надеюсь, к словам создателя LINQ тоже можно засчитать. Опускаю официальну часть письма, сразу ответы Эрика на мои вопросы.
Первый вопрос по сути совпадает с темой топика:

- Is relational data the main reason to start LINQ development?

It is a common misconception that LINQ is strongly coupled to relational data. If you look at the various papers on my homepage (http://research.microsoft.com/en-us/um/people/emeijer/ErikMeijer.html) you see that I emphasize LINQ’s monadic roots. Monads are a way to reason about general “computations” and querying a relational database is just one possible example of that. Take Rx http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx for instance, you see that we define LINQ over event-based and asynchronous computations. That is quite different from your typical relational database I would say. Other examples include LINQ to Sharepoint, LINQ to Twitter, …. Those query “data” but not relational data. Have a look at http://homepages.inf.ed.ac.uk/wadler/topics/monads.html for more examples of possible LINQ data sources.


Второй — ответ на утвержение
Автор: Gaperton
Дата: 17.11.09
, сделанное Гаптероном когда он комментировал мой пост.

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

Вот ответ Эрика:

- "if you throw away relational data application then impedance mismatch problem becomes somewhat inessential and insignificant to put such a huge effort to add a special support into the language". Do you think it is correct?

As the answer to the first question implies, LINQ is not tied to relational data. What I am trying to say in the interview you quote is that what LINQ does is to emphasize the correspondence between different data models by defining a common interface/pattern that a “data source” can expose and then define a query language in terms of that interface. This in contrast to ther approaches where people are converting their data into a universal data model and querying on that.
LINQ is about composing computations, querying relational data is one special, and important, form of composing computations.


Следующий мой вопрос был кастательно неоднократно здесь поднимающегося сравнения LINQ с реализацией на циклах.

- What are the main advantages of LINQ over using plain simple loops when LINQ is not used for relational data interaction?

That is not a correct question since, again, you assume that you are dealing with explicit data sources. How could you use loops to do Rx-style computations?


Ну и отфонарно вброшенный вопрос:

- Do you think LINQ-like approach would be a good addition for other languages?

Well, F#, Haskell and Scala all have (monad) comprehensions, so obviously yes.

Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[2]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 11.11.09 18:07
Оценка: -8
Здравствуйте, VladD2, Вы писали:

G>>Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.


VD>Ну, да. Человек либо понимает, что оперировать слишком общими понятиями довольно бессмысленно, либо — нет.


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

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


VD>Это твой любимый эрланг заточен под прикладную задачу . А LINQ — это красиво завернутая (для казуалов) библиотека функций высшего порядка (Select -> map, Where -> Filter, OrderBy -> sort, ...). СУБД тут совершенно не причем. Просто LINQ позволяет как выполнить методы локально, так и преобразовать их в SQL для выполнения на сервере. Так что лучше потрать некоторое время на изучение вражеских лиц .


"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.

VD>Так вот в мои понятия "удобный" и "простой" входит скорее удобство и простота решения задач на языке, а не простота реализации языка. Иначе я бы программировал на Обероне, клоном которого и является этот Go.


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

G>>И представляешь, в гугле при разработке веб-приложений как-то обходятся без РСУБД.


VD>Да мне по барабану. Хотя если моя почта лежит не в БД, то мне как-то страшновато за ее целостность.


И им по барабану, что ты не можешь представить себе БД без SQL. Поэтому, они обходятся как-то в своем gmail БД BigTable, и не страдают от отсутствия LINQ.
Re[9]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 14:24
Оценка: 63 (6) +1
Здравствуйте, Ehudi, Вы писали:

G>>Понятия "простой" и "удобный" правда кажутся тебе настолько сложными, неоднозначными, и непонятными, что требуют уточнения, и стоят длинной дискуссии? Ты считаешь, их вообще возможно уточнить и договориться, чтобы они стали "общими"? Все-таки "философия программирования" — это зазеркалье какое-то.


E>Договориться один раз и навсегда не получиться. Но я считаю, что каждый раз, когда возникает неоднозначность, надо уточнять о чем идет речь.

E>Что касается слова простой, то оно не так просто.
E>Ведь то что кажется простым одному, для другого не просто.

Хорошо. Применительно к языкам программирования — простота выражается в разных аспектах:
1) Концептуальная простота языка. Характеризуется количеством понятий и концепций в самом языке. LISP, FORTH, Smalltalk, Erlang, Javascript, Brainfuck, и ассемблеры — концептуально простые языки, в базе там минимум.

2) Простота изучения. Характеризуется временем, которое надо потратить программисту на то, чтобы начать писать на языке настоящие программы, наиболее идеоматическим для языка образом. Мануал по концептуально простому Common LISP, невероятно толстый. Чтобы понять, как правильно надо писать на FORTH, который кажется простым до дебилизма, надо также развернуть мозг и потратить достаточно много времени. Эрланг как язык прост в изучении, однако OTP, без понимания которого писать нельзя — уже далеко не так прост. То есть, концептуально простой язык далеко не обязательно прост в изучении. Однако, в целом, пункты (1) и (2) кореллируют.

3) Простота использования. Характеризуется количеством времени и размышлений, необходимых для того, чтобы решить ту или иную задачу. Эта простота также характеризуется легкостью накосячить, насколько язык опасен. Совершенно очевидно, что данный пункт сильно зависит от сочетания языка программирования, и характера задачи. Также, он связан с остальными характеристиками языка. На брейнфаке писать тяжело, не смотря на его простоту. На языке и платформе 1С — легко решать определенный класс задач, несмотря на простой базовый язык и концептуально сложную платформу.

Этот пункт — отдельная, в целом независимая характеристика.

4) Простота чтения чужого кода. Да-да. Хорошая программа должна быть в первую очередь не короткой, "потому что язык выразительный", а понятной. Язык программирования — это в первую очередь средство общения человек-человек, и только во вторую — человек-машина. Этот пункт игнорируется большинством при оценке языков.

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

Капитан очевидность сообщает: в целом, идеальный язык должен:
1) Быть концептуально простым — содержать минимум понятий.
2) Требовать минимум времени на изучение. Взял, и сразу начал писать.
3) Задачи должны решаться быстро и прямолинейным образом. Самое прямолинейное решение должно быть кратким, и правильным, никаких "паттернов" быть не должно. Программист не должен бороться с языком, он должен думать о задаче.
4) Программы на нем должны быть читабельны, и пониматься всеми программистами простым и однозначным образом, требуя для этого понимания минимума дополнительных знаний и дерганий по коду. Открыл, и без проблем понял, что написано и о чем оно.

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

E>И мне кажется, что Вы это тоже должны понимать.


Характеристика "простой язык" — субъективна по своей природе. Могу пояснить, что когда я называю язык простым, я имею в виду пункты 1, 2, и 4). Когда я хочу охарактеризовать (3) — говорю "удобный".

Чтобы понять, _почему_ я считаю язык простым, надо:
1) Спросить меня об этом,
2) Посмотреть спецификацию Go, черт возьми.

Тратить вместо этого время на обсуждение, уточнение, и согласование смысла слов "простой", "сложный" и прочее — это только здесь у вас в зазеркалье такое поведение считается естественным и нормальным. Я это нормальным не считаю.
Re[10]: LINQ только для РСУБД!
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.11.09 17:50
Оценка: 16 (1) +2 -3
Здравствуйте, Воронков Василий, Вы писали:

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


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


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

ВВ>С помощью какой магической комбинации слов тебе нужно объяснить, что ты не прав?

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

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

И, как это сплошь и рядом бывает, фича оторвалась и зажила своей жизнью.
The God is real, unless declared integer.
Re[14]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 15.11.09 12:36
Оценка: +4 :))
Здравствуйте, AndrewVK, Вы писали:

AVK>Иногда полезно посмотреть на себя со стороны. Другим точно так же твои выступления кажутся засовыванием в каждую дырку С++. Вообще, чуть менее чем все местные завсегдатаи имеют свою собственную серебрянную пулю, которую они таки пытаюся засунуть всюду — дотнет, хаскель, оберон, ерланг, хаскел, питон, немерле, ФП, МП и прочая и прочая.


То есть, ты считаешь, что большинство завсегдатаев данного форума не в состоянии подходить к вопросу технологий объективно, ибо по сути являются фанбоями, имеющими любимые игрушки — серебрянные пули.

Спасибо. Учту. Это многое объясняет.

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

http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_(%D0%BF%D1%81%D0%B8%D1%85%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F)

Я это тебе говорю, не с целью тебя позлить, а чтобы помочь тебе посмотреть на себя со стороны. Это полезно.
Re[4]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 11.11.09 22:18
Оценка: -1 :))) :)
Здравствуйте, Alexey Axyonov, Вы писали:

G>>"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.


AA>Интересно в каком из слов Language, Integrated, Queries ты нашел упоминание о СУБД.


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

http://ru.wikipedia.org/wiki/Language_Integrated_Query

Потом попробуй мне объяснить, каким именно боком LINQ, SQL, и реляционная модель тебе пригодиться, к примеру, при работе с базой данных построенной на схеме map-reduce. Если не слышал о таких — погугли.

Вообще есть огромный мир, лежащий за рамками того, к чему вы привыкли. Мир, в котором сервера работают не под Windows, и в котором не применяют РСУБД. В задачах телекома, к примеру, покажешь мне, в какое место засунуть ваш LINQ, и каким образом люди без него спокойно обходятся? Вне контекста баз данных, разумеется. Он же типа совсем-пресовсем никакого отношения к ним не имеет.
Re[6]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 11.11.09 23:49
Оценка: -5
Здравствуйте, Воронков Василий, Вы писали:

ВВ>У тебя не возникает сомнения, что твое мнение о LINQ на основе статьи из википедии может быть, скажем так, не совсем полным?


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

А тебе не приходило в голову, что я могу, понимая, что такое LINQ, относиться к нему в большой степени спокойно, и не считаю его офигенски крутой штукой, по той причине, что не вижу от него выраженной пользы в своих задачах?

Задачу сервера IP телефонии, к примеру, ты себе достаточно хорошо представляешь, чтобы у тебя не возникало сомнения в том, что польза знакомых тебе приемов и языковых средств может быть весьма зависима от природы задачи? А сервера обработки биржевых данных? А конвейра мультимедиа-плеера для цифрового телевидения? Среды моделирования микроэлектронных устройств?

Понимаешь, бывает так, что приложение построено вовсе не вокруг набора бизнес-объектов, по которым надо собирать аналитику и выполнять бизнес-логику. Ну вот бывает так. А в биржевых задачах с таймсериями, прикинь, джойнов практически нет. И логика в стиле SQL нифига не раскладывается, если надо строить агрегаты вроде P&F. А в медиаконвейре — вообще другие проблемы. Ну нет там никаких "запросов", прикинь — там потоковая обработка, парсинг стека протоколов, и их синхронизация.

И дофига таких задач на самом деле, понимаешь? Вот мне сплошь они попадаются уже лет 9 как. И то, что у вас там "на самом деле" произвольные источники данных, и что кастомайзить там все типо можно круто, что ваще это цельный типо-скриптовый-ембеднутый фреймворк такой, и можно для всего кроме баз данных это прикрутить — ну не имеет это большого значения. Дело в том, что сам характер работы с данными может быть _другим_, так что нафиг это все не нужно, нет значимого выигрыша.
Re[25]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 22:40
Оценка: +3 -2
Здравствуйте, Lloyd, Вы писали:

G>>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?


L>По-моему, все, что ты доказал — это то, что в go с помощью костылей можно съимитировать то, что на linq-е делается просто и красиво.


Не знаю, где ты видишь здесь "костыли". Я вот, например, вижу равное количество строк кода, одинаковый алгоритм, и существенно меньшие требования к подготовке читателя кода с циклами, при большей простоте языка и употребляемых конструкций. Все компактные решения через линк по сути просто переписывают циклы, не выигрывая при этом в выразительности ни капли, в отличии от comprehensions на базе честной ZF-нотации, а наоборот, вызывая у неподготовленного человека заворот мозгов на ровном месте.

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

Может быть, примеры не самые удачные? Так приведите удачные.
Re[26]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 24.11.09 05:27
Оценка: +3 :))
Здравствуйте, Gaperton, Вы писали:

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

G>А и не сужу о технологии. Я характеризую ровно то, что вижу, и не более того.

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


Я очень рад это слышать.

G>Я спрашиваю: "дальше что", то есть, ты-то что думаешь об этих примерах сам? Вот честно? Например, ты можешь сказать что-то вроде "да, действительно, вы подобрали поганые примеры, эти примеры не раскрывают силу технологии, она сильна в другом".


Я думаю, что примеры подобраны правильно, чтобы продемонстрировать нецелевое использование предмета обсуждения. Мы, в свою очередь, пытались доказать не то, что "Linq is the best of the best of the best", а показать, что с помощью Linq можно решать и такие задачи. Если бы ГВ спросил меня как бы я решал подобную задачу в реальности, а не в сферичности, то я бы ответил, что скорее всего обошёлся бы банальным циклом, т.к. для меня важнее простота и гибкость кода. С другой стороны твои комментарии вроде "Так держать" свидетельствуют о желании найти любой недостаток, в который можно было бы ткнуть пальцем как в том анекдоте:

Вышли из леса суровые русские мужики и увидели японскую бензопилу.
— А-а, б**! — сказали суровые русские мужики и засунули в пилу щепку.
— Вжик! — сказала пила и распилила щепку.
— У-у, б**! — сказали суровые русские мужики и засунули в пилу доску.
— Вжжик! — сказала пила и распилила доску.
— У-у, б**! — сказали суровые русские мужики и засунули в пилу бревно.
— Вжжжжик! — сказала пила и распилила бревно.
— У-у, б**!!! — сказали суровые русские мужики и засунули в пилу рельс.
— Хррр-дзинь — сказала пила и сломалась.
— А-а, б**... — сказали суровые русские мужики и пошли валить лес топорами.

Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 11.11.09 19:52
Оценка: -1 :)))
Здравствуйте, VladD2, Вы писали:

G>>"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.


VD>Ну, что же почитай манулы по C# 3.0. Потом обсудим еще раз. А то пока что разговор явно идет на уровен казуалов.


Извини, мне не интересно ни читать мануалы по С# 3.0, ни обсуждать с тобой LINQ. И то и другое имеет весьма далекое отношение к моей работе и интересам.

G>>Ну, я же хорошо осведомлен о твоих понятиях. И я знаю, что в их рамках адекватно описывается весьма ограниченный круг задач и ситуаций. Менять твои понятия в мои планы не входит.


VD>Не пойму, то ли ты потихонечку сливаешь спор переходя на личности, то ли стал настолько философом, что тебя стало трудно понять.

VD>Ты что этим пассажем сказать то хотел?

Разъясню, мне не трудно. Я хотел сказать ровно то, что сказал, в ответ на это:
VD>Так вот в мои понятия "удобный" и "простой" входит скорее удобство и простота решения задач на языке, а не простота реализации языка. Иначе я бы программировал на Обероне, клоном которого и является этот Go.

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

Не смотря на это, я бы может быть пообщался с тобой и на тему "понятий", если бы это было приятно и познавательно. Однако, не секрет, что манеры общения у тебя ни к черту, а от своих "понятий" ты ни в коем случае не откажешься. Подбив все вместе — ну и нафига мне с тобой твои "понятия" обсуждать? Толку ноль.

G>>И им по барабану, что ты не можешь представить себе БД без SQL.

VD>А причем тут SQL?
G>>Поэтому, они обходятся как-то в своем gmail БД BigTable, и не страдают от отсутствия LINQ.
VD>Да пусть не страдают. Главное что все же моя почта лежит в БД и управляется СУБД, а не кодом на доморощенном языке написанном на левой коленке.

И причем тут Немерле?
Re[10]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 13.11.09 17:58
Оценка: +2 -1 :)
Здравствуйте, AndrewVK, Вы писали:

G>>Я вот совершенно уверен в том, что _мне_лично_ выгода не очевидна.


AVK>Отличная позиция. Не знаю и знать не хочу. Только остальным то какое до этого дело?


Позиция не такая. "Из того, что об этом знаю — мне кажется, что выгода не очевидна" Вот такая позиция.

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

Хочешь показать выгоду — объясни.

G>>Я вижу, тебе по какой-то причине важно подчеркнуть, что у тебя опыт использования LINQ есть


AVK>Нет. Но если делаешь заявления — будь добр их аргументировать.


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

Но не тогда, когда я не спорю, а выражаю мнение. Я могу отказаться спорить на те темы, которые мне не интересны, и остаться при своем мнении. Никакой катастрофы в этом я не вижу.

Тема LINQ притянута за уши, и отношения к языку Go не имеет. В этом треде, сейчас, я не хотел на нее отвлекаться, и тем более тратить энергию на спор. Ты не согласен с моим мнением? Хочешь на него повлиять? Объясни, что именно я по твоему не учитываю или не понимаю. Я приму к сведению, возможно — отвечу. Попытаешься вместо этого спорить — не получится, я откажусь.

У меня получилось объяснить тебе мою позицию, Андрей?

G>>, а у меня нет. Пожалуйста. Да, опыта использования LINQ у меня в районе ноля, если не считать, что он похож на query list сomprehesions Эрланга, конечно.


AVK>Оно тоже исключительно под реляционные БД заточен?


Нет, конечно. Она by design с произвольными источниками работает.

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

AVK>>>Вот этот тезис — неверен и бездоказателен.


G>>Считаешь что неверен — возрази.


AVK>Еще раз — ты выдвинул, тебе и доказывать. И никак иначе.


Еще раз. Я не "выдвинул". А выразил мнение. Сообщил, что я думаю, без цели кого-либо в этом убеждать.

Мнение не тезис — оно идет as is. Не согласен — не соглашайся. Требовать доказательств не можешь — с тобой собственно, никто не спорит, и мы не в суде. Не имею желание тратить время — не доказываю. В треде о Go — не имею желания спорить о LINQ.

G>> Будут нормальные доводы — не только соглашусь, но и спасибо скажу.


AVK> достаточно взглянуть на имеющиеся прямо в BCL linq2objects и linq2xml, про которые упомянуто даже в бездарной статье в русской википедии. Ссылку на linq для CoachDB тебе тоже уже приводили. Есть linq для db4o. Этого мало?


Я, видишь-ли, ссылок у тебя не просил. Я вообще ничего не просил, что давало бы тебе повод спрашивать "этого мало?".

Я же тебе сказал — сейчас тема мне не интересна. Поэтому, ничего активно искать, рыть, и читать сейчас я не буду. Но если тебе хочется объяснить мне где я неправ — внимательно выслушаю. Если ты потратишь время, и дашь краткую выжимку, поделившись тем, что знаешь, съкономив время мне — я искренне буду тебе благодарен, потому что ценю не только свое время, но и твое — то которое ты потратил. Это — нормальное, человеческое поведение.

Если тебе не хочется — ну не объясняй, пусть я при своем мнении останусь, какое тебе дело в конце концов.

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

AVK>Нормальные доводы лежат на поверхности...


Тем более не вижу причин гнуть понты и не показать их кратко, дав выжимку. Имей в виду, что я тебя об этом не прошу. Только, если тебе самому хочется. Я не сильно заинтересован в этом разговоре.
Re[10]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 13.11.09 21:16
Оценка: -2 :))
Здравствуйте, Воронков Василий, Вы писали:

ВВ>С помощью какой магической комбинации слов тебе нужно объяснить, что ты не прав?


Удивительное рядом. Скажи мне, а почему именно тебе так сильно хочется это сделать — объяснить мне, что я не прав? Причем, до такой степени сильно, что подбор магической комбинации слов ты начал с откровенного хамства? Пост-то свой хамский помнишь, да? Не стыдно?

По поводу магической комбинации — я тебе сейчас объясню, что происходит, и почему у тебя не получается.

Видишь-ли, воспитанные люди, ведя степенную беседу, объясняют собеседнику не "что он не прав", а "в чем он не прав". Причина этого обычая, и тонкая разница, может от тебя ускользнуть, но она крайне проста. Чтобы объяснить первое, достаточно просто дать человеку в торец, а вот чтобы объяснить второе — необходимо уже включить верхнюю голову (не у всех получается), напрячь извилины (не у всех есть), и попытаться понять (не все хотят), что он, собеседник, вообще сказать-то хочет.

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

Так что единственное, что могу тебе посоветовать — это испробовать второй способ. Да, и над вопросом первым ты все-таки подумай. Вот, к примеру, у меня почему-то нет совершенно никакого непреодолимого желания объяснять тебе, что ты неправ.
Re[16]: Исправлена ссылка
От: FR  
Дата: 15.11.09 13:13
Оценка: +2 -1 :)
Здравствуйте, Gaperton, Вы писали:

G>>Оценка, которую человек выдает окружающим при недостатке информации — на самом деле больше говорит о самом человеке и его взгляде на мир, чем об окружающих. В частности, человек часто приписывает собственные черты, которые он не осознает, окружающим. Этот механизм называется "психопроекция".


G>Ссылка битая. здесь — рабочая.


Влад все-таки прав насчет мозговедства.
Re[17]: А-а-а-а-а-а! Я понял!!!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.11.09 07:01
Оценка: +2 :))
Здравствуйте, Gaperton,

RSDN-ейшая из RSDN-ейших инквизиций требует от заблудшего признать существование минималистически глобального универсального всемогутера! Просто кристально чистый образец деления на нуль и умножения на пустое множество. Достоин внесения во всяческие анналы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 22:22
Оценка: +1 -1 :))
Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?
Re[24]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 23.11.09 23:34
Оценка: +4
Здравствуйте, Gaperton, Вы писали:

G>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?


Я бы не стал судить о технологии на основании примеров, которые подбирались специально, чтобы посмотреть на неё в сценариях с нецелевым использованием.
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.09 00:48
Оценка: +3 -1
Здравствуйте, VladD2, Вы писали:

VD>>def (_, _, res) = lst.Aggregate((0, true, List()), ((prev, skip, res), cur) =>

VD>> if (skip) (cur, false, res)
VD>> else if (prev + 1 == cur) (cur, true, { res.Add(cur); res })
VD>> else (cur, false, res));

VD>Туплю. Можно еще проще:



VD>
VD>def (_, _, res) = lst.Aggregate( (  0,  true, List()), ((prev, skip, res), cur) =>
VD>   if (!skip && prev + 1 == cur) (cur,  true, { res.Add(cur); res })
VD>   else                          (cur, false, res));
VD>


Вот уж точно — иная простота хуже...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 09:53
Оценка: 37 (2) -1
Здравствуйте, yuriylsh, Вы писали:

Y>>>Странно, я вроде именно это и пытался сделать (впрочем, не только я). Даже болдом в цитате выделил проблему, решаемую LINQ, и она более значима, чем OR-mapping, ибо OR-mapping это лишь частный случай выделенной проблемы.


G>>Извини, не заметил. Попробуй еще раз — в чистом виде. Внимательно рассмотрим.


Y>Если до сих пор не заметил — дальнешее общение с тобой по этой теме — бесполезная трата времени. Засим отклниваюсь.


Молодец.

В догонку я тебе поясню, почему я не заметил.

Проблема "импеданса" при работе с неизвестными моделями данных данных — так же неизвестная, как эти неизвестные модели. Эта "проблема" по очевидной причине не стоит, и пока неизвестные модели не станут известными, проблемой не является, и поэтому — решена быть не может.

Никто и никогда не станет закладывать в язык фичу, имея цель решить воображаемые проблемы. Настоящие проблемы, на самом деле требующие решения, всегда звучат конкретно. Вот ORM — это проблема.

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

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

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

Что меня очень сильно радует.
Re[27]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 21:08
Оценка: 1 (1) +2
Здравствуйте, Gaperton, Вы писали:

L>>2)

L>>

L>>при этом извлечённый элемент не должен принимать участия в последующем сравнении

L>>Ты же заменил 2-е условие на другое:
L>>

L>>при этом предшествующий элемент не должен удовлетворять первому условию

L>>А такая замена некорректна.

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


Нет, он не удовлетворяет условию. Возьми последовательность {1, 2, 3, 4} и убедись.

G> Это можно строго доказать при желании.


Ты че такой упертый? Сам же видишь, что не прав, но продолжаешь упираться. Твой алгоритм даже на тестовом примере, что был изначально приведен, даст ответ, отличный от ожидаемого. О чем тут спорить?
Re[20]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.11.09 02:30
Оценка: 1 (1) +2
Здравствуйте, IT, Вы писали:

G>>Первая задача решена может и правильно, но однозначно чудовищно.

IT>О чудовищности мы можем поговорить отдельно.

Собственно, это главная фишка.

IT>Главное не это. Мы то все понимаем, что расчёт ГВ был прост и незатейлив — учитывая, что Linq работает с последовательностями, предложить задачу, в которой требуется обращение к предыдущему/последующему элементам, да ещё необходимо сохранять промежуточное состояние. В принципе, расчёт был верен, да вот только Linq не запрещает ни использование состояния, ни счётчиков, ни всего остального.


Всё так. Linq и в самом деле не запрещает использовать состояния, счётчики и всё прочее. Как бы это он смог что-то запретить, когда мы располагаем ссылками на объекты и таким артефактом, как не зависимые от Linq области видимости имён? Тут дело в другом. Пока что из показанных Linq-примеров самые компактные являются гипертрофированными операторными скобками к обычным циклам. Это не считая того, что в этих самых "циклах" ещё и примешаны лямбды. Если такая запись называется упрощением цикла, то кто-то что-то очень сильно путает.

IT>В реальных же задачах неумение свести задачу к обработке последовательности в большинстве случаев говорит лишь о неумении это делать. foreach в C# не просто так придумали, это как раз говорит о том, что большинству алгоритмов даже номер элемента в последовательности знать совсем не обязательно. А случаи, где это нужно знать как правило работают с двумя и более последовательностями и индекс нужен просто потому, что по другому это выразить нельзя. Хотя можно склеить две последовательности и получить тот же эффект и без индексов.


Игорь, давай без ссылок на большинство, реальность и разные "как правило". Вот здесь
Автор: Геннадий Васильев
Дата: 22.11.09
приведён пример, построенный на упрощённой реальной задаче. Как думаешь, получится решить его на Linq компактнее, чем циклами?

IT>[...] вести разговор в продуктивном ключе [...]


Двумя руками "за". Show me your code, ok?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[38]: LINQ только для РСУБД!
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 24.11.09 12:50
Оценка: 1 (1) +2
Здравствуйте, Lloyd, Вы писали:

L> В нем нет изменяемых данных, но есть нечто, что [...] меняется.


8-0 Это как?

state у тебя меняется явно в определении AttachState. А то, что у тебя при использовании AttachState, так это аргумент и результат функции, они да — неизменны. Например, item в Select тоже меняется

Насчёт состояние == мутабельность, это, конечно, не совсем так, но обычно, когда говорят "состояние" подразумевают именно изменяемое состояние. Обычно мало смысла говорить о неизменяемом состоянии:

const = 5


Глобальная переменная const — неизменяемая. Состояние или нет? Если да, то состояние — это что угодно, если нет, то под глобальным состоянием следует понимать именно изменяемое состояние. Как то так.
Re[5]: LINQ только для РСУБД!
От: Воронков Василий Россия  
Дата: 11.11.09 22:49
Оценка: +1 :))
Здравствуйте, Gaperton, Вы писали:

У тебя не возникает сомнения, что твое мнение о LINQ на основе статьи из википедии может быть, скажем так, не совсем полным?
Re[13]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.11.09 08:36
Оценка: +3
Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Пока что понты в топике больше от тебя


ГВ>Андрей, знал бы ты, как уже осточертело засовывание .Net и приблуд к нему по любому чиху в любую дырку.


Иногда полезно посмотреть на себя со стороны. Другим точно так же твои выступления кажутся засовыванием в каждую дырку С++. Вообще, чуть менее чем все местные завсегдатаи имеют свою собственную серебрянную пулю, которую они таки пытаюся засунуть всюду — дотнет, хаскель, оберон, ерланг, хаскел, питон, немерле, ФП, МП и прочая и прочая.
... << RSDN@Home 1.2.0 alpha 4 rev. 1284 on Windows 7 6.1.7600.0>>
AVK Blog
Re[13]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 03:32
Оценка: +1 -2
Здравствуйте, Геннадий Васильев, Вы писали:

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

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

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


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


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

ГВ>

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

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


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


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

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

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

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

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

И высказано это "мнение" было не просто так в рамках общего повествования, а в качестве аргумента в пользу тезиса, что наличие ЛИНК-а усложняет язык.
В Гугле, видите ли, не используют РСБУД. А кто об этом вообще спрашивал или говорил? Это "аргумент" основанный на полном не понимании приведенного примера. И как можно было о чем-то там продолжать говорить если Гапертон сам ушел от темы при этом выдвинув целых два утверждения не соответствующих действительности?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 17.11.09 09:25
Оценка: +1 -1 :)
Здравствуйте, 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 — я уже давно не чувствую в этом разговоре совершенно никакой практической пользы, а теперь — просто устал. Спасибо за конструктивную беседу.
Re[15]: LINQ только для РСУБД!
От: yuriylsh  
Дата: 18.11.09 03:00
Оценка: +3
Здравствуйте, Gaperton, Вы писали:

Y>>Неправильно. Идея игнорирования (Objects, XML например) — это как раз твоя прерогатива. Чтобы доказать твою неправоту не нужно игнорировать реляционные данные, достаточно показать, что это только один из источников.


G>Неправильно. Для этого недостаточно показать, что это один из источников. Что для этого достаточно — это обозначить другую проблему, кроме OR-mapping, решаемую LINQ, и продемонстрировать, что она как минимум не менее значима, чем OR-mapping. Этого никто не сделал. Даже не попытался.


Странно, я вроде именно это и пытался сделать (впрочем, не только я). Даже болдом в цитате выделил проблему, решаемую LINQ, и она более значима, чем OR-mapping, ибо OR-mapping это лишь частный случай выделенной проблемы.

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


Y>> И если цель была реляционные данные, зачем было городить огород с моделью провайдеров, включать реализацию LINQ to Objects, LINQ to XML?


G>Если основная цель и мотивация разработки — реляционные данные (т.е. сделать ORM менее геморройным), это вовсе не отменяет желания разработчиков сделать это посредством не узкозаточенной штуки, а более общего механизма, который способен заодно решать и более мелкие проблемы, и обрабатывать данные разных типов единообразно. Хорошее желание, правильное. Вот ровно как в статье, что ты привел, написано. Никакого противоречия тут нет.


Мда, если принять свою предпосылку за верную, то можно на этой основе строить рассуждения подтверждающие ее верность А насчет ровно как в статье...
Давай посмотрим. Вот исходный пример "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." Обрисовал он текущее положение вещей. Теперь продолжение: " 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". Какая модель данных потерялась? Объясни, если несложно, как ты не видишь здесь противоречия с тем, что основная цель разработки — решить проблему с одной единственной моделью данных (реляционной, именно которую он для примера и заменяет какой-то абсолютно новой). Он говорит что цель — работать с любыми моделями данных, пускай даже сейчас неизвестными, а ты утверждаешь, что нет, основная цель — реляционные данные. Действительно, никакого противоречия. Он говорит про 3 преобладающие модели данных (и как результат — эти модели доступны "из коробки" на момент релиза), абсолютно без ранжирования, ты работу с одной называешь главной, а другие — более мелкими проблемами. Действительно, вот ровно как в статье.

G>К сведению, "огород с разными провайдерами" городили еще в OLE DB. Можно сделать OLE DB провайдера к любому источнику — к файловой системе или ящику электронной почты. Я надеюсь, сомнений в основном предназначении OLE DB, несмотря на это, у тебя не возникает?


Ага, в ASP.NET тоже модель провайдеров естью И сомнений предназначение не вызывает. А при чем здесь LINQ?

Y>>Зачем что-то выкидывать? Опять тебя в крайности кидает.


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


G>Если ведущая проблема — не ORM, а XML+Objects, то нет никакого смысла тянуть SQL-синтаксис, и устраивать все так, как оно выглядит. Ибо можно проще. Здесь я полностью согласен с netch80.


Нет, ведущая проблема не XML+Objects, не ORM, не [подставь_свое], а независимость от модели данных, я ж даже выделил это в цитатах.По-этому рассматривать каждую модель "изолировано" и смысла нету.
Насчет SQL-синтаксиса, в цитате тоже есть ответ "then try to translate this into something that normal programmers can understand". SQL понимают большинство программистов — вот им и синтаксис привычен. При этом это не единственный синтаксис для работы с LINQ, более того, query expression keywords в С# даже не перекрываютquery standard query operators — ты не найдешь аналогов Distinct(), Min()/Max(), Any() и т.д.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[18]: А-а-а-а-а-а! Я понял!!!
От: IT Россия linq2db.com
Дата: 19.11.09 15:02
Оценка: :)))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>RSDN-ейшая из RSDN-ейших инквизиций требует от заблудшего признать существование минималистически глобального универсального всемогутера! Просто кристально чистый образец деления на нуль и умножения на пустое множество. Достоин внесения во всяческие анналы.


Ты сильно не зарывайся. Обсуждение инквизиции запрещено правилами форума, за это можно на сутки-двое и на костерок загреметь.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 06:47
Оценка: +3
Здравствуйте, IT, Вы писали:

G>>По-простому, это без ФВП и линков.


IT>Что плохого в ФВП, если они позволяют упрощать и угибчать код?


В ФВП, как в выразительном средстве — совершенно ничего плохого. Но решение без ФВП при прочих равных проще понимать. Во многих случаях.
Re[15]: LINQ только для РСУБД!
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 20.11.09 14:03
Оценка: :)))
Здравствуйте, VladD2, Вы писали:

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


VD>Ответа явно не будет. Что и требовалось доказать.

VD>Слив засчитан. Больше я на твой тролинг попадаться не буду.

Влад. Ты сам себе отвечаешь.
Re[26]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 24.11.09 00:59
Оценка: +3
Здравствуйте, Lloyd, Вы писали:

L>Мне вот что инетерсно:

Интересно — отвечаем.

L>ты считаешь, что все, кто использует Linq-to-Objects, делают это не по причине удобства, а по какой-то другой причине?


Я считаю, что приведенные примеры не показывают силу Linq-to-Objects. Она, по всей видимости, проявляется на каких-то других задачах.

И второе — да, я таки считаю, что отчасти линк используют на ровном месте просто "потому, что это круто". Я наблюдал подобную мотивацию и поведение у многих программистов на С++, когда они применяют шаблоны. И за некоторыми из которых вычищал от шаблонов а-ля Александреску код. Я думаю, частично подобная мотивация присутствует и у некоторых программистов на линк.

L> Или ты считаешь, что никто Linq-to-Objects не использует?


Нет, я так не считаю.
Re[22]: LINQ только для РСУБД!
От: Undying Россия  
Дата: 25.11.09 05:32
Оценка: +1 -2
Здравствуйте, IT, Вы писали:

IT>В данном случае простота напрямую зависит от уровня подготовки. Не секрет, что один и тот же код для одного человека может быть простым, а для другого сложным. Это как раз тот самый случай. Вот тут
Автор: IT
Дата: 22.09.08
я давал пример одного и того же алгоритма на Linq и в императивном стиле. Разница очевидна. ФП привносит в код декларативность, а значит простоту и гибкость. Но всё это требует определённой подготовки.


А совмещение императивного и функционального подхода читается еще проще:

    static Dictionary<string, List<Percent>> CalcPercents2(
        ProvidingVolume[] providingVolumes, ReceivingVolume[] receivingVolumes)
    {
      Dictionary<string, List<ProvidingVolume>> providingGroup = new Dictionary<string, List<ProvidingVolume>>();
      foreach (ProvidingVolume pv in providingVolumes)
        providingGroup.GetOrCreateValue(pv.Provider).Add(pv);

      Dictionary<string, List<ReceivingVolume>> receivingGroup = new Dictionary<string, List<ReceivingVolume>>();
      foreach (ReceivingVolume rv in receivingVolumes)
        receivingGroup.GetOrCreateValue(rv.Account).Add(rv);

      Dictionary<string, double> receivingSum = new Dictionary<string, double>();
      foreach (List<ReceivingVolume> list in receivingGroup.Values)
        receivingSum[list[0].Account] = list.Sum(delegate(ReceivingVolume rv) { return rv.Volume; });

      Dictionary<string, List<Percent>> percents = new Dictionary<string, List<Percent>>();
      foreach (List<ProvidingVolume> list in providingGroup.Values)
      {
        double sum = list.Sum(delegate(ProvidingVolume pv) { return pv.Volume; });

        foreach (ProvidingVolume pv in list)
        {
          List<ReceivingVolume> rv = receivingGroup.FindObject(pv.Account);
          if (rv != null)
          {
            foreach (ReceivingVolume r in rv)
            {
              Percent percent = new Percent();
              percent.Provider = pv.Provider;
              percent.Receiver = r.Receiver;
              percent.Account = pv.Account;
              percent.Value = pv.Volume / sum * r.Volume / receivingSum[r.Account];

              percents.GetOrCreateValue(percent.Provider).Add(percent);
            }
          }
        }
      }

      return percents;
    }


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

        static Dictionary<string, List<Percent>> CalcPercents(
            ProvidingVolume[] providingVolumes, ReceivingVolume[] receivingVolumes)
        {
            var percents = 
                from percent in
                    from prov in
                        from p in providingVolumes
                        group p by p.Provider into pg
                        let total = pg.Sum(v => v.Volume)
                        from pp in pg
                        select new { pp, total }
                    join rec in
                        from r in receivingVolumes
                        group r by r.Account into rg
                        let total = rg.Sum(v => v.Volume)
                        from rr in rg
                        select new { rr, total }
                    on prov.pp.Account equals rec.rr.Account
                    select new Percent
                    {
                        Provider = prov.pp.Provider,
                        Receiver = rec.rr.Receiver,
                        Account  = prov.pp.Account,
                        Value    = prov.pp.Volume / prov.total * rec.rr.Volume / rec.total
                    }
                group percent by percent.Provider;

            return percents.ToDictionary(p => p.Key, p => p.ToList());
        }
Re[15]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 20.11.09 02:26
Оценка: 52 (2)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот ещё пара встречных вопросов:


ГВ>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?


int lastNdx = int.MinValue;
var q1 = Enumerable.Range(1, arr.Length - 1).Where(i => {
    if (i == lastNdx + 1 || arr[i] != arr[i - 1] + 1) {
        return false;
    } else {
        lastNdx = i;
        return true;
    }
}).Select(i => arr[i]);


ГВ>2) Тот же массив, но нужно извлечь элементы, отстоящие на +/-1 от выбранного. Т.е. результат — {1, 3, 7, 9}.


var q2 = arr.Where(n => q1.Contains(n - 1) || q1.Contains(n + 1));


ГВ>Как ты понимаешь, традиционным for обе задачи решаются тривиально.


Re[11]: LINQ только для РСУБД!
От: yuriylsh  
Дата: 17.11.09 03:54
Оценка: 43 (1) +1
Здравствуйте, 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.


Как ты можешь заметить идей было обстрагировать любой источник данных чтобы можно было работать единообразно. И говорить что "возникло оно именно как средство работы для РСУБД" неправильно.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[27]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 20:47
Оценка: 38 (2)
Здравствуйте, Геннадий Васильев, Вы писали:

L>>Ну это еще цветочки. Ты не видел какой мрак получается с бесконечными последовательностями.


ГВ>Дык, я уже трепещу. Давай, свей мой разум в невозможную фигуру!


Кушать подано:
using System;
using System.Collections.Generic;
using System.Linq;

class Program {
    static void Main(string[] args) {
        var arr = new[] { 1, 2, 3, 7, 8, 9, 10 };
        var q = arr
            .Zip(arr.Skip(1), (prev, curr) => new { curr, prev })
            .Select((item, i) => new { item.curr, item.prev, i })
            .Where(item => item.curr == item.prev + 1)
            .AttachState(
                () => new { include = true, prev = -1 },
                (item, prevState) => new {
                    include = !prevState.include || (prevState.prev + 1 != item.i),
                    prev = item.i
                },
                (item, state) => new { item.curr, state.include }
            )
            .Where(item => item.include)
            .Select(item => item.curr);

        foreach (var item in q) {
            Console.WriteLine(item);
        }
    }
}

public static class StateEnumerableExtensions {
    public static IEnumerable<TResult> AttachState<T, TState, TResult>(
        this IEnumerable<T> source,
        Func<TState> getInitialState,
        Func<T, TState, TState> getNextState,
        Func<T, TState, TResult> selector
    ) {
        var state = getInitialState();
        foreach (var item in source) {
            yield return selector(item, state);
            state = getNextState(item, state);
        }
    }
}
Re[15]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 20.11.09 03:26
Оценка: 22 (1) :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Кроме того, насколько я понимаю, возможности LINQ по обработке агрегатов и вложенных запросов должны быть несколько уже, чем у SQL Server.


Шире, Гена, значительно шире.

ГВ>Возможно, что будут заморочки с having или где-то в районе вложенных запросов.


Where либо раскладывается на Having и Where, либо запрос оборачивается в подпзапрос при невозможности это сделать. Linq 2 SQL, например, не заморачивается и всегда идёт вторым путём.

ГВ>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?


ГВ>2) Тот же массив, но нужно извлечь элементы, отстоящие на +/-1 от выбранного. Т.е. результат — {1, 3, 7, 9}.


Ты про это что ли?

var arr  = new[] { 1, 2, 3, 7, 8, 9, 10 };
var list = new List<int>();
Func<int,bool> func = i => { list.Add(i); return true; };

var q1 =
    from a in arr.Select((n, i) => new { i, n })
    let prev = a.i - 1
    where
        prev >= 0 && a.n - 1 == arr[prev] && !list.Contains(prev) && func(a.i)
    select new { a.i, n = arr[a.i] };

foreach (var p in q1)
    Console.Write("{0} ", p.n);

var q2 =
    (from i in q1 select arr[i.i - 1]).
    Union(
    (from i in q1 where i.i + 1 < arr.Length select arr[i.i + 1])).
    OrderBy(i => i);

foreach (var p in q2)
    Console.Write("{0} ", p);


ГВ>Как ты понимаешь, традиционным for обе задачи решаются тривиально.


Да оно и так как бы ничего
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Я всё ж таки вот, о чём думаю
От: Lloyd Россия  
Дата: 22.11.09 19:06
Оценка: 22 (1) :)
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Where как и любой другой метод Linq — это и есть решение с помощью yield return. Поставь в месте где у тебя foreach arr.Where и получишь с небольшими модификациями практически тоже самое. Там где у тебя yield return будет return true, в остальных местах return false.


ГВ>Хммм... А с состоянием что делать? Может, лучше ты сам покажешь?


var q1 = arr
    .Where(((Func<Func<int, bool>>)(() => {
        bool first = true;
        int prev = 0;
        return i => {
            if (first) {
                first = false;
                prev = i;
                return false;
            } else if (i - prev == 1) {
                first = true;
                return true;
            } else {
                prev = 1;
                return false;
            }
        }; 
    }))());

Re[21]: LINQ только для РСУБД!
От: yuriylsh  
Дата: 23.11.09 05:31
Оценка: 22 (2)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Игорь, давай без ссылок на большинство, реальность и разные "как правило". Вот здесь
Автор: Геннадий Васильев
Дата: 22.11.09
приведён пример, построенный на упрощённой реальной задаче. Как думаешь, получится решить его на Linq компактнее, чем циклами?


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

IT>>[...] вести разговор в продуктивном ключе [...]


ГВ>Двумя руками "за". Show me your code, ok?


Ну так и начал бы с собственного решения на циклах?
Для твоей первой задачи.
Пускай у нас есть структура R:
public struct R
    {
        public TimeSpan time;
        public int value;
        public bool mark;
    }

И пускай у нас есть некий генератор входных данных generator, который кидает событие,когда пришло новое значение R.
Тогда можно подписатья на него как-то так:
var ro = Observable.FromEvent<REventArgs>(g, "R_arrived_event").Select(ea => ea.R);

Наколенное решение задачи будуте что-то вроде такого (я заменил везде Seconds на Milliseconds, чтобы не состариться пока отлаживаю ):
List<R> buffer = new List<R> { new R() };
ro.Do(r =>
          {
              buffer.RemoveAll(rr => r.time - rr.time > TimeSpan.FromMilliseconds(1800));
              buffer.Add(r);
          })
    .Where(r => r.mark)
    .Subscribe(r => Console.WriteLine("mark = true at {0}, first within 1800 ms: {1}", r.time.TotalMilliseconds,
                                      buffer[0].time.TotalMilliseconds));



P.S. Так как как у меня под рукой нету генератора , то использовал твои данные для проверки (это если кто-то еще захочет проверить), добавив в конец еще одно контрольное число с mark=true для пущей уверенности:

var rdata = new[]
                {
                    new R{mark = false,time = TimeSpan.FromMilliseconds(840), value = rnd.Next()},
                    new R{mark = false,time = TimeSpan.FromMilliseconds(928), value = rnd.Next()},
                    new R{mark = false,time = TimeSpan.FromMilliseconds(1100), value = rnd.Next()},
                    new R{mark = false,time = TimeSpan.FromMilliseconds(1657), value = rnd.Next()},
                    new R{mark = false,time = TimeSpan.FromMilliseconds(1799), value = rnd.Next()},
                    new R{mark = false,time = TimeSpan.FromMilliseconds(1948), value = rnd.Next()},
                    new R{mark = true,time = TimeSpan.FromMilliseconds(3332), value = rnd.Next()},
                    new R{mark = true, time = TimeSpan.FromMilliseconds(3900), value=rnd.Next()}
                };


var ro = Observable.Generate(0, // inital state 
                             index => index < rdata.Length, // continue 
                             index => rdata[index], // next value 
                             index =>
                                        {
                                            if (index == 0)
                                                return rdata[0].time;
                                            if (index == rdata.Length)
                                                return TimeSpan.FromMilliseconds(0);
                                            return rdata[index].time - rdata[index - 1].time;
                                        }, // waitInterval 
                             index => index + 1 // iterate 
);


P.P.S. Втотрую задачу не стал решать, ибо облом время тратить — тестовых входных данных колбасить еще больше, а решение еще проще. Грубо говоря, там будует что-то вроде stream1.WaitUntil(stream2.Where(st2item => st2item.mark)).Until(Observable.Interval(TimeSpan.FromHours(1)))
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[28]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 23:52
Оценка: 15 (2)
Здравствуйте, Геннадий Васильев, Вы писали:

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


L>>>Ты же заменил 2-е условие на другое:

L>>>

L>>>при этом предшествующий элемент не должен удовлетворять первому условию

L>>>А такая замена некорректна.

G>> ?! Такая "замена" абсолютно корректна, ибо никакой "замены" по сути нет. Алгоритм удовлетворяет условию. Это можно строго доказать при желании. Утверждение "извлеченный элемент не принимает участия в последующем сравнении" относится к критерию фильтра, а не к алгоритму, который является решением задачи.


ГВ>Не. Lloyd прав — твой алгоритм на монотонно возрастающей последовательности {1, 2, 3, 4, 5} выдаст {2}, а не {2, 4}.


Так. По-ходу, как фиксить багу я кажется понял. Удивительно, но похоже эту задачку все-таки можно решить через компрехеншнс (в чем и была моя изначальная идея — решить в компрехеншнс, и перевести в цикл). Получается, правда, уже не так красиво, как я написал... Но все-таки, похоже задача решается без протягивания состояния с итерации на итерацию. Что далеко не очевидно.

Предлагается примерно следующая схема:
собираем индексы начал монотонного возрастания с единицей
starts = [ i | i <- 0..N, x.p(i), !x.p(i-1) ]
и индексы концов.
ends = [ i | i <- 0..N, !x.p(i), x.p(i-1) ]

p — предикат из моего решения, надо его профиксить чтобы он работал при превышении границы массива (выдавал false).
Элементов в обоих списках должно получиться равное количество, если правильно подобрать границы.

Потом, мы пробегаемся по обоим одновременно, и для каждой пары s и e генерируем последовательность индексов с шагом 2, делая выборку индекса уже из нее. Так в компрехеншнсах можно.

res = [ x[n] | ( s <- start & e <- ends ), n <- seq( s, e, 2 ) ]
где
seq — это функция, генерирующая последовательность чисел начиная с s, с шагом в третьем аргументе, и не более чем e.
& для генераторов обозначает параллельную выборку.

Как-то так. Решение вполне реляционно, и должно получиться примерно 4-5 строк кода на языках с компрехеншнсами (если я опять чего-нибудь не пропустил). Естественно, это достаточно компактно (если сравнивать с компрехеншнсами) переводится в циклы. Сейчас уже делать не буду, да и смысла особого нет — обычный вариант с циклом и форсированием пропуска следующей итерации очевидно проще.

Но вообще — жесть. Повезло, что удалось зацепиться за особенности задачи. Небольшая вариация условия — и все, досвидос.

Геннадий, спасибо за задачку . Это был фан .
Re[28]: Теперь у меня опечатка
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 21:42
Оценка: 14 (1) :)
Здравствуйте, Геннадий Васильев, Вы писали:

Можно чутка попроще.

func loop( c, o chan int ) // два раза типы писать не надо.
{ 
     prev := <- c          // := позволяет не писать мусора при объявлении+инициализации

     for val := range с    //читать из потока идиоматично в нашем случае так.
     { 
         if val != prev + 1       // это у нас типо фильтр входных значений, мы его четко отделили
         {     
            prev = val
            continue
         }
         
         o <- val                 //а здесь обработка результата
         prev = <- c              //и как положено, пропускаем один шаг.
                                  //Да, операция чтения - унарная, и надо писать "равно".
     }
}


Вообще красота получилась. Не ожидал. Возьму на заметку.
Re[30]: Кстати
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.11.09 07:09
Оценка: 14 (1) +1
Здравствуйте, lomeo, Вы писали:

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


VD>>Не к реляционным, а к спискам. Просто спискам. Просто таблицы в РСБУД — это тоже списки кортежей. Вот и все.

VD>>Все что может быть представлено в виде списка может быть обработано линком.

L>А LINQ работает с деревом?

L>Если да — from obj in tree select obj.name — вернёт дерево имён или просто список?
И да и нет. Ответ зависит от наличия соответствующей реализации Query expression pattern-а. В дотнете идет реализация этого паттерна для всех типов, которые реализуют IEnumerable<T>. Но ничто не мешает обеспечить собственную реализацию для ITree<T>. Тогда from obj in tree select obj.name вытащит имена из дерева объектов и вернет дерево имен.

Здесь можно увидеть примеры других реализаций query expression pattern-a.
Re[23]: Я всё ж таки вот, о чём думаю
От: IT Россия linq2db.com
Дата: 24.11.09 05:47
Оценка: 2 (2)
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>В общем, всё это уже становится не интересным. Где не работает Linq я тебе и сам могу сказать. Linq не работает на деревьях и иерархиях, там, где для обработки требуются рекурсивные алгоритмы.


ГВ>Ну — упс, приехали. А как же Linq2XML?


Иерархичность XML ограниченна — в ней отсутсвует рекурсивность. Такую структуру всегда можно светсти к реляционной (если я правильно понял использование этого термина Гипертоном).

Но если говорить о Linq2XML вообще, то лично мне его использование не очень импонирует. Толи я пока не научилься его использовать, толи его API действительно громоздок и неудобен.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.11.09 19:18
Оценка: 1 (1) +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Как это вяжется с тем, что Linq, мол, предназначен для любых источников данных? Получается, что только для тех, которые сводятся к РСУБД-like.


Не к реляционным, а к спискам. Просто спискам. Просто таблицы в РСБУД — это тоже списки кортежей. Вот и все.
Все что может быть представлено в виде списка может быть обработано линком.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: LINQ только для РСУБД!
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.09 04:28
Оценка: 1 (1) +1
Здравствуйте, Lloyd, Вы писали:

L>Нет, для внешнего наблюдателя каждый раз порождается новое состояние на основе старого. Изменения переменных нет.


Это уже дело внешнего наблюдателя — интерпретировать. Как именно получен новый аргумент — на основе старого, не на основе — его не касается.

L>>Глобальная переменная const — неизменяемая. Состояние или нет? Если да, то состояние — это что угодно, если нет, то под глобальным состоянием следует понимать именно изменяемое состояние. Как то так.

L>Состояние, конечно.

Хорошо. У нас есть состояние — все привязки в нашей программе, например, связи фунции с их именами. Какие рассуждения можно вести в терминах понятия "состояние" о программе, учитывая, что оно, а следовательно и поведение программы, неизменно? Какие рассуждения можно получить из понятия "Вселенная" в физике, а не в философии? Т.е. какие полезные рассуждения могут быть проведены?
Re[6]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 11.11.09 22:36
Оценка: -2
Здравствуйте, Cyberax, Вы писали:

G>>Потом попробуй мне объяснить, каким именно боком LINQ, SQL, и реляционная модель тебе пригодиться, к примеру, при работе с базой данных построенной на схеме map-reduce. Если не слышал о таких — погугли.

C>Да элементарно пригодится.

Да ну.

C>На LINQ, вон, вообще трассировку лучей пишут: http://blogs.msdn.com/lukeh/archive/2007/10/01/taking-linq-to-objects-to-extremes-a-fully-linqified-raytracer.aspx


Слабовато как-то. Не проняло. Может быть, современная наука на этом не остановилась? И есть работа, как LINQ помогает в решении диффуров? Или кто-нибудь придумал, как на LINQ парсить протокол SIP? Или может быть, изобрели способ делать на LINQ драйверы, декодировать MPEG4 в реальном времени, или иным образом удалить гланды через задний проход?

Да, тогда б конечно. Я наверное поверил бы, что при работе с базой данных map-reduce без LINQ никак нельзя обойтись. Вероятно, я бы проигнорировал даже тот факт, что там совсем не реляционная модель в основе, и в этих плясках с бубнами нет необходимости.

Но пока пример слабоват.
Re[8]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 11.11.09 23:50
Оценка: +1 :)
Здравствуйте, Cyberax, Вы писали:

C>LINQ — это лишь способ выдирать Expression Tree. А что ты с ним дальше делаешь — твоё личное дело. Можешь приспособить для решения диффуров и декодирования MPEG4.


Позанудствую. Преобразованием лямбд в ExpressionTree занимается непосредственно компилятор. Это всё можно делать и без Linq, так же как и Linq можно использовать без ExpressionTree.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.09 16:30
Оценка: +2
Здравствуйте, FR, Вы писали:

FR>И победит в результате Хаскель


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

VD>>Ну, как идея?


FR>Нормально, давно пузомерок не было.


Дык возможно она позволит сблизит понимание между сектами. Ведь все мы хорошо знаем только 2-3 языка, а остальные только очень посредственно. Потому и не можем быть объективными зачастую.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Исправлена ссылка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.11.09 15:50
Оценка: +1 :)
Здравствуйте, FR, Вы писали:

FR>>>Влад все-таки прав насчет мозговедства.

ГВ>>Ты не понял ничего.
FR>Объясни.

Не всякое упоминание психологии суть мозговедство (расклеивание псевдопсихологических ярлыков). И не всякое мозговедство можно свести к психологии. Ну и кроме того, в тексте по приведённой ссылке описан один из механизмов нормальной психики, а вовсе не какой-то там "диагноз". "Диагнозы" — ещё одна особенность "мозговедения", например — "фобии".

Кстати, о фобиях. Чисто умозрительно к "фобии" можно свести, например, тягу к новизне, если поставить в основу рассуждения "страх отстать от прогресса". Но это я так, в порядке логических упражнений.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: LINQ только для РСУБД!
От: z00n  
Дата: 15.11.09 18:05
Оценка: +2
Здравствуйте, netch80, Вы писали:

N> И то, что в C# не пошли этим путём, а пошли через нынешний синтаксис LINQ — показывает, кто, как и зачем вводил: это были именно РСУБД'шники, и вводили фичу для себя.


Неправда — Linq разработал Erik Meijer — он функциональщик и один из отцов Haskell Синтаксис же разрабатывали под целевую аудиторию.

Или например дженерики для Явы разработал Филип Вадлер. Из синтаксиса дженериков для вас очевидно, что это он придумал применить монады в Haskell?
Re[11]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 16.11.09 13:32
Оценка: :))
Здравствуйте, netch80, Вы писали:

N>Гапертон таки прав тут, хотя и объясняет это... мнэээ... временами своеобразно.


Нормально я объясняю. Человек, имеющий желание понять, вполне в состоянии понять, что имеется в виду.

А человек, имеющий желание прицепиться и мониторящий сообщения на предмет повода "объяснить кому-нибудь, что он неправ" — найдет для этого повод в любом случае и при любом объяснении, вместе с десятком оправданий для своего бестактного поведения. Все дело в первую очередь в изначальной установке, а не в "объяснениях", аргументах, и пр.
Re[12]: LINQ только для РСУБД!
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 17.11.09 06:37
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:

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

VD>Аргументы? Ссылки?

Ты сам далее приводишь достаточно аргументов к тому, что я сказал.
The God is real, unless declared integer.
Re[12]: LINQ только для РСУБД!
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 17.11.09 07:44
Оценка: +1 -1
Здравствуйте, Воронков Василий, Вы писали:

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

ВВ>А давайте вы для начала объясните, почему вы вставляете эту буковку "Р" в РСУБД, и как именно она связана с LINQ-ом?

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

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

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


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

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

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

ВВ>А зачем делать "то же", но "немного менее эффективно или синтаксически сложнее"? :???: В целях мазохизма?

Я говорил про _видит_. А не про финальный выбор. Для которого SQL дань привычке, а не качеству результата.
The God is real, unless declared integer.
Re[17]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 17.11.09 09:42
Оценка: +1 :)
Здравствуйте, IT, Вы писали:

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


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


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

Что ты статью-то, что я привел, не комментируешь? С твоими выводами неудобно стыкуется, да? Дык оставайся при своих, я не против, и замнем для ясности. Отличный вариант, не находишь?
Re[12]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 17.11.09 09:53
Оценка: +1 :)
Здравствуйте, 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.

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

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

В отличии от проблемы параллелизма, к примеру. Которая в последнее время становится достаточно существенна, чтобы стоить такой поддержки.
Re[14]: LINQ только для РСУБД!
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 17.11.09 12:03
Оценка: +1 -1
Здравствуйте, Воронков Василий, Вы писали:

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


Ответил.

ВВ>Какое именно отражение реляционность структуры данных находит, давайте упростим задачу, в 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 не годится или годится с тяжёлыми натяжками. (Да, можно придумать искусственный случай без натяжек. Но это неинтересно.)
The God is real, unless declared integer.
Re[19]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 17.11.09 16:51
Оценка: +1 -1
Здравствуйте, Gaperton, Вы писали:

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


Я спорю вот с этим:

N>Да, использовать LINQ стали тут же не для РСУБД; но возникло оно именно как средство работы для РСУБД.


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


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


В статье написано, что была идея! Идея добавить возможность типизированной работы с SQL в языки вроде C#. Ну так эта идея была всегда и во всех языках. Но Linq возник не как средство работы для РСУБД. Его дизайн допускает (причём не лучшим образом) поддержку провайдеров БД, но это не фича языка, которая сделана специально для поддержки РСУБД в C#.

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


G>

G>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.

Хочешь чтобы я её прокомментировал? Не вижу что здесь интересного комментировать, но попробую. Мэт занялся линком как пилотным проектом, чтобы проверить насколько вообще возможно в рамках предлагаемого дизайна обеспечить поддержку БД. Вот и вся цитата Не уверен, но если этот парень работал в команде Linq 2 SQL, то с его творчеством я знаком достаточно хорошо. Его IQToolkit я смотрел одним глазом, но после изучения Linq 2 SQL освязь прослеживается довольно сильная.

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


Не надо за меня домысливать. Всё что я сказал про книжку — это то, что подавать материал можно по разному для целевой аудитории. Подавать Linq как средство работы с БД можно сколько угодно, но утвержать на основании этого, что Linq специально дезайнился для работы с БД ещё нельзя.

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


Думаю, ты всё и так давно понял. Просто признаться, что ошибался смелости не хватает. Это бывает. У некоторых со временем проходит, но не у всех.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.11.09 18:13
Оценка: -1 :)
Здравствуйте, VladD2, Вы писали:

VD>Поверь на слово, ты просто не понимаешь о чем говоришь. Не хочешь верить, разберись в вопросе.

VD>Право — это уже даже не смешно.

Поверь и ты на слово, что я очень хорошо разбираюсь в том, о чём имею нахальство заявлять в публичных дискуссиях. Это так, в качестве ограничительной вводной. А также поверь на слово, что не всё, что для тебя (в частности) является "новым миром", является таковым для твоих собеседников или оппонентов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: LINQ только для РСУБД!
От: yuriylsh  
Дата: 17.11.09 19:27
Оценка: +2
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, 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.

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


Неправильно. Идея игнорирования (Objects, XML например) — это как раз твоя прерогатива. Чтобы доказать твою неправоту не нужно игнорировать реляционные данные, достаточно показать, что это только один из источников.

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


Зачем что-то выкидывать? Опять тебя в крайности кидает. И если цель была реляционные данные, зачем было городить огород с моделью провайдеров, включать реализацию LINQ to Objects, LINQ to XML?

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


Ну и отлично, с этим я согласен. Пускай будет включено и то и другое. Возможно, PLINQ небольшой шаг в этом направлении
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[19]: Кроме того
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 20:17
Оценка: +2
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Кроме того, ты не внимательно прочёл обоснование. Оно заключалось в тех самых: "человек либо это понимает, либо нет".


Это было традиционное гапертоновское хамство. Содержательного в подобных словах ничего нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.11.09 20:24
Оценка: -2
Здравствуйте, VladD2, Вы писали:

ГВ>>Смысл твоего исходного утверждения был выяснен десятком уровней позже.

VD>А кто в этом виноват и какая разница?

Очевидно — ты, поскольку ты не позаботился о разъяснении своих высказываний.

VD>Не знаешь о чем говорят — переспроси. Сказал глупость и тебе на это указали, поправься и отталкивайся от корректных предпосылок.

VD>Вот это по-моему и есть "включить логику".

Угу, а не пытаться свести обсуждение вкуса бузины к цвету корней окружающих ёлок.

VD>>>Это называется ты включил логику? Это ближе к бреду в горячке. Причем тут "гипотетических путей развития языков"?

ГВ>>А как можно интерпретировать твои рассуждения на предмет "если бы, да кабы" и "а не лучше ли переделать ..."?
VD>Где ты увидел "если бы" в моих утверждениях?

Фу ты, ну ты. Ну надо же, не было у тебя именно словосочетания "если бы". Осыпаю главу пеплом.

ГВ>>Это разве рассуждения не о гипотетическом? Если нет, то покажи мне, пожалуйста, легковесные потоки в Nemerle. (Ой, это я зря сказал. )

VD>А причем тут вообще Немерел? Мое утверждение или чушь про линк котрую я получил в ответ касалось Немерле?
VD>Или это теперь модно вместо признания собственной неправоты переключать разговор на все что угодно лишь бы запутать все окончательно?

Хорошо, Немерле тут не при чём. Покажи мне легковесные потоки под .Net. Без них притягивание .Net к обсуждению Go лишено всякого смысла.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 17.11.09 22:28
Оценка: :))
Здравствуйте, IT, Вы писали:

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


IT>Мне всё равно совпадает твоё мнение с моим или нет. Я тут распинаюсь ради истины, а не ради тебя.


А. Ну тогда сколько угодно. Кстати, если ты выделишь тред с "истиной" в отдельный топик, будет совсем хорошо.

G>>Что ты статью-то, что я привел, не комментируешь?


IT>Там нечего комментировать


Весьма показательно. Ответ принят.

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


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


Если тебя это успокаивает, то как тебе будет угодно. Мне же вполне достаточно, что мои выводы подтверждаются свидетельством автора данной технологии в своем блоге.
Re[14]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 17.11.09 23:21
Оценка: +1 -1
Здравствуйте, yuriylsh, Вы писали:

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


Y>Неправильно. Идея игнорирования (Objects, XML например) — это как раз твоя прерогатива. Чтобы доказать твою неправоту не нужно игнорировать реляционные данные, достаточно показать, что это только один из источников.


Неправильно. Для этого недостаточно показать, что это один из источников. Что для этого достаточно — это обозначить другую проблему, кроме OR-mapping, решаемую LINQ, и продемонстрировать, что она как минимум не менее значима, чем OR-mapping. Этого никто не сделал. Даже не попытался.

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


Y> И если цель была реляционные данные, зачем было городить огород с моделью провайдеров, включать реализацию LINQ to Objects, LINQ to XML?


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

К сведению, "огород с разными провайдерами" городили еще в OLE DB. Можно сделать OLE DB провайдера к любому источнику — к файловой системе или ящику электронной почты. Я надеюсь, сомнений в основном предназначении OLE DB, несмотря на это, у тебя не возникает?

Y>Зачем что-то выкидывать? Опять тебя в крайности кидает.


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

Если ведущая проблема — не ORM, а XML+Objects, то нет никакого смысла тянуть SQL-синтаксис, и устраивать все так, как оно выглядит. Ибо можно проще. Здесь я полностью согласен с netch80.
Re[15]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 18.11.09 00:38
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

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


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


Тонкое наблюдение. Да, все так, и эта традиция имеет глубокие исторические корни .

Правило, что улик и доказательств недостаточно для того, чтобы спалить человека на костре, и для этого обязательно требуется его признание вины, практиковалось еще Священной Инквизицией — уважаемой организацией, которая еще в дремучее средневековье несла свет истины в народные массы. Очень гуманное правило. Признание, разумеется, выбивалось под пыткой — ну как же без этого, иначе он, сволочь, эта — совреть!

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


Спасибо за поддержку, дружище! Но зря ты таки в адвокаты записался. Ты посмотри хорошенько, кого ты защищаешь. Гапертон ведь неправ по полной программе.

Какое у вас тут оказывается интересное обсуждение моей персоны идет. Разговор такой же задушевный, прям как будто друзей диссидента в первый раз в КГБ на профилактическую беседу пригласили, и ненавязчиво так прессуют. Уписаццо.

Тему про Го таки засрали. Разумеется, из самых благородных побуждений — истины ради. С чем всех и поздравляю. Комменты по самому Го отыскать уже почти невозможно.
Re[13]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 18.11.09 01:07
Оценка: +2
Здравствуйте, Gaperton, Вы писали:

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


Сегодня надо было позицию от начала буфера по номеру колонки и строки посчитать:

int pos = text.Split('\n').Take(line).Sum(s => s.Length + 1) + column;

Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 18.11.09 22:44
Оценка: +1 :)
Здравствуйте, yuriylsh, Вы писали:

Y>>>Неправильно. Идея игнорирования (Objects, XML например) — это как раз твоя прерогатива. Чтобы доказать твою неправоту не нужно игнорировать реляционные данные, достаточно показать, что это только один из источников.


G>>Неправильно. Для этого недостаточно показать, что это один из источников. Что для этого достаточно — это обозначить другую проблему, кроме OR-mapping, решаемую LINQ, и продемонстрировать, что она как минимум не менее значима, чем OR-mapping. Этого никто не сделал. Даже не попытался.


Y>Странно, я вроде именно это и пытался сделать (впрочем, не только я). Даже болдом в цитате выделил проблему, решаемую LINQ, и она более значима, чем OR-mapping, ибо OR-mapping это лишь частный случай выделенной проблемы.


Извини, не заметил. Попробуй еще раз — в чистом виде. Внимательно рассмотрим.

G>>Если основная цель и мотивация разработки — реляционные данные (т.е. сделать ORM менее геморройным), это вовсе не отменяет желания разработчиков сделать это посредством не узкозаточенной штуки, а более общего механизма, который способен заодно решать и более мелкие проблемы, и обрабатывать данные разных типов единообразно. Хорошее желание, правильное. Вот ровно как в статье, что ты привел, написано. Никакого противоречия тут нет.


Y>Мда, если принять свою предпосылку за верную, то можно на этой основе строить рассуждения подтверждающие ее верность


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

Y>А насчет ровно как в статье...

Y>Давай посмотрим.

А вот это похоже на конструктивный разговор. Трактуем статью. Хорошо.

Y>Вот исходный пример "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." Обрисовал он текущее положение вещей.


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

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

А если это текущее положение вещей такое, что про программисты не должны каждый день начинать с того, чтобы запрашивать реляционные данные? А что, если им ни разу не вперлось превращать их после некоторой обработки в XML? Удивительно, как такое может быть? Простой пример:

Вот пусть так получается, что мои данные — это time series. И мне не надо превращать их в XML, потому, что ни нашлось ни одного идиота-архитектора, который решил, что это обязательно надо делать. Вот, к примеру, пишу я Windows Media Player — ну ни разу не вперлось ни то, ни другое. И что теперь будем делать с такой точной обрисовкой "текущего положения вещей", завязанной на разработчиков приложений, построенных вокруг РСУБД?

Получается, что он уже обрисовал текущее положение вещей далеко не для всех программистов, и не для всех задач, а только для достаточно узкого класса разработчиков, правда?

Y>Теперь продолжение: " 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". Какая модель данных потерялась? Объясни, если несложно, как ты не видишь здесь противоречия с тем, что основная цель разработки — решить проблему с одной единственной моделью данных (реляционной, именно которую он для примера и заменяет какой-то абсолютно новой).


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

http://rsdn.ru/forum/philosophy/3605554.1.aspx
Автор: Gaperton
Дата: 17.11.09


Y>Он говорит что цель — работать с любыми моделями данных, пускай даже сейчас неизвестными, а ты утверждаешь, что нет, основная цель — реляционные данные. Действительно, никакого противоречия.


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

При этом, что человек имел в виду и хотел сказать — мне вполне понятно, и это не глупость. В глупость его слова превратились сейчас, когда их взялся трактовать ты.

Y> Он говорит про 3 преобладающие модели данных (и как результат — эти модели доступны "из коробки" на момент релиза), абсолютно без ранжирования, ты работу с одной называешь главной, а другие — более мелкими проблемами. Действительно, вот ровно как в статье.


Целых три, надо же. Мне "модель данных Objects" доступна и так из коробки без всякого LINQ, ибо она всегда поддерживается языком непосредственно. Было бы странно и очень глупо, если взаимодействие с объектами языка из самого языка представляло собой проблему.

Как и XML — никакого особенно значимого напряга работать с XML нет. Если в языке не составляет проблемы обойти дерево.

G>>К сведению, "огород с разными провайдерами" городили еще в OLE DB. Можно сделать OLE DB провайдера к любому источнику — к файловой системе или ящику электронной почты. Я надеюсь, сомнений в основном предназначении OLE DB, несмотря на это, у тебя не возникает?


Y>Ага, в ASP.NET тоже модель провайдеров естью И сомнений предназначение не вызывает. А при чем здесь LINQ?


Я комментирую твой тезис, об "огороде провайдеров". Если он к LINQ не относится — то причем тут он?

Y>>>Зачем что-то выкидывать? Опять тебя в крайности кидает.


Y>Нет, ведущая проблема не XML+Objects, не ORM, не [подставь_свое], а независимость от модели данных, я ж даже выделил это в цитатах.По-этому рассматривать каждую модель "изолировано" и смысла нету.


Ага. В том числе, от всех сейчас неизвестных. Отличная цель. Достигается путем магии, плясок с бубном, и абстрактной математики.

Y>Насчет SQL-синтаксиса, в цитате тоже есть ответ "then try to translate this into something that normal programmers can understand". SQL понимают большинство программистов — вот им и синтаксис привычен. При этом это не единственный синтаксис для работы с LINQ, более того, query expression keywords в С# даже не перекрываютquery standard query operators — ты не найдешь аналогов Distinct(), Min()/Max(), Any() и т.д.


Я не против, если ты останешься при своем мнении. Оно в чем-то стройное и логичное.
Re[17]: LINQ только для РСУБД!
От: yuriylsh  
Дата: 19.11.09 02:55
Оценка: +2
Здравствуйте, Gaperton, Вы писали:

Y>>Странно, я вроде именно это и пытался сделать (впрочем, не только я). Даже болдом в цитате выделил проблему, решаемую LINQ, и она более значима, чем OR-mapping, ибо OR-mapping это лишь частный случай выделенной проблемы.


G>Извини, не заметил. Попробуй еще раз — в чистом виде. Внимательно рассмотрим.


Если до сих пор не заметил — дальнешее общение с тобой по этой теме — бесполезная трата времени. Засим отклниваюсь.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[14]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 20:29
Оценка: -2
Здравствуйте, IT, Вы писали:

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


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


IT>Сегодня надо было позицию от начала буфера по номеру колонки и строки посчитать:


IT>
IT>int pos = text.Split('\n').Take(line).Sum(s => s.Length + 1) + column;
IT>

IT>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.

[go]
pos := len(text) — len(strings.Split( text, "\n", line )[line]) + column
[/go]



Re[14]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.09 00:28
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>> В этом нет ничего страшного и нет никакой попытки кого-то задеть, просто акценты на фичах языка люди с разной спецификой работы расставляют по-разному.

VD>>Не было никаких акцентов. Было два слишком общих понятия смысл которых попросили уточнить.

ГВ>Дык. В том-то и фокус, что эти самые смыслы влёт считываются людьми, работающими над схожими проблемами.


Ну, давай, моговед, поведай нам, что же Гапертон имел в виду под словами "простой" и "удобный" если слово "простой" он сам же охарактеризовал как имеющее 4 значения (пруфлинк
Автор: Gaperton
Дата: 19.11.09
).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.09 00:36
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Коллизия между вопросами "зачем оно" и "что оно из себя представляет"...


Так. Давай как с чистого листа начнем. ОК?

Итак. Вот цитата Гапертона относительно ЛИНК:

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


Теперь я задам несколько вопросов, а ты постараешься на них дать честный вопрос и не уйти в сторону. ОК?
Принимаются ответы: "нет", "да" и "не знаю".

1. Можно ли с помощью линк обрабатывать коллекции в памяти.
2. Можно ли с помощью линка обрабатывать ХМЛ.
3. Есть ли в ЛИНК-е что-то что может быть применимо толко для РСУБД и не применимо для других источников данных?
4. Упрощает ли ЛИНК обрабтку списков объектов по сравнению с другими средствами их обработки доступными в шарпе и васике?
4. Можно ли называть технологию более удобную для обработки объектов в памяти нежели для работы с СУБД "большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД"?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Я всё ж таки вот, о чём думаю
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 22:38
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>...и пытаюсь поточнее сформулировать, где здесь торчат уши теории РСУБД. В принципе, задачку я подобрал такую, на которой обламывают зубы как раз SQL-сервера: с использованием относительного положения элементов в последовательности.


Ты совершенно правильно все сделал. Неотъемлемое свойство, и слабое место реляционной модели (превращается в силу в ряде контекстов) — отсутствие в этой модели порядка элементов. Кортежи принципиально неупорядоченны. Точка. И твой, и мои примеры с БД time series это свойство эксплуатируют.

Все, что тебе нужно, чтобы окончательно выбить у них почву из под ног — убрать из задачи регулярный индекс. Вот тогда им попа. Они просто не смогут выразить это одним запросом. Сделай так, что в качестве индекса идет, например, время, а не номер элемента.
Re[25]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 19:37
Оценка: +1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

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


G>>>>>Подозреваю, что и с вашим Linq эту задачу можно решить так же. В противном случае он бы вообще никуда не годился.

L>>>>Толсто, Gaperton, очень толсто. От вас я ожидал более умного троллинга.
ГВ>>>Show me your code.

L>>Для начала посмотри код Gaperton-а. Есть подозрение, что он не без ошибок.


ГВ>Кстати, да. Вместо "+ 1" в функции p должен быть "- 1". Только сути это не меняет — всё равно пока решения на Linq либо до мрачности сложны, либо сильно похожи на обычный цикл.


Это не единственная ошибка, заложенная в функцию p. Еще там должно стоять i > 0, а не i > 1. То есть, правильное условие — это

i > 0 && x[ i — 1 ] == x[ i ] — 1
Re[21]: Я всё ж таки вот, о чём думаю
От: Lloyd Россия  
Дата: 22.11.09 01:37
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

L>>А можно уточнить, какие сложности при этом возникают. Не втыкаю как-то.


ГВ>Не так просто привязаться к позиции. Например, у нас идут вот такие записи:


ГВ>
ГВ>struct R {
ГВ>  DateTime time;
ГВ>  int value;
ГВ>  bool mark;
ГВ>  ...
ГВ>};
ГВ>


ГВ>...в порядке возрастания time. Некоторые содержат true в mark. Когда на вход поступает очередная запись с mark=true (обозначим её r0), нужно выдать на выход "самую старую" запись, пришедшую не ранее, чем за 30 минут. Задача усложняется тем, что совершенно не обязательно, что time будет выравнен по границе минуты, т.е. к индексу уже не привяжешься.


Кешировать данные за последние тридцать минут, отбрасывая по мере изменения последнего time, и при появлении mark-а возвращать последюю. Или я опять чего-то недогоняю?
Re[19]: Я всё ж таки вот, о чём думаю
От: IT Россия linq2db.com
Дата: 23.11.09 14:41
Оценка: +2
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Where как и любой другой метод Linq — это и есть решение с помощью yield return. Поставь в месте где у тебя foreach arr.Where и получишь с небольшими модификациями практически тоже самое. Там где у тебя yield return будет return true, в остальных местах return false.


ГВ>Хммм... А с состоянием что делать? Может, лучше ты сам покажешь?


static IEnumerable<int> Sample1C(IEnumerable<int> arr)
{
    bool first = true;
    int  prev  = 0;

    return arr.Where(i =>
    {
        if (first)
        {
            first = false;
            prev  = i;
        }
        else if (i - prev == 1)
        {
            first = true;
            return true;
        }
        else prev = i;

        return false;
    });
}

Всё в точности как у тебя.
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 23.11.09 15:11
Оценка: :))
Здравствуйте, Lloyd, Вы писали:

L>И это еще не конец. Эх, Gaperton, вроде и язык простой и задача простая, а столько ошибок на пустом месте.

L>Как же так?

Что ты хотел — императивщина.
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 23.11.09 22:30
Оценка: -2
Здравствуйте, Gaperton, Вы писали:

G>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?


По-моему, все, что ты доказал — это то, что в go с помощью костылей можно съимитировать то, что на linq-е делается просто и красиво.
Re[25]: LINQ только для РСУБД!
От: no4  
Дата: 24.11.09 04:23
Оценка: +1 :)
Здравствуйте, IT, Вы писали:

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


G>>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?


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


И еще — не доказывают ли примеры, что lisp comprehensions в haskell были созданы для работы с РСУБД, но по какой-то странной ошибке природы они с ними работать не умеют?
Re[27]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 06:25
Оценка: -2
Здравствуйте, IT, Вы писали:

IT>Я думаю, что примеры подобраны правильно, чтобы продемонстрировать нецелевое использование предмета обсуждения. Мы, в свою очередь, пытались доказать не то, что "Linq is the best of the best of the best", а показать, что с помощью Linq можно решать и такие задачи.


Как это вяжется с тем, что Linq, мол, предназначен для любых источников данных? Получается, что только для тех, которые сводятся к РСУБД-like.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[30]: Кстати
От: IT Россия linq2db.com
Дата: 25.11.09 21:21
Оценка: +1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Как это вяжется с тем, что Linq, мол, предназначен для любых источников данных? Получается, что только для тех, которые сводятся к РСУБД-like.

IT>>Ты можешь дать определение РСУБД-like типам данных? Гапертон не смог.

ГВ>В данном случае ключевой признак — отсутствие связей внутри отношения. Остальное — см. теорию РСУБД.


Дай ссылочку на твою теорию, я посмотрю. А то мне не понятно как внутри отношения (слова, которое означает 'связь, зависимость') могут отсутствовать связи.
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 21:28
Оценка: -1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Куда уж полнее-то?


А ту где будет и массив и вывод результатов. Ты же просил решить задачу. Ну, вот и покажи ее полное решение.
А то как-то неудобно полную программу сравнивать с фрагментами реализации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 23:29
Оценка: :))
Здравствуйте, Gaperton, Вы писали:

G>Ты внимательно почитай, что тебе lomeo пишет. И задумайся как следует, почему именно он не возражает мне, а пытается что-то втолковать тебе. Разъясняя тебе, что именно я имел в виду.


Это надо у него спросить. Я вот тебе тоже уже не возражаю.
И ГВ тоже возражать надоело.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: LINQ только для РСУБД!
От: Константин Л.  
Дата: 01.12.09 08:30
Оценка: -1 :)
Здравствуйте, Belsen, Вы писали:

[]


B>Почему бы данный пример не записать сразу так:

B>
B>return XDocument.Load(xmlReader).Descendants("mapping")
B>    .ToDictionary(e => e.Attribute("extension").Value, e => e.Attribute("mimeType").Value);
B>


можно и так, с селектом красивее )
Re[8]: LINQ только для РСУБД!
От: Ehudi Россия  
Дата: 19.11.09 12:11
Оценка: 44 (1)
Здравствуйте, Gaperton, Вы писали:

G>Понятия "простой" и "удобный" правда кажутся тебе настолько сложными, неоднозначными, и непонятными, что требуют уточнения, и стоят длинной дискуссии? Ты считаешь, их вообще возможно уточнить и договориться, чтобы они стали "общими"? Все-таки "философия программирования" — это зазеркалье какое-то.


Договориться один раз и навсегда не получиться. Но я считаю, что каждый раз, когда возникает неоднозначность, надо уточнять о чем идет речь.
Что касается слова простой, то оно не так просто.
Ведь то что кажется простым одному, для другого не просто.
И мне кажется, что Вы это тоже должны понимать.
Re[21]: Я всё ж таки вот, о чём думаю
От: Lloyd Россия  
Дата: 24.11.09 06:28
Оценка: 20 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>...в порядке возрастания time. Некоторые содержат true в mark. Когда на вход поступает очередная запись с mark=true (обозначим её r0), нужно выдать на выход "самую старую" запись, пришедшую не ранее, чем за 30 минут. Задача усложняется тем, что совершенно не обязательно, что time будет выравнен по границе минуты, т.е. к индексу уже не привяжешься.


Оказалось не так уж сложно:
using System;
using System.Collections.Generic;
using System.Linq;

class Program {
    static void Main(string[] args) {
        var rs = GetData();
        var qrs = rs
            .AttachState(
                () => Enumerable.Empty<R>(),
                (r, prev) => prev.SkipWhile(_ => (r.Time - _.Time) > TimeSpan.FromMinutes(30)).Concat(new[] { r }),
                (r, state) => new { r, state }
            )
            .SkipWhile(_ => !_.r.Mark)
            .Select(_ => _.state)
            .First();

        foreach (var found in qrs)
            Console.WriteLine("{0}, {1}, {2}", found.Time, found.Value, found.Mark);
    }

    private static R[] GetData() {
        var rnd = new Random();
        var rs = new R[] { 
            new R {
                Time= DateTime.Today + new TimeSpan(0, 14, 00), 
                Value = rnd.Next(100), 
                Mark = false 
            },
            new R {
                Time= DateTime.Today + new TimeSpan(0, 15, 28), 
                Value = rnd.Next(100), 
                Mark = false 
            },
            new R {
                Time= DateTime.Today + new TimeSpan(0, 18, 20), 
                Value = rnd.Next(100), 
                Mark = false 
            },
            new R {
                Time= DateTime.Today + new TimeSpan(0, 27, 37), 
                Value = rnd.Next(100), 
                Mark = false 
            },
            new R {
                Time= DateTime.Today + new TimeSpan(0, 29, 59), 
                Value = rnd.Next(100), 
                Mark = false 
            },
            new R {
                Time= DateTime.Today + new TimeSpan(0, 32, 28), 
                Value = rnd.Next(100), 
                Mark = false 
            },
            new R {
                Time= DateTime.Today + new TimeSpan(0, 55, 32), 
                Value = rnd.Next(100), 
                Mark = true 
            },
        };
        return rs;
    }
}

public static class StateEnumerableExtensions {
    public static IEnumerable<TResult> AttachState<T, TState, TResult>(
        this IEnumerable<T> source,
        Func<TState> getInitialState,
        Func<T, TState, TState> getNextState,
        Func<T, TState, TResult> selector
    ) {
        var state = getInitialState();
        foreach (var item in source) {
            state = getNextState(item, state);
            yield return selector(item, state);
        }
    }
}

class R {
    public DateTime Time { get; set; }
    public int Value { get; set; }
    public bool Mark { get; set; }
}
Re[15]: LINQ только для РСУБД!
От: Dale_ee Эстония www.ammyui.com
Дата: 25.11.09 09:58
Оценка: 20 (1)
ГВ>Вот ещё пара встречных вопросов:

ГВ>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?


Для сохранения состояния в линке есть Aggregate. Хотя, бесспорно, с помощью цикла было бы удобнее.
            var array = new[] {1, 2, 3, 7, 8, 9, 10};

            var result = array.Aggregate(new 
                                         {
                                                PreviouslyTaken = array.FirstOrDefault() - 2,
                                                PreviousElement = array.FirstOrDefault() - 2,
                                                Result = (IEnumerable<int>)new int[0]
                                         },
                                         (ag, i) => new
                                                    {
                                                           PreviouslyTaken = (i - 1 == ag.PreviousElement) && ag.PreviousElement != ag.PreviouslyTaken 
                                                                             ? i : ag.PreviouslyTaken,
                                                           PreviousElement = i,
                                                           Result = (i - 1 == ag.PreviousElement && ag.PreviousElement != ag.PreviouslyTaken)
                                                                    ? ag.Result.Concat(new [] {i}) : ag.Result
                                                    },
                                         ag => ag.Result);
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[16]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 18:45
Оценка: 20 (1)
Здравствуйте, Dale_ee, Вы писали:


D_>Для сохранения состояния в линке есть Aggregate. Хотя, бесспорно, с помощью цикла было бы удобнее.

D_>
D_>            var array = new[] {1, 2, 3, 7, 8, 9, 10};

D_>            var result = array.Aggregate(new 
D_>                                         {
D_>                                                PreviouslyTaken = array.FirstOrDefault() - 2,
D_>                                                PreviousElement = array.FirstOrDefault() - 2,
D_>                                                Result = (IEnumerable<int>)new int[0]
D_>                                         },
D_>                                         (ag, i) => new
D_>                                                    {
D_>                                                           PreviouslyTaken = (i - 1 == ag.PreviousElement) && ag.PreviousElement != ag.PreviouslyTaken 
D_>                                                                             ? i : ag.PreviouslyTaken,
D_>                                                           PreviousElement = i,
D_>                                                           Result = (i - 1 == ag.PreviousElement && ag.PreviousElement != ag.PreviouslyTaken)
D_>                                                                    ? ag.Result.Concat(new [] {i}) : ag.Result
D_>                                                    },
D_>                                         ag => ag.Result);
D_>


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

var ary = new[] { 1, 2, 3, 7, 8, 9, 10 };

var result = ary.Aggregate(new { Prev = 0,   Skip = true,  Res = new List<int>() }, (acc, cur) => 
     acc.Skip            ? new { Prev = cur, Skip = false, acc.Res }
   : acc.Prev + 1 == cur ? new { Prev = cur, Skip = true,  Res = acc.Res.AddElem(cur) }
   :                       new { Prev = cur, Skip = false, acc.Res },
  ag => ag.Res);

foreach (var item in result)
  Console.WriteLine(item);

Правда тут потребуется метод расширения позволяющий добавлять элемент в List<T> и возвращающий экземпляр этого же списка.
Тоже самое на Nemerle не требует даже наличия метода расширения:
def lst = [1, 2, 3, 7, 8, 9, 10];

def (_, _, res) = lst.Aggregate((0, true, List()), ((prev, skip, res), cur) =>
  if      (skip)            (cur, false, res)
  else if (prev + 1 == cur) (cur,  true, { res.Add(cur); res })
  else                      (cur, false, res));

WriteLine($"..$res");


ЗЫ

Определенно более продвинутый вывод типов, использование блоков кода как выражений и наличие кортежей шарпу не помешали бы. Жаль, что его авторы так близоруки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 16.11.09 09:09
Оценка: 18 (1)
Здравствуйте, IT, Вы писали:

IT>Чистейшие домыслы. Если при разработке Linq и думали о РСУБД, то примерно так: "ну тут мы не знаем как сделать правильно, так что сделаем как-нибудь, а там парни разберуться, у них голова большая". Результат — разработка линк провайдеров для БД представляет собой редкостный по своей геморроидальности процесс.


The original motivation behind LINQ was to address the conceptual and technical difficulties encountered when using databases with .NET programming languages. With LINQ, Microsoft’s intention was to provide a solution for the
problem of object-relational mapping, as well as to simplify the interaction
between objects and data sources. LINQ eventually evolved into a general-purpose
language-integrated querying toolset. [...]

Chapter 1. Introducing LINQ
LINQ in Action
By: Fabrice Marguerie; Steve Eichert; Jim Wooley
http://my.safaribooksonline.com/9781933988160/ch01#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlkPTk3ODE5MzM5ODgxNjAvNSZpbWFnZXBhZ2U9NQ==
Re[24]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 20:21
Оценка: 18 (1)
Здравствуйте, Lloyd, Вы писали:

G>>Код будет, или тебе и правда по существу возразить совсем нечего? Не ожидал как-то от тебя. Ты просил пример с циклом — вот тебе пример с циклом, и еще с эквивалентным comprehensions впридачу.


L>Я просил не пример с циклами, а пример, решающий задачу. Чувствуешь разницу?


Не чувствую. Вот тебе код, где я поправил три опечатки. Длина не изменилась (замена двух символов, вставка третьего). Видишь ошибки в алгоритме — покажи их, и все. Зачем намеками-то говорить?

func ( x []int ) p( i int ) bool {
    return i > 0 && x[ i - 1 ] == x[ i ] - 1
}

func gena_1( x []int ) []int {
    res := vector.NewIntVector(0)
    
    for i, val := range x {
        if x.p( i ) && !x.p( i - 1 ) {
            res.Push( val )
        }
    }

    return res.Data()
}



G>>Что теперь-то тебя удерживает от демонстрации немерянной крутизны линка вне контекста "реляционных" задач? Просим-просим. Что стесняться-то, все свои.


L>Буде


Хорошо.
Re[17]: Я всё ж таки вот, о чём думаю
От: IT Россия linq2db.com
Дата: 22.11.09 18:42
Оценка: 11 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>
ГВ>static IEnumerable<int> sample1b(IEnumerable<int> arr)
ГВ>{
ГВ>  bool first = true;
ГВ>  int prev = 0;
ГВ>  foreach (int i in arr)
ГВ>  {
ГВ>    if (first)
ГВ>    {
ГВ>      first = false;
ГВ>      prev = i;
ГВ>    }
ГВ>    else if (i - prev == 1)
ГВ>    {
ГВ>      yield return i;
ГВ>      first = true;
ГВ>    }
ГВ>    else prev = i;
ГВ>  }
ГВ>}
ГВ>


ГВ>Можно это как-то сделать средствами LINQ?


Where как и любой другой метод Linq — это и есть решение с помощью yield return. Поставь в месте где у тебя foreach arr.Where и получишь с небольшими модификациями практически тоже самое. Там где у тебя yield return будет return true, в остальных местах return false.
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 14:14
Оценка: 10 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Интересная мысль, но не совсем так.


Агащазблин.

ГВ>Список всё же подразумевает отношение порядка "последующий-предыдущий", или хотя бы "голова-хвост".


В информатике "Список" — это упорядоченное множество элементов в котором некоторые элементы могут встречаться ноль или несколько раз.

ГВ>В случае с LINQ ключевая концепция другая — итератор. Однонаправленный, заметь.


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

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

Главное, что ваши рассуждения о релляционности линка — это полнейшее заблуждение или намеренная дезинформация.
Заявлять, что у линка релляционная природа — это все равно, что заявлять, что причина ветра заключается в качании деревьев, т.е. вы подменяете причину и следствие.

Повторяю еще раз свою мысль. Надеюсь, что последний.

В основе LINQ лежит библиотека работы со списками Haskell (Haskell prelude). Идея обобщения источников данных была предложена Меером еще в Хаскеле. Меер заметил, что все операции над БД можно выразить в терминах Haskell prelude. В результате Меер создал ДСЛ-библиотеку который в рантайме переписывал код выраженный в виде функций высшего порядка в аналогичный ему SQL. Позже он перешел на работу в Microsoft и разработал библиотеку аналогичную Haskell prelude, а так же идею Expression tree смысл которой заключается в том, чтобы заставить компилятор генерировать не исполняемый код, а AST которое можно будет анализировать в рантайме. Именно это позволило использовать линк для доступа к внешним серверам вроде SQL-серверов. Но это нисколичко не означает, что нельзя обращаться к другим серверам данные которых можно представить в виде списков.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.11.09 17:57
Оценка: 2 (1)
Здравствуйте, VladD2, Вы писали:

L>>Я уже давно потерял нить вашей дискуссии, так что даже при всём желании поспорить не смогу

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

В практическом отношении эти выражения как раз несут вполне определённый и однозначный смысл. "Мотивированное обсуждение" дефиниций подобного порядка, ИМХО, уведёт любую дискуссию в сторону "дихотомии добра и зла" и уточнения совершенно никчёмных деталей. То есть в самом прямом смысле — человек либо понимает своих собеседников сразу, либо нет.

VD>Когда Гапертон начал ёрничать и говорить, что "все очевидно", я привел в пример C# 2.0 и C# 3.0. Для меня C# 3.0 проще и удобнее так как в нем есть ЛИНК с помощью которого я могу значительно проще обрабатывать данные которые мне нужно обработать. Т.е. продемонстрировал случай когда большее количество фич сделало работу на языке проще.


Обрати внимание: "...с помощью которого я могу значительно проще обрабатывать данные которые мне нужно обработать". Таким образом ты обозначил тот круг задач, который тебе проще решать при наличии LINQ. А например, задача построения коммуникаций, которую обозначали и я, и Гапертон, у тебя не обозначена. Иными словами, ты сейчас только подтвердил субъективный характер оценок "простоты" и "удобства". И эта самая субъективность служит... См. ниже.

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


Очевидно, что если два субъекта оценивают один и тот же предмет одинаковыми субъективными оценками, то с большой вероятностью можно говорить о том, что эти двое пользуются схожими личными критериями оценки (тавтология, не правда ли?), что в разговорной речи заменяется оборотом "понимают друг друга". Ощущение понимания возрастает прямо пропорционально сложности обсуждаемого предмета, а языки программирования — это как раз очень сложные предметы. Именно это и послужило самой серьёзной причиной моего подключения к дискуссии. А вовсе не желание лишний раз поругаться с тобой. Я ж не виноват, что ты у нас Топ-0 активности.

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

По отношению к любой вещи, понимаешь ли, можно задать два независимых вопроса: "зачем?" и "чем является?" Так вот, ответы на второй вопрос никогда не подходят к первому, тогда как если известен ответ на первый, то на второй может и не понадобиться отвечать. Если теперь проанализировать перепалку этого топика, то будет заметно, что в ответ на суждение "зачем нужен LINQ" приводятся доводы "он является библиотекой ФВП". Понятна коллизия?

Зачем нужен мобильный телефон? Что послужило главной причиной его появления? Очевидно — потребность людей общаться друг с другом без привязки к стационарным телефонным аппаратам. Можно сделать такой однозначный вывод, глядя лишь на конструкцию мобильника? По всей видимости — нет, потому что в современных телефонах тридцать три вагона дополнительных функций, включая игры. Однако, если рассуждать, выстраивая индукцию снизу вверх, то легко получить суждения, которые, например, изоморфны демагогическим приёмам, когда реальные мотивы руководителей ("зачем") скрываются за обсуждением "характеристик народа" ("чем является"). Собственно, как раз на такие выводы налетаешь и ты, когда пытаешься вычислить моё целеполагание через призму одной лишь пикировки с собственной персоной.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.09 17:11
Оценка: 1 (1)
Здравствуйте, Gaperton, Вы писали:

G>Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.


Ну, да. Человек либо понимает, что оперировать слишком общими понятиями довольно бессмысленно, либо — нет.

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


Это твой любимый эрланг заточен под прикладную задачу . А LINQ — это красиво завернутая (для казуалов) библиотека функций высшего порядка (Select -> map, Where -> Filter, OrderBy -> sort, ...). СУБД тут совершенно не причем. Просто LINQ позволяет как выполнить методы локально, так и преобразовать их в SQL для выполнения на сервере. Так что лучше потрать некоторое время на изучение вражеских лиц .

Так вот в мои понятия "удобный" и "простой" входит скорее удобство и простота решения задач на языке, а не простота реализации языка. Иначе я бы программировал на Обероне, клоном которого и является этот Go.

G>И представляешь, в гугле при разработке веб-приложений как-то обходятся без РСУБД.


Да мне по барабану. Хотя если моя почта лежит не в БД, то мне как-то страшновато за ее целостность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.09 18:33
Оценка: 1 (1)
Здравствуйте, Gaperton, Вы писали:

G>"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.


Ну, что же почитай манулы по C# 3.0. Потом обсудим еще раз. А то пока что разговор явно идет на уровен казуалов.

VD>>Так вот в мои понятия "удобный" и "простой" входит скорее удобство и простота решения задач на языке, а не простота реализации языка. Иначе я бы программировал на Обероне, клоном которого и является этот Go.


G>Ну, я же хорошо осведомлен о твоих понятиях. И я знаю, что в их рамках адекватно описывается весьма ограниченный круг задач и ситуаций. Менять твои понятия в мои планы не входит.


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

G>>>И представляешь, в гугле при разработке веб-приложений как-то обходятся без РСУБД.


VD>>Да мне по барабану. Хотя если моя почта лежит не в БД, то мне как-то страшновато за ее целостность.


G>И им по барабану, что ты не можешь представить себе БД без SQL.


А причем тут SQL?

G>Поэтому, они обходятся как-то в своем gmail БД BigTable, и не страдают от отсутствия LINQ.


Да пусть не страдают. Главное что все же моя почта лежит в БД и управляется СУБД, а не кодом на доморощенном языке написанном на левой коленке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: LINQ только для РСУБД!
От: anton_t Россия  
Дата: 19.11.09 04:43
Оценка: 1 (1)
Здравствуйте, Gaperton, Вы писали:

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


VD>>Это твой любимый эрланг заточен под прикладную задачу . А LINQ — это красиво завернутая (для казуалов) библиотека функций высшего порядка (Select -> map, Where -> Filter, OrderBy -> sort, ...). СУБД тут совершенно не причем. Просто LINQ позволяет как выполнить методы локально, так и преобразовать их в SQL для выполнения на сервере. Так что лучше потрать некоторое время на изучение вражеских лиц .


G>"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.


Уже давно использую Linq2objects и ни разу не пользовался Linq2db. Чяднт?
Re[25]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 20:27
Оценка: 1 (1)
Здравствуйте, Gaperton, Вы писали:

L>>Я просил не пример с циклами, а пример, решающий задачу. Чувствуешь разницу?


G>Не чувствую. Вот тебе код, где я поправил три опечатки. Длина не изменилась (замена двух символов, вставка третьего). Видишь ошибки в алгоритме — покажи их, и все. Зачем намеками-то говорить?


Там два условия:
1) елемент на единицу больше предыдущего.
2)

при этом извлечённый элемент не должен принимать участия в последующем сравнении

Ты же заменил 2-е условие на другое:

при этом предшествующий элемент не должен удовлетворять первому условию

А такая замена некорректна.
Re[29]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 22.11.09 00:31
Оценка: 1 (1)
Здравствуйте, Gaperton, Вы писали:

ГВ>>Не. Lloyd прав — твой алгоритм на монотонно возрастающей последовательности {1, 2, 3, 4, 5} выдаст {2}, а не {2, 4}.


G>Так. По-ходу, как фиксить багу я кажется понял. Удивительно, но похоже эту задачку все-таки можно решить через компрехеншнс (в чем и была моя изначальная идея — решить в компрехеншнс, и перевести в цикл). Получается, правда, уже не так красиво, как я написал... Но все-таки, похоже задача решается без протягивания состояния с итерации на итерацию. Что далеко не очевидно.


Она решается без протягивания состояния исключительно потому, что в твоем решении сосотояние глобально.
В случае, когда у тебя будет только курсор, который можно прокрутить только вперед (IEnumerable) без состояния уже не обойтись, как минимум придется сохранять значение предиката на предыдущем элементе.
Re[23]: Я всё ж таки вот, о чём думаю
От: Lloyd Россия  
Дата: 24.11.09 06:54
Оценка: 1 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

L>>Оказалось не так уж сложно:


ГВ>Я правильно понял, что здесь два перечислителя по последовательности бегают?


Нет, только один + таскается состояние (предшествующие елементы, не старее 30 минут от текущего).
Re[30]: Кстати
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.11.09 08:46
Оценка: 1 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>>>Как это вяжется с тем, что Linq, мол, предназначен для любых источников данных? Получается, что только для тех, которые сводятся к РСУБД-like.

VD>>Не к реляционным, а к спискам. Просто спискам. Просто таблицы в РСБУД — это тоже списки кортежей. Вот и все.
VD>>Все что может быть представлено в виде списка может быть обработано линком.

ГВ>Интересная мысль, но не совсем так. Список всё же подразумевает отношение порядка "последующий-предыдущий", или хотя бы "голова-хвост". В случае с LINQ ключевая концепция другая — итератор. Однонаправленный, заметь.


Не итератор, а генератор итераторов. Он полностью изоморфен функциональному определению списка в виде голова:хвост.
Re[20]: Я всё ж таки вот, о чём думаю
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.09 18:39
Оценка: 1 (1)
Здравствуйте, Gaperton, Вы писали:

G>Его пример эксплуатирует именно это. Если ты, как ты предлагаешь, уберешь требование выкидывать уже обработанные элементы, то ты уберешь из алгоритма завязку на порядок элементов


Совсем нет. Убирается требование к хранению стейта. С сохранением порядка у линка никаких проблем нет, это не РСУБД.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
AVK Blog
Re[3]: LINQ только для РСУБД!
От: Alexey Axyonov Украина  
Дата: 11.11.09 21:44
Оценка: +1
G>"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.

Интересно в каком из слов Language, Integrated, Queries ты нашел упоминание о СУБД.
... << RSDN@Home 1.2.0 alpha 4 rev. 1277>>
Re[6]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 11.11.09 23:22
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

G>>Вот статья о LINQ в википедии. Покажи мне пожалуйста, каким именно образом можно обойти вниманием реляционную модель, реляционные базы данных, и SQL, говоря о LINQ.


AVK>Не не не. Это ты сперва покажи, каким образом их нельзя обойти, говоря о LINQ.


Мой тезис состоял в том, что при решении задачи, в которой ты не работаешь с внешними источниками данных с реляционной моделью, выгода от LINQ как минимум неочевидна. И его поддержка в языке не может трактоваться как однозначный плюс, вне контекста заточки языка под класс задач. Разумеется, наличие поддержки LINQ усложняет инструмент. Плюс одна концепция, которую надо знать, и которая будет встречаться в коде.

На, смотри.

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


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

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

Во-вторых, и это главное — потому что это навязанный мне тезис, не имеющий отношения к предмету разговора — я не собирался тратить время на бестолковые споры о LINQ в треде о Go. И не собираюсь. Не интересна мне притянутая за уши тема LINQ.

Однако, если ты хочешь возразить мне по существу тезиса — пожалуйста.

AVK>P.S. Статья в русской википедии по качеству просто никакая.


Бывает.
Re[7]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.09 23:40
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Мой тезис состоял в том, что при решении задачи, в которой ты не работаешь с внешними источниками данных с реляционной моделью, выгода от LINQ как минимум неочевидна.


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

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


Вот этот тезис — неверен и бездоказателен.

G>Однако, если ты хочешь возразить мне по существу тезиса — пожалуйста.


Возражать можно только на конкретные аргументы. А возражать против твоего голого имха сродни занятию пенисометрией.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
AVK Blog
Re[8]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 12.11.09 00:07
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

G>>Мой тезис состоял в том, что при решении задачи, в которой ты не работаешь с внешними источниками данных с реляционной моделью, выгода от LINQ как минимум неочевидна.


AVK>Ну, поскольку твой опыт в использовании линка, как я понимаю, чуть менее чем 0, то твоему экспертному мнению, не подкрепленному аргументами, я пока что не доверяю, уж извини.


Я вот совершенно уверен в том, что _мне_лично_ выгода не очевидна. И я совершенно не собираюсь тебя ни в чем убеждать — _мне_ она неочевидна, о чем я сообщаю, не пытаюсь тебе доказать, что ее нигде никогда нет. Ты высказываешь свое мнение, я свое. Мы ими обмениваемся. А не выясняем, какой эксперт экспертистее. Или я что-то не так понимаю, Андрей? Или так второе?

Я вижу, тебе по какой-то причине важно подчеркнуть, что у тебя опыт использования LINQ есть, а у меня нет. Пожалуйста. Да, опыта использования LINQ у меня в районе ноля, если не считать, что он похож на query list сomprehesions Эрланга, конечно. Но давай притворимся, что ничего общего между ними нет, и что LINQ жутко сложная штука, в которой я совсем ничерта не понимаю, я совершенно не против .

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


AVK>Вот этот тезис — неверен и бездоказателен.


Считаешь что неверен — возрази. Будут нормальные доводы — не только соглашусь, но и спасибо скажу.

G>>Однако, если ты хочешь возразить мне по существу тезиса — пожалуйста.


AVK>Возражать можно только на конкретные аргументы. А возражать против твоего голого имха сродни занятию пенисометрией.


Ок, не возражай. Андрей, я проблемы-то не вижу никакой, в чем дело-то? Кто-то заставляет тебя так реагировать на голое ИМХО, что это становится сродни занятию пенисометрией, я не пойму? На РСДН запретили разговорить конструктивно? Или на РСДН запретили высказывать ИМХО?
Re[10]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 12.11.09 01:18
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

C>>>LINQ — это лишь способ выдирать Expression Tree. А что ты с ним дальше делаешь — твоё личное дело. Можешь приспособить для решения диффуров и декодирования MPEG4.

G>>Простой вопрос — а нафига мне выдирать Expression Tree и что-то с ним делать, не имея действительно строгих к тому показаний, что без этого реально сильно туго/сложно получается?
C>В более человеческом стиле писать запросы или комбинировать предикаты для map/reduce, например.

Зачем мне комбинировать предикаты для map/reduce как-то "выдирая Expresison Tree", если я прям в теле функций map и reduce могу их "скомбинировать" стандартными средствами языка? Вот взять, в случае CouchDB, и обратиться к объектам JSON на родном для них JavaScript? map и reduce — это самые обычные, простые функции.

C>>>Так никто не говорит, что "не обойтись". Но с LINQом многое удобнее.

G>>А настолько-ли удобнее, чтобы ради пары финтифлюшек тянуть в решение очередную концепцию, и вводить еще один indirection level? Покажи, какие именно вещи ты сделаешь удобнее, в случае SIP-сервера. Задача ведь тебе знакома, так? Или библиотеки а-ля gstreamer. Что, правда радикальный эффект получится, да?
C>Не, ну так можно сказать о функциональном программировании, объектном ориентировании и т.п.

C>LINQ просто часто позволяет вместо простынь кода писать что-то короткое и красивое. Например, для SIPа это может быть поиск правил, подходящих по номеру, или поиск маршрута для пакета. Оно вообще по мелочи много где полезно бывает.


Поиск маршрута для пакета — это один лукап по "номерному плану". Таблица такая, с масками номеров, и дестинайшнами. Берется номер. Матчится.

Как-то маловато пользы от отсутствующего LINQ просматривается для того, чтобы такой славный Go отправлять втопку на задаче, например, SIP-сервера — решающее в ней совершенно не способность языка к LINQ, а другие качества.

Я так напоминаю — разговор вообще о Go. А не о том, как я не люблю LINQ.

C>>>Вот тут его для Coachdb можно использовать: http://james.newtonking.com/projects/json/help/

G>>Нафига? Ты представляешь себе характер запросов при работе с CouchDB? Ты в большинстве сразу из вьюхи-мапа простым лукап-запросом вынимаешь готовые данные, которые уже правильно сгруппированы, и все. Там многие вещи, привычные по реляционным БД, делаются _по_другому_. Т.е. совсем. Так, что не приходится ничего по сусекам выскребать.
C>Ну вот эту вьюху можно записать в виде LINQ. Оно для этого вообще идеально подходит. И где-то я это даже уже видел.

Можно. Тока опять, решающее преимущество разве будет? Вьюхи — не нормализованная система таблиц. Это денормализованный набор map-ов, с ключом и результатом произвольного типа, возможно составного. Его надо проектировать так, чтобы join-ов и OR-маппинга не возникало, и запросы были просты. Запрос по ключу — получаешь JSON документ. Отправил в браузер. Тот его прожевал — показал. И все. Нет semantic gap, который надо устранять, он сведен к минимуму.
Re[9]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.09 12:32
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Я вот совершенно уверен в том, что _мне_лично_ выгода не очевидна.


Отличная позиция. Не знаю и знать не хочу. Только остальным то какое до этого дело?

G>Я вижу, тебе по какой-то причине важно подчеркнуть, что у тебя опыт использования LINQ есть


Нет. Но если делаешь заявления — будь добр их аргументировать.

G>, а у меня нет. Пожалуйста. Да, опыта использования LINQ у меня в районе ноля, если не считать, что он похож на query list сomprehesions Эрланга, конечно.


Оно тоже исключительно под реляционные БД заточен?

AVK>>Вот этот тезис — неверен и бездоказателен.


G>Считаешь что неверен — возрази.


Еще раз — ты выдвинул, тебе и доказывать. И никак иначе.

G> Будут нормальные доводы — не только соглашусь, но и спасибо скажу.


Нормальные доводы лежат на поверхности, достаточно взглянуть на имеющиеся прямо в BCL linq2objects и linq2xml, про которые упомянуто даже в бездарной статье в русской википедии. Ссылку на linq для CoachDB тебе тоже уже приводили. Есть linq для db4o. Этого мало?
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
AVK Blog
Re[6]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 12.11.09 13:57
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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

Вот там-то его гоу и настигнет. Гоу уровнем пониже питона и попроще, это так. Зато, он быстр, и _достаточно_ выразителен, чтобы выкинуть _связку_ С/С++ — Питон. Он не заставляет выбирать между комфортом, простотой языка, и эффективностью, предоставляя достаточно неплохой балланс.

Да, и Эрлангу эта штука тоже вполне конкурент. Не потому, что язык похож чем-то, а потому, что удобен в том же классе задач.

G>>К разговору твоя личность конечно не имеет никакого отношения, как и моя, но почему бы тебе не узнать об этом моем ощущении, правда? Не вижу причин, почему нет.


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


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

VD>Я не профи в Питоне, но понимаю суть языка. Посему ствои слова вызыват у меня удивление.

VD>Основой фишкой питона является прототипный ООП, динамический контроль типов, утиная типизация и метапрограммирование которые замечательно получается на базе предыдущих фишек. В Гоу этим даже не пахнет. Напротив Гоу предлагате статическую типизацию. Упрощенный до нельзя ООП (или закос на него).
VD>Все это наследие Оберона, а не питона. И стало быть ниши этот язык будет скорее всего делить не с Питоном, а с Обероном и Компонентным Пасклаем (ака Блэк Бокс).

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

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

http://golang.org/doc/go_lang_faq.html#inheritance

Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods.


Ты вообще посмотри их language design FAQ, он короткий, и снимает все вопросы.
http://golang.org/doc/go_lang_faq.html

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


Как ты понимаешь, я думаю ровно наоборот. И ты должен знать, что я вроде как не полный идиот. Стало быть, на то есть причины. Можно обсуждать эти причины. Это и есть конструктивная дискуссия.
Re[8]: LINQ только для РСУБД!
От: FR  
Дата: 12.11.09 16:09
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Кстати, возникла одна идея. Можно организовать небольшую "войнушку"... Завести отдельную тему в которой попробовать сравнить языки по выразительной мощности.

VD>Я могу выступить за C# и Nemere. Ты за Go и Erlang, FR за Python, ну, и может быть еще кто-то подтянется. За одно можно будет сравнить полученные решения на скорость. Думаю, эта "битва" была бы интересна очень многим.

И победит в результате Хаскель

VD>Ну, как идея?


Нормально, давно пузомерок не было.
Re[11]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.09 12:52
Оценка: +1
Здравствуйте, jazzer, Вы писали:

J>Там интерфейсы — это как раз средство определения утиной типизации (типа "ходит и крякает") и используются в месте вызова, а не интерфейсы в стиле классических ООП-языков, в которых они используются в определении типа. Некоторая путаница в терминологии.

J>Примерно то, что хотели сделать концепциями в С++.

Да, я уже это понял. Пожалуй — это самая яркая и правильная концепция выбранная в Гоу. Опять же не в нем придуманная, но все же.

Отдельный вопрос как ее эффективно реализовать. Ведь мне не составит труда реализовать ее и для любого ООЯ, но при передаче ссылки придется неявно создавать еще один объект обертку или vtbl-map. Для немерле подобное можно даже на макросе залудить.

Так что вопрос в том как это реализовано? Даже не так... Как этом может быть эффективно реализовано?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: LINQ только для РСУБД!
От: Mamut Швеция http://dmitriid.com
Дата: 13.11.09 14:53
Оценка: +1
VD> M>Тут вот рядом тема «языки в боевых условиях»
VD> Вот эта тема да еще мне не интересна. Причем не по задумке, не по месту проведения.
VD> Тут нужен интерактив.

Что-то вроде блица с короткими брейками?
avalon 1.0rc3 rev 304, zlib 1.2.3 (13.10.2009 10:16:48 EEST :z)(Qt 4.5.3)


dmitriid.comGitHubLinkedIn
Re[11]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 14.11.09 15:38
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>И я тоже искренне не понимаю, какое остальным-то до этого дело?


Если остальным не должно быть до этого дела, то зачем ты это озвучил, да еще и в качестве аргумента? Ни за что не поверию, что последовавшей реакции ты не ожидал. Тебе надо было просто признать, что пример неудачный, но ты начал доказывать, что таки linq заточень на реляционные БД. Что тут необычного в ответной реакции ты нашел?

G>Хочешь показать выгоду — объясни.


Еще раз напоминаю — ты привел linq в качестве примера того, что язык заточили под одну узкую задачу. Именно ты, а не кто то другой. Так почему кто то что то тебе должен объяснять? Ты заведомо выбрал пример такой, что сам не очень понимаешь что оно собой представляет? Зачем?

G>Но не тогда, когда я не спорю, а выражаю мнение.


Тут все выражают свое мнение.

G>Тема LINQ притянута за уши


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

G>У меня получилось объяснить тебе мою позицию, Андрей?


Нет.

AVK>>Оно тоже исключительно под реляционные БД заточен?


G>Нет, конечно.


Уже лучше.

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


Нет.

G>, и данные имеют реляционный характер. Это я и имел в виду в первом посте.


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

G>>> Будут нормальные доводы — не только соглашусь, но и спасибо скажу.


AVK>> достаточно взглянуть на имеющиеся прямо в BCL linq2objects и linq2xml, про которые упомянуто даже в бездарной статье в русской википедии. Ссылку на linq для CoachDB тебе тоже уже приводили. Есть linq для db4o. Этого мало?


G>Я, видишь-ли, ссылок у тебя не просил. Я вообще ничего не просил, что давало бы тебе повод спрашивать "этого мало?".


Ты просил доводы. Я тебе их привел.

G>А вот спорить, и выслушивать серию разного рода понтов


Пока что понты в топике больше от тебя
... << RSDN@Home 1.2.0 alpha 4 rev. 1284 on Windows 7 6.1.7600.0>>
AVK Blog
Re[12]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 14.11.09 18:26
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

G>>Тема LINQ притянута за уши

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

Да ты что?!

Из-за чего сыр-бор и разгорелся: отсюда и далее
Автор: VladD2
Дата: 11.11.09
.

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

Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.

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

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


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

G>>А вот спорить, и выслушивать серию разного рода понтов

AVK>Пока что понты в топике больше от тебя

Андрей, знал бы ты, как уже осточертело засовывание .Net и приблуд к нему по любому чиху в любую дырку. Ну что за бардак: в топике по Go большая часть сообщений — грызня вокруг LINQ. Тогда как LINQ вообще ортогонален тем задачам, которые хорошо решаются на Go.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: LINQ только для РСУБД!
От: IB Австрия http://rsdn.ru
Дата: 15.11.09 08:16
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Неплохо. Но если убрать необходимость работы с реляционной базой, то не настолько необходимо, чтобы отсутствие являлось значимым недостатком.

Ну как тебе сказать. В 95% реального кода использование LINQ не связано с БД. Вообще.
Так что отсутствие этого дела сильно усложняет решение повседневных задач, и да, отсутсвие LINQ на практике — значимый недостаток даже если нет работы с БД.
Мы уже победили, просто это еще не так заметно...
Re[14]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.11.09 12:15
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Андрей, знал бы ты, как уже осточертело засовывание .Net и приблуд к нему по любому чиху в любую дырку.

AVK>Иногда полезно посмотреть на себя со стороны. Другим точно так же твои выступления кажутся засовыванием в каждую дырку С++.

Хорошо, раз кажется, значит кажется. Приму к сведению. По остальным пунктам, я так понял, возражений нет. Это тоже хорошо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: Исправлена ссылка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.11.09 14:51
Оценка: :)
Здравствуйте, FR, Вы писали:

G>>Ссылка битая. здесь — рабочая.


FR>Влад все-таки прав насчет мозговедства.


Ты не понял ничего.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: Исправлена ссылка
От: FR  
Дата: 15.11.09 15:15
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

FR>>Влад все-таки прав насчет мозговедства.


ГВ>Ты не понял ничего.


Объясни.
Re[9]: LINQ только для РСУБД!
От: IB Австрия http://rsdn.ru
Дата: 15.11.09 17:00
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G> Настолько радикально, что надо обязательно затащить в простой by design язык еще одну концепцию, сделав его сложнее.

Погоди, не сползай... Давай вспомним, откуда вообще LINQ в данной дискуссии всплыл.
Ты заговорил о простоте, в ответ тебе Влад привел LINQ в качестве примера сложной конструкции в языке, которая позволяет решать задачи просто. То, что ты за простоту — это понятно, вопрос за какую, за простоту языка или за простоту решений, которые посредством этого языка получаются?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[20]: Исправлена ссылка
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 15.11.09 19:52
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

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


FR>>>>Влад все-таки прав насчет мозговедства.

ГВ>>>Ты не понял ничего.
FR>>Объясни.

ГВ>Не всякое упоминание психологии суть мозговедство (расклеивание псевдопсихологических ярлыков). И не всякое мозговедство можно свести к психологии. Ну и кроме того, в тексте по приведённой ссылке описан один из механизмов нормальной психики, а вовсе не какой-то там "диагноз". "Диагнозы" — ещё одна особенность "мозговедения", например — "фобии".


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


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

Спасибо.

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[15]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 16.11.09 16:34
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

IT>>Давай лучше посмотрим не реалии здесь.


G>Давай.


G>LINQ to SQL, possibly Microsoft’s first ORM to actually ship in ten years of trying, was never even supposed to exist.


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

G>THE ORIGIN OF LINQ TO SQL,

G>Читаем дальше здесь.

А ты почитал вторую ссылку, которую я тебе дал? Там рассказано почему так получилось, почему в борьбе добра с Хейльсбергом, победило вовсе не добро.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 16.11.09 16:53
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

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


Будем думать головой и составлять своё собственное мнение, а не читать пресрелизы и делать из этого далеко идущие и к тому же хрен-оспоришь выводы.
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: Исправлена ссылка
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 03:38
Оценка: :)
Здравствуйте, kochetkov.vladimir, Вы писали:

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


Дык. Очевидно — это такой неявный намек модераторам, что тему поря сливать в КСВ, а ее участников в баню.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: LINQ только для РСУБД!
От: Воронков Василий Россия  
Дата: 17.11.09 10:57
Оценка: :)
Здравствуйте, netch80, Вы писали:

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

Повторяю:
Какое именно отражение реляционность структуры данных находит, давайте упростим задачу, в SQL92 (он отлично гуглится вместе со спецификаией). Как именно реляционность повлияла на этот язык? Что в этом языке свидетельствует о его "заточенности" для работы именно с реляционной структурой? Почему вы подчеркиваете, что речь именно об Р-СУБД, а не какой другой.
Re[13]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 14:13
Оценка: +1
Здравствуйте, netch80, Вы писали:

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


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

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

Тезис же этот разрушается о простейшие примеры. Линк отлично обрабатывает иерархический XML, списки объектов и ООБД.
Все сходство ЛИНКа с SQL заканчивается на наличии одинаковых ключевых слов (причем полного соответствия нет).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 17.11.09 15:02
Оценка: +1
Здравствуйте, netch80, Вы писали:

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


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

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

Толку от "реляционного" взгляда на мир в данной задаче — ноль, по причине отсутствия времени в реляционной модели в явном виде. Как и от разного рода comprehensions и прочего.
Re[15]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 16:03
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:

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


Поверь на слово, ты просто не понимаешь о чем говоришь. Не хочешь верить, разберись в вопросе.
Право — это уже даже не смешно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 16:32
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:

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


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


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

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


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


Я тебе привел четко аргументированное доказательство. Ты свои впечатления.
Ежу понятно, что если любой ценой игнорировать факты и очень хотеть во что-то верить, то можно оправдать любую чушь. Вот только насколько это конструктивно?

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


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

Какой в этом смысл?
И какой смысл защищать такую позицию?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 19:30
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хорошо, допустим, что LINQ создан не ради поддержки работы с РСУБД. Дальше что? Какое это отношение имеет к Go? Второй вопрос: какое действие можно осуществить на основании этого, бесспорно, глубокого и сакрального знания?


Ты внимательно прочел сообщение ответ на который цитировал?
Мне кажется там все было очевидно. Плюс я уже раза 3 рядом описал все это в разжеванном виде.
Не уж то нужно еще раз повторяться?


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


ГВ>Включаем логику.


Логику? А, да. Давно пора. А то все что я от тебя слышал ранее на логику не похоже.
Но я просил привести аргументы.

ГВ>Собеседника А не интересует точность его суждений по вопросу X, т.е. вопрос X находится вне сферы текущего обсуждения и вне сферы интересов собеседника А. Собесденик Б пытается навязать собеседнику А дискуссию по вопросу X. Какого хрена, извините?


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

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

VD>>Моя мысль никак не была привязана к ЛИНК-у. ЛИНК был приведен исключительно в качестве примера четко демонстрирующего, что увеличение фич языка (т.е. его формальное усложнение) зачастую делает сам язык проще и удобнее в использовании.


ГВ>Очень хорошо. Теперь снова включаем логику.


А зачем ты ее выключал то?

ГВ> Обсуждение Go — это обсуждение уже имеющегося языка. Обсуждение гипотетических путей развития языков, очевидно, в круг вопросов, связанных с Go не входят.


Это называется ты включил логику? Это ближе к бреду в горячке. Причем тут "гипотетических путей развития языков"?

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

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

Причем тут "Обсуждение гипотетических путей развития языков"?

Ты намеренно тролишь или действительно не можешь понять столь простых и очевидных объяснений?

ГВ>Внимательно прочти то, что я написал тебе выше.


Я внимательно прочел. И у меня только два подозрения. Или ты полностью не компетентен в предмете разговора и потому просто не можешь понять написанного (мало вероятно), или ты намеренно тролишь и разводить демагогию.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 17.11.09 23:30
Оценка: -1
Здравствуйте, Gaperton, Вы писали:

G>Неправильно. Для этого недостаточно показать, что это один из источников. Что для этого достаточно — это обозначить другую проблему, кроме OR-mapping, решаемую LINQ, и продемонстрировать, что она как минимум не менее значима, чем OR-mapping. Этого никто не сделал. Даже не попытался.


Пардон, виноват. AndrewVK основную проблему, решаемую LINQ, обозначил быстро и точно. Как OR-mapping .
Re[20]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 18.11.09 02:00
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

IT>>Мне всё равно совпадает твоё мнение с моим или нет. Я тут распинаюсь ради истины, а не ради тебя.

G>А. Ну тогда сколько угодно. Кстати, если ты выделишь тред с "истиной" в отдельный топик, будет совсем хорошо.

Ставь бомбу в нужном месте.

G>>>Что ты статью-то, что я привел, не комментируешь?

IT>>Там нечего комментировать
G>Весьма показательно. Ответ принят.

В предыдущем ответе я тебе всё же прокомментировал. Можешь там почитать.

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


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


Ты сегодня необычайно жжёшь!
Если технологией ты называешь IQToolkit Мэта, то я автор точно такой же технологии, только называется она BLToolkit.
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 18.11.09 09:54
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Как жоский патерналистический мужик (с), я сам решаю — кого защищать, а кого — эдипопапить.


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

ГВ>Попробую понадеяться на автомодерилку
Автор: VladD2
Дата: 11.11.09
. Присоединяйся — отпилить весь кусок с LINQ и хоть положить его рядом, что ли. А то и выкинуть подальше — годных рассуждений тут немного.


Хорошая мысль. Рядом, и пусть тонет. Я думаю так.
Re[5]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 12:01
Оценка: :)
Здравствуйте, Gaperton, Вы писали:

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


_>>Уже давно использую Linq2objects и ни разу не пользовался Linq2db. Чяднт?


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


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

Так вот, попробуй просто запомнить (раз понять не можешь) — LINQ — это общее название для технологии, а не только для Query comprehensions.
Чаще всего под LINQ понимается набор функций высшего порядка аналогичный map, filter, fold, skip и т.п.
Так что применять линк можно без использования синтаксических расширений. Просто открываешь пространство имен System.Linq и начинаеш использовать методы-расширения (которые при этом виртуально добавляются ко всему что можно перебрать, т.е. спискам):
using System.Linq;

...
int[] array = { 1, 2, 3, 4, 5, 6 };
var odds = array.Where(elem => (elem % 2) != 0);

foreach (var odd in odds)
  WriteLine(odd);


В данном примере не используются синтаксические расширения (только упрощенный синтаксис лямбд и методы-расширения которые являются универсальными усовершенствованиями языка).
Но LINQ здесь используется.

Тот же самый код с использованием query comprehensions будет выглядеть так:

using System.Linq;

...
int[] array = { 1, 2, 3, 4, 5, 6 };
var odds = from elem in array where (elem % 2) != 0 select elem;

foreach (var odd in odds)
  WriteLine(odd);


Так понятно? Потому, что если нет, то это уже просто невероятно!

G>Чтобы вставить в язык comprehensions, не обязательно выдумывать никакого LINQ, и делать это через него. И они вовсе не обязаны выглядеть тяжеловесно, как SQL запрос. Linq2objects — не причина появления LINQ, не смотря на то, что ты ее давно используешь, и что это приятная штука.


Без разницы что для чего обязательно, а что для чего не обязательно. Тебе нужно было понять совершенно простые и очевидные мысли. Но ты уперся как сам знаешь что сам знаешь во что и развел флэйм на 1000 сообщений.

Разговоры про тяжеловесность линк-запросов — это очередной виток этого флэйма. Тебя так и тянет насыпать ничем не обоснованных заявлений чтобы побередить умы окружающих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.11.09 21:39
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Любая задача, в том числе "задача построения коммуникаций" в конечном итоге состоит из обработки данных. Так что LINQ в ней будет применим по любому.


В какой-то степени — да. Вопрос только в значимости тех упрощений, которые даст LINQ для задач построения коммуникаций.

VD>Это примерно так же как в любой задаче можно применять циклы.


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

VD>Все что Гапертон говорил про линк — это набор заблуждений. Их развенчали сразу несколько человек. Но вы с Гапертоном даже не удосужились задуматься над их словами. А ты нагло врешь говоря "опровержений тезису Гапертона так и не появилось".


Их и не могло появиться, причина — ниже.

ГВ>>По отношению к любой вещи, понимаешь ли, можно задать два независимых вопроса: "зачем?" и "чем является?" [...] Понятна коллизия?

VD>[...] На что ему было убедительно доказано и много раз подтверждено практикой целой кучи людей, что ЛИНК не заточен ни под одну прикладную задачу и с базами данных работает по стольку по скольку умеет работать и с ними. Целая куча работы сказал ему и тебе, что использует линк исключительно для обработки списков объектов.

VD>Поясни в чем тут коллизия.


Коллизия между вопросами "зачем оно" и "что оно из себя представляет". Ответ на первый вопрос требует анализа причинно-следственных связей, которые привели к появлению предмета. Ответ на второй вопрос требует разбора внутренней структуры предмета. Выводы, полученные из ответа на второй вопрос ненадёжны, если мы ищем ответ на первый. Скажем, из того, что под влиянием LINQ (возможно) многие плотнее изучили ФП ещё не следует, что в первоначальные замыслы разработчиков LINQ входило несение света ФП в массы (зачем тогда маскировать ФП-конструкции под SQL-подобными?) А вот из того, что в 90-х — начале 2000-х ORM был едва ли не самым горячим топиком IT-сообществ очень даже напрашивается вывод, что как раз проблемами ORM и был вызван к жизни LINQ.

Кстати, любопытное подтверждение рассуждениям о возможном влиянии РСУБД мы находим в документации на SQL Server 2005:

You can use .NET Framework languages in addition to the Transact-SQL programming language to create database objects and retrieve and update data for Microsoft SQL Server 2005 databases. In Visual Basic, Visual C#, or Visual C++ projects, you can create stored procedures, triggers, aggregates, user-defined functions, and user-defined types.


Спору нет, LINQ — очень неплохое дополнение для языка, работающего в плотной связи с SQL Server. Обрати внимание, фактически здесь сказано об использовании языков .Net во вполне определённой среде, а здесь это не просто использование, это очень неплохой маркетинговый ответ Oracle. Как по мне, так эта причина стоит гораздо больше, чем возможность сканировать массивы объектов. И снова, смотрим на среду: оба-на — РСУБД!

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

VD>В прочем что ты тут можешь пояснить? Это гон чистой воды. И разбивается он примитивными примерами использования линка для обработки массивов, списков и других коллекций.


А давай не будем путать причины появления X и возможности X? Это две большие разницы. Я не собираюсь спорить с тем, что помимо работы с РСУБД LINQ подходит ещё для кучи других задач, это вполне естественно. Но причины появления из существующих возможностей однозначно вывести можно далеко не всегда.

VD>Только полное не понимание предмета разговора и еще большее не желание призначать собственную не правоту привело к этому бредовешему флэйму.


Опять двадцать пять.

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


Спроси у Гапертона об этом. На меня, например, минусы действуют ровно в той же степени, что и плюсы — как признак наличия обратной связи.

ГВ>>[... мобильный телефон ... изоморфны демагогическим приёмам ... вычислить моё целеполагание ...]

VD>Вот эту демагогию ты оставь для других. Мы обсуждаем тут ЛИНК. Вот о нем и говори.

Поаккуратней с повелительным наклонением. Если ты не понимаешь иллюстрации, то лучше переспроси, я объясню.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.09 00:01
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>В какой-то степени — да. Вопрос только в значимости тех упрощений, которые даст LINQ для задач построения коммуникаций.


Значимость можно оценить только попробовав самостоятельно. Тебе похоже это не гразит, так как ты исходно пологаешь, что тебе это все на фиг не нужно.
Для остальных же скажу, что применение ЛИНК-а по сравнению с традиционными для C# и Явы средствами позволяет сократить код в несколько раз. В некоторых случаях в 10-20 раз.


VD>>Это примерно так же как в любой задаче можно применять циклы.


ГВ>Ага, осталось довести до абсурда и вспомнить, что все Тьюринг-полные языки равны по своим возможностям.


А никакого абсурда. Это тольк ты понять не можешь. ЛИНК по сути и есть замена циклов.
Я думаю, что STL ты знаешь. Так? Ну, вот LINQ 2 Objects — это STL на стеройдах.

Так что если для решения некоторой задачи ты в силах применить STL вместо циклов, то работая на C# 3.0 сможешь там же применить ЛИНК. Причем объем кода будет существенно меньше чем на С++ с использованием STL и несравнимо меньше по сравнению с реализацией того же самого на циклах.

ГВ>Коллизия между вопросами "зачем оно" и "что оно из себя представляет". Ответ на первый вопрос требует анализа причинно-следственных связей, которые привели к появлению предмета.


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

ГВ>Ответ на второй вопрос требует разбора внутренней структуры предмета. Выводы, полученные из ответа на второй вопрос ненадёжны, если мы ищем ответ на первый. Скажем, из того, что под влиянием LINQ (возможно) многие плотнее изучили ФП ещё не следует, что в первоначальные замыслы разработчиков LINQ входило несение света ФП в массы


А зачем этму следовать? Есть факты. Они неоспоримы. ЛИНК — это и есть ФП. Конечно ЛИНК это больше чем просто ФП, но часть того что понимается под аббревиатурой ЛИНК — это несомненно ФП. И авторы линка — это отчетливо понимали.

ГВ>(зачем тогда маскировать ФП-конструкции под SQL-подобными?)


Это отдельный вопрос. Ответ на него лично для меня очевиден.
ФП в том виде в котором он был реализован в классических ФЯ (языках) не был принят массами хотя первому ФЯ уже стукнуло 50 лет, да и менее экстравагантным и более высокоуровневым языкам вроде ML-я и Хаскеля тоже уже по несколько десятков лет.
А вот синтаксис SQL-я людям знаком. При этом SQL — это пожалуй самая близка технология к ФП. По этому было найдено гениальное решение — функции ФП библиотек были переименованы в похожие функции SQL-я. Более того стандартный список ФП-шных функций был расширен. Тем же которые не имели аналогов в SQL оставили старые названия (например, Take, TakeWhile, Skip). Между прочем такой функции как TOP в ЛИНКе нет. Вместо нее как раз применяется Take. Так что совершенно ясно, что ноги линка растут именно от ФП, а не от SQL-я.
К сожалению у этого есть обратная сторона. Многие для кого доступ к данным очень важне, а ФП пока не знаком сочли линк плохим интерфейсом, так как он не позволяет формировать таких запросов к СУБД как им нужно. О таких вещах как оптимизация запросов вообще говорить не приходится.
Но что я тебе об этом рассказываю? Ты же ведь заранее имешь мнение которое хрен оспоришь. Разбираться ты тоже ни в чем не будешь.

ГВ>А вот из того, что в 90-х — начале 2000-х ORM был едва ли не самым горячим топиком IT-сообществ очень даже напрашивается вывод, что как раз проблемами ORM и был вызван к жизни LINQ.


Не что из того что было темами горячих дискуссий? Скажем темой горячих дискуссий последних лет является параллелизм. В 4-ом фрэймворке (очень скоро) выйдет PLINQ — это реализация LINQ 2 Object позволяющая автоматически распараллелить вычисления на имеющиеся в системе процессоры. Давай сделаем и из этого далеко идущие выводы. И тогда получится, что ЛИНК был вызван к жизни стремлением к распараллеливанию. А все эти провайдеры к СБУД — это так баловство.

Ну, как? Ну, ты конечно понимаешь что это глупость. Так вот твои идеи по поводу линк-а — это еще большея глупость.

Выстаиваемый SQL был известен за долго до появления C#. МС мог встроить SQL в C# еще при создании самого C#. Вот только в МС не захотели встаивать в универсальный язык общего назначения средства которые полезны только в одном (хотя и весьма широком) сегменте рынка разработки ПО.
А вот когда им предложили универсальную технологию которая покрывает все сферы разработки ПО и в том числе (а не в основном) доступ к релляционным данным, то они с радостью включили в язык эту технолгию. Ну, а то, что на поверку это оказалось

ГВ>Кстати, любопытное подтверждение рассуждениям о возможном влиянии РСУБД мы находим в документации на SQL Server 2005:


ГВ>

You can use .NET Framework languages in addition to the Transact-SQL programming language to create database objects and retrieve and update data for Microsoft SQL Server 2005 databases. In Visual Basic, Visual C#, or Visual C++ projects, you can create stored procedures, triggers, aggregates, user-defined functions, and user-defined types.


Ахринеть. И что же этот абзац подтверждает?
В Oracle 11G можно использовать Яву. И как это влияет на наличие в Яве средств вроде ЛИНК?

Короче, у тебя дичайшие проблемы с логикой. Как ты программистом то работаешь? Ты же ведь умудряешся делать выводы из вообще не связанных вещей? Ты хоть обрати на дату этой документации! Она же вышла раньше чем ЛИНК был задуман!

ГВ>Спору нет, LINQ — очень неплохое дополнение для языка, работающего в плотной связи с SQL Server.


Не. Это полнейшая клиника.
Чушь за гранью фола.

ГВ>Обрати внимание, фактически здесь сказано об использовании языков .Net во вполне определённой среде, а здесь это не просто использование, это очень неплохой маркетинговый ответ Oracle. Как по мне, так эта причина стоит гораздо больше, чем возможность сканировать массивы объектов. И снова, смотрим на среду: оба-на — РСУБД!


Блин, да фича такая есть в SQL Server 2005 — триггеры на управляемых языках. К ЛИНКу оно вообще отношения не имеет! Более того когда предполагается, что триггер должен обрабатывать большие массивы данных или вообще преимущественно занимаются запросами, то спецы по SQL Server советуют использовать транзакт, так как дотнетные триггеры оказываются медленнее и неудобнее.

ГВ>Что до неточностей формулировок в высказываниях на форуме, так их я списываю на ту или иную степень эмоциональной компоненты в реакциях собеседников. Все ж живые люди, в конце концов.


Ген. Если у тебя еще в состоянии, то ответь плиз на очень простой вопрос.

Если у нас есть фича с помощью которой мы можем одинаково удобно работать с СУБД (любой а не реалионной), ХМЛ-ем, объектами в памяти компьютера и даже распараллеливание вычисления, то эта фича универсальная или все же предназначена только для доступа к РСУБД?

VD>>В прочем что ты тут можешь пояснить? Это гон чистой воды. И разбивается он примитивными примерами использования линка для обработки массивов, списков и других коллекций.


ГВ>А давай не будем путать причины появления X и возможности X?


Да какая разница, в конце концов, какие были причины? Фича универсальная? 100%. Так какого хрена ты защищаешь высказывание "LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД"?

Оно верно?

ГВ>Спроси у Гапертона об этом. На меня, например, минусы действуют ровно в той же степени, что и плюсы — как признак наличия обратной связи.


Ну, да, ну, да... "...Их здесь тысячи..."

ГВ>>>[... мобильный телефон ... изоморфны демагогическим приёмам ... вычислить моё целеполагание ...]

VD>>Вот эту демагогию ты оставь для других. Мы обсуждаем тут ЛИНК. Вот о нем и говори.

ГВ>Поаккуратней с повелительным наклонением. Если ты не понимаешь иллюстрации, то лучше переспроси, я объясню.


Иллюстрации хороши когда ты что-то кому-то объясняешь. А когда ты что-то пытаешься обосновать или доказать иллюстрации — это часть обмана и демагогии. Так что про телефоны я с тобой разговаривать не буду. Они не имееют никакого отношения к вопросу. Они вообще ничего общего не имеют с ни с линком ни с ИТ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 01:49
Оценка: -1
Здравствуйте, VladD2, Вы писали:

ГВ>>Коллизия между вопросами "зачем оно" и "что оно из себя представляет"...

VD>Так. Давай как с чистого листа начнем. ОК?

Попробуем.

VD>Итак. Вот цитата Гапертона относительно ЛИНК:

VD>

VD>LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД.


VD>Теперь я задам несколько вопросов, а ты постараешься на них дать честный вопрос и не уйти в сторону. ОК?

VD>Принимаются ответы: "нет", "да" и "не знаю".

VD>1. Можно ли с помощью линк обрабатывать коллекции в памяти.


Да.

VD>2. Можно ли с помощью линка обрабатывать ХМЛ.


Да.

VD>3. Есть ли в ЛИНК-е что-то что может быть применимо толко для РСУБД и не применимо для других источников данных?


Я таких не припомню, во всяком случае. Хотя LINQ и получен обобщением проблем взаимодействия с РСУБД. Начиная от использования самого устоявшегося термина "запрос" до Expression Trees, которые хороши для (внимание!) трансляции в SQL-запросы (исчисление кортежей, ограниченные агрегаты). Кроме того, насколько я понимаю, возможности LINQ по обработке агрегатов и вложенных запросов должны быть несколько уже, чем у SQL Server. Но здесь надо покопаться плотнее в способностях самого SQL Server, я уж около года этим не занимался. Возможно, что будут заморочки с having или где-то в районе вложенных запросов.

VD>4. Упрощает ли ЛИНК обрабтку списков объектов по сравнению с другими средствами их обработки доступными в шарпе и васике?


По сравнению с какими?

Но. См. ответ на следующий вопрос.

VD>4. Можно ли называть технологию более удобную для обработки объектов в памяти нежели для работы с СУБД "большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД"?


Вопрос поставлен некорректно. Как понимать "более удобную для обработки объектов в памяти нежели для работы с СУБД"? Критерии сравнения "более менее" каковы?

Вот ещё пара встречных вопросов:

1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?

2) Тот же массив, но нужно извлечь элементы, отстоящие на +/-1 от выбранного. Т.е. результат — {1, 3, 7, 9}.

Как ты понимаешь, традиционным for обе задачи решаются тривиально.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: LINQ только для РСУБД!
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 20.11.09 15:07
Оценка: :)
Здравствуйте, VladD2, Вы писали:

L>>Влад. Ты сам себе отвечаешь.

VD>Естественно. А как еще можно ответить на смайлик вместо ответа?

Да я так, поржать, забей.
Re[22]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 20:17
Оценка: -1
Здравствуйте, IT, Вы писали:

IT>>>Что плохого в ФВП, если они позволяют упрощать и угибчать код?

G>>В ФВП, как в выразительном средстве — совершенно ничего плохого. Но решение без ФВП при прочих равных проще понимать. Во многих случаях.

IT>В данном случае простота напрямую зависит от уровня подготовки. Не секрет, что один и тот же код для одного человека может быть простым, а для другого сложным. Это как раз тот самый случай. Вот тут
Автор: IT
Дата: 22.09.08
я давал пример одного и того же алгоритма на Linq и в императивном стиле. Разница очевидна. ФП привносит в код декларативность, а значит простоту и гибкость. Но всё это требует определённой подготовки.


Этот пример из мира типовых задач, в которых применяют БД. На нем — разумеется, разница очевидна.
Re[21]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 20.11.09 23:02
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Нет, первая задача правильно решена. Выделенное значит, что ты ошибся в решении второй задачи на пару с Lloyd.

L>>А это уже гон. Постановка была неправильной, а не решение.

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


То есть ты ошибся с формулоировкой? Раз так, ок, замнем.
Re[18]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 23:09
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Сделай так, что в качестве индекса идет, например, время, а не номер элемента.


Вообще, знаешь, ты прав, пожалуй. Можно ввести требование, например, "отбирать запись, отстоящую от заданной не более, чем на -30 минут", или вообще — связанную с какой-то отдельной меткой события.

Есть ещё вариант — например, построить дерево по линейной последовательности в один проход.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 17:14
Оценка: -1
Здравствуйте, Lloyd, Вы писали:

L>Первый пример сводим к циклу, а не изображает его.

L>Он выигрывает перед циклом, т.к. цикла пока никто не показал.

func ( x []int ) p( i int ) bool {
    return i > 1 && x[ i - 1 ] == x[ i ] + 1
}

func gena_1( x []int ) []int {
    res := vector.NewIntVector(0)
    
    for i, val = range x {
        if x.p( i ) && !x.p( i - 1 ) {
            res.Push( val )
        }
    }

    return res.Data()
}



Лобовое решение, завернутое в отдельную функцию. Вся работа делается в 4-х строках кода. Просто, понятно, и очевидно.

Этот цикл в три строки элементарно записывается через array comprehension. Примерно так:

{ x[i] | i <- [2..len(x)-1], x.p(i) & !x.p(i-1) }

Что безусловно выглядит более изящно, но по сути своей — совершенно то же самое, и соответствует варианту с циклом один-в-один. Примерно так, с небольшими поправками на синтаксис, это будет выглядеть в Haskell, Clean, и Erlang. В первых двух задача вообще решается в две строки кода.

Ваши примеры с Linq — ужасны, и проигрывают компрехеншнсам. При этом, в них по своей сути нет ничего, что не могло бы быть сделано при помощи простых ФВП и циклов. Никакой принципиальной разницы, и преимущества нет. Только закрученный на ровном месте код, и все.

Подозреваю, что и с вашим Linq эту задачу можно решить так же. В противном случае он бы вообще никуда не годился.
Re[21]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 18:01
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Ваши примеры с Linq — ужасны, и проигрывают компрехеншнсам. При этом, в них по своей сути нет ничего, что не могло бы быть сделано при помощи простых ФВП и циклов. Никакой принципиальной разницы, и преимущества нет. Только закрученный на ровном месте код, и все.


G>Подозреваю, что и с вашим Linq эту задачу можно решить так же. В противном случае он бы вообще никуда не годился.


Толсто, Gaperton, очень толсто. От вас я ожидал более умного троллинга.
Re[26]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.09 19:46
Оценка: :)
Здравствуйте, Lloyd, Вы писали:

ГВ>>Только сути это не меняет — всё равно пока решения на Linq либо до мрачности сложны, либо сильно похожи на обычный цикл.

L>Ну это еще цветочки. Ты не видел какой мрак получается с бесконечными последовательностями.

Дык, я уже трепещу. Давай, свей мой разум в невозможную фигуру!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 20:15
Оценка: :)
Здравствуйте, Gaperton, Вы писали:

G>Ну, по мелочи — двоеточие пропустил. Вот здесь.


G>for i, val := range x {


И это еще не конец. Эх, Gaperton, вроде и язык простой и задача простая, а столько ошибок на пустом месте.
Как же так?
Re[24]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 20:45
Оценка: +1
Здравствуйте, Lloyd, Вы писали:

L>>>Толсто, Gaperton, очень толсто. От вас я ожидал более умного троллинга.


G>>Код будет, или тебе и правда по существу возразить совсем нечего? Не ожидал как-то от тебя. Ты просил пример с циклом — вот тебе пример с циклом, и еще с эквивалентным comprehensions впридачу.


L>Я просил не пример с циклами, а пример, решающий задачу. Чувствуешь разницу?


Второй пример. Беру твой код.
int lastNdx = int.MinValue;
var q1 = Enumerable.Range(1, arr.Length - 1).Where(i => {
    if (i == lastNdx + 1 || arr[i] != arr[i - 1] + 1) {
        return false;
    } else {
        lastNdx = i;
        return true;
    }
}).Select(i => arr[i]);


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

lastNdx := -1
res := vector.NewIntVector(0)

for i, val := range arr {
 if i == lastNdx + 1 || arr[i] != arr[i - 1] + 1 {
      continue
 } 
 lastNdx = i
 res.Push( val )
}


От чего твоему коду сильно легчает, и становится заметно, что это простейшая императивная реализация.

Вот тебе еще один пример с циклом, который проще чем твой вариант с линком.
Re[28]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.09 20:58
Оценка: :)
Здравствуйте, Lloyd, Вы писали:

L>Кушать подано:


Твою двадцать...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[24]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.11.09 02:08
Оценка: :)
Здравствуйте, Lloyd, Вы писали:

ГВ>>Всё верно. Теперь, пожалуйста, то же самое с помощью LINQ?

L>Что-то мне подсказывает, что тут можно как-то использовать новомодный rx (linq to events), потому как по сути речь идеть о преобразовании одних событий в другие.

Ну, как-то приблизительно смахивает. Если поглядеть в эту статью, то Linq2Events ну почти что подбирается к модели CSP. Подбирается как "фашисты к Севастополю", через пень-колоду, но тем не менее.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 22.11.09 18:18
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

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


Нормально разговаривать я всегда согласен. Если ты сумеешь удержаться от провокаций, то разговор вполне может получиться.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Отбой
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.11.09 21:28
Оценка: +1
Здравствуйте, Lloyd, Вы писали:

Опечатка:

            } else {
                prev = i;
                return false;
            }
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 23:06
Оценка: -1
Здравствуйте, IT, Вы писали:

L>>И это еще не конец. Эх, Gaperton, вроде и язык простой и задача простая, а столько ошибок на пустом месте.

L>>Как же так?

IT>Что ты хотел — императивщина.


Я бы попросил! Тот мой код хоть и неправильный, но по своей сути чисто функциональный
Re[25]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 01:48
Оценка: -1
Здравствуйте, IT, Вы писали:

G>>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?

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

В десятку! Значит — есть некое целевое использование? Последовательности — нецелевое, иерархии — нецелевое, а где ж тогда целевое?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 24.11.09 07:25
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот-вот. И тут как раз проходит граница практической применимости Linq. То, что его принципиально можно применить где угодно, ещё не означает, что его имеет смысл применять где угодно. Добавь сюда свои соображения относительно XML и что в сухом остатке? Правильно — табличное представление данных.


Ключевое слово другое, Гена. Не таблицы, а последовательности. Я уже устал это повторять, но повторюсь ещё раз. Подумай, зачем в C# добавили цикл foreach, который мгновенно стал одним из самых используемых. Так вот Linq применим везде, где применим foreach и даже в большем числе сценариев. При этом всё, что мы тут продемонстрировали из Linq в ФП две функции: iter и filter. Гапертону это отлично известно. Если ему это не известно, то либо Эрланг не функциональный язык, либо Гапертон врёт, что он его интенсивно использовал в своей команде.
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 24.11.09 11:21
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>Ключевое слово другое, Гена. Не таблицы, а последовательности. Я уже устал это повторять, но повторюсь ещё раз. Подумай, зачем в C# добавили цикл foreach, который мгновенно стал одним из самых используемых. Так вот Linq применим везде, где применим foreach и даже в большем числе сценариев. При этом всё, что мы тут продемонстрировали из Linq в ФП две функции: iter и filter. Гапертону это отлично известно.


Скажем так, пока вы ничего из ряда вон выходящего (то есть, превышающее возможности ФВП и comprehensions) не показали. При этом, comprehensions это по большей части стиль мышления, и переводится в цикл достаточно прямолинейно — не сильная потеря (выигрыш нагляден только при использовании ZF-notation).

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

IT>Если ему это не известно, то либо Эрланг не функциональный язык, либо Гапертон врёт, что он его интенсивно использовал в своей команде.


Не надо так говорить.
Re[29]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 08:40
Оценка: +1
Здравствуйте, VladD2, Вы писали:

ГВ>>Как это вяжется с тем, что Linq, мол, предназначен для любых источников данных? Получается, что только для тех, которые сводятся к РСУБД-like.

VD>Не к реляционным, а к спискам. Просто спискам. Просто таблицы в РСБУД — это тоже списки кортежей. Вот и все.
VD>Все что может быть представлено в виде списка может быть обработано линком.

Интересная мысль, но не совсем так. Список всё же подразумевает отношение порядка "последующий-предыдущий", или хотя бы "голова-хвост". В случае с LINQ ключевая концепция другая — итератор. Однонаправленный, заметь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[42]: LINQ только для РСУБД!
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.09 12:15
Оценка: +1
Здравствуйте, Lloyd, Вы писали:

L>К чему все это? Если вы согласились, что это состояние, то обсуждение закончено, т.к. тем самым опровергнуто, что из наличия состояния автоматически следует мутабельность. Это собственно и смутило меня в рассуждениях Gaperton-а.

L>Или я все-таки опять чего-то недопонимаю?

Цитирую себя, любимого

Насчёт состояние == мутабельность, это, конечно, не совсем так, но обычно, когда говорят "состояние" подразумевают именно изменяемое состояние.


т.е. о том, что состояние != мутабельность было сказано в первом же комменте. Что тут обсуждать? В ФП же обычно под состоянием понимается именно изменяемое состояние. Поэтому когда Gaperton говорил о состоянии, было вполне ясно из контекста, что имеется в виду.

Мои мотивы — мне показалось, что тебе это неизвестно, поэтому я попытался прояснить этот момент, чтобы устранить непонимание. В результате же непонимания стало ещё больше.

Поэтому давай не будем лить воду из пустого в порожнее.
Re[32]: Кстати
От: yuriylsh  
Дата: 25.11.09 17:15
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хм. Может, я чего-то не понимаю, но по-моему, всё, что ты тут сказал прямо доказывает, что LINQ предназначен в первую очередь для работы с SQL-серверами. Зачем иначе огород городить с ExpressionTrees?


Собственно, VladD2 это уже раскрывал в посте, на который ты отвечаешь:

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


А что дальше делать с полученным AST — это уже дело провайдера. Напрмер, реализовать LINQ to LLBLGen, LINQ to Twitter, LINQ to Google,...
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[33]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 18:13
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


Нами??? По-моему, ты первый взвился. Я ошибаюсь?

ГВ>>Да и вообще, вопрос не в том, кто что породил (прям Библия, не меньше), а зачем это было нужно.

VD>Вопрос бы один и он был очень прост. Является ли ЛИНК средством рассчитанным исключительно (или в основном) на работу с РСУБД или нет. Ответ на этот вопрос лично для меня очевиден — нет.

А нафиг всё же впёрся LINQ, если функциональный стиль и так поддерживается C# 3.0? Неужели бродилку по IEnumerable<> (к которой ты хочешь свести назначение LINQ) так сложно написать, что из-за неё стоит заморачиваться с введением аж модификаций в синтаксис C#?

ГВ>>Хм. Может, я чего-то не понимаю, но по-моему, всё, что ты тут сказал прямо доказывает, что LINQ предназначен в первую очередь для работы с SQL-серверами.

VD>Ген. Иди купи себе какой-нибудь учебник по логике. Прочти в нем раздел посвященный причино-следсвенной связи. Иначе с тобой просто невозможно говорить.

Угу-угу, кто б советовал...

VD>Подумай на досуге является ли то, что деревья качаются при ветре доказательством того, что они созданы для создания ветра?


Осталось задаться вопросом, что считать ветром, а что — деревьями. Ты, судя по всему, считаешь ветром лозунг "ФП — в массы" и ещё какую-то квази-альтруистическую риторику, я — что "надо состыковаться с SQL-сервером". Чей ветер стабильнее?

VD>Такая же фигня и с линком. Следствием его универсальности является возможность в том числе обрабатывать из хранимые в СУБД. Из факта "ЛИНК позволяет работать с данными из РСУБД" ни как не следует, что линк "предназначен в первую очередь для работы с SQL-серверами".


Вот теперь иди и покупай учебник по логике сам. Факт единственно лишь того, что LINQ работает с РСУБД не рассматривался в качестве достаточного для выводов основания ни мной, ни, полагаю, Гапертоном.

ГВ>>Зачем иначе огород городить с ExpressionTrees?


VD>Очевидно для того, чтобы можно было в рантайме проанализировать ЛИНК-запрос и что-то сделать на его основе. Частным случаем этого "что-то" является переписывание запроса в SQL и выполнение его некоторым сервером. Опять же ничто не говорит в пользу гипотезы "LINQ предназначен в первую очередь для работы с SQL-серверами".


А вот теперь подумай — на кой шут городить огород с генерацией/анализом AST, если у нас единая среда исполнения? Чтобы дать юзерам "визуальные языки"? Ещё какая-нибудь абстрактная идея света в массы?

VD>Если придерживаться твоей извращенной "логики" (в кавычках так как этот по сути алогизм), то можно заключить что ЛИНК, в первую очередь, предназначен для распределения вычислений по разным серверам, так как он позволяет это делать и есть люди которые этим пользуются.


С LINQ-ом вообще всё не слишком понятно обстоит — его, похоже, будут набивать фичами, которые больше некуда воткнуть.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[33]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 18:20
Оценка: :)
Здравствуйте, yuriylsh, Вы писали:

Y>А что дальше делать с полученным AST — это уже дело провайдера. Напрмер, реализовать LINQ to LLBLGen, LINQ to Twitter, LINQ to Google,...


Правильно. Это есть вполне нормальное следствие обобщения изначально узконаправленного средства.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[43]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 25.11.09 22:13
Оценка: :)
Здравствуйте, lomeo, Вы писали:

L>Поэтому давай не будем лить воду из пустого в порожнее.


А я сразу почувствовал, что если начать объяснять, то произойдет в итоге именно это.
Re[37]: Кстати
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.11.09 22:14
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


VD>>>fmap написан на хаскеле или это какая-то "магическая" функция предоставляемая системой?

VD>>>Думаю, второе.

К>>См. Functor, ничего магического


VD>Из этого ответа я ровным счетом ничего не понимаю.

VD>Я не понимаю как универсальная функция может получать возможность перебирать любые структуры дынных и строить их копии ничего не зная о них.

fmap — это не универсальная функция, а декларация о наличии конкретной функции для конкретных типов данных.
Re[16]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 22:20
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>>>4. Можно ли называть технологию более удобную для обработки объектов в памяти нежели для работы с СУБД "большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД"?

ГВ>>Вопрос поставлен некорректно. Как понимать "более удобную для обработки объектов в памяти нежели для работы с СУБД"? Критерии сравнения "более менее" каковы?

VD>Это вопрос к Гапертону. Это его цитата которую ты так ревностно защищаешь.


Странно. Цитирую тебя, а вопросы — к Гапертону.

ГВ>>Вот ещё пара встречных вопросов:

VD>Я просил ответить на мои вопросы.

Тем не менее, спасибо за ответы на мои.

VD>В прочем полученных ответов уже достаточно чтобы сделать вывод о том, что утверждения Гапертона ложны. А ЛИНК как ни странно является универсальным средством обработки данных.

VD>Что и следовало доказать.

Полученные ответы ортогональны вопросу Гапертона, потому в данном контексте они ничего не доказывают.

VD>Так что остается последний вопрос.

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

В чьих глазах?

ГВ>>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?


VD>Как-то так (Nemerle, так как писать на нем приятнее):

VD>
VD>using System.Collections.Generic;
VD>using System.Console;
VD>using System.Linq;

VD>def lst = [1, 2, 3, 7, 8, 9, 10];

VD>def (_, _, res) = lst.Aggregate((0, true, List()), ((prev, skip, res), cur) =>
VD>  if      (skip)            (cur, false, res)
VD>  else if (prev + 1 == cur) (cur,  true, { res.Add(cur); res })
VD>  else                      (cur, false, res));

VD>WriteLine($"..$res");
VD>


VD>Объясняю преимущества перед использованием циклов.

VD>1. Отсутствуют специальные случае вроде пустого массива которые можно забыть проверить.

i < arr.Length
спасает, как ни странно.

VD>2. Отсутствует работа с индексами, так что ошибка не приведет к генерации исключений в непротестированных случаях.


Каковые (случаи выхода за границы) попросту исчезают как данность.

VD>3. Решение задачи близко к ее постановке. Мы описывает, что хотим получить, а не то как мы это хотим получить. Нам не нужно думать о переборе значений, мы думаем только об алгоритме.


Угу. "Что" мы хотим получить в терминах ФП. Песню про "что-как" дихотомию я наслушался во времена ОО-истерии, хватит уже.

VD>Проблема только одна. Чтобы прочесть и понят данный код нужно иметь некоторый опыт использования ФВП и абстрагирования алгоритма от его реализации.


...а ещё он адски длинный и в нём очень трудно визуально выделить блоки. Этим же грешит неуёмное использование шаблонов C++.

ГВ>>Как ты понимаешь, традиционным for обе задачи решаются тривиально.

VD>Не не понимаю. Я понимаю, что ты постарался подобрать задачку которая по твоим соображениям плохо решается с помощью линковских функций. Более правильным направлением было бы выбрать задачи обработки матриц. В прочем и там можно использовать линк, хотя не так уж и осмысленно.

Угу. Но матрицами было бы сложнее, а тут простенькая задачка, зато какая феерия!

VD>Вопрос не в том удалось тебе или не удалось придумать такие задачки.

VD>Вопрос в том зачем ты это пытался сделать?

Мои мотивы выписаны во всём топике контрастными буквами.

VD>Ведь очевидно, что есть масса задач которые решаются с помощью линка в десятки раз удобнее. Будешь спорить?

VD>И эти задачи никак не связаны с СУБД тем более с реляционными.

Пока что оказывается, что они очень сильно на них похожи.

VD>А раз так, то говорить о какой-то привязанности линка к РСУБД — это просто идти против базовых концепций логики. Говоря простыми словами — это полный идиотизм.


Последи за лексикой, ладно? Поскольку у тебя всё равно рука не поднимется самого себя забанить, то я тебя прошу по-хорошему.

VD>Так что ты еще не понял, и что ты пыташся доказать?

VD>Или ты все же давно все понял и просто троллишь специально не желая мыслить логически?

Логически здесь как раз следует, что в ряде случаев LINQ — не пришей кобыле хвост. Одна лишь демонстрация крутизны на ровном месте. Да и честно сказать, даже реализация на Nemerle круто проигрывает банальному циклу в читабельности. Зато, что любопытно, реализация на Go
Автор: Gaperton
Дата: 22.11.09
по ясности изложения резко обходит всех.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[40]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 25.11.09 22:21
Оценка: +1
Здравствуйте, Lloyd, Вы писали:

L>>Насчёт состояние == мутабельность, это, конечно, не совсем так, но обычно, когда говорят "состояние" подразумевают именно изменяемое состояние.


L>Gaperton, куда ж ты слился-то. Ты же так активно отстаивал, что состояние == мутабльность. А теперь так резко замолчал.


Ты внимательно почитай, что тебе lomeo пишет. И задумайся как следует, почему именно он не возражает мне, а пытается что-то втолковать тебе. Разъясняя тебе, что именно я имел в виду.

И в будущем, пожалуйста избегай выражений вроде "слился", когда хочешь обратиться ко мне, будь так любезен.
Re[39]: Кстати
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.11.09 22:45
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


S>>fmap — это не универсальная функция, а декларация о наличии конкретной функции для конкретных типов данных.


VD>Тогда она в данном разговоре не в кассу. Ведь к любому типу можно прикрутить интерфейс.


В защиту хаскеля: классы типов гораздо круче интерфейсов.
Re[32]: Кстати
От: IT Россия linq2db.com
Дата: 25.11.09 23:23
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>В данном случае ключевой признак — отсутствие связей внутри отношения. Остальное — см. теорию РСУБД.

IT>>Дай ссылочку на твою теорию, я посмотрю. А то мне не понятно как внутри отношения (слова, которое означает 'связь, зависимость') могут отсутствовать связи.

ГВ>О! Я специально запасся ссылкой на Главный Источник Мудрости.


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

ГВ>Формулировка удивительная, но правильная по сути. Нормальные формы — как раз последовательное исключение функциональных связей.


А... ну если ты про отсутсвие таких связей, а не вообще, то тогда понятно. В принципе, между таблицами нет и половых связей, так что тоже можно говорить об отсутствии связей
Если нам не помогут, то мы тоже никого не пощадим.
Re[38]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 23:25
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Что тебе не понятно? Что было бы куда прикольней, если бы MS сделала прямое отображение IL на SQL-Server?


Мне понятно, что это чушь. ЛИНК потому и отображается во что угодно, что его модель ограничена декларативными конструкциями.

VD>>Не было там никаких адаптаций. Несколько функций переименовали просто чтобы людям не так страшно было новый мир осваивать. Map переименовали в Select, Filter в Where, Fold в Aggregate, Sort в OrderBy. По сути же как были функции, так и остались.

VD>>Или ты думаешь, что Хаскель тоже проектировали под соусом адаптации к SQL?

ГВ>Нет, разумеется.


А почему нет? Goto тоже нет!
Это же твоя логика?

ГВ>Да... 36-й уровень вложеннности в дискуссии — самое удачное место для обработки масс, кто бы спорил.


И это не может не радовать.

ГВ>Встречная просьба того же порядка.


Я не обосновал хотя бы одно свое суждение?

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


ГВ>Угу. Как всегда, когда доказать не удаётся, остаётся уговорить.


Ну, дык. Как можно доказать что-то человеку который просто фильтрует все аргументы и гнет одно и то же не смотря на то, что очевидно, что его утверждения противоречат фактам?

ГВ>Проблема в том, что сейчас мы обсуждаем как раз причины.


Да, ну? А, понял. Это ты себя на Вы. Да?

VD>>К тому же ты уже достал повторять чушь. Тебе сказали, что в Хаскеле может и думали только о СУБД. Но когда разрабатывали ЛИНК, то думали только и исключительно об универсальном решении. Просто средство доступа к данным никто в язык общего назначения не включил бы.


ГВ>Об универсальном решении чего?


Доступа к данным.

ГВ>>> И очень хорошо знаю, что до LINQ собственных более или менее адекватных средств разрешения этой проблемы у MS не было. Почему я должен скидывать эти два соображения со счетов — сие мне неведомо.

VD>>Потому что они не имеют отношения к делу.

ГВ>Не-не-не. Это ты настаиваешь на том, что я должен от них абстрагироваться. Почему я должен абстрагироваться от весьма весомых причин в контексте обсуждения причин — ещё одна тайна.


Продемонстрируй связь.

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

VD>>Опять же. Никому нет никокого дела до того что и под чем понимают люди и с какой частотой.
VD>>LINQ to Object используют чаще чем LINQ to SQL. Но из этого не следует, что LINQ создан толко для обработки данных в памяти.

ГВ>А кто-то это утверждает?


Что? Что LINQ to Object чаще используется? Или вывод? Вывод построен по твоим лекалам. Первое — это факт подтвержденный несколькими людьми прямо в этой теме.

VD>>Ну, как же? Ты все время меня пытаешься заставить подумать о разной фигне не относящейся к делу.


ГВ>Странно. Обсуждаем, вроде бы, назначение. А факторы, которые в немалой степени определяют это самое назначение, почему-то нужно выбросить из рассмотрения.


Ага. Назначение, а не причины создания. Улавливаешь разницу?

ГВ>>>Просто скажи, что тебе не интересно это обсуждать и выйди из обсуждения.

VD>>Ага. Не интересно. Я лучше тебя знаю был задуман и реализован линк.

ГВ>Дык. Жду прямых доказательств ошибочности моих суждений.


Я тебе доказал, что твои суждения о назначении линка неверны.
Доказывать что-то по поводу причин его создания не имею желания и не вижу смысла. К тому же свечку я не держал и мои слова будут не более чем догадками.

ГВ>>> Только какой смысл при этом встревать с опровержениями высказываний других?

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

ГВ>Ага. Иными словами — неймётся. Так и запишем.


Запиши. И читай перед сном. Может полегчает.

VD>>Я считаю LINQ универсальным средством и мне по фиг ради чего он введен.

VD>>Это факт и его глупо оспаривать.

ГВ>Ну пофиг, так пофиг. Я ж не требую от тебя изменить своё мировоззрение.


Это не мировоззрение. Это факт. Он не у меня. Он просто есть.


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


ГВ>Ну, чуть выше ты утверждал, что лучше меня знаешь, как и почему был задуман LINQ.


Ага.

ГВ>Так я жду рассказа. Желательно, с указанием причин событий, а не: "...и тут он решил, что было бы здорово...". Сначала расскажи о том, почему "он" получил право решать что-то.


А я рассказывал. Ты как обычно профильтровал.
К тому же это не имеет отношения к делу.

ГВ>>> Но вот кое-чего в Linq.Expressions нет. Например, нет меток/goto. По странному стечению обстоятельств goto отсутствует и в выражениях SQL-запросов.

VD>>В Хаскле и Nemerle тоже нет GOTO. Видимо тут тоже странное стечение обстоятельств.
VD>>Их тоже писали под влиянием SQL?

ГВ>Нет. Одно с другим не связано. Я просто отметил странное совпадение. А ещё goto — имманентная составляющая циклов.


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

VD>>Ты хоть понимаешь каких чудесных выводов можно добиться таким образом?

VD>>Кстати, в Яве тоже нет GOTO!

ГВ>Зато в Яве есть for/while. Вот незадача.


А в Nemerle и Haskell нет. И какие далеко идущие выводы из этого мы сделаем?

ГВ>>>Кстати, этот факт служит дополнительным аргументом (помимо других) для введения ФП-свойств в любой язык программирования, который предполагается использовать в тесной связи с SQL-серверами.

VD>>Гениально!
VD>>А чему служит факт, что современный SQL поддерживает рекурсивные запросы (на базе CTE), а ЛИНК нет?

ГВ>Вероятно, подтверждению моего высказывания о том, что возможности SQL Server всё ещё шире LINQ. Было тут где-то оно...


Так к чему все твои замечания то? Они ничего не доказывают и ни на что не влияют. Ты это понимаешь?

ГВ>Без паники. Зато я остался. Приключения продолжаются.


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

ГВ>>>Ну да-да. "Слоны всем, в ямы никого, Джунгахора!" Ладно, если не вышучивать, то всё это — вполне естественные следствия ФП. Хотя на мой взгляд, подо всё это хозяйство логичнее было бы завести подходящие атрибуты в C#.

VD>>Что за атрибуты? Выражайтесь яснее (с)

ГВ>Я тебе должен рассказать, что такое атрибуты в C#? Хм. VladD2 расспрашивает ГВ про C#? Ради этого момента стоило поспорить!


Просто между атрибутами C# и обсуждаемой темой на мой взгляд нет никаких связей. Я думал ты знаешь что-то, что я не знаю. Оказывается это очередное многозначительное высказывание не о чем. ОК.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.11.09 00:27
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>def (_, _, res) = lst.Aggregate((0, true, List()), ((prev, skip, res), cur) =>

VD> if (skip) (cur, false, res)
VD> else if (prev + 1 == cur) (cur, true, { res.Add(cur); res })
VD> else (cur, false, res));

Туплю. Можно еще проще:


def (_, _, res) = lst.Aggregate( (  0,  true, List()), ((prev, skip, res), cur) =>
   if (!skip && prev + 1 == cur) (cur,  true, { res.Add(cur); res })
   else                          (cur, false, res));
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.09 01:15
Оценка: :)
Здравствуйте, VladD2, Вы писали:

ГВ>>Тем не менее, спасибо за ответы на мои.

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

На какие именно вопросы ответов нет? По-моему, я ответил на все, кроме одного, поставленного некорректно.

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

ГВ>>В чьих глазах?
VD>Окружающих. Не думаешь же ты, что все такие идиоты, что не видят очевидных брешей в твоих рассуждениях?

"Отучаемся говорить за всех".

ГВ>>Логически здесь как раз следует, что в ряде случаев LINQ — не пришей кобыле хвост.

VD>Ты бы спросил, тебе бы сразу ответили, что LINQ это не панацея.
VD>Я сразу сказал, что линк зачастую позволяет получить намного более компактынй и понятный код. Во многих != во всех.
VD>Примеры тебе приводили.

О! Так вот как раз о тех случаях, которые выходят за пределы множества "во многих" я тут и толкую.

ГВ>> Одна лишь демонстрация крутизны на ровном месте.

VD>Да нет там никакой крутизны. Это инструмент которым нужно уметь пользоваться. Надо быть полным кретином чтобы при наличии линк накручивать многокилометровые циклы и выписывать отдельные методы в тех случаях когда линк позволяет обойтись парой строчек. И надо быть таким же кретином чтобы совать его во все дыры.

Какая блистательная мысль! Запомни её, а лучше запиши.

VD>Вопрос только в том причем тут РСБУД?


При том, что множество "во многих" странным образом похоже на "запросы к РСУБД".

ГВ>> Да и честно сказать, даже реализация на Nemerle круто проигрывает банальному циклу в читабельности.

VD>От части — это с непривычки. Я так оба варианта отлично читаю.
VD>Отчасти это потому, что задача действительно на циклах решается без особых потерь.

О! Слышу слова не мальчика...

VD>А отчасти потому, что оторвано от реальности.

VD>В реальности такие выпендрежи бывают крайне редко. А вот просто отфильтровать, отсортировать, сгрупировать, отобрать X элементов пропустив Y элементов — это нужно постоянно.

Вот это как раз и есть отличие "твоей" реальности от "моей". Вот мне, например, ровно наоборот — редко нужно "отфильтровать, сгруппировать, отобрать X элементов пропустив Y элементов", зато часто нужно быстро собрать в кучу и пихнуть в канал не глядя, посчитав crc32 для проформы. Или, например, проверить влетевшее сообщение на корректность, не используя new/delete, прямо по буферу данных. Или, скажем, собрать кучу сообщений из разных источников и плюнуть сигнал, что чудо таки случилось, и все прибежали. Куда мне тут LINQ вклеивать — ума не приложу. Но ведь тоже — источники данных с какой-то точки зрения.

А паче чаяния случается нужда гонять аккурат такую обработку, как у меня во второй задаче. Только в SQL-сервер я её запихнуть не могу и вообще в память полностью загрузить не получится, поскольку памяти будет острая нехватка, а на Win64 юзверь, зараза, переходить не желает. И ещё, шайтан-кнопкодав, хочет, чтобы это всё быстро работало. Мерзавец!

ГВ>>Зато, что любопытно, реализация на Go
Автор: Gaperton
Дата: 22.11.09
по ясности изложения резко обходит всех.

VD>Гы. Красота еще та. Туча бесполезных строк. Спроси у своего друга, на достуге, что будет если в потоке не будет данных. Он ведь так смело из него первый элемент читает.

А это горутина. Будет ждать, пока данные не поступят.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: LINQ только для РСУБД!
От: Belsen  
Дата: 01.12.09 03:21
Оценка: +1
Здравствуйте, Константин Л., Вы писали:

КЛ>Типичное применение Linq:


КЛ>
КЛ>var doc = XDocument.Load(xmlReader);
КЛ>                    return doc.Descendants("mapping")
КЛ>                        .Select(
КЛ>                            element =>
КЛ>                                new { Ext = element.Attribute("extension").Value, MimeType = element.Attribute("mimeType").Value }
КЛ>                        )
КЛ>                        .ToDictionary(
КЛ>                            mapping =>
КЛ>                                mapping.Ext
КЛ>                                ,
КЛ>                            mapping =>
КЛ>                                mapping.MimeType
КЛ>                        );
КЛ>


Почему бы данный пример не записать сразу так:
return XDocument.Load(xmlReader).Descendants("mapping")
    .ToDictionary(e => e.Attribute("extension").Value, e => e.Attribute("mimeType").Value);
I might be wrong...
Re[3]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.09 18:26
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Ну да. Человек либо дает себе труд разобраться в том, о чем пишет, либо нет.


+1

ЗЫ

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

В общем, нравится тебе этот язык. Замечательно. Только не надо его героизировать. А то станешь похожим на Вирта с его обероном.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 11.11.09 19:36
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Прости, но когда я прочел твое сравнение этого Гоу с Питоном, то у меня возникло стйкое ощущение, что как минимум Питон ты точно знаешь очень поверхностно.


А меня вот уже давно возникло стойкое ощущение, что 90% языков, которые ты берешься обсуждать, ты знаешь очень поверхностно. К разговору твоя личность конечно не имеет никакого отношения, как и моя, но почему бы тебе не узнать об этом моем ощущении, правда? Не вижу причин, почему нет.

Кстати, я не сравнивал этот язык с Питоном. Я говорил, что класс задач для этого языка будет примерно похожий. Имея при этом в виду серверные приложения Питона — в следующем посте есть пояснение, кстати. Но ты же у нас не всегда задумываешься над тем, что комментируешь. Так что я не в претензии.

VD>В общем, нравится тебе этот язык. Замечательно. Только не надо его героизировать. А то станешь похожим на Вирта с его обероном.


Я его не героизирую. Я отметил, что он мне понравился, и ничего больше. Можно, разрешаешь? Секта не против? А то порядки у вас больно строгие.
Re[5]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 11.11.09 20:33
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>А меня вот уже давно возникло стойкое ощущение, что 90% языков, которые ты берешься обсуждать, ты знаешь очень поверхностно. К разговору твоя личность конечно не имеет никакого отношения, как и моя...


Предлагаю на этом закруглиться с обсуждением личностей. IT
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: LINQ только для РСУБД!
От: Воронков Василий Россия  
Дата: 11.11.09 21:51
Оценка:
Здравствуйте, Alexey Axyonov, Вы писали:

AA>Интересно в каком из слов Language, Integrated, Queries ты нашел упоминание о СУБД.


Ну человеку спецификация C# 3.0 "неинтересна". Чего вы от него хотите?
Re[5]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 11.11.09 22:19
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

AA>>Интересно в каком из слов Language, Integrated, Queries ты нашел упоминание о СУБД.


ВВ>Ну человеку спецификация C# 3.0 "неинтересна". Чего вы от него хотите?


Да, неинтересна. И это совершенно нормально. Я вообще не люблю оффтопик.
Re[5]: LINQ только для РСУБД!
От: Cyberax Марс  
Дата: 11.11.09 22:25
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Потом попробуй мне объяснить, каким именно боком LINQ, SQL, и реляционная модель тебе пригодиться, к примеру, при работе с базой данных построенной на схеме map-reduce. Если не слышал о таких — погугли.

Да элементарно пригодится.

На LINQ, вон, вообще трассировку лучей пишут: http://blogs.msdn.com/lukeh/archive/2007/10/01/taking-linq-to-objects-to-extremes-a-fully-linqified-raytracer.aspx
Sapienti sat!
Re[5]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.09 22:44
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Вот статья о LINQ в википедии. Покажи мне пожалуйста, каким именно образом можно обойти вниманием реляционную модель, реляционные базы данных, и SQL, говоря о LINQ.


Не не не. Это ты сперва покажи, каким образом их нельзя обойти, говоря о LINQ.

P.S. Статья в русской википедии по качеству просто никакая.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
AVK Blog
Re[7]: LINQ только для РСУБД!
От: Cyberax Марс  
Дата: 11.11.09 23:20
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Слабовато как-то. Не проняло. Может быть, современная наука на этом не остановилась? И есть работа, как LINQ помогает в решении диффуров? Или кто-нибудь придумал, как на LINQ парсить протокол SIP? Или может быть, изобрели способ делать на LINQ драйверы, декодировать MPEG4 в реальном времени, или иным образом удалить гланды через задний проход?

LINQ — это лишь способ выдирать Expression Tree. А что ты с ним дальше делаешь — твоё личное дело. Можешь приспособить для решения диффуров и декодирования MPEG4.

G>Да, тогда б конечно. Я наверное поверил бы, что при работе с базой данных map-reduce без LINQ никак нельзя обойтись. Вероятно, я бы проигнорировал даже тот факт, что там совсем не реляционная модель в основе, и в этих плясках с бубнами нет необходимости.

Так никто не говорит, что "не обойтись". Но с LINQом многое удобнее.

Вот тут его для Coachdb можно использовать: http://james.newtonking.com/projects/json/help/
Sapienti sat!
Re[8]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 12.11.09 00:23
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>LINQ — это лишь способ выдирать Expression Tree. А что ты с ним дальше делаешь — твоё личное дело. Можешь приспособить для решения диффуров и декодирования MPEG4.


Простой вопрос — а нафига мне выдирать Expression Tree и что-то с ним делать, не имея действительно строгих к тому показаний, что без этого реально сильно туго/сложно получается?

G>>Да, тогда б конечно. Я наверное поверил бы, что при работе с базой данных map-reduce без LINQ никак нельзя обойтись. Вероятно, я бы проигнорировал даже тот факт, что там совсем не реляционная модель в основе, и в этих плясках с бубнами нет необходимости.

C>Так никто не говорит, что "не обойтись". Но с LINQом многое удобнее.

А настолько-ли удобнее, чтобы ради пары финтифлюшек тянуть в решение очередную концепцию, и вводить еще один indirection level? Покажи, какие именно вещи ты сделаешь удобнее, в случае SIP-сервера. Задача ведь тебе знакома, так? Или библиотеки а-ля gstreamer. Что, правда радикальный эффект получится, да?

C>Вот тут его для Coachdb можно использовать: http://james.newtonking.com/projects/json/help/


Нафига? Ты представляешь себе характер запросов при работе с CouchDB? Ты в большинстве сразу из вьюхи-мапа простым лукап-запросом вынимаешь готовые данные, которые уже правильно сгруппированы, и все. Там многие вещи, привычные по реляционным БД, делаются _по_другому_. Т.е. совсем. Так, что не приходится ничего по сусекам выскребать.
Re[9]: LINQ только для РСУБД!
От: Cyberax Марс  
Дата: 12.11.09 00:30
Оценка:
Здравствуйте, Gaperton, Вы писали:

C>>LINQ — это лишь способ выдирать Expression Tree. А что ты с ним дальше делаешь — твоё личное дело. Можешь приспособить для решения диффуров и декодирования MPEG4.

G>Простой вопрос — а нафига мне выдирать Expression Tree и что-то с ним делать, не имея действительно строгих к тому показаний, что без этого реально сильно туго/сложно получается?
В более человеческом стиле писать запросы или комбинировать предикаты для map/reduce, например.

C>>Так никто не говорит, что "не обойтись". Но с LINQом многое удобнее.

G>А настолько-ли удобнее, чтобы ради пары финтифлюшек тянуть в решение очередную концепцию, и вводить еще один indirection level? Покажи, какие именно вещи ты сделаешь удобнее, в случае SIP-сервера. Задача ведь тебе знакома, так? Или библиотеки а-ля gstreamer. Что, правда радикальный эффект получится, да?
Не, ну так можно сказать о функциональном программировании, объектном ориентировании и т.п.

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

C>>Вот тут его для Coachdb можно использовать: http://james.newtonking.com/projects/json/help/

G>Нафига? Ты представляешь себе характер запросов при работе с CouchDB? Ты в большинстве сразу из вьюхи-мапа простым лукап-запросом вынимаешь готовые данные, которые уже правильно сгруппированы, и все. Там многие вещи, привычные по реляционным БД, делаются _по_другому_. Т.е. совсем. Так, что не приходится ничего по сусекам выскребать.
Ну вот эту вьюху можно записать в виде LINQ. Оно для этого вообще идеально подходит. И где-то я это даже уже видел.
Sapienti sat!
Re[5]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.09 11:25
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Вот статья о LINQ в википедии.


G>http://ru.wikipedia.org/wiki/Language_Integrated_Query


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

Загрузи бесплатный C# Express и попробуй LINQ в реальной обстановке.

Если же обращаешься к Википедии, то хотя бы используй английский вариант:
http://en.wikipedia.org/wiki/Language_Integrated_Query

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


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

Давай лучше я еще раз и более развернуто объясню тебе, что имел в виду? ОК?

Так вот. LINQ — это:
1. Библиотека функций высшего в которой привычные для функциональщиков имена ФВП заменены на аналоги из SQL. При этом с самим SQL функции и даже синтаксис LINQ имеет мало общего. Эта библиотека имеет отдельное название LINQ to Object.
2. Синтаксические расширения языков. На самом деле не более чем сахар, так как и без них все ОК.
3. Языковые расширения позволяющие преобразовывать код так называемых лябда-выражений в AST (обозванное Expression [Tree]).
4. Ряд провайдеров позволяющих преобразовывать Expression Tree в запросы к внешним источникам данных.





G>Потом попробуй мне объяснить, каким именно боком LINQ, SQL, и реляционная модель тебе пригодиться, к примеру, при работе с базой данных построенной на схеме map-reduce. Если не слышал о таких — погугли.


G>Вообще есть огромный мир, лежащий за рамками того, к чему вы привыкли. Мир, в котором сервера работают не под Windows, и в котором не применяют РСУБД. В задачах телекома, к примеру, покажешь мне, в какое место засунуть ваш LINQ, и каким образом люди без него спокойно обходятся? Вне контекста баз данных, разумеется. Он же типа совсем-пресовсем никакого отношения к ним не имеет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.09 11:27
Оценка:
Здравствуйте, Gaperton, Вы писали:

Собственно я что-то занялся фигней. Зачем было столько писать когда я давным давно все что нужно написал вот здесь:
http://rsdn.ru/forum/dotnet/3081584.1.aspx
Автор: Чистяков Влад (VladD2)
Дата: 28.08.08
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.09 12:09
Оценка:
Здравствуйте, Gaperton, Вы писали:

VD>>Прости, но когда я прочел твое сравнение этого Гоу с Питоном, то у меня возникло стйкое ощущение, что как минимум Питон ты точно знаешь очень поверхностно.


G>А меня вот уже давно возникло стойкое ощущение, что 90% языков, которые ты берешься обсуждать, ты знаешь очень поверхностно.


Я этого и не скрываю. Но не до такой степени, чтобы не понимать, что класс задач у Гоу и Питона координально различаются.

G>К разговору твоя личность конечно не имеет никакого отношения, как и моя, но почему бы тебе не узнать об этом моем ощущении, правда? Не вижу причин, почему нет.


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

G>Кстати, я не сравнивал этот язык с Питоном. Я говорил, что класс задач для этого языка будет примерно похожий. Имея при этом в виду серверные приложения Питона — в следующем посте есть пояснение, кстати. Но ты же у нас не всегда задумываешься над тем, что комментируешь. Так что я не в претензии.


Я не профи в Питоне, но понимаю суть языка. Посему ствои слова вызыват у меня удивление.
Основой фишкой питона является прототипный ООП, динамический контроль типов, утиная типизация и метапрограммирование которые замечательно получается на базе предыдущих фишек. В Гоу этим даже не пахнет. Напротив Гоу предлагате статическую типизацию. Упрощенный до нельзя ООП (или закос на него).
Все это наследие Оберона, а не питона. И стало быть ниши этот язык будет скорее всего делить не с Питоном, а с Обероном и Компонентным Пасклаем (ака Блэк Бокс).

VD>>В общем, нравится тебе этот язык. Замечательно. Только не надо его героизировать. А то станешь похожим на Вирта с его обероном.


G>Я его не героизирую. Я отметил, что он мне понравился, и ничего больше. Можно, разрешаешь? Секта не против? А то порядки у вас больно строгие.


Шутка повторенная дважды перестает быть шуткой. У всех у нас есть свои "секты". Мировозрение разных людей не может быть идентичным.
Я стараюсь быть беспреспрестрастным когда говорю о языках. Чего и тебе советую.
Пойми я возразил тебе исключительно из-за тог, что твои рассужения, на мовй скромный взгляд, очень далеки от реальности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.09 13:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Основой фишкой питона является прототипный ООП, динамический контроль типов, утиная типизация и метапрограммирование которые замечательно получается на базе предыдущих фишек. В Гоу этим даже не пахнет.


Утячья типизация в нем есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
AVK Blog
Re[9]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.09 13:08
Оценка:
Здравствуйте, IT, Вы писали:

IT>Позанудствую. Преобразованием лямбд в ExpressionTree занимается непосредственно компилятор. Это всё можно делать и без Linq, так же как и Linq можно использовать без ExpressionTree.


Это вопрос того, что понимать под LINQ. МС под ним понимает весь набор функционала, не только query comprehension.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
AVK Blog
Re[11]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.09 13:08
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Можно. Тока опять, решающее преимущество разве будет?


Ты его не там ищешь. LINQ обеспечивает бесшовную интеграцию системы типов БД и системы типов используемого языка.

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


В контексте LINQ это совершенно пофик.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
AVK Blog
Re[7]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.09 14:07
Оценка:
Здравствуйте, Gaperton, Вы писали:

ВВ>>У тебя не возникает сомнения, что твое мнение о LINQ на основе статьи из википедии может быть, скажем так, не совсем полным?


G>Вот у тебя, к примеру, не возникло сомнения в том, что я знаком с LINQ только по русской википедии. Ты, также, по видимому, абсолютно уверен в том, что я просто не понимаю LINQ, а ты понимаешь, и ты хочешь мне это показать.


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

Ты очень правильно сравнил (тут где-то рядом) LINQ с лист/куари-компрехеншоном. Это оно и есть, если говорить о синтаксисе. В язык просто засунут синтаксис который переписывается компилятором в вызовы функций высшего порядка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 12.11.09 14:20
Оценка:
Здравствуйте, AndrewVK, Вы писали:

G>>Можно. Тока опять, решающее преимущество разве будет?


AVK>Ты его не там ищешь. LINQ обеспечивает бесшовную интеграцию системы типов БД и системы типов используемого языка.


В этой области искать преимущество LINQ мне запретили эксперты по LINQ, как ты мог заметить.

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

AVK>В контексте LINQ это совершенно пофик.

Не совсем пофиг, и дело не в LINQ. Дело в проблеме, которую он эффективно решает.

В контексте работы с базой map-reduce, не возникает проблемы mapping-а типов в тех масштабах и в таком виде, как при работе с РСУБД. И, как следствие, острой необходимости с ней бороться. Функции map и reduce пишутся в терминах "родных" типов. Отдельного развитого языка запросов нет — он не нужен. Данные в таких базах обычно нетипизированы — они лишены структуры и схемы. Поэтому, нет большого количества "типов", с которыми надо интегрироваться.

К примеру, имея дело с CouchDB весь mapping сводится к сериалайзеру JSON. И все. Его же можно устроить достаточно "гражданским" образом, не применяя "магии". И будет _достаточно_ удобно.

Это все имеет значение почему. Масштабируемые веб-приложения, способные работать на больших фермах, строятся сейчас и будут в будущем строиться на базе map-reduce.
Re[10]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.09 14:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Это вопрос того, что понимать под LINQ. МС под ним понимает весь набор функционала, не только query comprehension.


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

В спецификации C# 3.0 эта аббревиатура не встречается во все, а 4.0 только один раз:

This is useful in many LINQ methods. Using the declarations above:

var result = strings.Union(objects); // succeeds with an IEnumerable<object>

Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.09 14:24
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Основой фишкой питона является прототипный ООП, динамический контроль типов, утиная типизация и метапрограммирование которые замечательно получается на базе предыдущих фишек. В Гоу этим даже не пахнет.


AVK>Утячья типизация в нем есть.


А можно ссылку на описание?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.09 14:46
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А можно ссылку на описание?


Спецификация языка, интерфейсы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
AVK Blog
Re[13]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.09 14:46
Оценка:
Здравствуйте, Gaperton, Вы писали:

AVK>>Ты его не там ищешь. LINQ обеспечивает бесшовную интеграцию системы типов БД и системы типов используемого языка.


G>В этой области искать преимущество LINQ мне запретили эксперты по LINQ, как ты мог заметить.


Может и мог, но не заметил.

G>К примеру, имея дело с CouchDB весь mapping сводится к сериалайзеру JSON. И все. Его же можно устроить достаточно "гражданским" образом, не применяя "магии". И будет _достаточно_ удобно.


В итоге тебе все равно придется эти данные обрабатывать в самом приложении.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
AVK Blog
Re[7]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.09 16:01
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Все не так прямолинейно. Питон, как это ни странно, довольно часто применяется для серверных задач. В том же классе аппликух, что и Эрланг.


Все очень даже прямолинейно. Питон во много раз мощнее этого Гоу. И в ближайшие лет 5 Гоу его не догонит. В то же время, по скорости этот Гоу будет соперничать скорее с C# и Явой. Они тоже в серверных приложениях во всю применяются. Ты сейчас пользуешься сервером написанном на C#.

G>Вот там-то его гоу и настигнет. Гоу уровнем пониже питона и попроще, это так. Зато, он быстр, и _достаточно_ выразителен, чтобы выкинуть _связку_ С/С++ — Питон. Он не заставляет выбирать между комфортом, простотой языка, и эффективностью, предоставляя достаточно неплохой балланс.


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

G>Да, и Эрлангу эта штука тоже вполне конкурент. Не потому, что язык похож чем-то, а потому, что удобен в том же классе задач.


Не ты ли тут рассказывал, что без языковых особенностей Эрланга реализовать аналогичные фичи (легкие процессы общающеся между собой сообщениями) эффективно будет крайне тяжело? Если же говорить только о самих фишках, то конечно, наличие встроенных средств работы с многопоточностью чем-то роднит Эрланг и Гоу. Но тем самым класс задач у них не сильно пересекается. То что легко и качественно пишется на Эрланге на Гоу будет болью в жопе.

И опять же. В питоне как раз нет встроенных фишек работы с многопоточностью. Но зато в нем есть мега-фича — метапрограммирование которое позоляет реализовать в питоне любую из таких фишек. И те кого не устроят фишки Гоу опять же предпочтут питон.

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


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

VD>>Я не профи в Питоне, но понимаю суть языка. Посему ствои слова вызыват у меня удивление.

VD>>Основой фишкой питона является прототипный ООП, динамический контроль типов, утиная типизация и метапрограммирование которые замечательно получается на базе предыдущих фишек. В Гоу этим даже не пахнет. Напротив Гоу предлагате статическую типизацию. Упрощенный до нельзя ООП (или закос на него).
VD>>Все это наследие Оберона, а не питона. И стало быть ниши этот язык будет скорее всего делить не с Питоном, а с Обероном и Компонентным Пасклаем (ака Блэк Бокс).

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


Ну, почему же? Я вижу суть языка.
В последнее время танкостроение стало моим хобби. Я не утверждаю, что я мега-крут в этой области, но все же такие базовые вещи я различаю очень хорошо.
Так вот задачи для которых предназначен Гоу, на мой взгляд — это не сложные по логике, требующие более-менее приемлемой производительности, и надежности программы. Серверные, не серверные без разницы. Хотя конечно типобезопасный язык на сервере более важен в виду требований к устойчивости.
Питон же как раз сильно отличается тем, что обеспечивает решение более сложных задач за счет намного более мощьных языковых возможностей, но при этом не обеспечивающий приемлемой производительности и от того не применимый в так называемых системных задачах.

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


Ну, и как ты тогда умудряешься не замечать того, что языки очень сильно отличаются? Они предполагают радикально разный подход к разработке!

G>Go, будучи статически типизированным, разработан так, чтобы сохранить ощущение "легкости" и простоты, возникающей при применении динамических языков. Андрей рядом правильно тебе указал, что там есть утиная типизация.


G>http://golang.org/doc/go_lang_faq.html#inheritance

G>

G>Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods.


Это хорошее решение.

G>Ты вообще посмотри их language design FAQ, он короткий, и снимает все вопросы.

G>http://golang.org/doc/go_lang_faq.html

Да, я его смотрел. Но все детали сразу не углядишь.

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


G>Как ты понимаешь, я думаю ровно наоборот.


Понимаю .

G> И ты должен знать, что я вроде как не полный идиот. Стало быть, на то есть причины. Можно обсуждать эти причины. Это и есть конструктивная дискуссия.


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

ЗЫ

Кстати, возникла одна идея. Можно организовать небольшую "войнушку"... Завести отдельную тему в которой попробовать сравнить языки по выразительной мощности.
Я могу выступить за C# и Nemere. Ты за Go и Erlang, FR за Python, ну, и может быть еще кто-то подтянется. За одно можно будет сравнить полученные решения на скорость. Думаю, эта "битва" была бы интересна очень многим.

Ну, как идея?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.09 16:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>А можно ссылку на описание?


AVK>Спецификация языка, интерфейсы.


То есть утиная типизация доступна только для интерфейсов?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.09 16:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>То есть утиная типизация доступна только для интерфейсов?


На первый взгляд да.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
AVK Blog
Re[10]: LINQ только для РСУБД!
От: jazzer Россия Skype: enerjazzer
Дата: 13.11.09 12:24
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Спецификация языка, интерфейсы.


VD>То есть утиная типизация доступна только для интерфейсов?


Там интерфейсы — это как раз средство определения утиной типизации (типа "ходит и крякает") и используются в месте вызова, а не интерфейсы в стиле классических ООП-языков, в которых они используются в определении типа. Некоторая путаница в терминологии.
Примерно то, что хотели сделать концепциями в С++.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: LINQ только для РСУБД!
От: Mamut Швеция http://dmitriid.com
Дата: 13.11.09 13:43
Оценка:
VD> Кстати, возникла одна идея. Можно организовать небольшую "войнушку"... Завести отдельную тему в которой попробовать сравнить языки по выразительной мощности.
VD> Я могу выступить за C# и Nemere. Ты за Go и Erlang, FR за Python, ну, и может быть еще кто-то подтянется. За одно можно будет сравнить полученные решения на скорость. Думаю, эта "битва" была бы интересна очень многим.

VD> Ну, как идея?


Тут вот рядом тема «языки в боевых условиях»
avalon 1.0rc3 rev 304, zlib 1.2.3 (13.10.2009 10:16:48 EEST :z)(Qt 4.5.3)


dmitriid.comGitHubLinkedIn
Re[9]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.09 13:57
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Тут вот рядом тема «языки в боевых условиях»


Вот эта тема да еще мне не интересна. Причем не по задумке, не по месту проведения.

Тут нужен интерактив.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: LINQ только для РСУБД!
От: jazzer Россия Skype: enerjazzer
Дата: 13.11.09 17:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


J>>Там интерфейсы — это как раз средство определения утиной типизации (типа "ходит и крякает") и используются в месте вызова, а не интерфейсы в стиле классических ООП-языков, в которых они используются в определении типа. Некоторая путаница в терминологии.

J>>Примерно то, что хотели сделать концепциями в С++.

VD>Да, я уже это понял. Пожалуй — это самая яркая и правильная концепция выбранная в Гоу. Опять же не в нем придуманная, но все же.


Кстати, в каком языке она впервые реализована как конструкция языка? (понятно, что навернуть ее легко в динамических языках с первоклассными функциями, типа того же Перла)

VD>Отдельный вопрос как ее эффективно реализовать. Ведь мне не составит труда реализовать ее и для любого ООЯ, но при передаче ссылки придется неявно создавать еще один объект обертку или vtbl-map. Для немерле подобное можно даже на макросе залудить.


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

VD>Так что вопрос в том как это реализовано? Даже не так... Как этом может быть эффективно реализовано?


Ну язык же динамически типизированный в этой части.
Можно просто иметь табличку, какие типы каким интерфейсам удовлетворяют, заполнять ее в динамике и кэшировать результат.
Т.е. в первый раз проверить все честно, а потом просто смотреть: "ага, пришел типа А, должен сматчиться к интерфейсу Б, идем в табличку — ага, матчится, едем дальше".
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: LINQ только для РСУБД!
От: Mirrorer  
Дата: 13.11.09 17:49
Оценка:
Здравствуйте, Gaperton, Вы писали:


G>Извини, мне не интересно ни читать мануалы по С# 3.0, ни обсуждать с тобой LINQ. И то и другое имеет весьма далекое отношение к моей работе и интересам.


LINQ это монады в чистом виде. Базы тут постолько поскольку
И выстрелили они именно благодаря
а) удобству записи лямбд
б) выводу типов

Неужели плохо иметь возможность использования удобных паттернов?
Re[6]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 13.11.09 18:03
Оценка:
Здравствуйте, VladD2, Вы писали:

VD> Ты изучаешь технологии по статьям в Википедии?


Нет конечно, но я довольно часто привожу википедию в качестве иллюстрации. Удобно.

VD>Давай лучше я еще раз и более развернуто объясню тебе, что имел в виду? ОК?


VD>Так вот. LINQ — это:

VD>1. Библиотека функций высшего в которой привычные для функциональщиков имена ФВП заменены на аналоги из SQL. При этом с самим SQL функции и даже синтаксис LINQ имеет мало общего. Эта библиотека имеет отдельное название LINQ to Object.
VD>2. Синтаксические расширения языков. На самом деле не более чем сахар, так как и без них все ОК.
VD>3. Языковые расширения позволяющие преобразовывать код так называемых лябда-выражений в AST (обозванное Expression [Tree]).
VD>4. Ряд провайдеров позволяющих преобразовывать Expression Tree в запросы к внешним источникам данных.

Отлично. Теперь давай я тебе в свою очередь объясню, что я имел в виду. Для этого мне надо, чтобы ты ответил на два вопроса.

Какие проблемы решает LINQ, и что является для него killer application?
Re[7]: LINQ только для РСУБД!
От: Cyberax Марс  
Дата: 13.11.09 18:15
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Отлично. Теперь давай я тебе в свою очередь объясню, что я имел в виду. Для этого мне надо, чтобы ты ответил на два вопроса.

G>Какие проблемы решает LINQ, и что является для него killer application?
Доступ к данным.
Sapienti sat!
Re[8]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 13.11.09 18:19
Оценка:
Здравствуйте, VladD2, Вы писали:

G>>Вот у тебя, к примеру, не возникло сомнения в том, что я знаком с LINQ только по русской википедии. Ты, также, по видимому, абсолютно уверен в том, что я просто не понимаю LINQ, а ты понимаешь, и ты хочешь мне это показать.


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


Я не обижаюсь.

VD>Ты очень правильно сравнил (тут где-то рядом) LINQ с лист/куари-компрехеншоном. Это оно и есть, если говорить о синтаксисе. В язык просто засунут синтаксис который переписывается компилятором в вызовы функций высшего порядка.


Эрланговский QLC (query list conprehesion), с которым я сравнил LINQ, он не просто выглядит так же. Оно в Эрланге и работает примерно так же, дорогой тезка.

Это не list comprehensions. Это синтаксис list conprehensions, который переписывается компилятором при помощи parse transform в вызовы функций высшего порядка. Ну, не высшего, ок, в обычные функции, насколько я помню. Но точно так же — ты можешь определять произвольные источники данных, и эффекты во многом похожи.

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

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

Понятна ли мысль — это первый вопрос. Что ты об этом думаешь и согласен или не согласен — это тоже вопрос, но второй.
Re[14]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 13.11.09 18:31
Оценка:
Здравствуйте, AndrewVK, Вы писали:

G>>К примеру, имея дело с CouchDB весь mapping сводится к сериалайзеру JSON. И все. Его же можно устроить достаточно "гражданским" образом, не применяя "магии". И будет _достаточно_ удобно.


AVK>В итоге тебе все равно придется эти данные обрабатывать в самом приложении.


Придется. А в случае использования LINQ — неужели не придется? Объясни, не понимаю.
Re[13]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.09 18:34
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Ну язык же динамически типизированный в этой части.


Меня интересуют в основном статически типизированные языки. Для Питона или Руби нтерфейсы не нужны, а утиная типизация у них работает везде просто потому, что они динамически типизированные.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.09 18:39
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Какие проблемы решает LINQ, и что


Многие. В том числе казуальной обертки для ФП.

G>является для него killer application?


Как показало одно из обуждений данный термин понимается по разному.
Если говорить о главных особенностях, то их опять же много. Среди них и унификация обработки данных из разных источников (от списков объектов, до доступа к ООБД), и возможность обработки списков объектов в стиле ФП.

LINQ — это вообще торговая марка. В спецификации C# умудрились даже не дать его определения.

Ты же перескочил на обсуждение второстепенной темы и не понял того, что я тебе пытался сказать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 13.11.09 18:41
Оценка:
Здравствуйте, Mirrorer, Вы писали:

G>>Извини, мне не интересно ни читать мануалы по С# 3.0, ни обсуждать с тобой LINQ. И то и другое имеет весьма далекое отношение к моей работе и интересам.


M>LINQ это монады в чистом виде.

Это мне известно.

M>Базы тут постолько поскольку

M>И выстрелили они именно благодаря
M>а) удобству записи лямбд
M>б) выводу типов

Базы тут далеко не постольку поскольку.

Если бы не ацкие проблемы ввода-вывода в чистом Хаскеле, то и не было бы в нем все насквозь построено на монадах.

Монады при этом никак не завязаны на ввод-вывод, конечно. Однако, если бы не проблемы ввода-вывода, которые решаются монадами, то и do-синтаксис в Хаскель никто бы тащить не стал. В строгих языках ничего подобного нет, и не потому, что это не круто, бесполезно, или недостаточно общо, а просто потому, что нет ни острой проблемы ни необходимости.

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

M>Неужели плохо иметь возможность использования удобных паттернов?


Неплохо. Но если убрать необходимость работы с реляционной базой, то не настолько необходимо, чтобы отсутствие являлось значимым недостатком.
Re[8]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 13.11.09 18:43
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Хорошо, попробуй еще раз. Что ты хотел сказать?
Re[15]: LINQ только для РСУБД!
От: Воронков Василий Россия  
Дата: 13.11.09 18:44
Оценка:
Здравствуйте, Gaperton, Вы писали:

AVK>>В итоге тебе все равно придется эти данные обрабатывать в самом приложении.

G>Придется. А в случае использования LINQ — неужели не придется? Объясни, не понимаю.

Придется. Но ты сможешь делать это с помощью Linq. Например, Linq2Objects.
Re[9]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.09 18:45
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Это не так. И тебе об этом сказали сразу 4 действующих .нет-программиста. Но ты почему-то считаешь свое мнение правильным, а их не правильным.
Хотелось бы услышать обоснование, чем скажем:
lst.Where(el => el.Name == "Макс").Select(el => el.Age)

отличается скажем от:
map (filter lst fun el -> el#Name == "Макс") fun el -> el#Age

?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: LINQ только для РСУБД!
От: Cyberax Марс  
Дата: 13.11.09 18:49
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>Это не так. И тебе об этом сказали сразу 4 действующих .нет-программиста.
Более того, это сказал и я, хотя год назад я яростно флеймил против LINQ'а.

И вообще я .NET не люблю, но вот LINQ мне нравится.
Sapienti sat!
Re[9]: LINQ только для РСУБД!
От: Воронков Василий Россия  
Дата: 13.11.09 18:51
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Ну я вот не использую ни linq2sql, ни linq2entities. Не срослось. А вот, скажем, linq2objects использую постоянно. Не потому что он "мега-рулит" и на нем можно писать рей-трейсинг. Просто *удобнее*. Все. РСУБД при этом поблизости нет.
С помощью какой магической комбинации слов тебе нужно объяснить, что ты не прав?
Re[14]: LINQ только для РСУБД!
От: jazzer Россия Skype: enerjazzer
Дата: 13.11.09 19:27
Оценка:
Здравствуйте, VladD2, Вы писали:

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


J>>Ну язык же динамически типизированный в этой части.


VD>Меня интересуют в основном статически типизированные языки. Для Питона или Руби нтерфейсы не нужны, а утиная типизация у них работает везде просто потому, что они динамически типизированные.


Ну тогда смотри на плюсовые концепции.
Там тип сохраняется всю дорогу, так что ничего с собой тащить не надо.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[15]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.09 19:53
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Ну тогда смотри на плюсовые концепции.

J>Там тип сохраняется всю дорогу, так что ничего с собой тащить не надо.

Я на них 15 лет смотрел. Так ничего хорошего и не увидил. Был один лучик в темном царстве — концепты — но их похоже из нового стандарта выкинут.

И с типами там плохо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: LINQ только для РСУБД!
От: jazzer Россия Skype: enerjazzer
Дата: 13.11.09 20:57
Оценка:
Здравствуйте, VladD2, Вы писали:

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


J>>Ну тогда смотри на плюсовые концепции.

J>>Там тип сохраняется всю дорогу, так что ничего с собой тащить не надо.

VD>Я на них 15 лет смотрел. Так ничего хорошего и не увидил. Был один лучик в темном царстве — концепты — но их похоже из нового стандарта выкинут.


Так я именно их и имел в виду.

VD>И с типами там плохо.


Что именно плохо?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[12]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 14.11.09 21:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

G>>У меня получилось объяснить тебе мою позицию, Андрей?


AVK>Нет.


Жаль, все, что мог, я сделал. Не вижу смысла в дальнейшем разговоре.

G>>Тема LINQ притянута за уши


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


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

AVK>Ты просил доводы. Я тебе их привел.


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

AVK>Нет.


На обсуждение подобных "доводов" я время тратить не собираюсь. Может кому-то сильно интересно, почему это AVK сказал "нет" — но не мне. Так что с моей стороны дискуссия окончена.

G>>А вот спорить, и выслушивать серию разного рода понтов


AVK>Пока что понты в топике больше от тебя


Меня не интересуют понты. Не собираюсь их не выслушивать, ни обсуждать их количественную меру. Так что считай как тебе удобно. Все, пока.
Re[15]: Исправлена ссылка
От: Gaperton http://gaperton.livejournal.com
Дата: 15.11.09 13:01
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Оценка, которую человек выдает окружающим при недостатке информации — на самом деле больше говорит о самом человеке и его взгляде на мир, чем об окружающих. В частности, человек часто приписывает собственные черты, которые он не осознает, окружающим. Этот механизм называется "психопроекция".


Ссылка битая. здесь — рабочая.
Re[8]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 15.11.09 15:45
Оценка:
Здравствуйте, IB, Вы писали:

G>>Неплохо. Но если убрать необходимость работы с реляционной базой, то не настолько необходимо, чтобы отсутствие являлось значимым недостатком.

IB>Ну как тебе сказать. В 95% реального кода использование LINQ не связано с БД. Вообще.
IB>Так что отсутствие этого дела сильно усложняет решение повседневных задач, и да, отсутсвие LINQ на практике — значимый недостаток даже если нет работы с БД.

В Хаскеле тоже применение монад в 90% случаев не ограничивается монадой IO, и в общем случае не связанно с вводом-выводом. Вообще. Из чего вовсе не следует, что отсутствие "этого дела" радикально и невероятным образом усложнит решение повседневных задач в другом языке, с другим предназначением, и другой раскладкой плюсов-минусов, где идиоматичным является другой подход к тем же самым проблемам. Настолько радикально, что надо обязательно затащить в простой by design язык еще одну концепцию, сделав его сложнее.

Если ты считаешь отсутствие поддержки LINQ недостатком конкретного языка Go (давай к теме вернемся, задолбал офтопик уже), то не мог бы ты привести пример наиболее повседневной задачи, которая наиболее сильно усложняется при отсутствии LINQ? Перейдем к проблеме и коду, и посмотрим, насколько именно все усложнится, и насколько повседневная эта задача.
Re[20]: Исправлена ссылка
От: FR  
Дата: 15.11.09 16:11
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не всякое упоминание психологии суть мозговедство (расклеивание псевдопсихологических ярлыков). И не всякое мозговедство можно свести к психологии. Ну и кроме того, в тексте по приведённой ссылке описан один из механизмов нормальной психики, а вовсе не какой-то там "диагноз". "Диагнозы" — ещё одна особенность "мозговедения", например — "фобии".


Угу только в результате все равно получится срач.

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


Психиатры делят население на две категории: больные и не обследованные.

Re[11]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 15.11.09 18:52
Оценка:
Здравствуйте, netch80, Вы писали:

N>Да, использовать LINQ стали тут же не для РСУБД; но возникло оно именно как средство работы для РСУБД.


Чистейшие домыслы. Если при разработке Linq и думали о РСУБД, то примерно так: "ну тут мы не знаем как сделать правильно, так что сделаем как-нибудь, а там парни разберуться, у них голова большая". Результат — разработка линк провайдеров для БД представляет собой редкостный по своей геморроидальности процесс.
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.11.09 19:16
Оценка:
Здравствуйте, Gaperton, Вы писали:

В следующий раз за непрошенный психоанализ будет бан. Твое завуалированное хамство уже начинает доставать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1284 on Windows 7 6.1.7600.0>>
AVK Blog
Re[14]: Вопрос
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.11.09 19:23
Оценка:
Здравствуйте, AndrewVK,

А с чем ты тут
Автор: Геннадий Васильев
Дата: 15.11.09
не согласен?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: Вопрос
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.11.09 20:10
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А с чем ты тут
Автор: Геннадий Васильев
Дата: 15.11.09
не согласен?


С твоими выводами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1284 on Windows 7 6.1.7600.0>>
AVK Blog
Re[11]: LINQ только для РСУБД!
От: Воронков Василий Россия  
Дата: 15.11.09 23:07
Оценка:
Здравствуйте, netch80, Вы писали:

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


А давайте вы для начала объясните, почему вы вставляете эту буковку "Р" в РСУБД, и как именно она связана с LINQ-ом?

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

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


А зачем делать "то же", но "немного менее эффективно или синтаксически сложнее"? В целях мазохизма?
Re[10]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 16.11.09 00:21
Оценка:
Здравствуйте, IB, Вы писали:

G>> Настолько радикально, что надо обязательно затащить в простой by design язык еще одну концепцию, сделав его сложнее.

IB>Погоди, не сползай... Давай вспомним, откуда вообще LINQ в данной дискуссии всплыл.
IB>Ты заговорил о простоте, в ответ тебе Влад привел LINQ в качестве примера сложной конструкции в языке, которая позволяет решать задачи просто. То, что ты за простоту — это понятно, вопрос за какую, за простоту языка или за простоту решений, которые посредством этого языка получаются?

Отлично поставленный вопрос.

Да, я прекрасно понимаю эти два типа простоты. Крайние примеры обоих типов — это ассемблер, или брейнфак — как пример крайне простого языка, на котором невозможно писать, и на другом полюсе — что-то вроде встроенного языка 1С, на котором чрезвычайно просто решаются некоторые задачи, но сам язык (в случае 1С — платформа) концептуально сложен.

Или, из неспецифичных для задачи — скажем, Хаскель. По количеству применяемых концепций, и их "глубине" — он невероятно сложен. Зато, позволяет решать задачи просто (при этом, простое для автора кода решение может легко разрушить мозг другим программистам).

Что касается меня — я не выступаю ни за один из этих типов простоты, ибо сторонник балланса, зависящего от ситуации, а также природы и масштаба решаемых проблем.

В данном треде, посвященном обсуждению Go, я принимаю как данность установку авторов Go. И все. (Что не означает, что я выступаю за какой-то определенный вид баланса простоты в языке как наилучший на все случаи вообще. Мне нравятся совершенно разные языки.)

А авторы Го, насколько я понимаю (и насколько описано на сайте Го), хотели воплотить в языке тот же тип простоты, который привлекает людей в "легких" динамических языках, вроде Питона или JavaScript. Или Erlang. Вот примерно такой, как в перечисленных языках, балланс этих двух типов простоты. Это было целью разработчиков Го, и совершенно объективно, спрос на подобный балланс "простот" в среде программистов есть. Мне он последнее время симпатичен. Для меня — на этом спор о простоте заканчивается, не начавшись.

Далее можно задаваться вопросами:
1) Стоило-ли разрабатывать такой язык, с такими целями. Это интересует Влада. Меня нет.
2) Насколько хорошо у авторов Го получилось реализовать свое намерение. Это интересует меня.

Вот, собственно, и все.
Re[13]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 16.11.09 15:36
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>The original motivation behind LINQ was to address the conceptual and technical difficulties encountered when using databases with .NET programming languages.


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

Давай лучше посмотрим не реалии здесь.

Обрати внимание на первой картинке даже сами MS не в состоянии на 100% поддержать для БД то, что они сами надизайнили. Обрати внимание на второй картинке насколько использование Linq Query медленнее обычного Native Query. У продуктов от MS это десятки раз. Что бы эти тормоза хоть как-то устранить приходится использовать костыли вроде Compiled Linq Query.

Вот такой незатейливый дизайн behind LINQ as original motivation. По самому использованию можно, например, посмотреть через какую жо на Linq реализуется LEFT JOIN или IN. Ну и для полноты картины стоит упомянуть, что в самой MS разработку Linq2SQL (реализацию Linq провайдера для одного сервера) оценивают в миллионы долларов.

Кстати, для сравнения, поддержка БД в Немерле работает не медленнее нативного кода, полностью типо-безопасна, верефицирует SQL во время компиляции и, главное, написана чуть ли не в качестве упраждения по макросам.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 16.11.09 16:03
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>

G>The original motivation behind LINQ was to address the conceptual and technical difficulties encountered when using databases with .NET programming languages.


IT>И что из этого следует? То, что индусам Linq легче преподнести как средство работы с БД или то, что дизайн линка позволяет легко и непринуждённо писать провайдеры для баз данных, а я просто этого не заметил?


IT>Давай лучше посмотрим не реалии здесь.


Давай.

LINQ to SQL, possibly Microsoft’s first ORM to actually ship in ten years of trying, was never even supposed to exist.

It started out as a humble Visual Studio project on my desktop machine way back in the fall of 2003, long before anyone heard about it, long before anyone even guessed what would come next, except for the readers of this blog, of course, since I used to post often with long obtuse and sometimes psychedelic meanderings that with the proper one-time pad to decrypt it you might have possibly guessed what was on my mind. I needed that project to prepare for what was coming. I needed expression trees and a basic SQL translator to get ready for the day when I would get my hands on the C# codebase and turn it into language that could actually do something interesting for a change; a language that would know how to query. [Cue the FoxPro fans]

Luckily, it didn’t take me long to get the basics up and running. You see, it wasn’t the first time I’d slapped together an ORM or modified a language to add query capabilities; having already designed ObjectSpaces and parts of C-Omega so I was certainly up to the task.[...]

THE ORIGIN OF LINQ TO SQL,
Читаем дальше здесь.
http://blogs.msdn.com/mattwar/archive/2007/05/31/the-origin-of-linq-to-sql.aspx
Re[13]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 16.11.09 16:05
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>LINQ in Action


Ну и вот тут
Автор: Alexander Polyakov
Дата: 15.11.09
ещё человек недоумевает насчёт original motivation.
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 16.11.09 16:27
Оценка:
G>THE ORIGIN OF LINQ TO SQL,
G>Читаем дальше здесь.
G>http://blogs.msdn.com/mattwar/archive/2007/05/31/the-origin-of-linq-to-sql.aspx

Ну, и что теперь делать будем? Будем креативно толковать текст, или, может быть, перейдем на обсуждение личности автора блога?
Re[16]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 16.11.09 16:44
Оценка:
Здравствуйте, 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>А ты почитал вторую ссылку, которую я тебе дал? Там рассказано почему так получилось, почему в борьбе добра с Хейльсбергом, победило вовсе не добро.


Не вопрос, сейчас почитаю.
Re[17]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 16.11.09 17:42
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Понимать, что Linq поддерживает SQL в том числе, а не только. А при более детальном рассмотрении оказывается, что как раз поддержка SQL хоть и имелась ввиду, но делалась по остаточному принципу.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.11.09 18:44
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


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


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

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

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

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

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

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

Пока что я вижу ряд удачных выборов в дизайне языке. Самым удачным выбором мне кажется использование утиной типизации при применении интерфейсов. Вопрос только в том можно ли это решение реализовать эффективно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 03:41
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


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


Я упомянул ЛИНК как фичу языка упрощающую решение задач на этом языке. А вот ты начал притягивать за уши разные ошибочные аргументы из которых следовало...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 04:05
Оценка:
Здравствуйте, netch80, Вы писали:

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


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

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

Ты прав, в том, что в основе идей линка лежала идея интегрировать в язык обращение к БД. Прототипом ЛИНКа был как не странно HaskellDB. Но HaskellDB — это встроеный в хаскель DSL. В Шарп его встравил один из тех кто догое время работал над хасклем. Посему он выбрал очень прямолинейный путь — в дотнет была включена библиотека аналогичная хакселевской библиотеке работы со списками, а синтаксическое расширение встроенное в Шарп и Васик просто переписывало код в вызовы этой библиотеки. Такой подход назвали query pattrn.
А вот для прозрачного доступа к СУБД пришлось более серьезно расширять язык. В язык встроили поддержку неявного преобрзования типов для лябд. Это позволило реализуя query pattrn указывать не только методы получающие лямбды, но и методы получающие АСТ.
Причем, в отличии от ХаскельБД в ЛИНК изначально заложили поддержку разных источников данных и в первую очердь ОБЫЧНЫХ объектов.
С базами данных работают не все и не всегда. А вот со списками объектов, все и всегда.
В результате ЛИНК стал в первую очередь библиотекой функций высшего порядка по работе с коллекциями.
И это было одной из целей создателей линк-а. Так как это было первым случаем встраивания фич функционального программирования в мэйнстрим-язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.11.09 14:57
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

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


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

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

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

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

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


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

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


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


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

VD>И высказано это "мнение" было не просто так в рамках общего повествования, а в качестве аргумента в пользу тезиса, что наличие ЛИНК-а усложняет язык.

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

Утверждения Гапертона, на мой сторонний взгляд, сводятся к одному: "от...итесь!" Извини мне мой французский.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[16]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 17.11.09 16:35
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


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


И это очевидно на первом же, основном и простом типе запроса.

И есть пример еще проще. Запрос-основа для TickChart — построения графика котировок. Он выдает на выход временной ряд котировок, с наложением простых фильтров, выбрасывающих их часть. Так вот, даже его проблема выразить в терминах SQL92 и реляционной модели, потому что один из этих "простых фильтров" — flat filter (исключаются одинаковые "тики" идущие подряд, если последовательность не пересекает границу сессии).
Re[13]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 16:38
Оценка:
Здравствуйте, netch80, Вы писали:

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

VD>>Аргументы? Ссылки?

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


Так будут аргументы или нет?

Ты утверждал (и поддерживал мнение) о том, что ЛИНК расчитан исключительно на работу с РСБУД и то, что это не универсальный инструмент.
Вот и потрудись обосновать свои заявления (и заявления которые ты поддерживал).

Отсутствие аргументов будем считать тихим "сливом".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 17.11.09 16:54
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Мне всё равно совпадает твоё мнение с моим или нет. Я тут распинаюсь ради истины, а не ради тебя.

G>Что ты статью-то, что я привел, не комментируешь?


Там нечего комментировать

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


Мои выводы основаны на глубоком и всестороннем изучении технологии, на знании её внутренностей и деталей реализации. А ты даже прессрелизов не читал. Действительно, замнём.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.11.09 19:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А, то что все выводы сделанные на основании не верных предпосылок является не верными. Нужно просто признать это и перестать упираться.


Хорошо, допустим, что LINQ создан не ради поддержки работы с РСУБД. Дальше что? Какое это отношение имеет к Go? Второй вопрос: какое действие можно осуществить на основании этого, бесспорно, глубокого и сакрального знания?

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

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

Включаем логику. Собеседника А не интересует точность его суждений по вопросу X, т.е. вопрос X находится вне сферы текущего обсуждения и вне сферы интересов собеседника А. Собесденик Б пытается навязать собеседнику А дискуссию по вопросу X. Какого хрена, извините?

VD>Ежу понятно, что если любой ценой игнорировать факты и очень хотеть во что-то верить, то можно оправдать любую чушь. Вот только насколько это конструктивно?


См. выше.

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

VD>Моя мысль никак не была привязана к ЛИНК-у. ЛИНК был приведен исключительно в качестве примера четко демонстрирующего, что увеличение фич языка (т.е. его формальное усложнение) зачастую делает сам язык проще и удобнее в использовании.

Очень хорошо. Теперь снова включаем логику. Обсуждение Go — это обсуждение уже имеющегося языка. Обсуждение гипотетических путей развития языков, очевидно, в круг вопросов, связанных с Go не входят.

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


VD>Какой в этом смысл?

VD>И какой смысл защищать такую позицию?

Внимательно прочти то, что я написал тебе выше.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.11.09 20:02
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Хорошо, допустим, что LINQ создан не ради поддержки работы с РСУБД. Дальше что? Какое это отношение имеет к Go? Второй вопрос: какое действие можно осуществить на основании этого, бесспорно, глубокого и сакрального знания?

VD>Ты внимательно прочел сообщение ответ на который цитировал?
VD>Мне кажется там все было очевидно. Плюс я уже раза 3 рядом описал все это в разжеванном виде.
VD>Не уж то нужно еще раз повторяться?

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

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

ГВ>>Включаем логику.
VD>Логику? А, да. Давно пора. А то все что я от тебя слышал ранее на логику не похоже.
VD>Но я просил привести аргументы.

Воткнись: я привёл тебе объяснение, почему твои доказательства в данном случае — ни в дуду, ни в Красную Армию. Безотносительно их корректности.

ГВ>>Собеседника А не интересует точность его суждений по вопросу X, т.е. вопрос X находится вне сферы текущего обсуждения и вне сферы интересов собеседника А. Собесденик Б пытается навязать собеседнику А дискуссию по вопросу X. Какого хрена, извините?

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

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

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


Ага, мне, может, ещё и устыдиться?

ГВ>> Обсуждение Go — это обсуждение уже имеющегося языка. Обсуждение гипотетических путей развития языков, очевидно, в круг вопросов, связанных с Go не входят.

VD>Это называется ты включил логику? Это ближе к бреду в горячке. Причем тут "гипотетических путей развития языков"?

А как можно интерпретировать твои рассуждения на предмет "если бы, да кабы" и "а не лучше ли переделать ..."? Это разве рассуждения не о гипотетическом? Если нет, то покажи мне, пожалуйста, легковесные потоки в Nemerle. (Ой, это я зря сказал. )

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

VD>Еще раз, последний...

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


Угу. В огороде бузина, а в Киеве дядька. Так понятно?

VD>Причем тут "Обсуждение гипотетических путей развития языков"?

VD>Ты намеренно тролишь или действительно не можешь понять столь простых и очевидных объяснений?

Оно тут прямо и непосредственно рядом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: Кроме того
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.11.09 20:05
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Кроме того, ты не внимательно прочёл обоснование. Оно заключалось в тех самых: "человек либо это понимает, либо нет".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.09 20:15
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Смысл твоего исходного утверждения был выяснен десятком уровней позже.


А кто в этом виноват и какая разница?
Не знаешь о чем говорят — переспроси. Сказал глупость и тебе на это указали, поправься и отталкивайся от корректных предпосылок.

Вот это по-моему и есть "включить логику".

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


ГВ>Ага, мне, может, ещё и устыдиться?


С сможешь?

VD>>Это называется ты включил логику? Это ближе к бреду в горячке. Причем тут "гипотетических путей развития языков"?


ГВ>А как можно интерпретировать твои рассуждения на предмет "если бы, да кабы" и "а не лучше ли переделать ..."?


Где ты увидел "если бы" в моих утверждениях?

ГВ>Это разве рассуждения не о гипотетическом? Если нет, то покажи мне, пожалуйста, легковесные потоки в Nemerle. (Ой, это я зря сказал. )


А причем тут вообще Немерел? Мое утверждение или чушь про линк котрую я получил в ответ касалось Немерле?
Или это теперь модно вместо признания собственной неправоты переключать разговор на все что угодно лишь бы запутать все окончательно?

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


ГВ>Угу. В огороде бузина, а в Киеве дядька. Так понятно?


Понятно. Ты тролишь как можешь. Продолжать тролить в одиночестве.
Адью.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Кроме того
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.11.09 20:26
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Кроме того, ты не внимательно прочёл обоснование. Оно заключалось в тех самых: "человек либо это понимает, либо нет".

VD>Это было традиционное гапертоновское хамство. Содержательного в подобных словах ничего нет.

Это был очень толстый намёк на не менее толстые обстоятельства. Мне этот намёк понятен, насчёт остальных собеседников — не знаю.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[16]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 18.11.09 03:04
Оценка:
Здравствуйте, Gaperton, Вы писали:

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

G>Тонкое наблюдение. Да, все так, и эта традиция имеет глубокие исторические корни .

G>Правило, что улик и доказательств недостаточно для того, чтобы спалить человека на костре, и для этого обязательно требуется его признание вины, практиковалось еще Священной Инквизицией — уважаемой организацией, которая еще в дремучее средневековье несла свет истины в народные массы. Очень гуманное правило. Признание, разумеется, выбивалось под пыткой — ну как же без этого, иначе он, сволочь, эта — совреть!


Угу, тоже тонкое наблюдение. Настоящий философский диспут в традициях XIV-го века. Носители истины имеются. Заблудшие — тоже. Осталось принудить заблудших к признанию.

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

G>Спасибо за поддержку, дружище! Но зря ты таки в адвокаты записался. Ты посмотри хорошенько, кого ты защищаешь. Гапертон ведь неправ по полной программе.

Как жоский патерналистический мужик (с), я сам решаю — кого защищать, а кого — эдипопапить.

G>Какое у вас тут оказывается интересное обсуждение моей персоны идет. Разговор такой же задушевный, прям как будто друзей диссидента в первый раз в КГБ на профилактическую беседу пригласили, и ненавязчиво так прессуют. Уписаццо.


Да уж...

G>Тему про Го таки засрали. Разумеется, из самых благородных побуждений — истины ради. С чем всех и поздравляю. Комменты по самому Го отыскать уже почти невозможно.


Попробую понадеяться на автомодерилку
Автор: VladD2
Дата: 11.11.09
. Присоединяйся — отпилить весь кусок с LINQ и хоть положить его рядом, что ли. А то и выкинуть подальше — годных рассуждений тут немного.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.11.09 12:22
Оценка:
Здравствуйте, Gaperton, Вы писали:

ГВ>>Попробую понадеяться на автомодерилку
Автор: VladD2
Дата: 11.11.09
. Присоединяйся — отпилить весь кусок с LINQ и хоть положить его рядом, что ли. А то и выкинуть подальше — годных рассуждений тут немного.


G>Хорошая мысль. Рядом, и пусть тонет. Я думаю так.


Ага. Хорошая. Только отделять нужно твой ответ в котором ты ушел от темы и начал выдвигать свои смелые научные гипотезы по поводу ЛИНК-а.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 10:09
Оценка:
Здравствуйте, anton_t, Вы писали:

_>Уже давно использую Linq2objects и ни разу не пользовался Linq2db. Чяднт?


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

Чтобы вставить в язык comprehensions, не обязательно выдумывать никакого LINQ, и делать это через него. И они вовсе не обязаны выглядеть тяжеловесно, как SQL запрос. Linq2objects — не причина появления LINQ, не смотря на то, что ты ее давно используешь, и что это приятная штука.
Re[5]: LINQ только для РСУБД!
От: Ehudi Россия  
Дата: 19.11.09 10:33
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


G>Чтобы вставить в язык comprehensions, не обязательно выдумывать никакого LINQ, и делать это через него. И они вовсе не обязаны выглядеть тяжеловесно, как SQL запрос. Linq2objects — не причина появления LINQ, не смотря на то, что ты ее давно используешь, и что это приятная штука.


Когда я думаю о LINQ, первая ассоциация — синтаксический сахар для создания монад в шарпе.
А почему он появился, тоже понятно. Эрик Мейджер решил популяризовать ФП.
Re[6]: LINQ только для РСУБД!
От: Ehudi Россия  
Дата: 19.11.09 11:21
Оценка:
Здравствуйте, Ehudi, Вы писали:

Кстати, разногласия во многом вызваны тем, что слово LINQ используется носителями языка в разных значениях.
По этому поводу хотел спросить.
Диалог в начале ветки

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


G>Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.


выглядит так как будто Gaperton знает какой-то способ понимания собеседника, отличающийся от методики, когда используемые общие понятия уточняются, чтобы понять что собеседник имел в виду.

Люди! Если кто-нибудь знает этот способ, буду очень благодарен, если меня ткнут в него носом.
Re[7]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 12:05
Оценка:
Здравствуйте, Ehudi, Вы писали:

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


G>>Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.


E>выглядит так как будто Gaperton знает какой-то способ понимания собеседника, отличающийся от методики, когда используемые общие понятия уточняются, чтобы понять что собеседник имел в виду.


E>Люди! Если кто-нибудь знает этот способ, буду очень благодарен, если меня ткнут в него носом.


Понятия "простой" и "удобный" правда кажутся тебе настолько сложными, неоднозначными, и непонятными, что требуют уточнения, и стоят длинной дискуссии? Ты считаешь, их вообще возможно уточнить и договориться, чтобы они стали "общими"? Все-таки "философия программирования" — это зазеркалье какое-то.
Re[7]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 12:06
Оценка:
Здравствуйте, Ehudi, Вы писали:

E>выглядит так как будто Gaperton знает какой-то способ понимания собеседника, отличающийся от методики, когда используемые общие понятия уточняются, чтобы понять что собеседник имел в виду.


E>Люди! Если кто-нибудь знает этот способ, буду очень благодарен, если меня ткнут в него носом.


Такого способа однозначно нет. Единственный известный мне и работающий способ — это детерменирование используемых понятий. Используется в любой научной деятельности.

Но надо четко понять, что когда человеку нужно раздуть скандал, то этот способ не приемлем. Ведь цель не понять других и объяснить другим свою позицию, а создать много шума и заняться упражнениями в софистике.
И все то только потому, что твое мнение не поддержали окружающие, а создание логичного и взвешенного обоснования своих слов — это тяжелый и не благодарный труд.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 12:12
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Понятия "простой" и "удобный" правда кажутся тебе настолько сложными, неоднозначными, и непонятными, что требуют уточнения, и стоят длинной дискуссии? Ты считаешь, их вообще возможно уточнить и договориться, чтобы они стали "общими"? Все-таки "философия программирования" — это зазеркалье какое-то.


100%. Это доказал ты сам заявляя что синтаксис линка громоздкий в то время как множество людей считает его как раз понятным и лаконичным.
Еще раз повторю свою исходную мысль (на которую ты так и не дал ответа и развел флэйм).
Для кого-то простой язык — это язык с минимумом конструкций (типичные представители Оберон, и возможно Гоу).
Для кого-то это язык напичканный максимумом фич.
Для кого-то это язык обладающей одной-двумя мегафичами (вроде макросов Лиспа).
Для кого-то это безопасный язык.
...

Посему бросаться такими терминами без их уточнения не только бесполезно, но и вредно. Данный флэйм четко это подтверждает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 12:22
Оценка:
Здравствуйте, IT, Вы писали:

IT>
IT>int pos = text.Split('\n').Take(line).Sum(s => s.Length + 1) + column;
IT>

IT>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.

Что забавно — этот пример вообще невозможно выразить через куари-компрешеншон.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: LINQ только для РСУБД!
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 19.11.09 13:51
Оценка:
Здравствуйте, VladD2, Вы писали:

IT>>
IT>>int pos = text.Split('\n').Take(line).Sum(s => s.Length + 1) + column;
IT>>

IT>>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.

VD>Что забавно — этот пример вообще невозможно выразить через куари-компрешеншон.


А как он запишется с использованием специального синтаксиса LINQ?
Re[6]: LINQ только для РСУБД!
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 19.11.09 13:56
Оценка:
Здравствуйте, VladD2, Вы писали:

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


У вас спор идёт о добавлении синтаксических расширений в язык, разве нет?
Re[16]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 14:02
Оценка:
Здравствуйте, lomeo, Вы писали:

IT>>>
IT>>>int pos = text.Split('\n').Take(line).Sum(s => s.Length + 1) + column;
IT>>>

IT>>>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.

VD>>Что забавно — этот пример вообще невозможно выразить через куари-компрешеншон.


L>А как он запишется с использованием специального синтаксиса LINQ?


А в том то и дело, что ни как. Потому, как синтаксисом покрываются только функции Where, Join, Select, OrderBy и GroupBy. Все агрегатные функции, Distinct, все вариации Take и многое другое не покрываются синтаксисом. Но тем не менее они доступны как для обработки списков объектов, так и для других источников данных вроде SQL-СУБД.

Дак что как раз без использования расширенного синтаксиса прожить можно, а только с ним — нельзя.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 14:06
Оценка:
Здравствуйте, lomeo, Вы писали:

L>У вас спор идёт о добавлении синтаксических расширений в язык, разве нет?


Я вообще уже давно ни о чем не спорю. Просто уважаемый Гапертон почему-то ставит знак равенство между линком и расширением синтаксиса языков, а так же мпжду линком и доступом к РСУБД (причем именно к "Р") и в придачу считает что в линке используется SQL (на основании сходства названия операторов, наверно).

ЗЫ

Со мной по этому поводу спорить не надо. Я этого мнения не придерживаюсь. Я прекрасно понимаю, что линк это и библиотека функций обработки списков, и синтаксис, и провайдеры среди которых есть и провайдеры для РСБУД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: LINQ только для РСУБД!
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 19.11.09 14:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Со мной по этому поводу спорить не надо. Я этого мнения не придерживаюсь. Я прекрасно понимаю, что линк это и библиотека функций обработки списков, и синтаксис, и провайдеры среди которых есть и провайдеры для РСБУД.


Я уже давно потерял нить вашей дискуссии, так что даже при всём желании поспорить не смогу
Re[9]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 14:17
Оценка:
Здравствуйте, lomeo, Вы писали:

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


VD>>Со мной по этому поводу спорить не надо. Я этого мнения не придерживаюсь. Я прекрасно понимаю, что линк это и библиотека функций обработки списков, и синтаксис, и провайдеры среди которых есть и провайдеры для РСБУД.


L>Я уже давно потерял нить вашей дискуссии, так что даже при всём желании поспорить не смогу


Рассуждения очерь просты. Я высказал совершенно простую мысль о том, что слова "простой" и "удобный" без специального определения (пояснения) не несут особого смысла, так как для одного простым и удобным является одно, а для другого другое. Когда Гапертон начал ёрничать и говорить, что "все очевидно", я привел в пример C# 2.0 и C# 3.0. Для меня C# 3.0 проще и удобнее так как в нем есть ЛИНК с помощью которого я могу значительно проще обрабатывать данные которые мне нужно обработать. Т.е. продемонстрировал случай когда большее количество фич сделало работу на языке проще.

Ну, а далее Гапертон вместо того чтобы понять о чем ему говорят и согласиться с этим (или понять и мотивировано возразить) прицепился к слову ЛИНК и пошел рассуждать о том, что ЛИНК — это (по его мнению) средство работы с РСУБД и т.п. К нему на помощь пришел пришел Геннадий Васильев который начал поддерживать и доводить разговор до маразма. Короче остальную часть дискуссии ты можешь прочесть в корне данной темы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 14:39
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Хорошо. Применительно к языкам программирования — простота выражается в разных аспектах:...


Зашибись! Могу подписаться почти под каждым пунктом, ну, разве что кроме того, что все виды простоты тоже весьма субъективны, зависят от знаний людей, и разные люди считают разные вещи по разному.

Но я не пойму только одного. Если ты сам изначально понимал, что слова "простой" и "удобный" требуют пояснения, то зачем было разводить эту бодяку
Автор: Gaperton
Дата: 11.11.09
? Почему было просто не уточнить понятия как того от тебя просили? И зачем было начинать нести откровенную пургу по отнонешию технологии которую ты не пробовал и о которой ты имел очень поверхностные знания?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 14:45
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Нет. Полнешей глупостью является обсуждать простоту или удобство языка "в общем". Можно обсуждать только отдельные аспекты простоты и удобства которые ты так неплохо описал.

Ты хотя бы обратил внимание на то, что ты остался вдвоем с Генадием Васильевым которому вообще по фигу о чем спорить лиш бы со мной. Так что когда ты говоришь "у вас в зазеркалье", мне сразу вспоминается анекдот в котором жена звонит мужу в машину и говорит — Милый, будь осторожен. По телевизору сообщили, что какой-то маньяк едет по встречной полосе. А тот ей отвечает — Да их тут тысячи!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 14:57
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Вопрос, что ты имеешь в виду под простотой от VladD2 — это начало длинного безмазового флейма с выносом мозга.


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

Твоя же политика "посылания всех на хрен чтобы не мешали говорить" сдобренная кучей рассуждений о ЛИНК-е и привела в итоге к огромному флэму.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.11.09 18:08
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>Нет. Полнешей глупостью является обсуждать простоту или удобство языка "в общем". Можно обсуждать только отдельные аспекты простоты и удобства которые ты так неплохо описал.

А никто "в общем" её и не обсуждал. По-видимому, тебе показалось, что обсуждение носит слишком общий характер, поскольку задачи, решаемые пропонентами Go не похожи на те, которые решаешь ты и ещё несколько активных защитников LINQ. В этом нет ничего страшного и нет никакой попытки кого-то задеть, просто акценты на фичах языка люди с разной спецификой работы расставляют по-разному.

VD>Ты хотя бы обратил внимание на то, что ты остался вдвоем с Генадием Васильевым которому вообще по фигу о чем спорить лиш бы со мной.


По этому поводу я написал рядом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: LINQ только для РСУБД!
От: anton_t Россия  
Дата: 19.11.09 18:37
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


_>>Уже давно использую Linq2objects и ни разу не пользовался Linq2db. Чяднт?


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


G>Чтобы вставить в язык comprehensions, не обязательно выдумывать никакого LINQ, и делать это через него. И они вовсе не обязаны выглядеть тяжеловесно, как SQL запрос. Linq2objects — не причина появления LINQ, не смотря на то, что ты ее давно используешь, и что это приятная штука.


Открыл я для себя list comprehensions до linq-а, когда с питоном работал. А linq сделан таким каким сделан для того, что бы можно было прикрутить у нему как списки и бд, так и другие источники данных, в том числе и те, о которых мс не знает.
Re[11]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 20:04
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>В практическом отношении эти выражения как раз несут вполне определённый и однозначный смысл. "Мотивированное обсуждение" дефиниций подобного порядка, ИМХО, уведёт любую дискуссию в сторону "дихотомии добра и зла" и уточнения совершенно никчёмных деталей. То есть в самом прямом смысле — человек либо понимает своих собеседников сразу, либо нет.


-1

ГВ>Обрати внимание: "...с помощью которого я могу значительно проще обрабатывать данные которые мне нужно обработать". Таким образом ты обозначил тот круг задач, который тебе проще решать при наличии LINQ. А например, задача построения коммуникаций, которую обозначали и я, и Гапертон, у тебя не обозначена. Иными словами, ты сейчас только подтвердил субъективный характер оценок "простоты" и "удобства". И эта самая субъективность служит... См. ниже.


Любая задача, в том числе "задача построения коммуникаций" в конечном итоге состоит из обработки данных. Так что LINQ в ней будет применим по любому.
Это примерно так же как в любой задаче можно применять циклы.

ГВ>Очевидно, что если два субъекта оценивают один и тот же предмет одинаковыми субъективными оценками, то с большой вероятностью можно говорить о том, что эти двое пользуются схожими личными критериями оценки (тавтология, не правда ли?), что в разговорной речи заменяется оборотом "понимают друг друга". Ощущение понимания возрастает прямо пропорционально сложности обсуждаемого предмета, а языки программирования — это как раз очень сложные предметы. Именно это и послужило самой серьёзной причиной моего подключения к дискуссии. А вовсе не желание лишний раз поругаться с тобой. Я ж не виноват, что ты у нас Топ-0 активности.


Очень сомневаюсь.

ГВ>Ещё одна любопытная черта этой дискуссии состоит в том, что несмотря на обилие морально-этических оценок, продемонстрированных э-э-э... и тобой тоже, убедительных опровержений тезису Гапертона так и не появилось. И не могло появиться в силу одной очень серьёзной ошибки "защитников LINQ".


-1

Все что Гапертон говорил про линк — это набор заблуждений. Их развенчали сразу несколько человек. Но вы с Гапертоном даже не удосужились задуматься над их словами. А ты нагло врешь говоря "опровержений тезису Гапертона так и не появилось".

ГВ>По отношению к любой вещи, понимаешь ли, можно задать два независимых вопроса: "зачем?" и "чем является?" Так вот, ответы на второй вопрос никогда не подходят к первому, тогда как если известен ответ на первый, то на второй может и не понадобиться отвечать. Если теперь проанализировать перепалку этого топика, то будет заметно, что в ответ на суждение "зачем нужен LINQ" приводятся доводы "он является библиотекой ФВП". Понятна коллизия?


Так. Давай как разберемся по пунктам.
Что касается линка. Утверждение Гапертона:
http://rsdn.ru/forum/philosophy/3599325.1.aspx
Автор: Gaperton
Дата: 11.11.09

LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД

На что ему было убедительно доказано и много раз подтверждено практикой целой кучи людей, что ЛИНК не заточен ни под одну прикладную задачу и с базами данных работает по стольку по скольку умеет работать и с ними. Целая куча работы сказал ему и тебе, что использует линк исключительно для обработки списков объектов.

Поясни в чем тут коллизия.

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

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

ГВ>Зачем нужен мобильный телефон? Что послужило главной причиной его появления? Очевидно — потребность людей общаться друг с другом без привязки к стационарным телефонным аппаратам. Можно сделать такой однозначный вывод, глядя лишь на конструкцию мобильника? По всей видимости — нет, потому что в современных телефонах тридцать три вагона дополнительных функций, включая игры. Однако, если рассуждать, выстраивая индукцию снизу вверх, то легко получить суждения, которые, например, изоморфны демагогическим приёмам, когда реальные мотивы руководителей ("зачем") скрываются за обсуждением "характеристик народа" ("чем является"). Собственно, как раз на такие выводы налетаешь и ты, когда пытаешься вычислить моё целеполагание через призму одной лишь пикировки с собственной персоной.


Вот эту демагогию ты оставь для других. Мы обсуждаем тут ЛИНК. Вот о нем и говори.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.09 20:09
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Нет. Полнешей глупостью является обсуждать простоту или удобство языка "в общем". Можно обсуждать только отдельные аспекты простоты и удобства которые ты так неплохо описал.


ГВ>А никто "в общем" её и не обсуждал.


Нагло врешь. Вот цитата Гапертона:

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

Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.


VD>По-видимому, тебе показалось, что обсуждение носит слишком общий характер, поскольку задачи, решаемые пропонентами Go не похожи на те, которые решаешь ты и ещё несколько активных защитников LINQ.


Опять врешь. Вот сообщение гапертона в котором он сам отлично описал все смыслы которые могут вкладываться в эти общие понятия:
http://rsdn.ru/forum/philosophy/3608581.aspx
Автор: Gaperton
Дата: 19.11.09


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

VD> В этом нет ничего страшного и нет никакой попытки кого-то задеть, просто акценты на фичах языка люди с разной спецификой работы расставляют по-разному.


Не было никаких акцентов. Было два слишком общих понятия смысл которых попросили уточнить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 19.11.09 20:39
Оценка:
Здравствуйте, Gaperton, Вы писали:

IT>>
IT>>int pos = text.Split('\n').Take(line).Sum(s => s.Length + 1) + column;
IT>>

IT>>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.

G>[go]

G>pos := len(text) — len(strings.Split( text, "\n", line )[line]) + column
G>[/go]

G>


Take возвращает первые n элементов коллекции.
Re[16]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 20:49
Оценка:
Здравствуйте, Lloyd, Вы писали:

IT>>>
IT>>>int pos = text.Split('\n').Take(line).Sum(s => s.Length + 1) + column;
IT>>>

IT>>>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.

G>>[go]

G>>pos := len(text) — len(strings.Split( text, "\n", line )[line]) + column
G>>[/go]

G>>


L>Take возвращает первые n элементов коллекции.


А strings.Split с третьим параметром, отличающимся от ноля, бьет строку ровно на заданное количество сегментов. Причем, последний сегмент, который я и забираю указывая [line], остается не разбитым. Да, вероятно я немного ошибся, и надо указать [line-1]
Re[15]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 19.11.09 20:54
Оценка:
Здравствуйте, Gaperton, Вы писали:

IT>>
IT>>int pos = text.Split('\n').Take(line).Sum(s => s.Length + 1) + column;
IT>>

IT>>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.

G>[go]

G>pos := len(text) — len(strings.Split( text, "\n", line )[line]) + column
G>[/go]

G>

G>

Я это всё к тому, что метды Take и Sum принадлежат классу Enumerable пространства имён (внимание!) System.Linq. А ты к чему?
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 19.11.09 20:56
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Take возвращает первые n элементов коллекции.


G>А strings.Split с третьим параметром, отличающимся от ноля, бьет строку ровно на заданное количество сегментов. Причем, последний сегмент, который я и забираю указывая [line], остается не разбитым. Да, вероятно я немного ошибся, и надо указать [line-1]


Думаю будет проще объяснить, что делает код: он вычисляет порядковый номер символа в тексте через его строку (line) и колонку (column).
Re[16]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 21:07
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Take возвращает первые n элементов коллекции.


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

func ( arr []string )Sum( f func (string) int ) sum int {
   for _, val := range arr {
      sum += f( val )
   }

   return
}


После чего, я задам полный Split, и вместо Take просто возьму от него слайс. Как-то так:

pos := strings.Split( text, "\n", 0 )[0:line-1].Sum( func( s string ) int { return len( s ) + 1 } ) + column;


Этот пример иллюстрирует одно из интереснейших свойств Go — "ортогональность" методов и типов. Без generic-ов такие штуки в полный рост изображать тяжело, конечно. Но их скоро добавят.

Только нафига так делать, если можно писать по-простому? Забыли уж поди, как оно по-простому-то делается?
Re[17]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 19.11.09 21:14
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Только нафига так делать, если можно писать по-простому? Забыли уж поди, как оно по-простому-то делается?


По-простому — это то мясо, что ты написал? Это опять ирония что-ли?
Re[18]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 21:14
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>>>Take возвращает первые n элементов коллекции.


G>>А strings.Split с третьим параметром, отличающимся от ноля, бьет строку ровно на заданное количество сегментов. Причем, последний сегмент, который я и забираю указывая [line], остается не разбитым. Да, вероятно я немного ошибся, и надо указать [line-1]


L>Думаю будет проще объяснить, что делает код: он вычисляет порядковый номер символа в тексте через его строку (line) и колонку (column).


Да ну? Правда что-ли?
Re[19]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 19.11.09 21:16
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Думаю будет проще объяснить, что делает код: он вычисляет порядковый номер символа в тексте через его строку (line) и колонку (column).


G>Да ну? Правда что-ли?


Yup.
Re[18]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 21:17
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Только нафига так делать, если можно писать по-простому? Забыли уж поди, как оно по-простому-то делается?


L>По-простому — это то мясо, что ты написал? Это опять ирония что-ли?


По-простому, это без ФВП и линков.
Re[16]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 21:17
Оценка:
Здравствуйте, IT, Вы писали:

IT>Я это всё к тому, что метды Take и Sum принадлежат классу Enumerable пространства имён (внимание!) System.Linq. А ты к чему?


К выделенному.

IT>>>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.
Re[19]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 19.11.09 21:28
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>>>Только нафига так делать, если можно писать по-простому? Забыли уж поди, как оно по-простому-то делается?


L>>По-простому — это то мясо, что ты написал? Это опять ирония что-ли?


G>По-простому, это без ФВП и линков.


Не очень-то удачная попытка. С линком значительно проще.
Re[20]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 21:29
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>>>Думаю будет проще объяснить, что делает код: он вычисляет порядковый номер символа в тексте через его строку (line) и колонку (column).


G>>Да ну? Правда что-ли?


L>Yup.


Как странно, что моя функция делает то же самое.
Re[21]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 19.11.09 21:31
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>>>Да ну? Правда что-ли?


L>>Yup.


G>Как странно, что моя функция делает то же самое.


[line] возвращает все строки? Ну если так, то возможно.
Re[20]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 21:40
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>>>По-простому — это то мясо, что ты написал? Это опять ирония что-ли?


G>>По-простому, это без ФВП и линков.


L>Не очень-то удачная попытка. С линком значительно проще.


Понятие "простоты" у всех разное. Мой первый пример задействует базовые выразительные средства, в нем меньше телодвижений и суеты, и он должен быстрее работать.

А чтобы получить запись в точности как у вас в примере с линком, мне надо один раз написать несколько строк кода — как во втором примере. Не вижу никакой проблемы. Ты хоть понял, как и почему он работать-то будет? Или надо объяснять?

Не очень удачный пример — тот, который выбрал IT для демонстрации силы линка. Я бы на его месте другое что-нибудь привел.
Re[22]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 19.11.09 21:44
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Как странно, что моя функция делает то же самое.


L>[line] возвращает все строки? Ну если так, то возможно.


Да нет, все гораздо проще. Я же объяснил — дело в третьем параметре split.

http://golang.org/pkg/strings/#Split

If n > 0, split Splits s into at most n substrings; the last substring will be the unsplit remainder.


Я указываю, на сколько максимум подстрок надо быть строку. И последняя подстрока будет неразбита, и содержать остаток текста. Моя программа использует этот факт. И все.
Re[13]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.11.09 21:48
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>По-видимому, тебе показалось, что обсуждение носит слишком общий характер, поскольку задачи, решаемые пропонентами Go не похожи на те, которые решаешь ты и ещё несколько активных защитников LINQ.


VD>Опять врешь.


Как я могу врать в предположениях — тайна сия велика есть.

VD>Вот сообщение гапертона в котором он сам отлично описал все смыслы которые могут вкладываться в эти общие понятия:

VD>http://rsdn.ru/forum/philosophy/3608581.aspx
Автор: Gaperton
Дата: 19.11.09


Обрати внимание, когда это произошло.

VD>ЛИНК ты вообще приплел из обще-демагогических соображений. Он был не боле чем примером.


О! Уже, оказывается, я приплёл LINQ. Офигительно.

ГВ>> В этом нет ничего страшного и нет никакой попытки кого-то задеть, просто акценты на фичах языка люди с разной спецификой работы расставляют по-разному.

VD>Не было никаких акцентов. Было два слишком общих понятия смысл которых попросили уточнить.

Дык. В том-то и фокус, что эти самые смыслы влёт считываются людьми, работающими над схожими проблемами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 19.11.09 21:48
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>>>По-простому, это без ФВП и линков.


L>>Не очень-то удачная попытка. С линком значительно проще.


G>Понятие "простоты" у всех разное. Мой первый пример задействует базовые выразительные средства, в нем меньше телодвижений и суеты, и он должен быстрее работать.


По поводу "меньше телодвижений" это ты сильно преувеличиваешь. А почему он может быстрее работать?

G>А чтобы получить запись в точности как у вас в примере с линком, мне надо один раз написать несколько строк кода — как во втором примере. Не вижу никакой проблемы.


Зачем что-то писать, когда можно воспользоваться готовыми средствами?

G>Ты хоть понял, как и почему он работать-то будет? Или надо объяснять?


Не надо, вроде бы ничего сложного нет.
Re[23]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 19.11.09 21:50
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Тпереь понятно.
Re[19]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 19.11.09 22:34
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>По-простому, это без ФВП и линков.


Что плохого в ФВП, если они позволяют упрощать и угибчать код?
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 19.11.09 22:39
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Не очень удачный пример — тот, который выбрал IT для демонстрации силы линка. Я бы на его месте другое что-нибудь привел.


Я тебе демонстрировал не силу линка, а его использование без БД. Или ты теперь с БД решил переключиться на силу? Думаю, в твоём исполнении это уже никому не будет интересно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 06:52
Оценка:
Здравствуйте, Lloyd, Вы писали:

ГВ>>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?


L>
L>int lastNdx = int.MinValue;
L>var q1 = Enumerable.Range(1, arr.Length - 1).Where(i => {
L>    if (i == lastNdx + 1 || arr[i] != arr[i - 1] + 1) {
L>        return false;
L>    } else {
L>        lastNdx = i;
L>        return true;
L>    }
L>}).Select(i => arr[i]);
L>


Хорошо, но не надёжно из-за "Enumerable.Range(1, arr.Length — 1)" — свалится при arr.Length == 0;

ГВ>>2) Тот же массив, но нужно извлечь элементы, отстоящие на +/-1 от выбранного. Т.е. результат — {1, 3, 7, 9}.


L>
L>var q2 = arr.Where(n => q1.Contains(n - 1) || q1.Contains(n + 1));
L>


Компактно, но не правильно. Я имел в виду соседей выбранного элемента. В прочем, я не совсем удачно сформулировал вторую задачу.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 06:56
Оценка:
Здравствуйте, IT, Вы писали:

G>>Не очень удачный пример — тот, который выбрал IT для демонстрации силы линка. Я бы на его месте другое что-нибудь привел.


IT>Я тебе демонстрировал не силу линка, а его использование без БД.


...Для этого недостаточно показать, что это один из источников. Что для этого достаточно — это обозначить другую проблему, кроме OR-mapping, решаемую LINQ, и продемонстрировать, что она как минимум не менее значима, чем OR-mapping. Этого никто не сделал. Даже не попытался.


IT>Или ты теперь с БД решил переключиться на силу?


Я тебе показал, как обозначенная тобой в примере проблема решается без линка, на примере Go. Значимой разницы я не вижу. Пример, я так полагаю, ты выбрал не совсем удачный.

IT>Думаю, в твоём исполнении это уже никому не будет интересно.


А вот твое мнение об этом меня интересует как-то совсем мало. Какая разница, что ты там себе думаешь.
Re[16]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 06:58
Оценка:
Здравствуйте, IT, Вы писали:

[skip]

ГВ>>Как ты понимаешь, традиционным for обе задачи решаются тривиально.

IT>Да оно и так как бы ничего

Кхм. Подожду пока со своим мнением, может, ещё кто что подкинет. Вторая задача, кстати, тоже не совсем правильно решена — из-за Union могут быть проглочены соседние элементы, например на вот таком массиве { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 } ответ получается {1, 3, 4}, а должен быть как минимум {1, 3, 3, 4}.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.09 13:05
Оценка:
Здравствуйте, VladD2, Вы писали:

Ответа явно не будет. Что и требовалось доказать.
Слив засчитан. Больше я на твой тролинг попадаться не буду.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 20.11.09 13:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хорошо, но не надёжно из-за "Enumerable.Range(1, arr.Length — 1)" — свалится при arr.Length == 0;


Enumerable.Range(0, arr.Length).Skip(1)

ГВ>Компактно, но не правильно. Я имел в виду соседей выбранного элемента. В прочем, я не совсем удачно сформулировал вторую задачу.


Это еще проще.
Re[16]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.09 14:37
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Влад. Ты сам себе отвечаешь.


Естественно. А как еще можно ответить на смайлик вместо ответа?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 20.11.09 18:44
Оценка:
Здравствуйте, Gaperton, Вы писали:

IT>>Что плохого в ФВП, если они позволяют упрощать и угибчать код?

G>В ФВП, как в выразительном средстве — совершенно ничего плохого. Но решение без ФВП при прочих равных проще понимать. Во многих случаях.

В данном случае простота напрямую зависит от уровня подготовки. Не секрет, что один и тот же код для одного человека может быть простым, а для другого сложным. Это как раз тот самый случай. Вот тут
Автор: IT
Дата: 22.09.08
я давал пример одного и того же алгоритма на Linq и в императивном стиле. Разница очевидна. ФП привносит в код декларативность, а значит простоту и гибкость. Но всё это требует определённой подготовки.
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 20.11.09 18:50
Оценка:
Здравствуйте, Gaperton, Вы писали:

IT>>Или ты теперь с БД решил переключиться на силу?


G>Я тебе показал, как обозначенная тобой в примере проблема решается без линка, на примере Go. Значимой разницы я не вижу. Пример, я так полагаю, ты выбрал не совсем удачный.


Ещё раз повторюсь. Я тебе демонстрировал не значимость, а возможность использовать Linq без БД, т.е. способности в которых ты очень сильно сомневаешься. На значимость я тебе дал ссылку в предыдущем посте, вот она
Автор: IT
Дата: 22.09.08
ещё раз. Перепиши это на Go ради забавы, а мы все вместе полюбуемся.

IT>>Думаю, в твоём исполнении это уже никому не будет интересно.

G>А вот твое мнение об этом меня интересует как-то совсем мало. Какая разница, что ты там себе думаешь.

Меня мало волнует интересует тебя моё мнение или нет. И мне нет никакой разницы, что ты там себе думаешь о том, что я там себе думаю.
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 20.11.09 18:54
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вторая задача, кстати, тоже не совсем правильно решена — из-за Union могут быть проглочены соседние элементы, например на вот таком массиве { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 } ответ получается {1, 3, 4}, а должен быть как минимум {1, 3, 3, 4}.


Я задачу понял именно так. Для твоего уточнения достаточно заменить Union на Cancat. И что значит выделенное, первая задача решена не правильно?
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 20:14
Оценка:
Здравствуйте, IT, Вы писали:

G>>Я тебе показал, как обозначенная тобой в примере проблема решается без линка, на примере Go. Значимой разницы я не вижу. Пример, я так полагаю, ты выбрал не совсем удачный.


IT>Ещё раз повторюсь. Я тебе демонстрировал не значимость, а возможность использовать Linq без БД, т.е. способности в которых ты очень сильно сомневаешься.


Я не сомневаюсь в возможности использовать Linq без БД. Кстати, твой пример выше мне понравился — он вполне симпатичен. Я правда не понял, зачем огород городить ради такой простой и симпатичной штуки, когда для нее достаточно "ортогональности" системы типов, как в Go.

В чем я действительно сомневаюсь — это в том, что Linq проявляет себя в полную силу в классе приложений, отличном от того, где у тебя в бэкенде стоит реляционная БД. Мне кажется, что его настоящий killing application — это приложения с реляционным источником.

IT>На значимость я тебе дал ссылку в предыдущем посте, вот она
Автор: IT
Дата: 22.09.08
ещё раз. Перепиши это на Go ради забавы, а мы все вместе полюбуемся.


Это по своей природе типичная "реляционная" задача. И это весьма показательно, что силу linq ты предпочел демонстрировать на ней.

Работая с Go, я просто заверну это в хранимую процедуру, как делал еще в 90-х, и выиграю в производительности, одновременно абстрагировавшись от схемы БД. И все.
Re[24]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 20:43
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>Думаю, в твоём исполнении это уже никому не будет интересно.


Хорошо, попробую сказать прямо, без намеков. Небольшая личная просьба. Ты не мог бы сделать над собой усилие, и воздержаться от переходов на личности в своих следующих ответах. В противном случае, я просто перестану тратить время на их чтение, как уже сделал с постами VladD2 — он пытался, но у него не получилось. Мне это совсем не сложно сделать (посты твои не читать), это легко и приятно, но делать не хотелось бы, ибо ты уже начал разговаривать как нормальный человек.

Переходом на личности является любое суждение относительно личности собеседника, или суждение выражающее некоторое мнение касательно характеристик этой личности. Наглядным примером является твоя цитата выше. Могу ли я рассчитывать на твое понимание, Игорь? Давай без отмазок и галсов, ты нормально разгаривать согласен, или нет. Надоело уже просто.
Re[18]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 20:53
Оценка:
Здравствуйте, IT, Вы писали:

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


ГВ>>Вторая задача, кстати, тоже не совсем правильно решена — из-за Union могут быть проглочены соседние элементы, например на вот таком массиве { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 } ответ получается {1, 3, 4}, а должен быть как минимум {1, 3, 3, 4}.


IT>Я задачу понял именно так. Для твоего уточнения достаточно заменить Union на Cancat. И что значит выделенное, первая задача решена не правильно?


Первая задача решена может и правильно, но однозначно чудовищно.

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

В общем, так держать!
Re[18]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 20:56
Оценка:
Здравствуйте, Lloyd, Вы писали:

ГВ>>Компактно, но не правильно. Я имел в виду соседей выбранного элемента. В прочем, я не совсем удачно сформулировал вторую задачу.


L>Это еще проще.


Так покажи.

У тебя в целом код лучше, чем у IT. Первый пример, правда, по очевидной причине проигрывает циклу (ибо ты изображаешь цикл), но давай понадеемся на второй.
Re[6]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 21:12
Оценка:
Здравствуйте, anton_t, Вы писали:

_>Открыл я для себя list comprehensions до linq-а, когда с питоном работал.


А я — когда с Хаскелем.

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


Сделан он таким для того, чтобы можно было прикрутить у нему как списки и бд, так и другие источники данных — в этом ты совершенно прав. Но появился он в языке не из-за этого. Была некоторая важная, конкретная проблема. Или несколько. Linq появился, чтобы их решить, не просто так. И он был создан для того, чтобы их решить. Что это за проблема(ы)?
Re[19]: А-а-а-а-а-а! Я понял!!!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 21:15
Оценка:
Здравствуйте, IT, Вы писали:

ГВ>>RSDN-ейшая из RSDN-ейших инквизиций требует от заблудшего признать существование минималистически глобального универсального всемогутера! Просто кристально чистый образец деления на нуль и умножения на пустое множество. Достоин внесения во всяческие анналы.


IT>Ты сильно не зарывайся. Обсуждение инквизиции запрещено правилами форума, за это можно на сутки-двое и на костерок загреметь.


Точно. Запрещено секретным пунктом правил. И в его подпункте написано, что IT лишен чувства юмора.
Re[18]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 21:28
Оценка:
Здравствуйте, IT, Вы писали:

ГВ>>Вторая задача, кстати, тоже не совсем правильно решена — из-за Union могут быть проглочены соседние элементы, например на вот таком массиве { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 } ответ получается {1, 3, 4}, а должен быть как минимум {1, 3, 3, 4}.


IT>Я задачу понял именно так. Для твоего уточнения достаточно заменить Union на Cancat. И что значит выделенное, первая задача решена не правильно?


Нет, первая задача правильно решена. Выделенное значит, что ты ошибся в решении второй задачи на пару с Lloyd. Кстати говоря, замена Union на Concat приводит к другой ошибке: на данных { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 } результат получается {1, 1, 1, 3, 3, 4, 4}.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 21:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, давай, моговед, поведай нам, что же Гапертон имел в виду под словами "простой" и "удобный" если слово "простой" он сам же охарактеризовал как имеющее 4 значения (пруфлинк
Автор: Gaperton
Дата: 19.11.09
).


Гапертон говорил:

Есть вещи, которые человек либо понимает, либо нет.


Сказать, что он сам не понимал, до какой степени он был прав, нельзя. Ибо, он прекрасно это понимал.
Re[16]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 22:27
Оценка:
Здравствуйте, IT, Вы писали:

Я сравниваю вот этот код:
// IT
var arr  = new[] { 1, 2, 3, 7, 8, 9, 10 };
var list = new List<int>();
Func<int,bool> func = i => { list.Add(i); return true; };

var q1 =
    from a in arr.Select((n, i) => new { i, n })
    let prev = a.i - 1
    where
        prev >= 0 && a.n - 1 == arr[prev] && !list.Contains(prev) && func(a.i)
    select new { a.i, n = arr[a.i] };


потом вот этот код
// Lloyd
int lastNdx = int.MinValue;
var q1 = Enumerable.Range(1, arr.Length - 1).Where(i => {
    if (i == lastNdx + 1 || arr[i] != arr[i - 1] + 1) {
        return false;
    } else {
        lastNdx = i;
        return true;
    }
}).Select(i => arr[i]);


с таким:

delegate void F<in T>(T arg);

static void sample1(int[] arr, F<int> func)
{
  for(int i = 1; i < arr.Length; ++i)
  {
    if (arr[i] - arr[i - 1] == 1)
    {
      func(arr[i]);
      ++i;
    }
  }
}


...и пытаюсь поточнее сформулировать, где здесь торчат уши теории РСУБД. В принципе, задачку я подобрал такую, на которой обламывают зубы как раз SQL-сервера: с использованием относительного положения элементов в последовательности. Тут вот какой фокус — элементам множества можно, конечно, сопоставить отношение порядка (индекс), но тогда мы вылетим на то, что обработка последовательности сведётся (в пределе) к перепахиванию всего множества. По сути, запрос LINQ к данным апеллирует к тому же — к отбору элементов из всего множества данных. У меня задача была поставлена по-другому: я предложил отбирать данные, основываясь на их относительном положении в потенциально бесконечной последовательности. Чувствуешь, к чему клоню? Ну то есть, ту же первую задачу можно решить на yield return:

static IEnumerable<int> sample1b(IEnumerable<int> arr)
{
  bool first = true;
  int prev = 0;
  foreach (int i in arr)
  {
    if (first)
    {
      first = false;
      prev = i;
    }
    else if (i - prev == 1)
    {
      yield return i;
      first = true;
    }
    else prev = i;
  }
}


Можно это как-то сделать средствами LINQ?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 22:31
Оценка:
Здравствуйте, Lloyd, Вы писали:

ГВ>>Хорошо, но не надёжно из-за "Enumerable.Range(1, arr.Length — 1)" — свалится при arr.Length == 0;

L>Enumerable.Range(0, arr.Length).Skip(1)

Ясно.

ГВ>>Компактно, но не правильно. Я имел в виду соседей выбранного элемента. В прочем, я не совсем удачно сформулировал вторую задачу.

L>Это еще проще.

Кстати, а как?

Вообще, давай продолжим здесь
Автор: Геннадий Васильев
Дата: 21.11.09
.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 20.11.09 22:43
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Так покажи.


Под рукой компилятора нет. Идея в том, что из первого запроса выбрасываем селект и получаем массив индексов в arr. Далее — аналогично второму запросу, но в левой части (перед where) стоит Enumerable.Range(1, arr.Length), а условие остается таким же.

G>У тебя в целом код лучше, чем у IT. Первый пример, правда, по очевидной причине проигрывает циклу (ибо ты изображаешь цикл), но давай понадеемся на второй.


Первый пример сводим к циклу, а не изображает его.
Он выигрывает перед циклом, т.к. цикла пока никто не показал.
Re[19]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 20.11.09 22:46
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Компактно, но не правильно. Я имел в виду соседей выбранного элемента. В прочем, я не совсем удачно сформулировал вторую задачу.

L>>Это еще проще.

ГВ>Кстати, а как?


ГВ>Вообще, давай продолжим здесь
Автор: Геннадий Васильев
Дата: 21.11.09
.


Сейчас не могу. Но бесконесность последовательности — не препятствие, просто код несколько сложнее будет.
Re[18]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 22:49
Оценка:
Здравствуйте, Gaperton, Вы писали:

ГВ>>...и пытаюсь поточнее сформулировать, где здесь торчат уши теории РСУБД. В принципе, задачку я подобрал такую, на которой обламывают зубы как раз SQL-сервера: с использованием относительного положения элементов в последовательности.


G>Ты совершенно правильно все сделал. Неотъемлемое свойство, и слабое место реляционной модели (превращается в силу в ряде контекстов) — отсутствие в этой модели порядка элементов. Кортежи принципиально неупорядоченны. Точка. И твой, и мои примеры с БД time series это свойство эксплуатируют.


Угу-угу. В том-то и дело, что в ряде контекстов — да, превращается. А когда нужно перепахать много гиг в один проход — превращается в наказание. Ну или как вариант — работа в реальном времени с временными отсчётами.

G>Все, что тебе нужно, чтобы окончательно выбить у них почву из под ног — убрать из задачи регулярный индекс. Вот тогда им попа. Они просто не смогут выразить это одним запросом. Сделай так, что в качестве индекса идет, например, время, а не номер элемента.


Обрати внимание на последний пример в моём постинге, там как раз не используется индекс. В принципе, foreach можно заменить на вот такую конструкцию:

static IEnumerable<int> sample1c(IEnumerable<int> arr)
{
  bool first = true;
  int prev = 0;
  IEnumerator<int> ie = arr.GetEnumerator();
  if (ie.MoveNext())
    for (int i = ie.Current; ; i = ie.Current)
    {
      if (first)
        first = false;
      else if (i - prev == 1)
      {
        yield return i;
        first = true;
      }

      prev = i;

      if (!ie.MoveNext())
        break;
    }
}


Получаем автомат, работающий на бесконечной последовательности и никакого регулярного индекса. Просто не хотелось усложнять — вводить ещё сравнения времени, дополнительные фишки какие-то. В общем-то, заморочки с позиционным счислением пример, по-моему, иллюстрирует достаточно хорошо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 22:52
Оценка:
Здравствуйте, Lloyd, Вы писали:

ГВ>>Кстати, а как?

ГВ>>Вообще, давай продолжим здесь
Автор: Геннадий Васильев
Дата: 21.11.09
.


L>Сейчас не могу. Но бесконесность последовательности — не препятствие, просто код несколько сложнее будет.


Вот как раз его очень любопытно было бы посмотреть.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 20.11.09 22:55
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Нет, первая задача правильно решена. Выделенное значит, что ты ошибся в решении второй задачи на пару с Lloyd.


А это уже гон. Постановка была неправильной, а не решение.
Re[20]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 23:00
Оценка:
Здравствуйте, Lloyd, Вы писали:

ГВ>>Нет, первая задача правильно решена. Выделенное значит, что ты ошибся в решении второй задачи на пару с Lloyd.

L>А это уже гон. Постановка была неправильной, а не решение.

Ну не начинай. Я уже сказал, что не совсем внятно поставил задачу, там могли быть разночтения. И давай замнём на этом для ясности.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 23:02
Оценка:
Здравствуйте, Lloyd, Вы писали:

ГВ>>Кстати, а как?

ГВ>>Вообще, давай продолжим здесь
Автор: Геннадий Васильев
Дата: 21.11.09
.

L>Сейчас не могу. Но бесконесность последовательности — не препятствие, просто код несколько сложнее будет.

Никто никуда не торопится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: Я всё ж таки вот, о чём думаю
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 23:30
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

G>>Сделай так, что в качестве индекса идет, например, время, а не номер элемента.


ГВ>Вообще, знаешь, ты прав, пожалуй. Можно ввести требование, например, "отбирать запись, отстоящую от заданной не более, чем на -30 минут", или вообще — связанную с какой-то отдельной меткой события.


Да, именно это я и имел в виду.

Замечу — ты все понял, без уточнения понятий "индекс" и "время" .
Re[20]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.09 23:37
Оценка:
Здравствуйте, Gaperton, Вы писали:

ГВ>>Вообще, знаешь, ты прав, пожалуй. Можно ввести требование, например, "отбирать запись, отстоящую от заданной не более, чем на -30 минут", или вообще — связанную с какой-то отдельной меткой события.

G>Да, именно это я и имел в виду.

G>Замечу — ты все понял, без уточнения понятий "индекс" и "время" .


Дык. Шишки на лбу не пропьёшь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.11.09 23:57
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Первый пример сводим к циклу, а не изображает его.

L>Он выигрывает перед циклом, т.к. цикла пока никто не показал.

Ок, если честно — я не показывал цикла, ибо считал решение с циклом слишком простым и очевидным. Давай я и покажу чуть позже. Попробую на Go. Этот язык мне так же мало знаком, как и тебе, так что вставлю комменты.
Re[22]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.09 18:13
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Подозреваю, что и с вашим Linq эту задачу можно решить так же. В противном случае он бы вообще никуда не годился.

L>Толсто, Gaperton, очень толсто. От вас я ожидал более умного троллинга.

Show me your code.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 18:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

G>>>Подозреваю, что и с вашим Linq эту задачу можно решить так же. В противном случае он бы вообще никуда не годился.

L>>Толсто, Gaperton, очень толсто. От вас я ожидал более умного троллинга.

ГВ>Show me your code.


Для начала посмотри код Gaperton-а. Есть подозрение, что он не без ошибок.
Re[24]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.09 18:21
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>>>Подозреваю, что и с вашим Linq эту задачу можно решить так же. В противном случае он бы вообще никуда не годился.

L>>>Толсто, Gaperton, очень толсто. От вас я ожидал более умного троллинга.
ГВ>>Show me your code.

L>Для начала посмотри код Gaperton-а. Есть подозрение, что он не без ошибок.


Кстати, да. Вместо "+ 1" в функции p должен быть "- 1". Только сути это не меняет — всё равно пока решения на Linq либо до мрачности сложны, либо сильно похожи на обычный цикл.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 19:40
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

L>>Для начала посмотри код Gaperton-а. Есть подозрение, что он не без ошибок.


ГВ>Кстати, да. Вместо "+ 1" в функции p должен быть "- 1". Только сути это не меняет — всё равно пока решения на Linq либо до мрачности сложны, либо сильно похожи на обычный цикл.


Не только, ищи дальше.
Re[25]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 19:42
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

L>>Для начала посмотри код Gaperton-а. Есть подозрение, что он не без ошибок.


ГВ>Только сути это не меняет — всё равно пока решения на Linq либо до мрачности сложны, либо сильно похожи на обычный цикл.


Ну это еще цветочки. Ты не видел какой мрак получается с бесконечными последовательностями.
Re[27]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 19:47
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Только сути это не меняет — всё равно пока решения на Linq либо до мрачности сложны, либо сильно похожи на обычный цикл.

L>>Ну это еще цветочки. Ты не видел какой мрак получается с бесконечными последовательностями.

ГВ>Дык, я уже трепещу. Давай, свей мой разум в невозможную фигуру!


Ща, свой сперва раскукожу.
Re[26]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.09 19:50
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Это не единственная ошибка, заложенная в функцию p. Еще там должно стоять i > 0, а не i > 1. То есть, правильное условие — это


G>i > 0 && x[ i — 1 ] == x[ i ] — 1


А на обработке канала слабо написать? А то мне сейчас до юниксов тянуться долго.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 19:55
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Ваши примеры с Linq — ужасны, и проигрывают компрехеншнсам. При этом, в них по своей сути нет ничего, что не могло бы быть сделано при помощи простых ФВП и циклов. Никакой принципиальной разницы, и преимущества нет. Только закрученный на ровном месте код, и все.


G>>Подозреваю, что и с вашим Linq эту задачу можно решить так же. В противном случае он бы вообще никуда не годился.


L>Толсто, Gaperton, очень толсто. От вас я ожидал более умного троллинга.


Код будет, или тебе и правда по существу возразить совсем нечего? Не ожидал как-то от тебя. Ты просил пример с циклом — вот тебе пример с циклом, и еще с эквивалентным comprehensions впридачу. Что теперь-то тебя удерживает от демонстрации немерянной крутизны линка вне контекста "реляционных" задач? Просим-просим. Что стесняться-то, все свои.
Re[27]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 20:01
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

G>>Это не единственная ошибка, заложенная в функцию p. Еще там должно стоять i > 0, а не i > 1. То есть, правильное условие — это


G>>i > 0 && x[ i — 1 ] == x[ i ] — 1


ГВ>А на обработке канала слабо написать? А то мне сейчас до юниксов тянуться долго.


Использовать канал в качестве итератора? Я думал об этом, но отмел этот вариант, так как почувствовал, что он будет сложнее. Давай попробую, почему нет.
Re[25]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 20:06
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Кстати, да. Вместо "+ 1" в функции p должен быть "- 1". Только сути это не меняет — всё равно пока решения на Linq либо до мрачности сложны, либо сильно похожи на обычный цикл.


Ну, по мелочи — двоеточие пропустил. Вот здесь.

for i, val := range x {

Тяжело, когда под рукой нет компилятора. Впрочем, наши коллеги линкеры также свой код не тестили. Иначе бы заметили, что их результаты с твоими примерами не совпадают.
Re[23]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 20:09
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Толсто, Gaperton, очень толсто. От вас я ожидал более умного троллинга.


G>Код будет, или тебе и правда по существу возразить совсем нечего? Не ожидал как-то от тебя. Ты просил пример с циклом — вот тебе пример с циклом, и еще с эквивалентным comprehensions впридачу.


Я просил не пример с циклами, а пример, решающий задачу. Чувствуешь разницу?

G>Что теперь-то тебя удерживает от демонстрации немерянной крутизны линка вне контекста "реляционных" задач? Просим-просим. Что стесняться-то, все свои.


Буде
Re[25]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 21.11.09 20:50
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>От чего твоему коду сильно легчает, и становится заметно, что это простейшая императивная реализация.


G>Вот тебе еще один пример с циклом, который проще чем твой вариант с линком.


Ну вот, превратил занятную головоломку для последующих supporter-ов в какое-то банальное унылое г**но.
Re[27]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 20:54
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Ну, по мелочи — двоеточие пропустил. Вот здесь.


G>>for i, val := range x {


L>И это еще не конец. Эх, Gaperton, вроде и язык простой и задача простая, а столько ошибок на пустом месте.

L>Как же так?

Компилятора нет, пишу на бумажке. Кроме того, это одна из моих первых программ на Go, и я постоянно сверяюсь с мануалом.

Удовлетворен? Или будут еще не относящиеся к делу вопросы?
Re[26]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.09 20:56
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Можно гипотетически прикинуть. Уменя получилось что-то вроде такого (предположим для простоты, что канал бесконечен):

func (c chan int, o chan int) {
  var va int <- c
  var vb int := 0
  for {
    vb <- c
    if vb - a = 1 {
      o <- vb
      va <- c
    }
    else va := vb
  }
}
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: Теперь у меня опечатка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.09 21:01
Оценка:
func (c chan int, o chan int) {
  var va int <- c
  var vb int := 0
  for {
    vb <- c
    if vb - va = 1 {
      o <- vb
      va <- c
    }
    else va := vb
  }
}
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 21:03
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Там два условия:

L>1) елемент на единицу больше предыдущего.
L>2)
L>

L>при этом извлечённый элемент не должен принимать участия в последующем сравнении

L>Ты же заменил 2-е условие на другое:
L>

L>при этом предшествующий элемент не должен удовлетворять первому условию

L>А такая замена некорректна.

?! Такая "замена" абсолютно корректна, ибо никакой "замены" по сути нет. Алгоритм удовлетворяет условию. Это можно строго доказать при желании. Утверждение "извлеченный элемент не принимает участия в последующем сравнении" относится к критерию фильтра, а не к алгоритму, который является решением задачи.
Re[26]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 21:16
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>От чего твоему коду сильно легчает, и становится заметно, что это простейшая императивная реализация.


G>>Вот тебе еще один пример с циклом, который проще чем твой вариант с линком.


L>Ну вот, превратил занятную головоломку для последующих supporter-ов в какое-то банальное унылое г**но.


Виноват, привычка, доведенная до автоматизма годами практики. Видишь-ли, я на саппорте 6 лет отработал.
Re[27]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.09 21:19
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Ты же заменил 2-е условие на другое:

L>>

L>>при этом предшествующий элемент не должен удовлетворять первому условию

L>>А такая замена некорректна.

G> ?! Такая "замена" абсолютно корректна, ибо никакой "замены" по сути нет. Алгоритм удовлетворяет условию. Это можно строго доказать при желании. Утверждение "извлеченный элемент не принимает участия в последующем сравнении" относится к критерию фильтра, а не к алгоритму, который является решением задачи.


Не. Lloyd прав — твой алгоритм на монотонно возрастающей последовательности {1, 2, 3, 4, 5} выдаст {2}, а не {2, 4}.

Вот экивалент на шарпе:

static bool p(int[] x, int i)
{
  return i > 0 && x[i - 1] == (x[i] - 1);
}

static List<int> gena_1(int[] x){
  var res = new List<int>();
  for(int i = 0; i < x.Length; ++i)
  {
    if (p(x, i) && !p(x, i - 1))
      res.Add(x[i]);
  }
  return res;
}
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.09 21:49
Оценка:
Здравствуйте, Lloyd, Вы писали:

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


L>Нет, он не удовлетворяет условию. Возьми последовательность {1, 2, 3, 4} и убедись.


Ага, теперь вижу. Блин, и правда бага . Непорядок. Ща схожу за сигаретами, и что-нибудь придумаю.

G>> Это можно строго доказать при желании.


L>Ты че такой упертый? Сам же видишь, что не прав, но продолжаешь упираться.


Не видел, пока ты не привел теста, на котором оно ломается. Че, не знаешь как баги репортить штоли?
Re[29]: Теперь у меня опечатка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.09 22:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Вообще красота получилась. Не ожидал. Возьму на заметку.


Это CSP.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: Я всё ж таки вот, о чём думаю
От: Lloyd Россия  
Дата: 22.11.09 00:40
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вообще, знаешь, ты прав, пожалуй. Можно ввести требование, например, "отбирать запись, отстоящую от заданной не более, чем на -30 минут", или вообще — связанную с какой-то отдельной меткой события.


А можно уточнить, какие сложности при этом возникают. Не втыкаю как-то.
Re[29]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.11.09 00:41
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Как-то так. Решение вполне реляционно, и должно получиться примерно 4-5 строк кода на языках с компрехеншнсами (если я опять чего-нибудь не пропустил). Естественно, это достаточно компактно (если сравнивать с компрехеншнсами) переводится в циклы. Сейчас уже делать не буду, да и смысла особого нет — обычный вариант с циклом и форсированием пропуска следующей итерации очевидно проще.


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

G>Но вообще — жесть. Повезло, что удалось зацепиться за особенности задачи. Небольшая вариация условия — и все, досвидос.

G>Геннадий, спасибо за задачку . Это был фан .

Всегда пожалуйста.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.11.09 01:04
Оценка:
Здравствуйте, Lloyd, Вы писали:

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


ГВ>>Вообще, знаешь, ты прав, пожалуй. Можно ввести требование, например, "отбирать запись, отстоящую от заданной не более, чем на -30 минут", или вообще — связанную с какой-то отдельной меткой события.


L>А можно уточнить, какие сложности при этом возникают. Не втыкаю как-то.


Не так просто привязаться к позиции. Например, у нас идут вот такие записи:

struct R {
  DateTime time;
  int value;
  bool mark;
  ...
};


...в порядке возрастания time. Некоторые содержат true в mark. Когда на вход поступает очередная запись с mark=true (обозначим её r0), нужно выдать на выход "самую старую" запись, пришедшую не ранее, чем за 30 минут. Задача усложняется тем, что совершенно не обязательно, что time будет выравнен по границе минуты, т.е. к индексу уже не привяжешься.

Вот такой пример, скажем:

time    mark
------------
0:14:00    f
0:15:28    f
0:18:20    f
0:27:37    f < ...а вернуть надо вот эту
0:29:59    f
0:32:28    f
0:55:32    t < mark = true, теперь см. выше...


Или, например, так. Та же структура, только на входе два потока — один "чаще", второй "реже". Теперь нужно выдавать на выход те записи первого потока, временнАя метка которых лежит в пределах [время-в-записи-второго-потока...+2 часа].

Ну то есть:

Stream 2, "редкий"
time     mark
-------------
3:00:00    f
4:15:00    t <- опорное время

Stream 1, "частый"
time    mark
------------
4:14:00    f
4:15:28    f <- начать нужно отсюда...
4:18:20    f
4:27:37    f 
4:35:32    f 
...
5:14:30    f <- ...а закончить здесь
5:15:32    f


Для Stream 1 тоже может быть добавлено какое-то условие, скажем, вычленять записи, находящиеся в диапазоне [-10 минут ... +2 часа].

Ну и дополнительную прелесть задаче придаёт то, что такие серии могут быть в десятки мегабайт размером.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: Поспешил
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.11.09 01:07
Оценка:
Несколько опечаток:

ГВ>Или, например, так. Та же структура, только на входе два потока — один "чаще", второй "реже". Теперь нужно выдавать на выход те записи первого потока, временнАя метка которых лежит в пределах [время-в-записи-второго-потока...+1 час].


ГВ>Для Stream 1 тоже может быть добавлено какое-то условие, скажем, вычленять записи, находящиеся в диапазоне [-10 минут ... +1 час].
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[30]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 22.11.09 01:20
Оценка:
Здравствуйте, Lloyd, Вы писали:

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


ГВ>>>Не. Lloyd прав — твой алгоритм на монотонно возрастающей последовательности {1, 2, 3, 4, 5} выдаст {2}, а не {2, 4}.


G>>Так. По-ходу, как фиксить багу я кажется понял. Удивительно, но похоже эту задачку все-таки можно решить через компрехеншнс (в чем и была моя изначальная идея — решить в компрехеншнс, и перевести в цикл). Получается, правда, уже не так красиво, как я написал... Но все-таки, похоже задача решается без протягивания состояния с итерации на итерацию. Что далеко не очевидно.


L>Она решается без протягивания состояния исключительно потому, что в твоем решении сосотояние глобально.


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

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


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

Интерес, правда, в этом скорее академический. Уж больно через жопу как-то получается. Но надо на всякий случай запомнить, может пригодится когда-нибудь.
Re[30]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 22.11.09 01:27
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

G>>Как-то так. Решение вполне реляционно, и должно получиться примерно 4-5 строк кода на языках с компрехеншнсами (если я опять чего-нибудь не пропустил). Естественно, это достаточно компактно (если сравнивать с компрехеншнсами) переводится в циклы. Сейчас уже делать не буду, да и смысла особого нет — обычный вариант с циклом и форсированием пропуска следующей итерации очевидно проще.


ГВ>Ещё можно поиграть с возвратом замыканий. Тоже, кажется, должно компактно получиться.


Возврат замыкания принципиально не отличается от алгоритмов, выраженных через foldl, с явным состоянием, и от "объектного" стиля, где состояние завернуто в объект, и от простых циклов. Во всех этих случаях так или иначе состояние протягивается с одной итерации на другую, только разными способами. Работая с Go, я бы предпочел, вероятно, завернуть состояние в объект, ибо объекты там очень легко делаются. Может быть, ты что-то другое имеешь в виду, правда.
Re[31]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.11.09 01:32
Оценка:
Здравствуйте, Gaperton, Вы писали:

ГВ>>Ещё можно поиграть с возвратом замыканий. Тоже, кажется, должно компактно получиться.


G>Возврат замыкания принципиально не отличается от алгоритмов, выраженных через foldl, с явным состоянием, и от "объектного" стиля, где состояние завернуто в объект, и от простых циклов. Во всех этих случаях так или иначе состояние протягивается с одной итерации на другую, только разными способами. Работая с Go, я бы предпочел, вероятно, завернуть состояние в объект, ибо объекты там очень легко делаются. Может быть, ты что-то другое имеешь в виду, правда.


Да нет, я как раз именно протягивание состояния имею в виду. А в случае Go, кстати, состояние неплохо заворачивается в горутину. Что ты думаешь, я тут крыльями машу?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[31]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 22.11.09 01:33
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Она решается без протягивания состояния исключительно потому, что в твоем решении сосотояние глобально.


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


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

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


G>Ты имеешь в виду, при невозможности обращения к исходному массиву по индексу, штоли? Да вроде и этого можно избежать, при желании. Все должно ложиться на однопроходные операции, а обращение по индексу может быть решено через джойны.


Объясни, что ты имеешь в виду. Что зв join?

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


Почему "академический"? Бесконечные последовательности по-моему вполне реальный пример. Разве нет? А по ним по индексу не побегаешь.
Re[22]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.11.09 01:39
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Кешировать данные за последние тридцать минут, отбрасывая по мере изменения последнего time, и при появлении mark-а возвращать последюю. Или я опять чего-то недогоняю?


Всё верно. Теперь, пожалуйста, то же самое с помощью LINQ?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: Я всё ж таки вот, о чём думаю
От: Lloyd Россия  
Дата: 22.11.09 01:44
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

L>>Кешировать данные за последние тридцать минут, отбрасывая по мере изменения последнего time, и при появлении mark-а возвращать последюю. Или я опять чего-то недогоняю?


ГВ>Всё верно. Теперь, пожалуйста, то же самое с помощью LINQ?


Что-то мне подсказывает, что тут можно как-то использовать новомодный rx (linq to events), потому как по сути речь идеть о преобразовании одних событий в другие.
Но эта область для меня пока темный лес.
Re[32]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 22.11.09 02:03
Оценка:
Здравствуйте, Lloyd, Вы писали:

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


L>Что-то я не улавливаю связи между неличием состояния и мутабельными операциями. В моем последнем примере с линком состояние было, но не было мутабельных операций.


"Изменяемое состояние" обычно связывают с отсутствием "чистоты". Связь самая прямая. Я не понимаю, что ты в данном случае называешь глобальным состоянием, может быть пояснишь?

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

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


G>>Ты имеешь в виду, при невозможности обращения к исходному массиву по индексу, штоли? Да вроде и этого можно избежать, при желании. Все должно ложиться на однопроходные операции, а обращение по индексу может быть решено через джойны.


L>Объясни, что ты имеешь в виду. Что зв join?


Аналог моей операции для генераторов & (zip, сделать из двух последовательностей одну последовательность пар, либо просто синхронно пробежаться по двум впараллель) у вас есть, или нет? Если да, то ты можешь сгенерировать последовательность индексов, и использовать так, как используют ключи в реляционной БД. Клеишь эти индексы к значениям а, чтобы парами шли. Дальше — джойнами работаешь, схожими приемами, как в SQL. Вообще я затрудняюсь это более понятно объяснить.

Не слишком эффективно, но сработать должно.

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

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


L>Почему "академический"? Бесконечные последовательности по-моему вполне реальный пример. Разве нет? А по ним по индексу не побегаешь.


Бесконечные? Давай я подумаю на этот счет, их я пока не рассматривал. Сейчас уже ничего не соображаю, потом.
Re[33]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 22.11.09 02:12
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Объясни, что ты имеешь в виду. Что зв join?


G>Аналог моей операции для генераторов & (zip, сделать из двух последовательностей одну последовательность пар, либо просто синхронно пробежаться по двум впараллель) у вас есть, или нет? Если да, то ты можешь сгенерировать последовательность индексов, и использовать так, как используют ключи в реляционной БД.


Да, да, при таком подходе внутри генераторов индексов у тебя будет от итерации к итерации протягиваться щотчик. Но это нормально и как-бы не считается. Потому, что эта передача хорошо изолирована где-то на окраине, и на остальное не влияет.
Re[33]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 22.11.09 14:39
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


L>>Что-то я не улавливаю связи между неличием состояния и мутабельными операциями. В моем последнем примере с линком состояние было, но не было мутабельных операций.


G>"Изменяемое состояние" обычно связывают с отсутствием "чистоты". Связь самая прямая.


Опять какая-то путаница. Понятно, что для мутабельнсости, нужно состояние, т.к. если нет состояния, то и менять нечего. Но у тебя вывод-то дурой: состояния нет, т.к. нет мутабельных операций. Причина со следствие переставлены.

G>Я не понимаю, что ты в данном случае называешь глобальным состоянием, может быть пояснишь?


Поясню: массив, из кторого ты читаешь.

G>>>Ты имеешь в виду, при невозможности обращения к исходному массиву по индексу, штоли? Да вроде и этого можно избежать, при желании. Все должно ложиться на однопроходные операции, а обращение по индексу может быть решено через джойны.


L>>Объясни, что ты имеешь в виду. Что зв join?


G>Аналог моей операции для генераторов & (zip, сделать из двух последовательностей одну последовательность пар, либо просто синхронно пробежаться по двум впараллель) у вас есть, или нет?


Есть, более того, он (Zip) был использован в моем примере.

G>Если да, то ты можешь сгенерировать последовательность индексов, и использовать так, как используют ключи в реляционной БД. Клеишь эти индексы к значениям а, чтобы парами шли. Дальше — джойнами работаешь, схожими приемами, как в SQL. Вообще я затрудняюсь это более понятно объяснить.


Опять не понимаю. Можно кодом?

G>Не слишком эффективно, но сработать должно.


G>Что касается построения первых двух множеств — там все еще проще, потому как известна "глубина просмотра" назад на каждой итерации, и она постоянна. Берешь исходный массив, сдвигаешь его, клеишь с исходным, и вперед.


Это и будет "простаскиванием" состояния.

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


L>>Почему "академический"? Бесконечные последовательности по-моему вполне реальный пример. Разве нет? А по ним по индексу не побегаешь.


G>Бесконечные? Давай я подумаю на этот счет, их я пока не рассматривал. Сейчас уже ничего не соображаю, потом.


Ок.
Re[25]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 22.11.09 18:16
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>В чем я действительно сомневаюсь — это в том, что Linq проявляет себя в полную силу в классе приложений, отличном от того, где у тебя в бэкенде стоит реляционная БД. Мне кажется, что его настоящий killing application — это приложения с реляционным источником.


Что такое реляционный источник?

G>Это по своей природе типичная "реляционная" задача. И это весьма показательно, что силу linq ты предпочел демонстрировать на ней.


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

G>Работая с Go, я просто заверну это в хранимую процедуру, как делал еще в 90-х, и выиграю в производительности, одновременно абстрагировавшись от схемы БД. И все.


Это задача является частью процесса, который как раз был вынесен из БД в целях улучшения производительности. Дело в том что аллокирование затрат может происходить на тех, с кого нужно это опять списать, поэтому расчёт делается множетсвом итераций пока у нас всё не распределиться. Учитывая, что речь идёт о количестве обрабатываемых записей в десятки миллионов, то одна итерация в БД занимала примерно 20 минут, а итерация в памяти около 10 секунд. В результате оказывается быстрее посчитать всё в памяти и потом залить результат через bcp, чем крутить циклы в SQL.
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 22.11.09 18:31
Оценка:
Здравствуйте, Gaperton, Вы писали:

ГВ>>>Вторая задача, кстати, тоже не совсем правильно решена — из-за Union могут быть проглочены соседние элементы, например на вот таком массиве { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 } ответ получается {1, 3, 4}, а должен быть как минимум {1, 3, 3, 4}.


IT>>Я задачу понял именно так. Для твоего уточнения достаточно заменить Union на Cancat. И что значит выделенное, первая задача решена не правильно?


G>Первая задача решена может и правильно, но однозначно чудовищно.


О чудовищности мы можем поговорить отдельно. Главное не это. Мы то все понимаем, что расчёт ГВ был прост и незатейлив — учитывая, что Linq работает с последовательностями, предложить задачу, в которой требуется обращение к предыдущему/последующему элементам, да ещё необходимо сохранять промежуточное состояние. В принципе, расчёт был верен, да вот только Linq не запрещает ни использование состояния, ни счётчиков, ни всего остального. В реальных же задачах неумение свести задачу к обработке последовательности в большинстве случаев говорит лишь о неумении это делать. foreach в C# не просто так придумали, это как раз говорит о том, что большинству алгоритмов даже номер элемента в последовательности знать совсем не обязательно. А случаи, где это нужно знать как правило работают с двумя и более последовательностями и индекс нужен просто потому, что по другому это выразить нельзя. Хотя можно склеить две последовательности и получить тот же эффект и без индексов.

G>Зато вторая — неиллюзорно доставляет. Заставляет меня вспомнить молодые годы, когда мы по неопытности любили использовать SQL весьма необычным способом. Так, что читателей бросало в дрожь. Помню, когда мой первый начальник увидел мой первый "промышленный" SQL-запрос, он после этого наотрез отказался изучать SQL. И никто так и не смог его переубедить.


G>В общем, так держать!


Ты тут постом выше предложил вести разговор в продуктивном ключе или это тебя самого не касалось?
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: А-а-а-а-а-а! Я понял!!!
От: IT Россия linq2db.com
Дата: 22.11.09 18:32
Оценка:
Здравствуйте, Gaperton, Вы писали:

IT>>Ты сильно не зарывайся. Обсуждение инквизиции запрещено правилами форума, за это можно на сутки-двое и на костерок загреметь.


G>Точно. Запрещено секретным пунктом правил. И в его подпункте написано, что IT лишен чувства юмора.


Если бы не моё чувство юмора вы бу уже все давно горели синим пламенем.
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.11.09 18:53
Оценка:
Здравствуйте, IT, Вы писали:

IT>Where как и любой другой метод Linq — это и есть решение с помощью yield return. Поставь в месте где у тебя foreach arr.Where и получишь с небольшими модификациями практически тоже самое. Там где у тебя yield return будет return true, в остальных местах return false.


Хммм... А с состоянием что делать? Может, лучше ты сам покажешь?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.11.09 21:22
Оценка:
Здравствуйте, Lloyd, Вы писали:

ГВ>>Хммм... А с состоянием что делать? Может, лучше ты сам покажешь?


L>
L>var q1 = arr
L>    .Where(((Func<Func<int, bool>>)(() => {
L>        bool first = true;
L>        int prev = 0;
L>        return i => {
L>            if (first) {
L>                first = false;
L>                prev = i;
L>                return false;
L>            } else if (i - prev == 1) {
L>                first = true;
L>                return true;
L>            } else {
L>                prev = 1;
L>                return false;
L>            }
L>        }; 
L>    }))());
L>

L>

Осталось только выяснить, почему на наборе { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 } на выходе получается {2, 2}.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[34]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 14:28
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>"Изменяемое состояние" обычно связывают с отсутствием "чистоты". Связь самая прямая.


L>Опять какая-то путаница. Понятно, что для мутабельнсости, нужно состояние, т.к. если нет состояния, то и менять нечего. Но у тебя вывод-то дурой: состояния нет, т.к. нет мутабельных операций. Причина со следствие переставлены.

G>>Я не понимаю, что ты в данном случае называешь глобальным состоянием, может быть пояснишь?
L>Поясню: массив, из кторого ты читаешь.

У меня никакой "путаницы" нет, я пользуюсь общепринятой терминологией среди функциональщиков. Объясняю.

Первое. Массив доступен глобально, но "состоянием" он не является, именно потому, что он иммутебельный.

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

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

Протяжку состояния можно сделать и неявной, при помощи монад, например, что не меняет сути дела.

Но в моем решении нет "протягивания состояния". Ни явного, ни скрытого. Массив не модифицируется, и не "протягивается" через вызовы. Соответственно, он не является никаким состоянием, ни явным, ни "протянутым".

L>Есть, более того, он (Zip) был использован в моем примере.


Вот и отлично.

G>>Если да, то ты можешь сгенерировать последовательность индексов, и использовать так, как используют ключи в реляционной БД. Клеишь эти индексы к значениям а, чтобы парами шли. Дальше — джойнами работаешь, схожими приемами, как в SQL. Вообще я затрудняюсь это более понятно объяснить.


L>Опять не понимаю. Можно кодом?


Можно конечно. Чуть позже.

G>>Не слишком эффективно, но сработать должно.


G>>Что касается построения первых двух множеств — там все еще проще, потому как известна "глубина просмотра" назад на каждой итерации, и она постоянна. Берешь исходный массив, сдвигаешь его, клеишь с исходным, и вперед.


L>Это и будет "простаскиванием" состояния.


Нет, как раз именно это и не является протаскиванием состояния. Протянутое состояние невозможно выразить в терминах comprehensions.

Вот если я вместо цикла напишу, например, какой-нибудь foldl, и буду транформировать массив на каждом шаге, передавая его изменения с одной итерации на другую — то это будет оно. Протянутое состояние.
Re[35]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 23.11.09 14:39
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>>>"Изменяемое состояние" обычно связывают с отсутствием "чистоты". Связь самая прямая.


L>>Опять какая-то путаница. Понятно, что для мутабельнсости, нужно состояние, т.к. если нет состояния, то и менять нечего. Но у тебя вывод-то дурой: состояния нет, т.к. нет мутабельных операций. Причина со следствие переставлены.

G>>>Я не понимаю, что ты в данном случае называешь глобальным состоянием, может быть пояснишь?
L>>Поясню: массив, из кторого ты читаешь.

G>У меня никакой "путаницы" нет, я пользуюсь общепринятой терминологией среди функциональщиков. Объясняю.


Отсылки не общепринятую терминологию лучше подкреплять ссылками.

G>Первое. Массив доступен глобально, но "состоянием" он не является, именно потому, что он иммутебельный.


Почему ты ставишь знак равенства м/у состоянием и мутабельностью? Это разные вещи.

G>"Протягивание состояния" — термин, обозначающий общую технику избавления от явного состояния, состоящую в передаче и транформации данных через последовательность вызовов, передаваемых и возвращаемых отдельным параметром через все вызовы.


G>Простейший пример — у меня есть цикл, который суммирует массив во внутренней мутабельной переменной. Она — является состоянием. Как мне от него избавиться? Преобразовать цикл в рекурсию, и передовать значение текущей суммы через параметр функции. Эта переменная — и есть "протянутое состояние".


G>Протяжку состояния можно сделать и неявной, при помощи монад, например, что не меняет сути дела.


Спасибо, капитан очевидность.

G>Но в моем решении нет "протягивания состояния". Ни явного, ни скрытого. Массив не модифицируется, и не "протягивается" через вызовы. Соответственно, он не является никаким состоянием, ни явным, ни "протянутым".


Состояние != мутабельнсости.

G>>>Если да, то ты можешь сгенерировать последовательность индексов, и использовать так, как используют ключи в реляционной БД. Клеишь эти индексы к значениям а, чтобы парами шли. Дальше — джойнами работаешь, схожими приемами, как в SQL. Вообще я затрудняюсь это более понятно объяснить.


L>>Опять не понимаю. Можно кодом?


G>Можно конечно. Чуть позже.


Ok.

G>>>Не слишком эффективно, но сработать должно.


G>>>Что касается построения первых двух множеств — там все еще проще, потому как известна "глубина просмотра" назад на каждой итерации, и она постоянна. Берешь исходный массив, сдвигаешь его, клеишь с исходным, и вперед.


L>>Это и будет "простаскиванием" состояния.


G>Нет, как раз именно это и не является протаскиванием состояния. Протянутое состояние невозможно выразить в терминах comprehensions.


Расшифруй.

G>Вот если я вместо цикла напишу, например, какой-нибудь foldl, и буду транформировать массив на каждом шаге, передавая его изменения с одной итерации на другую — то это будет оно. Протянутое состояние.


Ты именно так и предлагаешь по сути делать. Только это протягивание будет не на этапе fold-а, а переде ним, там где ьы собрался делать склейку. В fold придет уже придет последовательность с нужными данными, но сформированы они как раз будет все через то же протягивание.
Re[21]: Я всё ж таки вот, о чём думаю
От: IT Россия linq2db.com
Дата: 23.11.09 15:00
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не так просто привязаться к позиции. Например, у нас идут вот такие записи:


ГВ>
ГВ>struct R {
ГВ>  DateTime time;
ГВ>  int value;
ГВ>  bool mark;
ГВ>  ...
ГВ>};
ГВ>


ГВ>...в порядке возрастания time. Некоторые содержат true в mark. Когда на вход поступает очередная запись с mark=true (обозначим её r0), нужно выдать на выход "самую старую" запись, пришедшую не ранее, чем за 30 минут. Задача усложняется тем, что совершенно не обязательно, что time будет выравнен по границе минуты, т.е. к индексу уже не привяжешься.


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

R trueMark = ...

var q = 
    from r in db.R
    where r.time > trueMark.date.AddMinuties(-30)
    orderby r.time descending select r;

var prev = q.FirstOrDefault();

Если способ хранения выбран в памяти, то вместо сортировки и First можно обойтись Last.

В общем, всё это уже становится не интересным. Где не работает Linq я тебе и сам могу сказать. Linq не работает на деревьях и иерархиях, там, где для обработки требуются рекурсивные алгоритмы.
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 20:45
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да нет, я как раз именно протягивание состояния имею в виду. А в случае Go, кстати, состояние неплохо заворачивается в горутину. Что ты думаешь, я тут крыльями машу?


Ну, если ты поэтому машешь крыльями, то тебе стоит обратить внимание на Эрланг. Там заворачивание состояния в процесс (==goroutine) ходовая техника, ибо по другому мутабельное состояние заворачивать не то, что-бы низя. А неидеоматично. То есть, в Эрланге практика проектирования такова, что вместо объектов массово применяются процессы.
Re[22]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 22:00
Оценка:
Здравствуйте, yuriylsh, Вы писали:

Y>public struct R

Y> {
Y> public TimeSpan time;
Y> public int value;
Y> public bool mark;
Y> }
Y>[/c#]

Это сохраняем.

Y>
Y>var ro = Observable.FromEvent<REventArgs>(g, "R_arrived_event").Select(ea => ea.R);
Y>


Вместо подписки на сообщения у нас будут каналы. То есть, вообще ничего писать не надо. Никаких ацких заклинаний.

Y>
Y>List<R> buffer = new List<R> { new R() };
Y>ro.Do(r =>
Y>          {
Y>              buffer.RemoveAll(rr => r.time - rr.time > TimeSpan.FromMilliseconds(1800));
Y>              buffer.Add(r);
Y>          })
Y>    .Where(r => r.mark)
Y>    .Subscribe(r => Console.WriteLine("mark = true at {0}, first within 1800 ms: {1}", r.time.TotalMilliseconds,
Y>                                      buffer[0].time.TotalMilliseconds));
Y>


А это переписываем так. На простых циклах.

buffer := vector.NewIntVector( 0 )

ReceiveMessage: for x := range ro { // Это твой Do
   if x.mark { // Это твой where
        for i, y := range buffer {
            if x.time - y.time >= 30 { // Это условие твоего RemoveAll в лямбде
                out <- y; // Это твой Subscribe, который писать в лом
                buffer = buffer.Cut( i, len( buffer ) - 1 )  // Это твой RemoveAll
                continue ReceiveMessage
            } 
        }
   }

   buffer.Push( x ) // А это твой BufferPush 
}


Как-то так. Длинновато конечно. 9 строк кода против 6. Ай-ай, как у нас линк зарулил. Зато сложность алгоритма с циклом поменьше — не на каждое значение буфер целиком пробегаем на предмет RemoveAll, ловя сложность в N*глубину буфера (либо у тебя там бага с добавлением нового элемента, предполагаю первое).

А все почему? Потому, что стандартная библиотка работы с векторами в Go бедновата. Но мы, не торопясь добавлять в язык пожжержку LINQ, ее дополним. Можно? В чем там твой выигрышь-то по строкам был по сути? Элементы из буфера в одну строку удалаешь, да? Вот такая, значит, функция, должна быть в библиотеке?

func (arr IntVector) Filter( func ( x int ) bool )


И тогда, сталбыть, цикл так станет выглядеть?

buffer := vector.NewIntVector( 0 )

for x := range ro { // Это твой Do
   if x.mark { // Это твой where
        buffer.Filter( func ( x int ) bool { return x.time - y.time < 30 } ) // Твой RemoveAll
        out <- buffer[0]; // Это твой Subscribe, который писать в лом
        }
   }

   buffer.Push( x ) // А это твой BufferPush 
}


Ну надо ж. "С циклами" те же самые 6 строк. С минимальным и вполне полезным допилом стандартной библиотеки. Только мозг у неподготовленного читателя в трубочку не сворачивается. И в чем маза?
Re[23]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 22:02
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>
G>buffer := vector.NewIntVector( 0 )

G>ReceiveMessage: for x := range ro { // Это твой Do
G>   if x.mark { // Это твой where
G>        for i, y := range buffer {
G>            if x.time - y.time >= 30 { // Это условие твоего RemoveAll в лямбде
G>                out <- y; // Это твой Subscribe, который писать в лом
G>                buffer = buffer.Cut( i, len( buffer ) - 1 )  // Это твой RemoveAll
G>                continue ReceiveMessage
G>            } 
G>        }
G>   }

G>   buffer.Push( x ) // А это твой BufferPush 
G>}
G>


continue c меткой отсюда надо убрать. Так — правильно. Получается 8 строк кода, а не 9.
Re[23]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 22:07
Оценка:
G>
G>buffer := vector.NewIntVector( 0 )

G>for x := range ro { // Это твой Do
G>   if x.mark { // Это твой where
G>        buffer.Filter( func ( x int ) bool { return x.time - y.time < 30 } ) // Твой RemoveAll
G>        out <- buffer[0]; // Это твой Subscribe, который писать в лом
G>   }

G>   buffer.Push( x ) // А это твой BufferPush 
G>}
G>


А это правильно должно выглядеть вот так. С удаленной скобкой. Плохо писать код в веб-браузере, плохо.
Re[24]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.11.09 22:25
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?


Иди расскажи о своем "факте" в "Декларативное программирование".
Тот над тобой там посмеются.

Linq — это копия хаскелевского прилю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: LINQ только для РСУБД!
От: yuriylsh  
Дата: 23.11.09 22:35
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>
G>buffer := vector.NewIntVector( 0 )

G>for x := range ro { // Это твой Do
G>   if x.mark { // Это твой where
G>        buffer.Filter( func ( x int ) bool { return x.time - y.time < 30 } ) // Твой RemoveAll
G>        out <- buffer[0]; // Это твой Subscribe, который писать в лом
G>        }
G>   }

G>   buffer.Push( x ) // А это твой BufferPush 
G>}
G>


G>Ну надо ж. "С циклами" те же самые 6 строк. С минимальным и вполне полезным допилом стандартной библиотеки. Только мозг у неподготовленного читателя в трубочку не сворачивается. И в чем маза?


Ок, допиливаю и я стандартную библиотеку и добавляем коллекцию, которая при вызове Add итерирует свои элементы начиная с первого (у нас входные данные бесплатно отсортированы ), применяя предоставленный предикат к элементу и если предикат выполняеться, удаляет его, и так до тех пор пока предикат не вернет false. А затем добавляет переданный элемент в конец.
Тогда код запишеться:

var buffer = new SmartBuffer<R>(x, y =>  x.time - y.time < 30);
ro.Do(buffer.Add(r)).Where(r => r.mark).Subscribe(r => /*Это мой Subscribe, который писать в лом*/);


Ну надо ж. "С LINQ" всего 2 строчки. С минимальным и вполне полезным допилом стандартной библиотеки. Только мозг у неподготовленного читателя в трубочку не сворачивается. И в чем маза?

З.Ы. Почему-то и предполагал что скатиться к оптимизациям.

З.З.Ы. С того времени как я сказал, что мне общаться с тобой не интересно ничего не поменялось...
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[26]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 23.11.09 22:45
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Ну, мне остается только процитировать тебя же (извини, если не точно): человек либо понимает, либо нет.
Re[24]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 22:48
Оценка:
Здравствуйте, yuriylsh, Вы писали:

Y>З.Ы. Почему-то и предполагал что скатиться к оптимизациям.


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

Y>З.З.Ы. С того времени как я сказал, что мне общаться с тобой не интересно ничего не поменялось...


Не интересно — не общайся, в чем проблема-то? Ты спрашивал вариант с циклом — я привел. Два варианта, в одном из которых показал влияние на результат функции Filter. Что ты так расстроился-то? Ты решив задачу через линк, никакого подвига не совершил — все что ты сделал, это записал цикл необычным образом. От этого в самом деле никакого выигрыша нет .
Re[27]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 22:51
Оценка:
Здравствуйте, Lloyd, Вы писали:

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


L>Ну, мне остается только процитировать тебя же (извини, если не точно): человек либо понимает, либо нет.


Ну да, все правильно. Я совершенно искренне не понимаю, чем такая запись, как в примере выше, лучше цикла. Могу совершенно честно это сказать.

Что-тут понимать-то надо? Мне уж любопытно стало, ты меня заинтриговал. Не объяснишь? Вот прям на этом примере — чем он лучше аналогичного цикла?
Re[28]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 23.11.09 22:54
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Ну, мне остается только процитировать тебя же (извини, если не точно): человек либо понимает, либо нет.


G>Ну да, все правильно. Я совершенно искренне не понимаю, чем такая запись, как в примере выше, лучше цикла. Могу совершенно честно это сказать.


G>Что-тут понимать-то надо? Мне уж любопытно стало, ты меня заинтриговал. Не объяснишь? Вот прям на этом примере — чем он лучше аналогичного цикла?


Напрасный труд, ибо:

человек либо понимает, либо нет

Если не согласен с процитированным, предлагаю найти сообщение, из которого эта цитата, и подискутировать с автором оного. Удачи.
Re[29]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 23:02
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Что-тут понимать-то надо? Мне уж любопытно стало, ты меня заинтриговал. Не объяснишь? Вот прям на этом примере — чем он лучше аналогичного цикла?


L>Напрасный труд, ибо:


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

L>

L>человек либо понимает, либо нет

L>Если не согласен с процитированным, предлагаю найти сообщение, из которого эта цитата, и подискутировать с автором оного. Удачи.

Почему это — не согласен. Согласен вполне. Это из меня цитата
Re[25]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.09 23:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Linq — это копия хаскелевского прилю.


О! Это все меняет
Re[25]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 23.11.09 23:13
Оценка:
Здравствуйте, Gaperton, Вы писали:

Y>>З.З.Ы. С того времени как я сказал, что мне общаться с тобой не интересно ничего не поменялось...


G>Не интересно — не общайся, в чем проблема-то? Ты спрашивал вариант с циклом — я привел. Два варианта, в одном из которых показал влияние на результат функции Filter. Что ты так расстроился-то? Ты решив задачу через линк, никакого подвига не совершил — все что ты сделал, это записал цикл необычным образом. От этого в самом деле никакого выигрыша нет .


Мне вот что инетерсно: ты считаешь, что все, кто использует Linq-to-Objects, делают это не по причине удобства, а по какой-то другой причине? Или ты считаешь, что никто Linq-to-Objects не использует?
Re[27]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.11.09 23:33
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Ну, мне остается только процитировать тебя же (извини, если не точно): человек либо понимает, либо нет.


Тут другой случай. Человек приципиально не хочет понимать и рисует у себя в мозгу картины которые ему же хочется видеть. В общем, полный отрыв от реальности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.11.09 23:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

VD>>Linq — это копия хаскелевского прилю.


G>О! Это все меняет


Ой, и правда... Что может это изменить если ты уже зачислил Линк в средства доступа к РСУБД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 24.11.09 00:54
Оценка:
Здравствуйте, IT, Вы писали:

G>>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?


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


А и не сужу о технологии. Я характеризую ровно то, что вижу, и не более того.

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

Я спрашиваю: "дальше что", то есть, ты-то что думаешь об этих примерах сам? Вот честно? Например, ты можешь сказать что-то вроде "да, действительно, вы подобрали поганые примеры, эти примеры не раскрывают силу технологии, она сильна в другом". И показать другой короткий пример, который наоборот, сильный. С реляционной БД поработай, там. Шутка, шутка. Вэлкам, дружище. Мне пока нравится, как мы друг другу код демонстрируем. Движуха какая-то. Прикольно.
Re[27]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 24.11.09 01:19
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>ты считаешь, что все, кто использует Linq-to-Objects, делают это не по причине удобства, а по какой-то другой причине?


G>Я считаю, что приведенные примеры не показывают силу Linq-to-Objects. Она, по всей видимости, проявляется на каких-то других задачах.


G>И второе — да, я таки считаю, что отчасти линк используют на ровном месте просто "потому, что это круто".


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

Теперь посмотри на это со стороны. Не находишь картинку несколькой странной и наталкивающей на размышления?
Re[33]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 01:44
Оценка:
Здравствуйте, Gaperton, Вы писали:

ГВ>>Да нет, я как раз именно протягивание состояния имею в виду. А в случае Go, кстати, состояние неплохо заворачивается в горутину. Что ты думаешь, я тут крыльями машу?

G>Ну, если ты поэтому машешь крыльями, то тебе стоит обратить внимание на Эрланг.

Скажем так — не в последнюю очередь.

G>Там заворачивание состояния в процесс (==goroutine) ходовая техника, ибо по другому мутабельное состояние заворачивать не то, что-бы низя. А неидеоматично. То есть, в Эрланге практика проектирования такова, что вместо объектов массово применяются процессы.


Спасибо, я в курсе более или менее. Только вот к Эрлангу бы добавить ещё C-подобную семантику и синтаксис (да-да, чтобы он был императивным по сути), и сопоставимое c С быстродействие...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 01:53
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Я считаю, что приведенные примеры не показывают силу Linq-to-Objects. Она, по всей видимости, проявляется на каких-то других задачах.

G>>И второе — да, я таки считаю, что отчасти линк используют на ровном месте просто "потому, что это круто".
L>Но при этом, судя по твоим постам, linq ты почти не знаешь и в практике не использовал. Но те, кто его знают, использовал и продолжает использовать, по твоему мнению используют его просто "потому, что это круто".

Не надо обобщать. Речь о части применений. Какой именно части — вопрос, на который никто не ответит.

L>Теперь посмотри на это со стороны. Не находишь картинку несколькой странной и наталкивающей на размышления?


Угу. Раньше вместо LINQ-еров отгавкивались C++-ники.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 01:54
Оценка:
Здравствуйте, IT, Вы писали:

IT>В общем, всё это уже становится не интересным. Где не работает Linq я тебе и сам могу сказать. Linq не работает на деревьях и иерархиях, там, где для обработки требуются рекурсивные алгоритмы.


Ну — упс, приехали. А как же Linq2XML?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 01:56
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?


L>По-моему, все, что ты доказал — это то, что в go с помощью костылей можно съимитировать то, что на linq-е делается просто и красиво.


Что-то больше похоже на обратную ситуацию: что таки не всякий цикл по данным должен реализовываться LINQ-ом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: Я всё ж таки вот, о чём думаю
От: Lloyd Россия  
Дата: 24.11.09 02:00
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>В общем, всё это уже становится не интересным. Где не работает Linq я тебе и сам могу сказать. Linq не работает на деревьях и иерархиях, там, где для обработки требуются рекурсивные алгоритмы.


ГВ>Ну — упс, приехали. А как же Linq2XML?


А где там работа с деревьями?
Re[24]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 02:05
Оценка:
Здравствуйте, Lloyd, Вы писали:

IT>>>В общем, всё это уже становится не интересным. Где не работает Linq я тебе и сам могу сказать. Linq не работает на деревьях и иерархиях, там, где для обработки требуются рекурсивные алгоритмы.

ГВ>>Ну — упс, приехали. А как же Linq2XML?
L>А где там работа с деревьями?

Неужто XML деревом быть перестал? Сильное колдунство!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: Я всё ж таки вот, о чём думаю
От: Lloyd Россия  
Дата: 24.11.09 02:27
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Ну — упс, приехали. А как же Linq2XML?

L>>А где там работа с деревьями?

ГВ>Неужто XML деревом быть перестал? Сильное колдунство!


xml-вполне себе дерево, да вот только Linq2Xml (в части linq) не дает никаких средств для работы с xml-ем как с деревом.
Re[26]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 04:30
Оценка:
Здравствуйте, Lloyd, Вы писали:

ГВ>>>>Ну — упс, приехали. А как же Linq2XML?

L>>>А где там работа с деревьями?
ГВ>>Неужто XML деревом быть перестал? Сильное колдунство!
L>xml-вполне себе дерево, да вот только Linq2Xml (в части linq) не дает никаких средств для работы с xml-ем как с деревом.

Упс №2... И ведь верно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 24.11.09 05:36
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

G>>>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?

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

ГВ>В десятку! Значит — есть некое целевое использование? Последовательности — нецелевое, иерархии — нецелевое, а где ж тогда целевое?


Последовательности как раз целевое. Для последовательностей, кстати, в C# добавлен foreach и yield с сотоварищами. Но в них работа с состоянием и индексами выглядит столь же нелепо как и в Linq. Тем не менее ты сам подобными решениями, как я понял, не брезгуешь.

Иерархии подразумевают принципиальной другой способ обработки данных, который в C# пока вообще нельзя выразить лаконично. Для этого нужно добавлять в язык локальные функции.
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 24.11.09 05:38
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Угу. Раньше вместо LINQ-еров отгавкивались C++-ники.


Первое китайсое.
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 24.11.09 05:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Что-то больше похоже на обратную ситуацию: что таки не всякий цикл по данным должен реализовываться LINQ-ом.


foreach — это классический цикл. Его оличие от for в наличии индекса, что легко можно симулировать. А отличие от while в том, что while работает не с перебором последовательности данных, а вообще с хрен знает чем.
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 06:05
Оценка:
Здравствуйте, IT, Вы писали:

ГВ>>Что-то больше похоже на обратную ситуацию: что таки не всякий цикл по данным должен реализовываться LINQ-ом.

IT>foreach — это классический цикл. Его оличие от for в наличии индекса, что легко можно симулировать. А отличие от while в том, что while работает не с перебором последовательности данных, а вообще с хрен знает чем.

Скорее так — ни for, ни while не привязаны к перечислителю (это если мы о C-шных).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 06:07
Оценка:
Здравствуйте, IT, Вы писали:

IT>Иерархии подразумевают принципиальной другой способ обработки данных, который в C# пока вообще нельзя выразить лаконично. Для этого нужно добавлять в язык локальные функции.


Можно более развёрнуто?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 06:20
Оценка:
Здравствуйте, IT, Вы писали:

IT>Я думаю, что примеры подобраны правильно, чтобы продемонстрировать нецелевое использование предмета обсуждения. Мы, в свою очередь, пытались доказать не то, что "Linq is the best of the best of the best", а показать, что с помощью Linq можно решать и такие задачи.


С этим никто и не спорил. Речь шла об основном назначении Linq.

IT>Если бы ГВ спросил меня как бы я решал подобную задачу в реальности, а не в сферичности, то я бы ответил, что скорее всего обошёлся бы банальным циклом, т.к. для меня важнее простота и гибкость кода.


Вот-вот. И тут как раз проходит граница практической применимости Linq. То, что его принципиально можно применить где угодно, ещё не означает, что его имеет смысл применять где угодно. Добавь сюда свои соображения относительно XML и что в сухом остатке? Правильно — табличное представление данных.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: опечатка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 06:22
Оценка:
ГВ>относительно XML...

относительно иерархических данных...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 24.11.09 06:47
Оценка:
Здравствуйте, IT, Вы писали:

IT>Иерархии подразумевают принципиальной другой способ обработки данных, который в C# пока вообще нельзя выразить лаконично. Для этого нужно добавлять в язык локальные функции.


А их разве нет?

Func<int> getInt = () => 100;
Re[22]: Я всё ж таки вот, о чём думаю
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 06:50
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Оказалось не так уж сложно:


Я правильно понял, что здесь два перечислителя по последовательности бегают?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 24.11.09 07:18
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Иерархии подразумевают принципиальной другой способ обработки данных, который в C# пока вообще нельзя выразить лаконично. Для этого нужно добавлять в язык локальные функции.


ГВ>Можно более развёрнуто?


Иерархии обрабатываются рекурсивными алгоритмами. В C# сегодня это либо члены класса, но для этого нужно состояние либо выносить в класс, либо городить огород из длинного списка параметров. Либо эмулировать локальные функции делегатами, вроде этого:

void Foo()
{
    Func<int,int> bar; bar = n =>
    {
        // ...
        bar(n + 1);
    };

    var y = bar(1);
}

Громоздко и некрасиво, особенно, если нужны вложенные функции.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Кстати
От: IT Россия linq2db.com
Дата: 24.11.09 07:29
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Я думаю, что примеры подобраны правильно, чтобы продемонстрировать нецелевое использование предмета обсуждения. Мы, в свою очередь, пытались доказать не то, что "Linq is the best of the best of the best", а показать, что с помощью Linq можно решать и такие задачи.


ГВ>Как это вяжется с тем, что Linq, мол, предназначен для любых источников данных? Получается, что только для тех, которые сводятся к РСУБД-like.


Ты можешь дать определение РСУБД-like типам данных? Гапертон не смог.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 24.11.09 07:36
Оценка:
Здравствуйте, Lloyd, Вы писали:

IT>>Иерархии подразумевают принципиальной другой способ обработки данных, который в C# пока вообще нельзя выразить лаконично. Для этого нужно добавлять в язык локальные функции.


L>А их разве нет?


L>
L>Func<int> getInt = () => 100;
L>

Это эмуляция, на которую грустно смотреть.

Во-первых, при рекурсии тебе понадобится разбить объявление и инициализацию getInt и таким образом добавить лишний мусор в код.
Во-вторых, этот мусор многократно усугубляется с вложенностью.
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 24.11.09 08:28
Оценка:
Здравствуйте, IT, Вы писали:

IT>

IT>Вышли из леса суровые русские мужики и увидели японскую бензопилу.
IT>- А-а, б**! — сказали суровые русские мужики и засунули в пилу щепку.
IT>- Вжик! — сказала пила и распилила щепку.
IT>- У-у, б**! — сказали суровые русские мужики и засунули в пилу доску.
IT>- Вжжик! — сказала пила и распилила доску.
IT>- У-у, б**! — сказали суровые русские мужики и засунули в пилу бревно.
IT>- Вжжжжик! — сказала пила и распилила бревно.
IT>- У-у, б**!!! — сказали суровые русские мужики и засунули в пилу рельс.
IT>- Хррр-дзинь — сказала пила и сломалась.
IT>- А-а, б**... — сказали суровые русские мужики и пошли валить лес топорами.


Да, мы такие
Re[26]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 24.11.09 09:13
Оценка:
Здравствуйте, no4, Вы писали:

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


no4>И еще — не доказывают ли примеры, что lisp comprehensions в haskell были созданы для работы с РСУБД, но по какой-то странной ошибке природы они с ними работать не умеют?


Нет, не доказывают. В основе list comprehensions лежит ZF-нотация, и применяются они для компактной записи создания объектов. В некоторых языках, к примеру, в близком к хаскелю Clean, они могут применяться не только для создания, но и для модификации элементов массивов, заменяя собой циклы с независимыми итерациями.

И, кстати, по странной ошибке природы, в некоторых языках местами умеют в том числе и работать с СУБД, и вообще работать с произвольным источником. Например, в Эрланге. См. Query List Comprehensions. http://erlang.org/doc/man/qlc.html

Что к сути дискуссии не имеет никакого отношения, на самом деле. Ты в этой сути разобрался бы, прежде чем с комментами влезать в ее окончание.
Re[28]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 24.11.09 09:17
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>И второе — да, я таки считаю, что отчасти линк используют на ровном месте просто "потому, что это круто".


L>Но при этом, судя по твоим постам, linq ты почти не знаешь и в практике не использовал. Но те, кто его знают, использовал и продолжает использовать, по твоему мнению используют его просто "потому, что это круто".


L>Теперь посмотри на это со стороны. Не находишь картинку несколькой странной и наталкивающей на размышления?


Я нахожу весьма странным, и наталкивающим на размышления, что вместо демонстрации примеров, убедительно показывающих, почему же люди используют линк, тебе оказывается проще перевести разговор на обсуждение моей личности.
Re[29]: LINQ только для РСУБД!
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 24.11.09 09:59
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ключевое слово другое, Гена. Не таблицы, а последовательности.


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

Например, функция от аргумента известного типа, результат которой имеет отображаемый тип — вполне может быть типом для LINQ, как и последовательность, дерево и прочие контейнерные типы.

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

Вытаскиваем значения из отображений отображений:

m => from sub in m from val in sub select val


Лифтим функцию над значениями в функцию над отображениями

f, m1, m2, m3 => from x1 in m1 from x2 in m2 from x3 in m3 select f(x1,x2,x3)


и т.п. Забесплатно — кучу функций над разными типами, лёгкий equational reasoning.
Теперь что касается синтаксиса LINQ, то преимущества здесь ровно те же, что и у do-синтаксиса в Haskell

m1.SelectMany(x1 => m2.SelectMany(x2 => m3.Select(x3 => f(x1, x2, x3)))


кажется не таким наглядным. Только вы же не о синтаксисе здесь спорите?
Re[29]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.09 12:06
Оценка:
Здравствуйте, IT, Вы писали:

IT>Громоздко и некрасиво, особенно, если нужны вложенные функции.


Всё ясно. Да, тут действительно с Linq не понятно, как поступать — разве что, заворачивать запрос в функцию и вызывать эту же функцию из запроса. В принципе, получается то же самое "протягивание" состояния. Может, кстати, lomeo прав насчёт отображения, сохраняющего структуру...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[36]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 24.11.09 12:06
Оценка:
Здравствуйте, Lloyd, Вы писали:

>>Первое. Массив доступен глобально, но "состоянием" он не является, именно потому, что он иммутебельный.


L>Почему ты ставишь знак равенства м/у состоянием и мутабельностью? Это разные вещи.

...
L>Состояние != мутабельнсости.

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

G>>Нет, как раз именно это и не является протаскиванием состояния. Протянутое состояние невозможно выразить в терминах comprehensions.


L>Расшифруй.


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

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


[ map( x ) | x <- y, filter( x ) ]

При использовании функций map и filter у тебя нет возможности "протянуть" состояние от вызова к вызову, так как ты не можешь передать его через параметр функции ни в map, ни в reduce. Ты можешь его передать только явно, через мутабельную переменную, что будет явным состоянием. А неизменяемые данные состоянием не являются.

Одним из следствий отсутствия изменяемого состояния является "прозрачность по ссылкам" — независимость результата от порядка вычислений.

G>>Вот если я вместо цикла напишу, например, какой-нибудь foldl, и буду транформировать массив на каждом шаге, передавая его изменения с одной итерации на другую — то это будет оно. Протянутое состояние.


L>Ты именно так и предлагаешь по сути делать. Только это протягивание будет не на этапе fold-а, а переде ним, там где ьы собрался делать склейку. В fold придет уже придет последовательность с нужными данными, но сформированы они как раз будет все через то же протягивание.


Нет, я предлагаю делать совершенно не так. В своем решении я не пользуюсь foldl. Если говорить в терминах функций, оно целиком основано на комбинации map, filter, и функций-генераторах числовых последовательностей. Ни то, ни другое не протягивает состояния.
Re[37]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 24.11.09 12:30
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Почему ты ставишь знак равенства м/у состоянием и мутабельностью? Это разные вещи.

G>...
L>>Состояние != мутабельнсости.

G>Я считаю, что исчерпывающим образом объяснил, что я имею в виду, и ты при желании можешь понять, что я говорю. Спорить с тобой на эту тему я не собираюсь, считай как хочешь, это твое дело.


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

G>>>Нет, как раз именно это и не является протаскиванием состояния. Протянутое состояние невозможно выразить в терминах comprehensions.


L>>Расшифруй.


G>

G>"Протягивание состояния" — термин, обозначающий общую технику избавления от явного состояния, состоящую в передаче и транформации данных через последовательность вызовов, передаваемых и возвращаемых отдельным параметром через все вызовы.

G>Простейший пример — у меня есть цикл, который суммирует массив во внутренней мутабельной переменной. Она — является состоянием. Как мне от него избавиться? Преобразовать цикл в рекурсию, и передовать значение текущей суммы через параметр функции. Эта переменная — и есть "протянутое состояние".


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

G>[ map( x ) | x <- y, filter( x ) ]


G>При использовании функций map и filter у тебя нет возможности "протянуть" состояние от вызова к вызову, так как ты не можешь передать его через параметр функции ни в map, ни в reduce. Ты можешь его передать только явно, через мутабельную переменную, что будет явным состоянием. А неизменяемые данные состоянием не являются.


Я приводил пример с методом AttachState. В нем нет изменяемых данных, но есть нечто (у меня оно было названо state), что передается от вызова к вызову и при этом от вызова к вызову меняется. Считаешь ли ты это нечто состоянием или нет?

G>>>Вот если я вместо цикла напишу, например, какой-нибудь foldl, и буду транформировать массив на каждом шаге, передавая его изменения с одной итерации на другую — то это будет оно. Протянутое состояние.


L>>Ты именно так и предлагаешь по сути делать. Только это протягивание будет не на этапе fold-а, а переде ним, там где ьы собрался делать склейку. В fold придет уже придет последовательность с нужными данными, но сформированы они как раз будет все через то же протягивание.


G>Нет, я предлагаю делать совершенно не так. В своем решении я не пользуюсь foldl. Если говорить в терминах функций, оно целиком основано на комбинации map, filter, и функций-генераторах числовых последовательностей. Ни то, ни другое не протягивает состояния.


Ок. С map и filter понятно. Осталось понять что ты называешь функциями-генераторами. Можно привести пример?
Re[38]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 24.11.09 12:55
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Я считаю, что исчерпывающим образом объяснил, что я имею в виду, и ты при желании можешь понять, что я говорю. Спорить с тобой на эту тему я не собираюсь, считай как хочешь, это твое дело.


L>Я вроде и не спорю.


Если не считать, что ты несколько раз в разных вариантах повторил, что "состояние != мутабельнсости", без каких-либо пояснений, то да — ты не споришь.

L>Я просто пытаюсь понять, твою логику, понять почему ты ставишь занк равенства между этими понятиями. Но если, не хочешь, не буду настаивать.


Ну, я объяснил как мог.

G>>>>Нет, как раз именно это и не является протаскиванием состояния. Протянутое состояние невозможно выразить в терминах comprehensions.


L>>>Расшифруй.


G>>

G>>"Протягивание состояния" — термин, обозначающий общую технику избавления от явного состояния, состоящую в передаче и транформации данных через последовательность вызовов, передаваемых и возвращаемых отдельным параметром через все вызовы.

G>>Простейший пример — у меня есть цикл, который суммирует массив во внутренней мутабельной переменной. Она — является состоянием. Как мне от него избавиться? Преобразовать цикл в рекурсию, и передовать значение текущей суммы через параметр функции. Эта переменная — и есть "протянутое состояние".


L>Ты избавлялся от состояний и в результате получил "протянутое состояние". Я правильно понимаю, что "протянутое состояние" для тебя состоянием не является?


Да, "протянутое состояние" вполне можно назвать состоянием.

G>>[ map( x ) | x <- y, filter( x ) ]


G>>При использовании функций map и filter у тебя нет возможности "протянуть" состояние от вызова к вызову, так как ты не можешь передать его через параметр функции ни в map, ни в reduce. Ты можешь его передать только явно, через мутабельную переменную, что будет явным состоянием. А неизменяемые данные состоянием не являются.


L>Я приводил пример с методом AttachState. В нем нет изменяемых данных, но есть нечто (у меня оно было названо state), что передается от вызова к вызову и при этом от вызова к вызову меняется. Считаешь ли ты это нечто состоянием или нет?


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

G>>>>Вот если я вместо цикла напишу, например, какой-нибудь foldl, и буду транформировать массив на каждом шаге, передавая его изменения с одной итерации на другую — то это будет оно. Протянутое состояние.


L>>>Ты именно так и предлагаешь по сути делать. Только это протягивание будет не на этапе fold-а, а переде ним, там где ьы собрался делать склейку. В fold придет уже придет последовательность с нужными данными, но сформированы они как раз будет все через то же протягивание.


G>>Нет, я предлагаю делать совершенно не так. В своем решении я не пользуюсь foldl. Если говорить в терминах функций, оно целиком основано на комбинации map, filter, и функций-генераторах числовых последовательностей. Ни то, ни другое не протягивает состояния.


L>Ок. С map и filter понятно. Осталось понять что ты называешь функциями-генераторами. Можно привести пример?


Конечно. Генератором в comprehensions являются выражения вида (паттерн) <- (выражение, возвращающее множество). К примеру, n <- seq( 1, n, 2) — это генератор.

Функцией-генератором я в данном случае назвал seq( startIdx, endIdx, step ), которая генерирует последовательность индексов начиная со startIdx, не более чем endIdx, с шагом step. В Эрланге этому соответствует именно вызов функции. В Хаскеле/Clean может быть записан как список, что-то вроде [1..n], а при преобразовании comprehensions в циклы — эта штука преобразуется тупо в заголовок цикла for.
Re[30]: LINQ только для РСУБД!
От: IT Россия linq2db.com
Дата: 24.11.09 14:38
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Я тебе уже давал ссылку. Вот она
Автор: IT
Дата: 22.09.08
ещё раз.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: LINQ только для РСУБД!
От: vdimas Россия  
Дата: 24.11.09 15:15
Оценка:
Здравствуйте, IT, Вы писали:

IT>
IT>int pos = text.Split('\n').Take(line).Sum(s => s.Length + 1) + column;
IT>

IT>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.

Положа руку на сердце, деле класс-расширение Linq.Enumerable к самому Linq постольку-поскольку относится, правильнее было его в какие-нить System.Collections закинуть. А вот аналогичный Linq.Queryable — ему в линке самое место, но ты его в примере не пользуешь.
Re[39]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 24.11.09 19:08
Оценка:
Здравствуйте, lomeo, Вы писали:

L>> В нем нет изменяемых данных, но есть нечто, что [...] меняется.


L>8-0 Это как?


L>state у тебя меняется явно в определении AttachState. А то, что у тебя при использовании AttachState, так это аргумент и результат функции, они да — неизменны. Например, item в Select тоже меняется


Нет, для внешнего наблюдателя каждый раз порождается новое состояние на основе старого. Изменения переменных нет.

L>Насчёт состояние == мутабельность, это, конечно, не совсем так, но обычно, когда говорят "состояние" подразумевают именно изменяемое состояние. Обычно мало смысла говорить о неизменяемом состоянии:


Почему?

L>
L>const = 5
L>


L>Глобальная переменная const — неизменяемая. Состояние или нет? Если да, то состояние — это что угодно, если нет, то под глобальным состоянием следует понимать именно изменяемое состояние. Как то так.


Состояние, конечно.
Re[39]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 24.11.09 19:15
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>>>>>Нет, как раз именно это и не является протаскиванием состояния. Протянутое состояние невозможно выразить в терминах comprehensions.


L>>>>Расшифруй.


G>>>

G>>>"Протягивание состояния" — термин, обозначающий общую технику избавления от явного состояния, состоящую в передаче и транформации данных через последовательность вызовов, передаваемых и возвращаемых отдельным параметром через все вызовы.

G>>>Простейший пример — у меня есть цикл, который суммирует массив во внутренней мутабельной переменной. Она — является состоянием. Как мне от него избавиться? Преобразовать цикл в рекурсию, и передовать значение текущей суммы через параметр функции. Эта переменная — и есть "протянутое состояние".


L>>Ты избавлялся от состояний и в результате получил "протянутое состояние". Я правильно понимаю, что "протянутое состояние" для тебя состоянием не является?


G>Да, "протянутое состояние" вполне можно назвать состоянием.


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

G>>>[ map( x ) | x <- y, filter( x ) ]


G>>>При использовании функций map и filter у тебя нет возможности "протянуть" состояние от вызова к вызову, так как ты не можешь передать его через параметр функции ни в map, ни в reduce. Ты можешь его передать только явно, через мутабельную переменную, что будет явным состоянием. А неизменяемые данные состоянием не являются.


L>>Я приводил пример с методом AttachState. В нем нет изменяемых данных, но есть нечто (у меня оно было названо state), что передается от вызова к вызову и при этом от вызова к вызову меняется. Считаешь ли ты это нечто состоянием или нет?


G>В принципе можно, с некоторой натяжкой. Ты можешь назвать его состоянием, с целью подчеркнуть, что оно "протягивается". И люди тебя в целом поймут.


Но оно же не меняется. Просто на основе старого значения вячисляется новое. Разве не получается, что есть состояние и при этом оно неизменно.

G>>>>>Вот если я вместо цикла напишу, например, какой-нибудь foldl, и буду транформировать массив на каждом шаге, передавая его изменения с одной итерации на другую — то это будет оно. Протянутое состояние.


L>>>>Ты именно так и предлагаешь по сути делать. Только это протягивание будет не на этапе fold-а, а переде ним, там где ьы собрался делать склейку. В fold придет уже придет последовательность с нужными данными, но сформированы они как раз будет все через то же протягивание.


G>>>Нет, я предлагаю делать совершенно не так. В своем решении я не пользуюсь foldl. Если говорить в терминах функций, оно целиком основано на комбинации map, filter, и функций-генераторах числовых последовательностей. Ни то, ни другое не протягивает состояния.


L>>Ок. С map и filter понятно. Осталось понять что ты называешь функциями-генераторами. Можно привести пример?


G>Конечно. Генератором в comprehensions являются выражения вида (паттерн) <- (выражение, возвращающее множество). К примеру, n <- seq( 1, n, 2) — это генератор.


G>Функцией-генератором я в данном случае назвал seq( startIdx, endIdx, step ), которая генерирует последовательность индексов начиная со startIdx, не более чем endIdx, с шагом step. В Эрланге этому соответствует именно вызов функции. В Хаскеле/Clean может быть записан как список, что-то вроде [1..n], а при преобразовании comprehensions в циклы — эта штука преобразуется тупо в заголовок цикла for.


Тогда непонятно как ты будешь "транформировать массив", если ни одна из перечиленных функций не меняет состояния. Как в итоге массив окажется странсформированным?
Re[29]: Кстати
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.09 04:35
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Не к реляционным, а к спискам. Просто спискам. Просто таблицы в РСБУД — это тоже списки кортежей. Вот и все.

VD>Все что может быть представлено в виде списка может быть обработано линком.

А LINQ работает с деревом?
Если да — from obj in tree select obj.name — вернёт дерево имён или просто список?
Re[22]: Для увеличения лаконичности еще var использовать
От: Undying Россия  
Дата: 25.11.09 05:50
Оценка:
Здравствуйте, IT, Вы писали:

IT>В данном случае простота напрямую зависит от уровня подготовки. Не секрет, что один и тот же код для одного человека может быть простым, а для другого сложным. Это как раз тот самый случай. Вот тут
Автор: IT
Дата: 22.09.08
я давал пример одного и того же алгоритма на Linq и в императивном стиле. Разница очевидна. ФП привносит в код декларативность, а значит простоту и гибкость. Но всё это требует определённой подготовки.


Ежели сильно нужна лаконичность, то можно все переменные на var заменить, хотя читабельность это несколько ухудшит (за исключением использования var при создании Dictionary).
Re[31]: Кстати
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.09 07:39
Оценка:
Здравствуйте, samius, Вы писали:

L>>Если да — from obj in tree select obj.name — вернёт дерево имён или просто список?

S>И да и нет. Ответ зависит от наличия соответствующей реализации Query expression pattern-а. В дотнете идет реализация этого паттерна для всех типов, которые реализуют IEnumerable<T>. Но ничто не мешает обеспечить собственную реализацию для ITree<T>. Тогда from obj in tree select obj.name вытащит имена из дерева объектов и вернет дерево имен.

Странно, я предполагал, что типы функций у LINQ такие:

public static M<B> SelectMany<M, A, B>(this M<A> m, Func<A, M<B>> k)


А он получается может что угодно возвращать?
Re[32]: Кстати
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.11.09 09:55
Оценка:
Здравствуйте, lomeo, Вы писали:

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


L>>>Если да — from obj in tree select obj.name — вернёт дерево имён или просто список?

S>>И да и нет. Ответ зависит от наличия соответствующей реализации Query expression pattern-а. В дотнете идет реализация этого паттерна для всех типов, которые реализуют IEnumerable<T>. Но ничто не мешает обеспечить собственную реализацию для ITree<T>. Тогда from obj in tree select obj.name вытащит имена из дерева объектов и вернет дерево имен.

L>Странно, я предполагал, что типы функций у LINQ такие:


L>
L>public static M<B> SelectMany<M, A, B>(this M<A> m, Func<A, M<B>> k)
L>


L>А он получается может что угодно возвращать?
Re[32]: Кстати
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.11.09 09:57
Оценка:
Здравствуйте, lomeo, Вы писали:


L>Странно, я предполагал, что типы функций у LINQ такие:


L>
L>public static M<B> SelectMany<M, A, B>(this M<A> m, Func<A, M<B>> k)
L>


взял из спецификации:

class C<T>
{
   public C<V> SelectMany<U,V>(Func<T,C<U>> selector,
        Func<T,U,V> resultSelector);
}

или
public C<V> SelectMany<U,V>(this C<T> source, Func<T,C<U>> selector,
        Func<T,U,V> resultSelector);


L>А он получается может что угодно возвращать?


Что угодно C<V> может делать из C<T>.
Re[40]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 25.11.09 10:11
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Функцией-генератором я в данном случае назвал seq( startIdx, endIdx, step ), которая генерирует последовательность индексов начиная со startIdx, не более чем endIdx, с шагом step. В Эрланге этому соответствует именно вызов функции. В Хаскеле/Clean может быть записан как список, что-то вроде [1..n], а при преобразовании comprehensions в циклы — эта штука преобразуется тупо в заголовок цикла for.


L>Тогда непонятно как ты будешь "транформировать массив", если ни одна из перечиленных функций не меняет состояния. Как в итоге массив окажется странсформированным?


Элементарно. Новый массив создается. Старый — не изменяется. Если написать программу на Хаскеле, которая реализует мой алгоритм с компрехеншнсами, то все именно так и будет.

А состояние всей системы для внешнего наблюдателя в чистом языке при этом конечно изменится — но это уже совсем другое "состояние". Это состояние — World, и рассуждения о его изменении лишено практической пользы и смысла. Так как в силу отсутствия мутабельных операций, для внутренних "наблюдателей" состояние меняться не будет. Релятивистские эффекты, пнимаешь. Все относительно.

На философские вопросы о состоянии и прочей терминологии очень хорошо получается отвечать у lomeo здесь рядом. Он — умница, поговори с ним. Все правильно пишет.

Кстати, смысл так понравившейся тебе фразы "человек либо понимает, либо нет", состоит в том, что первично на самом деле желание понять. Если этого желания нет, то объяснять что-либо бесполезно. Человек будет спорить, спорить, спорить... У меня складывается ощущение, что у тебя первичным было желание "объяснить мне, что я неправ". Плохое желание. С таким желанием легко попасть в глупое положение.
Re[40]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 25.11.09 10:23
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Нет, для внешнего наблюдателя каждый раз порождается новое состояние на основе старого. Изменения переменных нет.


1)
x.DoSomething()

x — объект, он имеет состояние. Оно изменилось.

2)
x_1 = DoSomething( x )

x — не изменился. x_1 — новое значение.

Наличие мутабельных операций и операции присваивания связывают не только с "прозрачностью по ссылкам", но оно так же тесно связано с наличием у объектов identity.

В случае (1) у тебя есть "идентити" у объекта х — например, ссылка или указатель. И именно потому, что у объекта есть состояние. Ты вызвал DoSomething. Состояние этого объекта, с идентити &x, изменилось. Но это тот же самый объект.

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

Теперь рассмотрим (2). Объекты в такой системе не имеют "идентити", оно им просто не нужно. Они имеют только значения, которые могут меняться. Значения могут быть равны, или не равны. Никаких "объектов", имеющих идентити и состояние, при отсутствии мутабельного состояния и присваивания нет. Как в математике — нет там ни присваивания, ни состояний.

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

Это фундаментальный принцип, который иллюстрирует саму суть "чистоты".
Re[41]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 25.11.09 10:26
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Тогда непонятно как ты будешь "транформировать массив", если ни одна из перечиленных функций не меняет состояния. Как в итоге массив окажется странсформированным?


G>Элементарно. Новый массив создается. Старый — не изменяется. Если написать программу на Хаскеле, которая реализует мой алгоритм с компрехеншнсами, то все именно так и будет.


Теперь понятно. Но согласись, несколько странно говорить, что состояние — мутабельное, когда оно на самом деле не меняется.

G>Кстати, смысл так понравившейся тебе фразы "человек либо понимает, либо нет", состоит в том, что первично на самом деле желание понять. Если этого желания нет, то объяснять что-либо бесполезно. Человек будет спорить, спорить, спорить... У меня складывается ощущение, что у тебя первичным было желание "объяснить мне, что я неправ". Плохое желание. С таким желанием легко попасть в глупое положение.


Очень самокритично.
Re[41]: Правка
От: Gaperton http://gaperton.livejournal.com
Дата: 25.11.09 10:29
Оценка:
G>Теперь рассмотрим (2). Объекты в такой системе не имеют "идентити", оно им просто не нужно. Они имеют только значения, которые не могут меняться. Значения могут быть равны, или не равны. Но объекты неотличимы друг от друга. Никаких "объектов", имеющих идентити и состояние, при отсутствии мутабельного состояния и присваивания нет. Как в математике — нет там ни присваивания, ни состояний.
Re[29]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 10:32
Оценка:
Здравствуйте, IT, Вы писали:

ГВ>>Как это вяжется с тем, что Linq, мол, предназначен для любых источников данных? Получается, что только для тех, которые сводятся к РСУБД-like.

IT>Ты можешь дать определение РСУБД-like типам данных? Гапертон не смог.

В данном случае ключевой признак — отсутствие связей внутри отношения. Остальное — см. теорию РСУБД.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[42]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 25.11.09 10:37
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Кстати, смысл так понравившейся тебе фразы "человек либо понимает, либо нет", состоит в том, что первично на самом деле желание понять. Если этого желания нет, то объяснять что-либо бесполезно. Человек будет спорить, спорить, спорить... У меня складывается ощущение, что у тебя первичным было желание "объяснить мне, что я неправ". Плохое желание. С таким желанием легко попасть в глупое положение.


L>Очень самокритично.


Самокритично это было бы, если бы я говорил о себе. А я просто разъясняю тебе смысл фразы. И кроме того, ко мне это при всем желании отнести тяжело — у меня нет навязчивого желания кому-либо доказывать, что он неправ, "истины ради". Это вы у нас пережить не можете, если чье-то мнение с вашим не совпадает.
Re[43]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 25.11.09 10:52
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Очень самокритично.


G>Самокритично это было бы, если бы я говорил о себе. А я просто разъясняю тебе смысл фразы. И кроме того, ко мне это при всем желании отнести тяжело — у меня нет навязчивого желания кому-либо доказывать, что он неправ, "истины ради". Это вы у нас пережить не можете, если чье-то мнение с вашим не совпадает.


Вы очень тонкий психолог. Вот так, по паре десятков постов, точно поставить диагноз, это вызывает уважение. Браво, маэстро. Снимаю шляпу.
Re[41]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 25.11.09 11:09
Оценка:
Здравствуйте, lomeo, Вы писали:

L>>>Глобальная переменная const — неизменяемая. Состояние или нет? Если да, то состояние — это что угодно, если нет, то под глобальным состоянием следует понимать именно изменяемое состояние. Как то так.

L>>Состояние, конечно.

L>Хорошо. У нас есть состояние — все привязки в нашей программе, например, связи фунции с их именами. Какие рассуждения можно вести в терминах понятия "состояние" о программе, учитывая, что оно, а следовательно и поведение программы, неизменно? Какие рассуждения можно получить из понятия "Вселенная" в физике, а не в философии? Т.е. какие полезные рассуждения могут быть проведены?


К чему все это? Если вы согласились, что это состояние, то обсуждение закончено, т.к. тем самым опровергнуто, что из наличия состояния автоматически следует мутабельность. Это собственно и смутило меня в рассуждениях Gaperton-а.
Или я все-таки опять чего-то недопонимаю?
Re[30]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 13:50
Оценка:
Здравствуйте, lomeo, Вы писали:

L>А LINQ работает с деревом?


Любое дерево можно представить в виде вложенных списков дочерних элементов. По этому ответ и да, и нет.
Прямых средств работы с деревьями в линке нет. Но с тем же ХМЛ-ем получается работать без пробелем, хотя он и есть чистой воды деревом.

L>Если да — from obj in tree select obj.name — вернёт дерево имён или просто список?


Вернет просто списко. Но такой код особого смысла не имеет. Скорее всего будет что-то вроде:
var nodes = from node in tree.Elements() where node.Name.StartsWith("prefix") select node;

И тогда в nodes будет часть дерева, которую можно снова обработать.
Если, скажем, поместить подобный запрос в рекурсивную функцию, то можно организовать и рекурсивную обработку дерева.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Кстати
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.09 14:47
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Если да — from obj in tree select obj.name — вернёт дерево имён или просто список?

VD>Вернет просто списко. Но такой код особого смысла не имеет.

Скажем, есть некая иерархия, начальник-подчинённые. Я хочу получить точно такое же дерево, как и исходное, но не с самими персонами, а с их именами. Так не работает текущая реализация, верно?

VD>Скорее всего будет что-то вроде:

VD>
VD>var nodes = from node in tree.Elements() where node.Name.StartsWith("prefix") select node;
VD>

VD>И тогда в nodes будет часть дерева, которую можно снова обработать.

Т.е. Elements возвращяет элементы верхнего уровня? И проверка работает только над ними?
Re[32]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 15:24
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Скажем, есть некая иерархия, начальник-подчинённые. Я хочу получить точно такое же дерево, как и исходное, но не с самими персонами, а с их именами. Так не работает текущая реализация, верно?


Не верно. И я уже сказал почему.

L>Т.е. Elements возвращяет элементы верхнего уровня? И проверка работает только над ними?


Нужны другие уровни, используй:
from node in tree.Elements()
from subnode in node.Elements()
...

Нужна рекурсия пиши рекурсивную функцию обрабатывающую один уровень.

Встречный вопрос. В Хаскеле ты бы справился с обработкой дерева?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 16:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Повторяю еще раз свою мысль. Надеюсь, что последний.


VD>В основе LINQ лежит библиотека работы со списками Haskell (Haskell prelude). Идея обобщения источников данных была предложена Меером еще в Хаскеле. Меер заметил, что все операции над БД можно выразить в терминах Haskell prelude. В результате Меер создал ДСЛ-библиотеку который в рантайме переписывал код выраженный в виде функций высшего порядка в аналогичный ему SQL.


Допустим, но что это меняет? Не думаешь же ты, надеюсь, что раз Haskell, то сразу малиновые штаны? Да и вообще, вопрос не в том, кто что породил (прям Библия, не меньше), а зачем это было нужно.

VD>Позже он перешел на работу в Microsoft и разработал библиотеку аналогичную Haskell prelude, а так же идею Expression tree смысл которой заключается в том, чтобы заставить компилятор генерировать не исполняемый код, а AST которое можно будет анализировать в рантайме. Именно это позволило использовать линк для доступа к внешним серверам вроде SQL-серверов. Но это нисколичко не означает, что нельзя обращаться к другим серверам данные которых можно представить в виде списков.


Хм. Может, я чего-то не понимаю, но по-моему, всё, что ты тут сказал прямо доказывает, что LINQ предназначен в первую очередь для работы с SQL-серверами. Зачем иначе огород городить с ExpressionTrees?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[32]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 16:46
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>В основе LINQ лежит библиотека работы со списками Haskell (Haskell prelude). Идея обобщения источников данных была предложена Меером еще в Хаскеле. Меер заметил, что все операции над БД можно выразить в терминах Haskell prelude. В результате Меер создал ДСЛ-библиотеку который в рантайме переписывал код выраженный в виде функций высшего порядка в аналогичный ему SQL.


ГВ>Допустим, но что это меняет?


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

ГВ>Не думаешь же ты, надеюсь, что раз Haskell, то сразу малиновые штаны?


Нет.

ГВ>Да и вообще, вопрос не в том, кто что породил (прям Библия, не меньше), а зачем это было нужно.


Вопрос бы один и он был очень прост. Является ли ЛИНК средством рассчитанным исключительно (или в основном) на работу с РСУБД или нет. Ответ на этот вопрос лично для меня очевиден — нет.

ГВ>Хм. Может, я чего-то не понимаю, но по-моему, всё, что ты тут сказал прямо доказывает, что LINQ предназначен в первую очередь для работы с SQL-серверами.


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

Подумай на досуге является ли то, что деревья качаются при ветре доказательством того, что они созданы для создания ветра?

Такая же фигня и с линком. Следствием его универсальности является возможность в том числе обрабатывать из хранимые в СУБД. Из факта "ЛИНК позволяет работать с данными из РСУБД" ни как не следует, что линк "предназначен в первую очередь для работы с SQL-серверами".

ГВ>Зачем иначе огород городить с ExpressionTrees?


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

Если придерживаться твоей извращенной "логики" (в кавычках так как этот по сути алогизм), то можно заключить что ЛИНК, в первую очередь, предназначен для распределения вычислений по разным серверам, так как он позволяет это делать и есть люди которые этим пользуются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 17:33
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Странно, я предполагал, что типы функций у LINQ такие:


L>
L>public static M<B> SelectMany<M, A, B>(this M<A> m, Func<A, M<B>> k)
L>


L>А он получается может что угодно возвращать?


Зачем что-то предполагать?
Скачай спецификацию C# 3.0.
Там в разделе "26.7.2 The query expression pattern" дано описание на чем основан паттерн. А в разделе "26.7 Query expressions" то как синтаксис переписывается в этот паттерн.

Ну, и надо так же понимать, что ЛИНК — это торговая марка под которой нет четкого определения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 17:37
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Ты можешь дать определение РСУБД-like типам данных? Гапертон не смог.


ГВ>В данном случае ключевой признак — отсутствие связей внутри отношения. Остальное — см. теорию РСУБД.


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

Кстати, фраза "отсутствие связей внутри отношения" звучит как белиберда.

Про теорию "РСУБД" тоже очень интересно было бы послушать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Кстати
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.11.09 17:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Скачай спецификацию C# 3.0.

Конкретно эта спецификация 2005-го года.
Лучше брать отсюда
Re[34]: Кстати
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.11.09 18:26
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Y>>А что дальше делать с полученным AST — это уже дело провайдера. Напрмер, реализовать LINQ to LLBLGen, LINQ to Twitter, LINQ to Google,...


ГВ>Правильно. Это есть вполне нормальное следствие обобщения изначально узконаправленного средства.


Это тоже?
Re[15]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 19:21
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>1. Можно ли с помощью линк обрабатывать коллекции в памяти.


ГВ>Да.


VD>>2. Можно ли с помощью линка обрабатывать ХМЛ.


ГВ>Да.


VD>>3. Есть ли в ЛИНК-е что-то что может быть применимо толко для РСУБД и не применимо для других источников данных?


ГВ>Я таких не припомню, во всяком случае.


Значит ответ тоже "да".

ГВ>Хотя LINQ и получен обобщением проблем взаимодействия с РСУБД.


Никто не спрашивал как получен линк. Так что это позволю себе проигнорировать эту фантазию. В прочем, с удовольствием послушаю логически корректное доказательство этой гипотезы.

VD>>4. Упрощает ли ЛИНК обрабтку списков объектов по сравнению с другими средствами их обработки доступными в шарпе и васике?


ГВ>По сравнению с какими?


А что в Шарпе есть какие-то средства отличные от циклов?

ГВ>Но. См. ответ на следующий вопрос.


VD>>4. Можно ли называть технологию более удобную для обработки объектов в памяти нежели для работы с СУБД "большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД"?


ГВ>Вопрос поставлен некорректно. Как понимать "более удобную для обработки объектов в памяти нежели для работы с СУБД"? Критерии сравнения "более менее" каковы?


Это вопрос к Гапертону. Это его цитата которую ты так ревностно защищаешь.

ГВ>Вот ещё пара встречных вопросов:


Я просил ответить на мои вопросы.

В прочем полученных ответов уже достаточно чтобы сделать вывод о том, что утверждения Гапертона ложны. А ЛИНК как ни странно является универсальным средством обработки данных.
Что и следовало доказать.

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

ГВ>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?


Как-то так (Nemerle, так как писать на нем приятнее):
using System.Collections.Generic;
using System.Console;
using System.Linq;

def lst = [1, 2, 3, 7, 8, 9, 10];

def (_, _, res) = lst.Aggregate((0, true, List()), ((prev, skip, res), cur) =>
  if      (skip)            (cur, false, res)
  else if (prev + 1 == cur) (cur,  true, { res.Add(cur); res })
  else                      (cur, false, res));

WriteLine($"..$res");


Объясняю преимущества перед использованием циклов.
1. Отсутствуют специальные случае вроде пустого массива которые можно забыть проверить.
2. Отсутствует работа с индексами, так что ошибка не приведет к генерации исключений в непротестированных случаях.
3. Решение задачи близко к ее постановке. Мы описывает, что хотим получить, а не то как мы это хотим получить. Нам не нужно думать о переборе значений, мы думаем только об алгоритме.

Проблема только одна. Чтобы прочесть и понят данный код нужно иметь некоторый опыт использования ФВП и абстрагирования алгоритма от его реализации.

ГВ>2) Тот же массив, но нужно извлечь элементы, отстоящие на +/-1 от выбранного. Т.е. результат — {1, 3, 7, 9}.


Не понял саму постановку задачи.

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

ГВ>Как ты понимаешь, традиционным for обе задачи решаются тривиально.


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

Так что ты еще не понял, и что ты пыташся доказать?
Или ты все же давно все понял и просто троллишь специально не желая мыслить логически?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Кстати
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.09 19:36
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Скажем, есть некая иерархия, начальник-подчинённые. Я хочу получить точно такое же дерево, как и исходное, но не с самими персонами, а с их именами. Так не работает текущая реализация, верно?

VD>Не верно. И я уже сказал почему.

Я уже запутался Не верно — т.е. текущая реализация так работает что ли? Ты же сам пишешь, что функция нерекурсивная. Или "не верно" относится к чему-то другому?

VD>Встречный вопрос. В Хаскеле ты бы справился с обработкой дерева?


Конечно! Это же обычный map. Только для деревьев. Вот код:

query = fmap name


В общем я почитал (спасибо за ссылки). LINQ ограничивает результат конкретным типом (IEnumerable/IQueryable). В этом смысле Select ни разу ни функтор. Вернее, зависит от реализации.

В Haskell Select — это fmap (эндофунктор, отображение), поэтому его тип

public static F<B> Select<F,A,B>(Function<A,B> f, F<A> struc)


Для дерева результат — это дерево, для функции — функция, для любого другого типа данных, являющегося функтором — соответствующее отображение.
Re[34]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 20:03
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Нами??? По-моему, ты первый взвился. Я ошибаюсь?


Что значит "взвился". Если ты не заметил. Я вообще отвалил от этого глупого спора.

ГВ>А нафиг всё же впёрся LINQ, если функциональный стиль и так поддерживается C# 3.0?


Ты кажется любишь пообсуждать что от чего было пораждено. Так вот C# 3.0 такой какой он есть в основном благодаря LINQ.
Возможности для программирования в функциональном стиле были и в 2.0. Но удобным это стало только в 3.0, так как:
А. Язык расширели выводом типов, локаничными лямбдами и деревьями выражений.
Б. Появилась библиотека ФВП входящая в LINQ. Без нее программировать в функциональном стиле невозможно. Конечно можно было бы написать свою, но рядовой программист это не понятнул бы. Появилось бы море разных реализацию не совместимых между собой (смотрим на С++). LINQ же предоставляет отлично реализованную библиотеку максимально полно покрывающую обще потребности. И получилось все так неплохо потому что делали LINQ под контролем очень хороших функциональщиков которые в отличие от многих крикунов с нашего сайта понимают не букву ФП, а его суть.

ГВ>Неужели бродилку по IEnumerable<> (к которой ты хочешь свести назначение LINQ) так сложно написать, что из-за неё стоит заморачиваться с введением аж модификаций в синтаксис C#?


Представь себе не просто. Как и написание любой библиотеки данная задача требует системного подхода, анализа, немалых знаний и опыта. У автора LINQ-а все это было, так как он чуть ли не является соавтором хаскеля.

ГВ>Угу-угу, кто б советовал...


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

VD>>Подумай на досуге является ли то, что деревья качаются при ветре доказательством того, что они созданы для создания ветра?


ГВ>Осталось задаться вопросом, что считать ветром, а что — деревьями.


Ну, пошла полная софистика.

ГВ>Ты, судя по всему, считаешь ветром лозунг "ФП — в массы" и ещё какую-то квази-альтруистическую риторику, я — что "надо состыковаться с SQL-сервером". Чей ветер стабильнее?


Я не намерен отвечать на очередную попытку увести обсуждение черт знает куда.

VD>>Такая же фигня и с линком. Следствием его универсальности является возможность в том числе обрабатывать из хранимые в СУБД. Из факта "ЛИНК позволяет работать с данными из РСУБД" ни как не следует, что линк "предназначен в первую очередь для работы с SQL-серверами".


ГВ>Вот теперь иди и покупай учебник по логике сам. Факт единственно лишь того, что LINQ работает с РСУБД не рассматривался в качестве достаточного для выводов основания ни мной, ни, полагаю, Гапертоном.


Да, ну? А что же за "факты" ты использовал?
И можно поинтересоваться, ты серьезно считаешь, что если факт ничего не говорящий о проблеме соединить с другими, то он начнет хоть как-то относиться к проблеме или влиять на общий вывод?

VD>>Очевидно для того, чтобы можно было в рантайме проанализировать ЛИНК-запрос и что-то сделать на его основе. Частным случаем этого "что-то" является переписывание запроса в SQL и выполнение его некоторым сервером. Опять же ничто не говорит в пользу гипотезы "LINQ предназначен в первую очередь для работы с SQL-серверами".


ГВ>А вот теперь подумай — на кой шут городить огород с генерацией/анализом AST, если у нас единая среда исполнения? Чтобы дать юзерам "визуальные языки"? Ещё какая-нибудь абстрактная идея света в массы?


А мне не надо об этом думать. Информация о том что явилось причиной для разработки универсального механизма никак не влияет на факт его использования.

Использовать деревья выражений можно как угодно. Их можно трансформировать в рантайме и скомпилировать. На этом принципе, в не малой степени реализован тип dinamic в C# 4.0. Их можно использовать для генерации запросов к ООБД которая никогда не пользовалась реляционными принципами. Их можно вообще не использовать. Например, LINQ to Objects и LINQ to XML вообще их не использут, но при этом позволяют как использовать ФВП входящие в состав LINQ-а, так и синтаксические расширения языков.

VD>>Если придерживаться твоей извращенной "логики" (в кавычках так как этот по сути алогизм), то можно заключить что ЛИНК, в первую очередь, предназначен для распределения вычислений по разным серверам, так как он позволяет это делать и есть люди которые этим пользуются.


ГВ>С LINQ-ом вообще всё не слишком понятно обстоит — его, похоже, будут набивать фичами, которые больше некуда воткнуть.


Это не понятно только с твоей колокольни. Если перестать думать о LINQ-е как о каком-то ESQL-е переростке, то все станет сразу очевидным. LINQ не набивают фичами. Наоборот на его основе делают необходимые в конкретных предметных областых расширения.

Пойми. Все очень просто. Линк — это абстрагирование от паттернов кодирования. Абстрагирование от них делает код более декларативным. А декларативный код можно интерпретировать по разному. Его вычисление можно организовать по разному. Можно распараллеливание (как в PLINQ), можно превратить код в дерево выражений в рантайме передать некоему провайдеру который сделает с ним то что нужно провайдеру (передаст на выполнение на другую машину или сформирует SQL и выполнит его в СУБД).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Кстати
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.11.09 20:06
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Конечно! Это же обычный map. Только для деревьев. Вот код:


L>
L>query = fmap name
L>


L>В общем я почитал (спасибо за ссылки). LINQ ограничивает результат конкретным типом (IEnumerable/IQueryable). В этом смысле Select ни разу ни функтор. Вернее, зависит от реализации.


Разве fmap не зависит от реализации?


L>В Haskell Select — это fmap (эндофунктор, отображение), поэтому его тип


L>
L>public static F<B> Select<F,A,B>(Function<A,B> f, F<A> struc)
L>


L>Для дерева результат — это дерево, для функции — функция, для любого другого типа данных, являющегося функтором — соответствующее отображение.


С Select-ом все точно так же. Просто штатных реализаций всего 2 — IEnumerable/IQueryable.
Re[34]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 20:13
Оценка:
Здравствуйте, lomeo, Вы писали:


L>Конечно! Это же обычный map. Только для деревьев. Вот код:


L>
L>query = fmap name
L>


А без fmap не справился бы?

L>В общем я почитал (спасибо за ссылки). LINQ ограничивает результат конкретным типом (IEnumerable/IQueryable). В этом смысле Select ни разу ни функтор. Вернее, зависит от реализации.


Там все несколько сложнее. Есть конкретные реализации завязанные на IEnumerable/IQueryable, а есть "query expression pattern" который абстрагирован от конкретики:
delegate R Func<T1,R>(T1 arg1);
delegate R Func<T1,T2,R>(T1 arg1, T2 arg2);
class C
{
  public C<T> Cast<T>();
}
class C<T> : C
{
  public C<T> Where(Func<T,bool> predicate);
  public C<U> Select<U>(Func<T,U> selector);
  public C<V> SelectMany<U,V>(Func<T,C<U>> selector, Func<T,U,V> resultSelector);
  public C<V> Join<U,K,V>(C<U> inner, Func<T,K> outerKeySelector, Func<U,K> innerKeySelector, Func<T,U,V> resultSelector);
  public C<V> GroupJoin<U,K,V>(C<U> inner, Func<T,K> outerKeySelector, Func<U,K> innerKeySelector, Func<T,C<U>,V> resultSelector);
  public O<T> OrderBy<K>(Func<T,K> keySelector);
  public O<T> OrderByDescending<K>(Func<T,K> keySelector);
  public C<G<K,T>> GroupBy<K>(Func<T,K> keySelector);
  public C<G<K,E>> GroupBy<K,E>(Func<T,K> keySelector, Func<T,E> elementSelector);
}
class O<T> : C<T>
{
  public O<T> ThenBy<K>(Func<T,K> keySelector);
  public O<T> ThenByDescending<K>(Func<T,K> keySelector);
}
class G<K,T> : C<T>
{
  public K Key { get; }
}


Ты где-то видишь здесь IEnumerable/IQueryable?

L>В Haskell Select — это fmap (эндофунктор, отображение), поэтому его тип


L>
L>public static F<B> Select<F,A,B>(Function<A,B> f, F<A> struc)
L>


fmap написан на хаскеле или это какая-то "магическая" функция предоставляемая системой?
Думаю, второе.

Потенциально конечно можно реализовать query expression pattern через рефлексию и ты получишь полный аналог fmap за исключением ограничений безопасности. Но оно надо, такое решение?

L>Для дерева результат — это дерево, для функции — функция, для любого другого типа данных, являющегося функтором — соответствующее отображение.


В хаскеле много чего нет. Например, нет инкапсуляции и безопасности на ее основе. В общем, язык другой.
Я же тебе хотел сказать о другом. В хаскеле вполне можно работат с деревьями без fmap. Более того скорее всего для реальной прикладной задачи ты как раз не будешь использовать fmap. Ты или напишешь рекурсивную функцию, или будешь работать с деревом используя знания о его структуре. Вот та же фигня и в линке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 20:13
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Смотри сюда
Автор: Геннадий Васильев
Дата: 21.11.09
и дальше по ветке. Вторую задачу я "снял с соревнований" — слишком неясная формулировка оказалась.

По остальным пунктам позже отвечу.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[35]: Кстати
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.11.09 20:19
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В хаскеле много чего нет. Например, нет инкапсуляции и безопасности на ее основе. В общем, язык другой.

Другой, но инкапсуляция все же есть. Это как если бы в C# все поля были открыты, но инкапсуляция бы обеспечивалась только тем, что у клиентского кода есть только интерфейс сущности и нет знаний о типе, его реализующем. У хаскеля роль интерфейсов играют классы типов. Чем не инкапсуляция?
Re[35]: Кстати
От: Курилка Россия http://kirya.narod.ru/
Дата: 25.11.09 20:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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


L>>В Haskell Select — это fmap (эндофунктор, отображение), поэтому его тип


L>>
L>>public static F<B> Select<F,A,B>(Function<A,B> f, F<A> struc)
L>>


VD>fmap написан на хаскеле или это какая-то "магическая" функция предоставляемая системой?

VD>Думаю, второе.

См. Functor, ничего магического
Re[39]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 25.11.09 20:55
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Насчёт состояние == мутабельность, это, конечно, не совсем так, но обычно, когда говорят "состояние" подразумевают именно изменяемое состояние.


Gaperton, куда ж ты слился-то. Ты же так активно отстаивал, что состояние == мутабльность. А теперь так резко замолчал.
Re[43]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 25.11.09 21:00
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Поэтому давай не будем лить воду из пустого в порожнее.


Да я не против.
Просто ваш коллега настолько рьяно настаивал, что состояние — это неизменно мутабельность, что я начал сомневаться в здравом смысле. Но, судя по тому, что он не только не стал вам возражать, но и плюсует ваши посты, можно сделать вывод, что мы просто друг друга не до конца поняли.
Re[17]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 21:16
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Смотри сюда
Автор: Геннадий Васильев
Дата: 21.11.09
и дальше по ветке. Вторую задачу я "снял с соревнований" — слишком неясная формулировка оказалась.


В приведенном сообщении полной реализации нет. Смотреть тонных вложенных сообщений нет никакого желания. Так что жду полного примера здесь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 21:16
Оценка:
Здравствуйте, VladD2, Вы писали:

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


ГВ>>Нами??? По-моему, ты первый взвился. Я ошибаюсь?


VD>Что значит "взвился". Если ты не заметил. Я вообще отвалил от этого глупого спора.


ГВ>>А нафиг всё же впёрся LINQ, если функциональный стиль и так поддерживается C# 3.0?

VD>Ты кажется любишь пообсуждать что от чего было пораждено. Так вот C# 3.0 такой какой он есть в основном благодаря LINQ.

Угу. Вполне это допускаю, что ради интеграции LINQ пришлось доработать C#. Значит, -1 аргумент в пользу "благих намерений" MS.

VD>Возможности для программирования в функциональном стиле были и в 2.0. Но удобным это стало только в 3.0, так как:

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

Угу-угу. Отображать структуру IL-кода прайвеси не позволяет, могут не понять. Потому пришлось городить дополнительный огород с отображаемыми выражениями. Между прочим, это самый простой и естественный способ построения развитого ORM даже средствами C++. Уж поверь мне на слово.

VD>Б. Появилась библиотека ФВП входящая в LINQ. Без нее программировать в функциональном стиле невозможно. Конечно можно было бы написать свою, но рядовой программист это не понятнул бы. Появилось бы море разных реализацию не совместимых между собой (смотрим на С++). LINQ же предоставляет отлично реализованную библиотеку максимально полно покрывающую обще потребности. И получилось все так неплохо потому что делали LINQ под контролем очень хороших функциональщиков которые в отличие от многих крикунов с нашего сайта понимают не букву ФП, а его суть.


Ёлки зелёные. Это никак не отражается на том назначении LINQ, которое (на мой взгляд) просвечивает у него через все дырки.

ГВ>>Неужели бродилку по IEnumerable<> (к которой ты хочешь свести назначение LINQ) так сложно написать, что из-за неё стоит заморачиваться с введением аж модификаций в синтаксис C#?

VD>Представь себе не просто. Как и написание любой библиотеки данная задача требует системного подхода, анализа, немалых знаний и опыта. У автора LINQ-а все это было, так как он чуть ли не является соавтором хаскеля.

Ну, и я прекрасно понимаю автора. Под соусом адаптации к SQL построить довольно интересную штуковину. И ни на йоту оного автора не осуждаю. Я бы тоже так поступил на его месте. Тем более, что ФП-фичи и в самом деле довольно полезная штука. Как и ОО-фичи, если без излишней голубоглазости ими пользоваться.

ГВ>>Угу-угу, кто б советовал...

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

Давай замнём этот вопрос для ясности. Так оно спокойней.

VD>>>Подумай на досуге является ли то, что деревья качаются при ветре доказательством того, что они созданы для создания ветра?

ГВ>>Осталось задаться вопросом, что считать ветром, а что — деревьями.
VD>Ну, пошла полная софистика.

Какая ж это софистика? Это сотая попытка прояснить действительные причины супротив вымышленных.

ГВ>>Ты, судя по всему, считаешь ветром лозунг "ФП — в массы" и ещё какую-то квази-альтруистическую риторику, я — что "надо состыковаться с SQL-сервером". Чей ветер стабильнее?

VD>Я не намерен отвечать на очередную попытку увести обсуждение черт знает куда.

Иными словами, тебе плевать на установление действительных причин. Согласен, гораздо проще руководствоваться иллюзиями альтруизма MS.

ГВ>>Вот теперь иди и покупай учебник по логике сам. Факт единственно лишь того, что LINQ работает с РСУБД не рассматривался в качестве достаточного для выводов основания ни мной, ни, полагаю, Гапертоном.

VD>Да, ну? А что же за "факты" ты использовал?
VD>И можно поинтересоваться, ты серьезно считаешь, что если факт ничего не говорящий о проблеме соединить с другими, то он начнет хоть как-то относиться к проблеме или влиять на общий вывод?

Я очень хорошо знаю о проблеме ORM и соответствующих фактах наличия сторонних средств. И очень хорошо знаю, что до LINQ собственных более или менее адекватных средств разрешения этой проблемы у MS не было. Почему я должен скидывать эти два соображения со счетов — сие мне неведомо. Ещё я очень хорошо знаю, что под "источником данных" чаще всего подразумевается РСУБД, такова общая практика. Ещё я могу припомнить кое-что из своей практики, после всего этого, поверь, можно сделать очень много выводов.

ГВ>>А вот теперь подумай — на кой шут городить огород с генерацией/анализом AST, если у нас единая среда исполнения? Чтобы дать юзерам "визуальные языки"? Ещё какая-нибудь абстрактная идея света в массы?

VD>А мне не надо об этом думать. Информация о том что явилось причиной для разработки универсального механизма никак не влияет на факт его использования.

Если тебе не надо об этом думать — никто тебя не заставляет. Просто скажи, что тебе не интересно это обсуждать и выйди из обсуждения. Только какой смысл при этом встревать с опровержениями высказываний других? Ты считаешь LINQ универсальным средством, введённым MS ради заботы о малых сих — нет проблем. А я этого не считаю и поддерживаю разными +-*/ тех, кто высказывается в таком ключе, вот и весь спор. Переубедить меня сможет, вполне вероятно, письмо Билла Гейтса, датированное 2001-м годом, где будет написано: "...we need to implement functional programming for our customers, are you know somebody good in functional languages development?" Если у тебя завалялось такое, то я с удовольствием соглашусь с твоими доводами. Если нет или потёр случайно — ну извини, я продолжаю считать, что первопричиной разработки LINQ явился OR-импеданс. Это просто, понятно и лишено обоснований с привлечением иррациональных соображений.

VD>Использовать деревья выражений можно как угодно. Их можно трансформировать в рантайме и скомпилировать. На этом принципе, в не малой степени реализован тип dinamic в C# 4.0. Их можно использовать для генерации запросов к ООБД которая никогда не пользовалась реляционными принципами. Их можно вообще не использовать. Например, LINQ to Objects и LINQ to XML вообще их не использут, но при этом позволяют как использовать ФВП входящие в состав LINQ-а, так и синтаксические расширения языков.


Для "как угодно" у них довольно узкий набор, хотя вполне достаточный для построения сложных выражений, не буду спорить. Но вот кое-чего в Linq.Expressions нет. Например, нет меток/goto. По странному стечению обстоятельств goto отсутствует и в выражениях SQL-запросов. Кстати, этот факт служит дополнительным аргументом (помимо других) для введения ФП-свойств в любой язык программирования, который предполагается использовать в тесной связи с SQL-серверами.

ГВ>>С LINQ-ом вообще всё не слишком понятно обстоит — его, похоже, будут набивать фичами, которые больше некуда воткнуть.

VD>Это не понятно только с твоей колокольни. Если перестать думать о LINQ-е как о каком-то ESQL-е переростке, то все станет сразу очевидным. LINQ не набивают фичами. Наоборот на его основе делают необходимые в конкретных предметных областых расширения.

Ладно, согласен. Не набивают, а пришивают куда угодно. На основное соображение, оспариваемое без малого двумя сотнями сообщений это никак не влияет.

VD>Пойми. Все очень просто. Линк — это абстрагирование от паттернов кодирования. Абстрагирование от них делает код более декларативным.


Вот за такую постановку задачи бьют канделябром. Исключение составляют совсем юные и синеглазые. Им можно изъясняться подобными оборотами.

VD>А декларативный код можно интерпретировать по разному. Его вычисление можно организовать по разному. Можно распараллеливание (как в PLINQ), можно превратить код в дерево выражений в рантайме передать некоему провайдеру который сделает с ним то что нужно провайдеру (передаст на выполнение на другую машину или сформирует SQL и выполнит его в СУБД).


Ну да-да. "Слоны всем, в ямы никого, Джунгахора!" Ладно, если не вышучивать, то всё это — вполне естественные следствия ФП. Хотя на мой взгляд, подо всё это хозяйство логичнее было бы завести подходящие атрибуты в C#.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 21:19
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Смотри сюда
Автор: Геннадий Васильев
Дата: 21.11.09
и дальше по ветке. Вторую задачу я "снял с соревнований" — слишком неясная формулировка оказалась.

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

Их там две. Ладно, цитирую:

// раз
delegate void F<in T>(T arg);

static void sample1(int[] arr, F<int> func)
{
  for(int i = 1; i < arr.Length; ++i)
  {
    if (arr[i] - arr[i - 1] == 1)
    {
      func(arr[i]);
      ++i;
    }
  }
}

// два
static IEnumerable<int> sample1b(IEnumerable<int> arr)
{
  bool first = true;
  int prev = 0;
  foreach (int i in arr)
  {
    if (first)
    {
      first = false;
      prev = i;
    }
    else if (i - prev == 1)
    {
      yield return i;
      first = true;
    }
    else prev = i;
  }
}


Куда уж полнее-то?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 21:30
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

Да... и желательно решение без создания лишних функций. А то как-то не красиво получается сравнивать оверхэд создаваемый лишними функциями с решением умещающимся на четырех строках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 21:31
Оценка:
Здравствуйте, samius, Вы писали:

VD>>В хаскеле много чего нет. Например, нет инкапсуляции и безопасности на ее основе. В общем, язык другой.

S>Другой, но инкапсуляция все же есть. Это как если бы в C# все поля были открыты, но инкапсуляция бы обеспечивалась только тем, что у клиентского кода есть только интерфейс сущности и нет знаний о типе, его реализующем. У хаскеля роль интерфейсов играют классы типов. Чем не инкапсуляция?

Тем что fmap позволяет ее нарушить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 21:36
Оценка:
Здравствуйте, Курилка, Вы писали:

VD>>fmap написан на хаскеле или это какая-то "магическая" функция предоставляемая системой?

VD>>Думаю, второе.

К>См. Functor, ничего магического


Из этого ответа я ровным счетом ничего не понимаю.
Я не понимаю как универсальная функция может получать возможность перебирать любые структуры дынных и строить их копии ничего не зная о них.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 21:41
Оценка:
Здравствуйте, IT, Вы писали:

ГВ>>В данном случае ключевой признак — отсутствие связей внутри отношения. Остальное — см. теорию РСУБД.

IT>Дай ссылочку на твою теорию, я посмотрю. А то мне не понятно как внутри отношения (слова, которое означает 'связь, зависимость') могут отсутствовать связи.

О! Я специально запасся ссылкой на Главный Источник Мудрости.

Формулировка удивительная, но правильная по сути. Нормальные формы — как раз последовательное исключение функциональных связей.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: LINQ только для РСУБД!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 21:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Да... и желательно решение без создания лишних функций.


Хорошо, перефразирую первый вариант.

VD>А то как-то не красиво получается сравнивать оверхэд создаваемый лишними функциями с решением умещающимся на четырех строках.


namespace MyProgram { class Program {

static void sample1(int[] arr, F<int> func)
{
    for(int i = 1; i < arr.Length; ++i)
    {
        if (arr[i] - arr[i - 1] == 1)
        {
            func(arr[i]);
            ++i;
        }
    }
}

static IEnumerable<int> sample1b(IEnumerable<int> arr)
{
    bool first = true;
    int prev = 0;
    foreach (int i in arr)
    {
        if (first)
        {
            first = false;
            prev = i;
        }
        else if (i - prev == 1)
        {
            yield return i;
            first = true;
        }
        else prev = i;
    }
}

static void Main(string[] args)
{

  int[] arr = { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 };

  foreach (int i in sample1b(arr))
      Console.WriteLine(i);

  sample1(arr, i => Console.WriteLine(i));

  // Cпециально для VladD2
  for (int i = 1; i < arr.Length; ++i)
  {
      if (arr[i] - arr[i - 1] == 1)
      {
          Console.WriteLine(arr[i]);
          ++i;
      }
  }

}

}}


А вот речи об обязательном порождении нового массива в условии задачи не было.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: Блин
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 21:57
Оценка:
Забыл кое-что вставить:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MyProgram { class Program {

delegate void F<in T>(T arg);

static void sample1(int[] arr, F<int> func)
{
    for(int i = 1; i < arr.Length; ++i)
    {
        if (arr[i] - arr[i - 1] == 1)
        {
            func(arr[i]);
            ++i;
        }
    }
}

static IEnumerable<int> sample1b(IEnumerable<int> arr)
{
    bool first = true;
    int prev = 0;
    foreach (int i in arr)
    {
        if (first)
        {
            first = false;
            prev = i;
        }
        else if (i - prev == 1)
        {
            yield return i;
            first = true;
        }
        else prev = i;
    }
}

static void Main(string[] args)
{

  int[] arr = { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 };

  foreach (int i in sample1b(arr))
      Console.WriteLine(i);

  sample1(arr, i => Console.WriteLine(i));

  // Cпециально для VladD2
  for (int i = 1; i < arr.Length; ++i)
  {
      if (arr[i] - arr[i - 1] == 1)
      {
          Console.WriteLine(arr[i]);
          ++i;
      }
  }

}

}}
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[44]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 25.11.09 22:10
Оценка:
Здравствуйте, Lloyd, Вы писали:

G>>Самокритично это было бы, если бы я говорил о себе. А я просто разъясняю тебе смысл фразы. И кроме того, ко мне это при всем желании отнести тяжело — у меня нет навязчивого желания кому-либо доказывать, что он неправ, "истины ради". Это вы у нас пережить не можете, если чье-то мнение с вашим не совпадает.


L>Вы очень тонкий психолог. Вот так, по паре десятков постов, точно поставить диагноз, это вызывает уважение. Браво, маэстро. Снимаю шляпу.


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

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

И есть вторая причина, почему я не оцениваю вашу личность — она мне ни в малейшей степени не интересна. Меня интересует исключительно тема беседы, и то, что вы по поводу темы беседы можете сказать. И все.
Re[36]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 22:21
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Угу. Вполне это допускаю, что ради интеграции LINQ пришлось доработать C#. Значит, -1 аргумент в пользу "благих намерений" MS.


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

Я конечно свечку не держал, но думаю, что одной из уловок Меера было протаскивание ФП под видом черт знает чего.

VD>>Возможности для программирования в функциональном стиле были и в 2.0. Но удобным это стало только в 3.0, так как:

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

ГВ>Угу-угу. Отображать структуру IL-кода прайвеси не позволяет, могут не понять. Потому пришлось городить дополнительный огород с отображаемыми выражениями. Между прочим, это самый простой и естественный способ построения развитого ORM даже средствами C++. Уж поверь мне на слово.


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

ГВ>Ёлки зелёные. Это никак не отражается на том назначении LINQ, которое (на мой взгляд) просвечивает у него через все дырки.


У тебя явно пунктик по поводу назначения. Повторять тебе что-то считаю бессмысленным. Живи в своем вымешленном мире дальше.

ГВ>Ну, и я прекрасно понимаю автора. Под соусом адаптации к SQL построить довольно интересную штуковину.


Кончай повторять бред. Не было там никаких адаптаций. Несколько функций переименовали просто чтобы людям не так страшно было новый мир осваивать. Map переименовали в Select, Filter в Where, Fold в Aggregate, Sort в OrderBy. По сути же как были функции, так и остались.

Или ты думаешь, что Хаскель тоже проектировали под соусом адаптации к SQL?

ГВ>И ни на йоту оного автора не осуждаю. Я бы тоже так поступил на его месте. Тем более, что ФП-фичи и в самом деле довольно полезная штука. Как и ОО-фичи, если без излишней голубоглазости ими пользоваться.


Замечательно что ты это понял. Осталось расстаться с предрассудками которые ты тут пытался насаждать в неокрепшие умы масс.

ГВ>Давай замнём этот вопрос для ясности. Так оно спокойней.


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

ГВ>Иными словами, тебе плевать на установление действительных причин. Согласен, гораздо проще руководствоваться иллюзиями альтруизма MS.


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

К тому же ты уже достал повторять чушь. Тебе сказали, что в Хаскеле может и думали только о СУБД. Но когда разрабатывали ЛИНК, то думали только и исключительно об универсальном решении. Просто средство доступа к данным никто в язык общего назначения не включил бы.

ГВ>>>Вот теперь иди и покупай учебник по логике сам. Факт единственно лишь того, что LINQ работает с РСУБД не рассматривался в качестве достаточного для выводов основания ни мной, ни, полагаю, Гапертоном.

VD>>Да, ну? А что же за "факты" ты использовал?
VD>>И можно поинтересоваться, ты серьезно считаешь, что если факт ничего не говорящий о проблеме соединить с другими, то он начнет хоть как-то относиться к проблеме или влиять на общий вывод?

ГВ>Я очень хорошо знаю о проблеме ORM и соответствующих фактах наличия сторонних средств.


Я тебя не спрашивал что ты знаешь о "проблеме ORM". Я задал конкретный вопрос. Можно отвечать именно на него, а не выдавать мнение на отвлеченные темы?
Я же уже четко продемонстрировал тебе, что отвлекаться на них не буду.

ГВ> И очень хорошо знаю, что до LINQ собственных более или менее адекватных средств разрешения этой проблемы у MS не было. Почему я должен скидывать эти два соображения со счетов — сие мне неведомо.


Потому что они не имеют отношения к делу.

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


Опять же. Никому нет никокого дела до того что и под чем понимают люди и с какой частотой.
LINQ to Object используют чаще чем LINQ to SQL. Но из этого не следует, что LINQ создан толко для обработки данных в памяти.

VD>>А мне не надо об этом думать. Информация о том что явилось причиной для разработки универсального механизма никак не влияет на факт его использования.


ГВ>Если тебе не надо об этом думать — никто тебя не заставляет.


Ну, как же? Ты все время меня пытаешься заставить подумать о разной фигне не относящейся к делу.

ГВ>Просто скажи, что тебе не интересно это обсуждать и выйди из обсуждения.


Ага. Не интересно. Я лучше тебя знаю был задуман и реализован линк.

ГВ> Только какой смысл при этом встревать с опровержениями высказываний других?


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

ГВ> Ты считаешь LINQ универсальным средством, введённым MS ради заботы о малых сих — нет проблем.


Я считаю LINQ универсальным средством и мне по фиг ради чего он введен.
Это факт и его глупо оспаривать.

ГВ> А я этого не считаю и поддерживаю разными +-*/ тех, кто высказывается в таком ключе, вот и весь спор.


Ты не просто поддерживаешь. Ты постоянно нарушаешь принципы логического вывода в своих суждениях.

ГВ> Переубедить меня сможет, вполне вероятно, письмо Билла Гейтса, датированное 2001-м годом, где будет написано: "...we need to implement functional programming for our customers, are you know somebody good in functional languages development?" Если у тебя завалялось такое, то я с удовольствием соглашусь с твоими доводами. Если нет или потёр случайно — ну извини, я продолжаю считать, что первопричиной разработки LINQ явился OR-импеданс. Это просто, понятно и лишено обоснований с привлечением иррациональных соображений.


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

VD>>Использовать деревья выражений можно как угодно. Их можно трансформировать в рантайме и скомпилировать. На этом принципе, в не малой степени реализован тип dinamic в C# 4.0. Их можно использовать для генерации запросов к ООБД которая никогда не пользовалась реляционными принципами. Их можно вообще не использовать. Например, LINQ to Objects и LINQ to XML вообще их не использут, но при этом позволяют как использовать ФВП входящие в состав LINQ-а, так и синтаксические расширения языков.


ГВ>Для "как угодно" у них довольно узкий набор,


Очередное голословное утверждение.

ГВ> хотя вполне достаточный для построения сложных выражений, не буду спорить.


Так и не спорь.

ГВ> Но вот кое-чего в Linq.Expressions нет. Например, нет меток/goto. По странному стечению обстоятельств goto отсутствует и в выражениях SQL-запросов.


В Хаскле и Nemerle тоже нет GOTO. Видимо тут тоже странное стечение обстоятельств.
Их тоже писали под влиянием SQL?

Ты хоть понимаешь каких чудесных выводов можно добиться таким образом?

Кстати, в Яве тоже нет GOTO!

ГВ>Кстати, этот факт служит дополнительным аргументом (помимо других) для введения ФП-свойств в любой язык программирования, который предполагается использовать в тесной связи с SQL-серверами.


Гениально!

А чему служит факт, что современный SQL поддерживает рекурсивные запросы (на базе CTE), а ЛИНК нет?

VD>>Это не понятно только с твоей колокольни. Если перестать думать о LINQ-е как о каком-то ESQL-е переростке, то все станет сразу очевидным. LINQ не набивают фичами. Наоборот на его основе делают необходимые в конкретных предметных областых расширения.


ГВ>Ладно, согласен.


Ого! Прогресс?

ГВ>Не набивают, а пришивают куда угодно. На основное соображение, оспариваемое без малого двумя сотнями сообщений это никак не влияет.


... кажется нет.
Заметь, кстати, две сотни накатали 2 человека. Один уже свалил из спора (похоже).

VD>>Пойми. Все очень просто. Линк — это абстрагирование от паттернов кодирования. Абстрагирование от них делает код более декларативным.


ГВ>Вот за такую постановку задачи бьют канделябром. Исключение составляют совсем юные и синеглазые. Им можно изъясняться подобными оборотами.


Ну, канделябром ни каждому получится вдарить. Ведь нападающему могут этот канделябр и засунуть куда не следует .
А то что ты не понимаешь моих слов говорит только о том, что ты не умеешь глядеть на вещи с разных углов.

VD>>А декларативный код можно интерпретировать по разному. Его вычисление можно организовать по разному. Можно распараллеливание (как в PLINQ), можно превратить код в дерево выражений в рантайме передать некоему провайдеру который сделает с ним то что нужно провайдеру (передаст на выполнение на другую машину или сформирует SQL и выполнит его в СУБД).


ГВ>Ну да-да. "Слоны всем, в ямы никого, Джунгахора!" Ладно, если не вышучивать, то всё это — вполне естественные следствия ФП. Хотя на мой взгляд, подо всё это хозяйство логичнее было бы завести подходящие атрибуты в C#.


Что за атрибуты? Выражайтесь яснее (с)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: LINQ только для РСУБД!
От: Lloyd Россия  
Дата: 25.11.09 22:31
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>>Насчёт состояние == мутабельность, это, конечно, не совсем так, но обычно, когда говорят "состояние" подразумевают именно изменяемое состояние.


L>>Gaperton, куда ж ты слился-то. Ты же так активно отстаивал, что состояние == мутабльность. А теперь так резко замолчал.


G>Ты внимательно почитай, что тебе lomeo пишет. И задумайся как следует, почему именно он не возражает мне, а пытается что-то втолковать тебе. Разъясняя тебе, что именно я имел в виду.


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

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


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

Удачи.
Re[19]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 22:36
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>static void Main(string[] args)
ГВ>{

ГВ>  int[] arr = { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 };

ГВ>  // Cпециально для VladD2
ГВ>  for (int i = 1; i < arr.Length; ++i)
ГВ>  {
ГВ>      if (arr[i] - arr[i - 1] == 1)
ГВ>      {
ГВ>          Console.WriteLine(arr[i]);
ГВ>          ++i;
ГВ>      }
ГВ>  }
ГВ>}


ГВ>А вот речи об обязательном порождении нового массива в условии задачи не было.


Ну, давай добавим.

Так же давай попробуем в твоем решении заменить массив на энумератор.

Надеюсь мы установили, что ЛИНК-ом она тоже решается и не так уж страшно?
Тут проблема то в чем. Пока задачка детская ее конечно по фигу чем решать.
А вот когда задачки наслаиваются друг на друга, когда они становятся не тривиальны, то циклы очень быстро превращаются в одну большую кашу.
Конечно разбивая все на функции можно добиваться приемлемой сложности отдельно взятых фрагментов, но намного удобнее использовать ФВП которые в шарпе предоставляет ЛИНК.

Не веришь?

Давай тогда решим другие задачки. Скажем те что требуют группировки и сортировки данных. А еще лучше требующие комплексой их обработки в соответствии с некоторыми условиями.

Ты ведь еще не знаешь, что линк позволяет делать условные запросы динамически?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 22:36
Оценка:
Здравствуйте, samius, Вы писали:

S>fmap — это не универсальная функция, а декларация о наличии конкретной функции для конкретных типов данных.


Тогда она в данном разговоре не в кассу. Ведь к любому типу можно прикрутить интерфейс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Кстати
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.09 22:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Там все несколько сложнее. Есть конкретные реализации завязанные на IEnumerable/IQueryable, а есть "query expression pattern" который абстрагирован от конкретики:

VD>Ты где-то видишь здесь IEnumerable/IQueryable?

VD>fmap написан на хаскеле или это какая-то "магическая" функция предоставляемая системой?

VD>Думаю, второе.

Первое. По аналогии с LINQ для своего типа мы реализуем её по своему.

data Tree a = Node [Tree a] -- дерево - это нода со списком деревьев.

instance Functor Tree where
    fmap f (Node xs) = fmap (fmap f) xs


VD>Потенциально конечно можно реализовать query expression pattern через рефлексию и ты получишь полный аналог fmap за исключением ограничений безопасности. Но оно надо, такое решение?


Такое тоже есть gmap, но сейчас не об этом.

L>>Для дерева результат — это дерево, для функции — функция, для любого другого типа данных, являющегося функтором — соответствующее отображение.

VD>В хаскеле много чего нет. Например, нет инкапсуляции и безопасности на ее основе. В общем, язык другой.

Инкапсуляция есть. Ограничения на уровне модуля — говорим, что импортируем.

module Test
  (Foo, mkFoo, fromFoo)
where
data Foo = Foo Int
mkFoo = Foo
fromFoo (Foo i) = i


Ты не сможешь залезть в потроха Foo иначе чем через fromFoo, создать Foo сможешь тоже только с помощью функции mkFoo. Иначе говоря, паттерн-матчингом разобрать не сможешь.

VD>Я же тебе хотел сказать о другом. В хаскеле вполне можно работат с деревьями без fmap. Более того скорее всего для реальной прикладной задачи ты как раз не будешь использовать fmap. Ты или напишешь рекурсивную функцию, или будешь работать с деревом используя знания о его структуре. Вот та же фигня и в линке.


В Haskell есть даже такое понятие как type class morphism. Для своих типов данных считается хорошим тоном реализовывать инстансы стандартных классов типов. Т.е. если я реализую дерево — то я, скорее всего, напишу для него реализацию Functor/Foldable/Traversable и т.д. Наоборот, если я пользуюсь чьим то типом данных, то я ожидаю, что у него есть соответствующие инстансы, и ожидаю от них соответствующего поведения (потому что это достаточно абстрактные вещи, которые есть у многих многих типов данных — вспомним бананы, линзы, колючую проволоку).

С другой стороны, в Haskell работать с рекурсивными типами данных через рекурсивные функции считается плохим тоном, если есть готовые комбинаторы для соответствующих морфизмов. Обычно они есть.

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

Спасибо, я, кажется, разобрался. Поправь меня — в принципе, ничто не мешает конкретной реализации LINQ возвращать любой тип в Select, например, отличающийся от исходного (без учёта типов-аргументов).
Re[39]: Кстати
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.09 22:46
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>fmap — это не универсальная функция, а декларация о наличии конкретной функции для конкретных типов данных.

VD>Тогда она в данном разговоре не в кассу. Ведь к любому типу можно прикрутить интерфейс.

Я её сравнивал с Select. Его же тоже можно к любому типу прикрутить.
Re[37]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.09 22:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я конечно свечку не держал, но думаю, что одной из уловок Меера было протаскивание ФП под видом черт знает чего.


Удивительное дело, как мы тут с тобой совпадаем.

ГВ>>Угу-угу. Отображать структуру IL-кода прайвеси не позволяет, могут не понять. Потому пришлось городить дополнительный огород с отображаемыми выражениями. Между прочим, это самый простой и естественный способ построения развитого ORM даже средствами C++. Уж поверь мне на слово.

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

Что тебе не понятно? Что было бы куда прикольней, если бы MS сделала прямое отображение IL на SQL-Server?

ГВ>>Ну, и я прекрасно понимаю автора. Под соусом адаптации к SQL построить довольно интересную штуковину.

VD>Кончай повторять бред.

Хм. Читаем цитату в начале этого постинга... Тут случится дзен, почти обещаю.

VD>Не было там никаких адаптаций. Несколько функций переименовали просто чтобы людям не так страшно было новый мир осваивать. Map переименовали в Select, Filter в Where, Fold в Aggregate, Sort в OrderBy. По сути же как были функции, так и остались.

VD>Или ты думаешь, что Хаскель тоже проектировали под соусом адаптации к SQL?

Нет, разумеется.

ГВ>>И ни на йоту оного автора не осуждаю. Я бы тоже так поступил на его месте. Тем более, что ФП-фичи и в самом деле довольно полезная штука. Как и ОО-фичи, если без излишней голубоглазости ими пользоваться.

VD>Замечательно что ты это понял. Осталось расстаться с предрассудками которые ты тут пытался насаждать в неокрепшие умы масс.

Да... 36-й уровень вложеннности в дискуссии — самое удачное место для обработки масс, кто бы спорил.

ГВ>>Давай замнём этот вопрос для ясности. Так оно спокойней.

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

Встречная просьба того же порядка.

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


Угу. Как всегда, когда доказать не удаётся, остаётся уговорить.

ГВ>>Иными словами, тебе плевать на установление действительных причин. Согласен, гораздо проще руководствоваться иллюзиями альтруизма MS.


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


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

VD>К тому же ты уже достал повторять чушь. Тебе сказали, что в Хаскеле может и думали только о СУБД. Но когда разрабатывали ЛИНК, то думали только и исключительно об универсальном решении. Просто средство доступа к данным никто в язык общего назначения не включил бы.


Об универсальном решении чего?

ГВ>>>>Вот теперь иди и покупай учебник по логике сам. Факт единственно лишь того, что LINQ работает с РСУБД не рассматривался в качестве достаточного для выводов основания ни мной, ни, полагаю, Гапертоном.

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

Это один из фактов, наводящих на вполне определённые размышления о причинно-следственных связях. Извини за длинную цитату.

ГВ>> И очень хорошо знаю, что до LINQ собственных более или менее адекватных средств разрешения этой проблемы у MS не было. Почему я должен скидывать эти два соображения со счетов — сие мне неведомо.

VD>Потому что они не имеют отношения к делу.

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

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

VD>Опять же. Никому нет никокого дела до того что и под чем понимают люди и с какой частотой.
VD>LINQ to Object используют чаще чем LINQ to SQL. Но из этого не следует, что LINQ создан толко для обработки данных в памяти.

А кто-то это утверждает?

VD>>>А мне не надо об этом думать. Информация о том что явилось причиной для разработки универсального механизма никак не влияет на факт его использования.

ГВ>>Если тебе не надо об этом думать — никто тебя не заставляет.
VD>Ну, как же? Ты все время меня пытаешься заставить подумать о разной фигне не относящейся к делу.

Странно. Обсуждаем, вроде бы, назначение. А факторы, которые в немалой степени определяют это самое назначение, почему-то нужно выбросить из рассмотрения.

ГВ>>Просто скажи, что тебе не интересно это обсуждать и выйди из обсуждения.

VD>Ага. Не интересно. Я лучше тебя знаю был задуман и реализован линк.

Дык. Жду прямых доказательств ошибочности моих суждений.

ГВ>> Только какой смысл при этом встревать с опровержениями высказываний других?

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

Ага. Иными словами — неймётся. Так и запишем.

ГВ>> Ты считаешь LINQ универсальным средством, введённым MS ради заботы о малых сих — нет проблем.

VD>Я считаю LINQ универсальным средством и мне по фиг ради чего он введен.
VD>Это факт и его глупо оспаривать.

Ну пофиг, так пофиг. Я ж не требую от тебя изменить своё мировоззрение.

ГВ>> А я этого не считаю и поддерживаю разными +-*/ тех, кто высказывается в таком ключе, вот и весь спор.

VD>Ты не просто поддерживаешь. Ты постоянно нарушаешь принципы логического вывода в своих суждениях.

Да-да. Например, путём учёта контекста. Ясное дело — грубейшее нарушение принципов логического вывода.

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


Ну, чуть выше ты утверждал, что лучше меня знаешь, как и почему был задуман LINQ. Так я жду рассказа. Желательно, с указанием причин событий, а не: "...и тут он решил, что было бы здорово...". Сначала расскажи о том, почему "он" получил право решать что-то.

VD>>>Использовать деревья выражений можно как угодно.[...]

ГВ>>Для "как угодно" у них довольно узкий набор,
VD>Очередное голословное утверждение.

Хм. Прочесть два предложения следом — не дозволяет религия?

ГВ>> хотя вполне достаточный для построения сложных выражений, не буду спорить.

VD>Так и не спорь.

С этим и не спорю.

ГВ>> Но вот кое-чего в Linq.Expressions нет. Например, нет меток/goto. По странному стечению обстоятельств goto отсутствует и в выражениях SQL-запросов.

VD>В Хаскле и Nemerle тоже нет GOTO. Видимо тут тоже странное стечение обстоятельств.
VD>Их тоже писали под влиянием SQL?

Нет. Одно с другим не связано. Я просто отметил странное совпадение. А ещё goto — имманентная составляющая циклов.

VD>Ты хоть понимаешь каких чудесных выводов можно добиться таким образом?

VD>Кстати, в Яве тоже нет GOTO!

Зато в Яве есть for/while. Вот незадача.

ГВ>>Кстати, этот факт служит дополнительным аргументом (помимо других) для введения ФП-свойств в любой язык программирования, который предполагается использовать в тесной связи с SQL-серверами.

VD>Гениально!
VD>А чему служит факт, что современный SQL поддерживает рекурсивные запросы (на базе CTE), а ЛИНК нет?

Вероятно, подтверждению моего высказывания о том, что возможности SQL Server всё ещё шире LINQ. Было тут где-то оно...

VD>>>Это не понятно только с твоей колокольни. Если перестать думать о LINQ-е как о каком-то ESQL-е переростке, то все станет сразу очевидным. LINQ не набивают фичами. Наоборот на его основе делают необходимые в конкретных предметных областых расширения.

ГВ>>Ладно, согласен.
VD>Ого! Прогресс?

А ты думал?!

ГВ>>Не набивают, а пришивают куда угодно. На основное соображение, оспариваемое без малого двумя сотнями сообщений это никак не влияет.

VD>... кажется нет.
VD>Заметь, кстати, две сотни накатали 2 человека. Один уже свалил из спора (похоже).

Без паники. Зато я остался. Приключения продолжаются.

VD>>>Пойми. Все очень просто. Линк — это абстрагирование от паттернов кодирования. Абстрагирование от них делает код более декларативным.

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

Дык. Тут такой угол, что всем углам — щель.

VD>>>А декларативный код можно интерпретировать по разному. Его вычисление можно организовать по разному. Можно распараллеливание (как в PLINQ), можно превратить код в дерево выражений в рантайме передать некоему провайдеру который сделает с ним то что нужно провайдеру (передаст на выполнение на другую машину или сформирует SQL и выполнит его в СУБД).

ГВ>>Ну да-да. "Слоны всем, в ямы никого, Джунгахора!" Ладно, если не вышучивать, то всё это — вполне естественные следствия ФП. Хотя на мой взгляд, подо всё это хозяйство логичнее было бы завести подходящие атрибуты в C#.
VD>Что за атрибуты? Выражайтесь яснее (с)

Я тебе должен рассказать, что такое атрибуты в C#? Хм. VladD2 расспрашивает ГВ про C#? Ради этого момента стоило поспорить!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[36]: Кстати
От: Gaperton http://gaperton.livejournal.com
Дата: 25.11.09 22:59
Оценка:
Здравствуйте, samius, Вы писали:

VD>>В хаскеле много чего нет. Например, нет инкапсуляции и безопасности на ее основе. В общем, язык другой.

S>Другой, но инкапсуляция все же есть. Это как если бы в C# все поля были открыты, но инкапсуляция бы обеспечивалась только тем, что у клиентского кода есть только интерфейс сущности и нет знаний о типе, его реализующем. У хаскеля роль интерфейсов играют классы типов. Чем не инкапсуляция?

Не то, чтоб я спорил, просто хочу уточнить. Наиболее корректный смысл "инкапсуляции" в том виде, в котором она употребляется в ООП (инкапсуляция, наследование, полиморфизм) — это обычно ADT (Abstract Data Type) + mutable state. То есть, мы взяли мутабельный стейт, но не дали доступа к его структуре, вместо этого выставили интерфейс из функций. Капитан очевидность на связи, и готов сообщить, что такая штука называется "объект".

Таких штук в Хаскеле, насколько я понимаю, нет. В Хаскеле есть просто ATD. Это не плохо, и не хорошо. Это нормально. Просто "инкапсуляция" хреновый и замыленный термин, понимаемый всеми по своему (прям как "архитектор" и "архитектура"), которого лучше избегать, чтобы избежать неоднозначности в беседе и достичь понимания.
Re[36]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 23:00
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Ты не сможешь залезть в потроха Foo иначе чем через fromFoo, создать Foo сможешь тоже только с помощью функции mkFoo. Иначе говоря, паттерн-матчингом разобрать не сможешь.


А как же gmap?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 23:02
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>В защиту хаскеля: классы типов гораздо круче интерфейсов.


Они не круче. У каждого свои преимущества и недостатки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 23:03
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Я её сравнивал с Select. Его же тоже можно к любому типу прикрутить.


Если рассуждать так, то конечно. Только прикручивать будешь ты сам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Кстати
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.09 23:11
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Ты не сможешь залезть в потроха Foo иначе чем через fromFoo, создать Foo сможешь тоже только с помощью функции mkFoo. Иначе говоря, паттерн-матчингом разобрать не сможешь.

VD>А как же gmap?

Ты про использование? Там тоже должен использовать fromFoo

gmap fromFoo


вместо

gmap (Foo i -> i) -- ошибка!
Re[37]: Кстати
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.11.09 23:25
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Таких штук в Хаскеле, насколько я понимаю, нет. :)


К сожалению, есть — IORef/STRef/MVar и прочие ссылки и указатели. Достаточно представить себе ADT, оборачивающий один из этих типов, чтобы увидеть проблему.
Re[17]: LINQ только для РСУБД!
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 23:26
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Тем не менее, спасибо за ответы на мои.


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

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


ГВ>В чьих глазах?


Окружающих. Не думаешь же ты, что все такие идиоты, что не видят очевидных брешей в твоих рассуждениях?

ГВ>Логически здесь как раз следует, что в ряде случаев LINQ — не пришей кобыле хвост.


Ты бы спросил, тебе бы сразу ответили, что LINQ это не панацея.
Я сразу сказал, что линк зачастую позволяет получить намного более компактынй и понятный код. Во многих != во всех.
Примеры тебе приводили.

ГВ> Одна лишь демонстрация крутизны на ровном месте.


Да нет там никакой крутизны. Это инструмент которым нужно уметь пользоваться. Надо быть полным кретином чтобы при наличии линк накручивать многокилометровые циклы и выписывать отдельные методы в тех случаях когда линк позволяет обойтись парой строчек. И надо быть таким же кретином чтобы совать его во все дыры.

Вопрос только в том причем тут РСБУД?

ГВ> Да и честно сказать, даже реализация на Nemerle круто проигрывает банальному циклу в читабельности.


От части — это с непривычки. Я так оба варианта отлично читаю.
Отчасти это потому, что задача действительно на циклах решается без особых потерь.
А отчасти потому, что оторвано от реальности.
В реальности такие выпендрежи бывают крайне редко. А вот просто отфильтровать, отсортировать, сгрупировать, отобрать X элементов пропустив Y элементов — это нужно постоянно.

ГВ>Зато, что любопытно, реализация на Go
Автор: Gaperton
Дата: 22.11.09
по ясности изложения резко обходит всех.


Гы. Красота еще та. Туча бесполезных строк. Спроси у своего друга, на достуге, что будет если в потоке не будет данных. Он ведь так смело из него первый элемент читает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Кстати
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.11.09 23:27
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Ты про использование? Там тоже должен использовать fromFoo


L>
L>gmap fromFoo
L>


Что такое fromFoo?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.09 01:53
Оценка:
Здравствуйте, gandjustas, Вы писали:

Y>>>А что дальше делать с полученным AST — это уже дело провайдера. Напрмер, реализовать LINQ to LLBLGen, LINQ to Twitter, LINQ to Google,...

ГВ>>Правильно. Это есть вполне нормальное следствие обобщения изначально узконаправленного средства.

G>Это тоже?


Угу. Почему бы нет?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: Ах, да
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.09 01:55
Оценка:
Здравствуйте, VladD2, Вы писали:

Таки пропустил один вопрос.

VD>>>4. Упрощает ли ЛИНК обрабтку списков объектов по сравнению с другими средствами их обработки доступными в шарпе и васике?

ГВ>>По сравнению с какими?
VD>А что в Шарпе есть какие-то средства отличные от циклов?

Да, в некоторых случаях — упрощает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[37]: Кстати
От: yuriylsh  
Дата: 26.11.09 02:32
Оценка:
З.Ы. Завтра напишу ему спасибо за ответы, так что есле есть еще вопросы, могу невзначай присовокупить к своему thank you имейлу
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[38]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.09 04:52
Оценка:
Здравствуйте, yuriylsh, Вы писали:

Y>З.Ы. Завтра напишу ему спасибо за ответы, так что есле есть еще вопросы, могу невзначай присовокупить к своему thank you имейлу


Да нет у меня к нему вопросов. Расспрашивать же, почему он оказался именно в Microsoft, думаю, довольно таки бестактно, да и задавать такие вопросы надо не самому Мейеру, а его руководству. Ну просто по банальной житейской логике: о чём будет говорить создатель вещи? О куче предпосылок к её созданию или о том, какое замечательное решение он нашёл?

Не знаю, кому как, но мне многое сказала персональная страница Мейера на Microsoft Research:

Erik Meijer:

He runs the Cloud Programmability Team at Microsoft, where his primary focus has been to remove the impedance mismatch between databases and programming languages.


И вот тут:

In the past few years I have done "legendary work" with the C# and Visual Basic teams on language and type-system support for bridging the worlds of object-oriented (CLR), relational (SQL), and hierarchical (XML) data, and of course first class functions.


Но менеджмент в Microsoft, надо сказать, весьма толковый.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[39]: Кстати
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.11.09 07:15
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>
L>>gmap fromFoo
L>>


VD>Что такое fromFoo?


Я там модуль писал, ты его порезал:

module Test
  (Foo, mkFoo, fromFoo)
where
data Foo = Foo Int
mkFoo = Foo
fromFoo (Foo i) = i


Поскольку fromFoo в модуле, то он имеет доступ к внутренней структуре. Снаружи доступ только через fromFoo.
Re[2]: LINQ только для РСУБД!
От: Alexander Polyakov  
Дата: 26.11.09 17:30
Оценка:
VD>А LINQ — это красиво завернутая (для казуалов) библиотека функций высшего порядка (Select -> map, Where -> Filter, OrderBy -> sort, ...). СУБД тут совершенно не причем.
Так LINQ это не только method syntax, еще же и query syntax прикрутили. Попробуй сджойнить 3-4 таблицы с помощью method syntax. Громоздко, и много лишнего. Это они поправили введением query syntax. В итоге, это уже не просто “библиотека”, а захарткоженные специальные конструкции в языке.

А поскольку список этих захаркоженных методов определялся именно схожестью с SQL-ем, то автор треда отчасти прав. Но, вся забавность ситуации в том, что для РСУБД linq как-то не совсем подходит. Об этом я пишу в соседнем форуме.
Re[38]: Кстати
От: Gaperton http://gaperton.livejournal.com
Дата: 27.11.09 10:22
Оценка:
Здравствуйте, lomeo, Вы писали:

G>>Таких штук в Хаскеле, насколько я понимаю, нет.


L>К сожалению, есть — IORef/STRef/MVar и прочие ссылки и указатели. Достаточно представить себе ADT, оборачивающий один из этих типов, чтобы увидеть проблему.


М-да, пора бы мне уже привыкнуть к тому, что Хаскель может все .
Re: LINQ только для РСУБД!
От: Константин Л.  
Дата: 30.11.09 16:59
Оценка:
Здравствуйте, Gaperton, Вы писали:

[]

Не позорься.

Типичное применение Linq:

var doc = XDocument.Load(xmlReader);
                    return doc.Descendants("mapping")
                        .Select(
                            element =>
                                new { Ext = element.Attribute("extension").Value, MimeType = element.Attribute("mimeType").Value }
                        )
                        .ToDictionary(
                            mapping =>
                                mapping.Ext
                                ,
                            mapping =>
                                mapping.MimeType
                        );
Re[23]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.12.09 23:14
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Вместо подписки на сообщения у нас будут каналы


Observable это не совсем "подписка на сообщения", это continuation monad.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
AVK Blog
Re[29]: LINQ только для РСУБД!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.12.09 23:14
Оценка:
Здравствуйте, IT, Вы писали:

IT>Иерархии обрабатываются рекурсивными алгоритмами. В C# сегодня это либо члены класса, но для этого нужно состояние либо выносить в класс, либо городить огород из длинного списка параметров. Либо эмулировать локальные функции делегатами, вроде этого:


Либо сделать набор итераторов, обходящих дерево наиболее общеупотребимыми способами. А дальше обычный LINQ.
На практике получается вполне употребимо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
AVK Blog
Re[29]: опечатка
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.12.09 23:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>относительно XML...


ГВ>относительно иерархических данных...


Относительно XML в LINQ2XML уже есть набор готовых итераторов по дереву, так что особых проблем с его обработкой не возникает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
AVK Blog
Re[18]: Я всё ж таки вот, о чём думаю
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.12.09 23:30
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Ты совершенно правильно все сделал. Неотъемлемое свойство, и слабое место реляционной модели (превращается в силу в ряде контекстов) — отсутствие в этой модели порядка элементов. Кортежи принципиально неупорядоченны. Точка. И твой, и мои примеры с БД time series это свойство эксплуатируют.


Его пример эксплуатирует не это. Убери из него требование выкидывать уже обработанные элементы, и линк применить станет намного проще.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
AVK Blog
Re[19]: Я всё ж таки вот, о чём думаю
От: Gaperton http://gaperton.livejournal.com
Дата: 20.12.09 17:05
Оценка:
Здравствуйте, AndrewVK, Вы писали:

G>>Ты совершенно правильно все сделал. Неотъемлемое свойство, и слабое место реляционной модели (превращается в силу в ряде контекстов) — отсутствие в этой модели порядка элементов. Кортежи принципиально неупорядоченны. Точка. И твой, и мои примеры с БД time series это свойство эксплуатируют.


AVK>Его пример эксплуатирует не это. Убери из него требование выкидывать уже обработанные элементы, и линк применить станет намного проще.


Его пример эксплуатирует именно это. Если ты, как ты предлагаешь, уберешь требование выкидывать уже обработанные элементы, то ты уберешь из алгоритма завязку на порядок элементов, и именно по этой причине (естественно) применять линк станет намного проще. А не почему-нибудь еще.
Re[24]: LINQ только для РСУБД!
От: Gaperton http://gaperton.livejournal.com
Дата: 20.12.09 17:05
Оценка:
Здравствуйте, AndrewVK, Вы писали:

G>>Вместо подписки на сообщения у нас будут каналы


AVK>Observable это не совсем "подписка на сообщения", это continuation monad.


Вау.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.