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

EC>А что, здесь где-то ссылочная прозрачность нарушается или есть какие-то вещи противоречащие чистому ФП?

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

EC>SELECT * FROM mytable это тоже императивщина?

Нет. Никакого явного описания последовательности действий здесь нет.

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

EC>>Это можно сделать только, если ты сознательно действуешь в обход системы типов языка. Случайно это сделать она не позволит.
S>Да ладно!
S>Из-за отсутствия стандарта бинарной совместимости, компоненты вынуждены общаться между собой при помощи даункастов.
S>Стандартнейшая штука "выполнить данный метод в GUI-потоке" обрабатывается через передачу адреса в виде целых полей плоской структуры оконного сообшения Windows.
Вышеописанное и есть действие в обход системы типов.
Только я не понимаю почему ты это называешь даункастом. Где там иерархия наследования?

EC>>Не припомню, чтобы как-то акцентировали внимание на строготипизированности ссылок в .NET.
S>Акцентируют, и еще как. Type-safety в дотнете вообще рассматривается с позиции именно строготипизированности любых ссылок. Просто конкретный пример обсуждал именно pointer to method.
В контексте безопасности с этим трудно не согласиться, но с позиций системы типов делегаты не более типизированны, чем всё остальное.
Но замечение хорошее — теперь вопросов больше нет.

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

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

S>>Кажись eao197 подумал, что я тоже пытаюсь покритиковать Влада и наставил мне плюсов. Аж 21.

E>Пруфлинк по поводу плюсов в студию. 21 -- это оценка "Интересно", но не "Согласен".

Ёпть, что тут за крышесносящая система рейтингов. Проще надо, ближе к народу Ушёл в аут... заочно приношу извинения eao. Ну думал, что моно собирать по плюсику с ответа, а можно одним махом — аж 21. Карма треснет.

Влад! У нас тут по ходу целое несовпадение мировоззрений, посему продолжение быстро перерастёт в разборки

Чтобу не тратить время.
а) Во многом с вами согласен.
б) Очень не люблю когда критикуют людей, которые хоть что-то делают за то, чего они не сделали. Особенно не изучая перед этим матчасть. Лично к вам не относится.
в) Не люблю подход "да будет шмагия!". Лично к вам не относится.

Офтоп про декларативыность linq:

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

Проблема с Linq2Objects в том, что _пока_ оно реализовано только для перебираемых последовательностей. Это некритично, пока стоимость запроса линейна, а объём невелик. Если у нас жойн, получаем O(n*m). Причём для любого, кто долго работал с SQL это абсолютно неинтуитивно, потому как он привык к оптимизатору, который достаточно умён, чтобы использовать индексы (если они есть) и сократить до O(max(n,m)) в идеальном и O(m*log(n)) в худшем случае.

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

Сам по себе LINQ не тру декларативен. Декларативность подразумевает произвольную реализацию алгоритма в зависимости от ситуации. С некоторой натяжкой можно обозвать декларативным сам язык — эдакий DSL вокруг набора методов. Вы ж не будете обзывать декларативным это:

new StringBuilder.Append("A").Append("B");

А вот это — декларативный код?

new int[] {1,2,3}.Where(i=>i>2).Select(i=>"#" + i.ToString());

А вот это — уже похоже, да?

from i in new int[] {1,2,3} where i>2 select "#" + i.ToString());

Так вот, если понимать, что DSL в третьем шарпе лишь синтаксический сахар, что предикаты для LINQ2Objects будут выполняться именно в том порядке, как вы их зададите, и что вам по-прежнему нужно уделять внимание внутренней логике запроса, то язык не повернётся называть linq чисто декларативным. Да, идеи кое-какие позаимствованы, но внутри — императивщина-императивщиной.

В принципе, о декларативных запросах к графам — неважно, объектным, XML, иерархическим БД — писал ещё Дейт начиная с 8 издания. Точной цитаты не приведу — книги на руках нет, быстрый поиск не помог, но суть там была такая, что из-за захардкоденной структуры возможность произвольного доступа невелика, различных путей выполнения не так уж и много, а использование этих путей в запросах в принципе лишает смысла использование оптимизатора. Посему те же XQuery/XSLT так и пребудут императивными во веки веков до скончания оных

VD>Нет в природе никаких анонимных делегатов. Если кто-то так называет анонимные методы, то он просто ошибается.

Может ты скушал не ту пилюлю, нео?

Не всё так просто. Если посмотреть что происходит в реальности:

Если замыканий нет — компилятор создаёт приватный метод и приватную переменную — делегат, которую инициализирует при первом выполнении метода. Так что в каком-то смысле анонимный делегат существует.

В случае с замыканиями всё чуть сложнее — для хранения переменных создаётся отдельный private класс (эдакий carrying-wrapper) и в нём же паблик метод в котором живёт код анонимного метода. Здесь закешировать делегат нельзя, посему приватной переменной-делегата нет и анонимного делегата не существует.

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

S>>Почему без шапки?!!
VD>Что? Что значит "шапка"?

Несмешной армейский анекдот. Не обращайте внимания.

VD>Ты сам-то внимательно прочем то, что написано в приведенной статье? Если отбросить громкие заявления о высокой производительности и поглядеть описание процесса вызова, то становится отчетливо видно, что вызов дико не оптимален. Перед ним делается масса проверок которые снижают производительность. Решение без ошибок дизайна привело бы к одному виртуальному вызову который в общем-то и виртуальным можно назвать с натяжкой, так как конкретные реализации могли бы быть sealed. В итоге во многих случаях JIT мог бы после устранения виртуальности устранять и сам вызов встраивая его по месту.

Читаем http://blogs.msdn.com/zifengh/archive/2008/01/21/from-c-to-clr-jitted-code-call-delegate.aspx. Не запутайтесь — там подряд идёт создание и вызов делегата. JIT работает так, как вы и хотели. Если можем предложить более оптимальный вариант — предлагаем. Нет — не холиварим или учим матчасть.

VD>Я не понял зачем мне что-то доказывать. Делегаты и так не совместимы по сигнатуре между собой. А принципиально это было сделано или по недомыслию лично мне все равно.

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

S>>Дальше.
S>>

S>>Именно так обычно пишет код 90% императивных программистов. Причем чем больше нужно выполнить действий над элементами списка, тем больше и сложнее становится тело цикла (а так же его пролог и эпилог). Не мудрено, что в большинстве случаев такой код превращается в кашу.

S>>Я шо-то не понимаю, вы привлекаете народ, объясняя что он — недоразвитое быдло? Тактичней надо, мяхше.
S>>Да, "быдло" обычно использует StringBuilder. Не знаю прям почему...

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

Придётся править. Реально вопринимается как наезд. Или предвзятость. Ибо "90% императивных программистов" пишет код аккуратней. Да! Я себя к императивщикам не отношу. Вообще ни к кому не отношу. Не люблю таскаться

VD>В прочем, данное замечание отлично демонстриует мышление императивного программиста. Даже освоив приемы ФП ты рассуждаешь не о том что делает код, а о том как он это делает. Особенностью ФП как раз является то, что он описывает "что", а не "как". А вопрос "как" перекладывается на реализацию библиотеки. И чем более высокоуровневая функция используется тем больше простора для оптимизаций у создателя этой функции.

Свою точку зрения разжёвал выше. Почему "вопрос "как" перекладывается на реализацию библиотеки" — особенность ФП? Это принципиально невозможно в императивных языках?

S>>И объясняя, что здесь нет чёрной магии, а только все те же методы и делегаты, вы привлечёте куда больше императивщиков.

VD>Объяснять как это реализовано на низком уровне бессмысленно! Это ничего не даст людям для понимакния того как это использовать и как извлечь из этого выгоды.

Я ж говорю — несовпадение мировоззрений. Не будем.


S>>P.P.S. Кто хочет посмеяться — Почему "делегаты" отстой. Версия Сан. (чесслово — они первые взяли делегаты в кавычки). Судя по упоминанию JDK 1.1 и J++ — статья 2001-2002 гг.

VD>Кстати, к вопросу о происхождении делегатов. Отсюда явно видно, что МС предлагал делегаты в первую очередь как базу для реализации событий.

Ну, если для вас маркетинг-отдел Сана достоверней Рихтера... Не могу найти точной цитаты, но делегаты как каллбэки в рантайме были заложены ещё до событий и собсно фреймворка — ещё когда было только "common object runtime". Отсюда и делегат/мультикаст делегат. Одно для калбэков, другое для событий. Потом пришло осознание, что в принципе сценарии пересекаются и вполне себе оптимизируются в рантайме. Но было уже поздно(с). Принципиально нет ограничений для кастинга делегатов по сигнатуре. Оно просто не реализовано. Если у вас есть идеи, какими должны быть делегаты — озвучьте

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

S>Проблема с Linq2Objects в том, что _пока_ оно реализовано только для перебираемых последовательностей. Это некритично, пока стоимость запроса линейна, а объём невелик. Если у нас жойн, получаем O(n*m). Причём для любого, кто долго работал с SQL это абсолютно неинтуитивно, потому как он привык к оптимизатору, который достаточно умён, чтобы использовать индексы (если они есть) и сократить до O(max(n,m)) в идеальном и O(m*log(n)) в худшем случае.

Хитрость в том, что перейти от Linq2objects к чему-нибудь более интересному можно лёгким манием руки. Именно благодаря тому, что запросы заданы таки в декларативной форме, а то, о чем ты рассказываешь — всего лишь одна из возможных ее интерпретаций. На досуге ознакомься с http://www.codeplex.com/i4o .

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

S>Проблема с Linq2Objects в том, что _пока_ оно реализовано только для перебираемых последовательностей. Это некритично, пока стоимость запроса линейна, а объём невелик. Если у нас жойн, получаем O(n*m).

Это не так. Если условие будет в where, то да, получим O(n*m) и определённые тормоза. А если использовать join, то работает на порядок быстрее. Подробностей не знаю, выводы сделаны исключительно основываясь на практике применения linq с большими объёмами данных. Впрочем, можно предположить, что для where никуда не денешься, приходится сравнивать каждую запись с каждой, а в случае join строиться словарь.

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

S>Так вот, если понимать, что DSL в третьем шарпе лишь синтаксический сахар, что предикаты для LINQ2Objects будут выполняться именно в том порядке, как вы их зададите, и что вам по-прежнему нужно уделять внимание внутренней логике запроса, то язык не повернётся называть linq чисто декларативным. Да, идеи кое-какие позаимствованы, но внутри — императивщина-императивщиной.

Рефлектором я смотрел давненько, но тем не менее в пямяти у меня осталось обратное, вроде ExpressionTree там таки переписывается.

E>Прямо во введении:

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

-- снобизм и попытка закосить под элитарность.

Вот выделенное шрифтом — это VladD2 написал? Да?

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

IT>Это не так. Если условие будет в where, то да, получим O(n*m) и определённые тормоза. А если использовать join, то работает на порядок быстрее. Подробностей не знаю, выводы сделаны исключительно основываясь на практике применения linq с большими объёмами данных. Впрочем, можно предположить, что для where никуда не денешься, приходится сравнивать каждую запись с каждой, а в случае join строиться словарь.

Совершенно верно. Join и GroupJoin используют System.Linq.Lookup<key, value>

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

E>>Прямо во введении:

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

-- снобизм и попытка закосить под элитарность.

T>Вот выделенное шрифтом — это VladD2 написал? Да?

Да.

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

S>Проблема с Linq2Objects в том, что _пока_ оно реализовано только для перебираемых последовательностей. Это некритично, пока стоимость запроса линейна, а объём невелик. Если у нас жойн, получаем O(n*m). Причём для любого, кто долго работал с SQL это абсолютно неинтуитивно, потому как он привык к оптимизатору, который достаточно умён, чтобы использовать индексы (если они есть) и сократить до O(max(n,m)) в идеальном и O(m*log(n)) в худшем случае.

Ну для меня лично, для объектов в памяти, это не критично. А вот в Linq2SQL как раз, где критично, за дело берется оптимизатор.

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

E>>Прямо во введении:

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

-- снобизм и попытка закосить под элитарность.

T>Вот выделенное шрифтом — это VladD2 написал? Да?

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

Мона я сразу скопом всем отвечу?

Абсолютно согласен с самой идеей Linq, мне очень нравится, как там работает всё вместе — делегаты, итераторы и ExpressionTrees. То что linq работает как dsl для запросов к различным провайдерам — это вообще одна из главных киллфич. Та же идея насчёт индексов давно витала в воздухе, стоило упомянуть — Sinclair привёл ссылку. Спасибо, не знал, что есть реализации.

По ходу у нас обычная путаница в терминологии. Если под linq понимать только сам dsl/представление в expression trees — то он декларативен, тут спорить не о чем.

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

IT, я микротестами совсем давно занимался, де-то в сентябре 2007-го. И тогда у меня жойн и where работали примерно одинаково. Linq к большим массивам — заинтересовался после какой-то маркетинговой статьи про революционную мощь декларативного мегаязыка и ничего не стоящие запросы из коробки. Может поменяли чего?

-------
Чуть офтопа (спрашиваю больше из интереса, до парсинга expression trees ешё не дошёл):
Может кто подскажет, как определяется тип ExpressionNode? только по имени extension-метода? Потому как у того же Linq2Entities или у Linq2DataSet свои extension methods. Или это дело QueryProvider'a — ему скармливается структура запроса с полными именами методов, а тот уже рзбирается что/где/куда?

Просто чую я скрытую попу с возможным перекрытием этих самых ExtensionMethods...

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

K>Совершенно верно. Join и GroupJoin используют System.Linq.Lookup<key, value>

Ага, спасибо. Не знал.

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

S>По ходу у нас обычная путаница в терминологии. Если под linq понимать только сам dsl/представление в expression trees — то он декларативен, тут спорить не о чем.

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

Вообще-то, имхо, имеет смысл только первое. Потому, что если смотреть совсем уж педантично, то мы в любом случае собираемся исполнять программу на совершенно определенной архитектуре, которая 100% императивна в худшем смысле этого слова.

Вся декларативность — в том, что конкретный способ исполнения выбирает именно фреймворк, а не программист.

Далее, не вполне понятно, что такое "чудовищно страшный мегагитлеримперативный код". Вот, к примеру, как ты думаешь, что мы увидим, вскрыв дебаггером MS SQL Server во время работы? Скорее всего, в окрестностях EIP там будет такой код, по сравнению с которым исходники Link2objects покажутся детской песенкой.
Ну и что в том плохого? Этот код был выбран оптимизатором запросов, с учетом большого объема информации, и порвать его по производительности, соблюдая все ограничения, затруднительно.

Так что это нормальная для декларативных языков практика. Более того, я приветствую наличие "суперстрашного" кода в конвеере исполнения — в том смысле, что как правило его устрашнения связаны с оптимизацией. К примеру, в исходных кодах goto и copy/paste — однозначное зло. А во время исполнения это здорово — они превращаются в shortcut evaluation и inlining.

E>>>

...уж совсем немногие действительно разобрались...

T>>Вот выделенное шрифтом — это VladD2 написал? Да?
Y>Да. С моей колокольни кажется, что он очень хорошо разобрался и что самое важное, без всяких перекосов в какую-либо из сторон. Не то, что некоторые, не будем показывать пальцами

Если палец указует на меня, то я открещусь — я не разбирался, и даже не пытался. Я просто использую Хаскель, по прямым моим обязанностям вот уже пятый год, а так — с конца 1998 года.

Это даёт мне время присмотреться, например, к зависимым типам данных. Которые в Хаскеле появились года три назад и в урезанном виде (GADT). И которые в C# если и появятся, то года через три-четыре.

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

Гм... может у нас просто взаимонедоперенепонимание?

Я никаким обраом не собираюсь агитировать против или за LINQ. Просто сказал, что надо быть аккуратнее и привёл примеры, когда надо понимать что ты пишешь, ибо декларативное описание может тебя обмануть. С одним даже почти угадал — жойн работает быстрее чем предикат в where. Вот и всё.

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

S>Вообще-то, имхо, имеет смысл только первое. Потому, что если смотреть совсем уж педантично, то мы в любом случае собираемся исполнять программу на совершенно определенной архитектуре, которая 100% императивна в худшем смысле этого слова.

Да. Тут наверно всё дело в том, что у меня по дефолту под Linq понимается именно linq2Objects с реализацией через итераторы и т.п.

S>Вся декларативность — в том, что конкретный способ исполнения выбирает именно фреймворк, а не программист.
Угу. именно.

S>Далее, не вполне понятно, что такое "чудовищно страшный мегагитлеримперативный код". Вот, к примеру, как ты думаешь, что мы увидим, вскрыв дебаггером MS SQL Server во время работы? Скорее всего, в окрестностях EIP там будет такой код, по сравнению с которым исходники Link2objects покажутся детской песенкой.
S>Ну и что в том плохого? Этот код был выбран оптимизатором запросов, с учетом большого объема информации, и порвать его по производительности, соблюдая все ограничения, затруднительно.

Угу-угу. Имелось в виду то, что в тру декларативном описании ты не определяешь алгоритм, а только описываешь граничные условия. Проблема только в том, что не всегда очевидно — ты описываешь запрос или пишеь как он будет выполняться. Ну дык внимательно надо.

S>Так что это нормальная для декларативных языков практика. Более того, я приветствую наличие "суперстрашного" кода в конвеере исполнения — в том смысле, что как правило его устрашнения связаны с оптимизацией. К примеру, в исходных кодах goto и copy/paste — однозначное зло. А во время исполнения это здорово — они превращаются в shortcut evaluation и inlining.

Аналогично.

ЗЫ. Может уже закончим переуточнять? По-моему, тема исчерпана.

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

S>Гм... может у нас просто взаимонедоперенепонимание?
Есть такое.
S>Я никаким обраом не собираюсь агитировать против или за LINQ. Просто сказал, что надо быть аккуратнее и привёл примеры, когда надо понимать что ты пишешь, ибо декларативное описание может тебя обмануть.
Гм. Продолжаю непонимать:
1. А есть какие-то примеры, когда можно не понимать, что пишешь? В принципе, пока ты не задумываешься о производительности, либо "побочных эффектах" то любая абстракция хороша в том смысле, что ты не обязан разбираться, во что она там унутре выливается. Простой пример: 99% современных программистов имеют весьма отдаленное представление о том, в какие процессорные инструкции превращается их код (сюда входит и значительная доля тех, кто думает, что понимает). Никаких особенных проблем это не вызывает: производительность 90% приложений на рынке вполне достаточна.
2. Каким именно образом декларативное описание может "обмануть"? Вот в соседнем форуме оказалось, что одного товарища всю жизнь обманывал Соломон, обещая корректную алфавитную сортировку для FindFirstFile/FindNextFile на NTFS. И никак этот товарищ не хочет поверить, что никаких обещаний никто ему не делал, что он это додумал самостоятельно, интерпретируя непонятные слова неверным образом. А теперь испытывает те же эмоции, что и ПТУшница, обнаружив, что её интерпретация вечерних обещаний оказалась далека от авторской.

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

А то, что ты ожидаешь каких-то волшебных performance характеристик — это болезнь молодости. Почитай Хайнлайна по ключевым словам "беспристрастный свидетель":

- какого цвета вон тот дом на холме?
— те две стены, которые я вижу отсюда, светло-голубые.

S>Да. Тут наверно всё дело в том, что у меня по дефолту под Linq понимается именно linq2Objects с реализацией через итераторы и т.п.
Опять же, лучше уточнять. У очень многих людей по дефолту под Linq понимается именно Linq2Sql.

S>Угу-угу. Имелось в виду то, что в тру декларативном описании ты не определяешь алгоритм, а только описываешь граничные условия. Проблема только в том, что не всегда очевидно — ты описываешь запрос или пишеь как он будет выполняться. Ну дык внимательно надо.
А можно мне показать пример описания "как он будет выполняться" в декларативном стиле?

S>ЗЫ. Может уже закончим переуточнять? По-моему, тема исчерпана.
Нет уж, давай порисуем.

S>>В принципе, комбинирование ИП и ДП — достаточно нормальная штука.
EC>Это пожалуй единственный на данный момент реальный варинт применения ДП, если ты пишешь не на Haskell или Clean.

А если на Agda2 или Coq? Не пойдёт?

K>Нет. Мне кажется, вы путааете возможность программировать декларативно и невозможность программировать императивно.

Lambda: the Ultimate Imperative, в конце концов! (правда, исходная статья по ссылке второго рода не доступна, но это, может быть, только мой глюк)