LINQ в Питоне

зойчем оно в питоне? есть же sqlalchemy

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

В GLORP, например, вот уже хз сколько лет обращения к БД как синтаксически, так и семантически ничем не отличаются от работы со стандартными коллекциями - те же сообщения, лямбды, etc. И ничего удивительного, смолтокеры к таким вещам уже привычные.

s/привычные/привыкшие/

а толку то от него? мене вот все виндузятники в один голос из всех его плюсов называют только возможность проверки синтаксиса при составлении запроса. вообще подобное вроде есть в Scala

http://us.pycon.org/2009/conference/schedule/event/70/

LINQ, в той форме в которой оно есть сейчас в C#, не особо эпично - это не более чем сахар над парой функций высших порядков и лямбдами с некоторой оптимизацией. Причём кол-во этиф ФВП там сильно ограничего(map, filter, ну и sort'ы, особо не разбежишься). Оно не стоит того, чтобы фапать именно на сахар LINQ.

Не просто сахар над ФВП. Это сахар для монад.

ни насколько не снижает, это просто синт сахар.

> Это сахар для монад.

Нет, это не сахар для монад.

пруф или не было

Докажи обратное.

> ни насколько не снижает, это просто синт сахар.

Можно пруф? Гугл говорит об обратном. Ну или пруф на то, как отражается использование методов расширения на скорость исполнения кода.

http://devhawk.net/2008/07/30/monadic-philosophy-part-2-the-linq-monad/

Сылку не читал, просто первое попавшееся в гугле. Просто у меня есть некое интуитивное понимание что есть монада, и linq мною понимается как монада.

А вообще питониячий list comprehension есть как раз есть способ обработки iterable объектов как монад. Короче тебе нужно написать некие обертки для твоих объектов доступа к бд и обернуть их в iterable, потом сможешь делать над ними LH как над монадами, получится примерно то же, что и linq.

А можешь дать вменяемую ссылку на статью\книгу, где бы описывалось что есть монада, скажем так, с точки зрения паттерна чтоли. А то, я подозреваю, что пишу(на F#) их достаточно много(судя по статье с rsdn), но не до конца понимаю суть этих объектов.

ты работаешь генератором феерического бреда?

Вот вроде норм статья http://www.rsdn.ru/article/funcprog/monad.xml

> Просто у меня есть некое интуитивное понимание что есть монада

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

> Вот вроде норм статья http://www.rsdn.ru/article/funcprog/monad.xml

Читал, но хочется не описания, какие монады бывают, а чёткой классификации, что есть монада, а что нет(что-то типа математического опр.).

Linq транслируется компилятором в обычные вызовы. Как это может отразиться на скорости исполнения кода, если код фактически (после трансформации компилятором) будет один и тот же?

> а чёткой классификации, что есть монада, а что нет

монада - это такая штука, для которой определены две ф-и - bind и return с соответствующими сигнатурами и удовлетворяющими соответствующим аксиомам.

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

А ничего что сами эти вызовы прибиты к стандартным классам расширяющими методами?

по-этому считать монадой можно практически все что угодно.

Бинго. Поэтому питонячий «for ... in ...» можно считать чем-то вроде bind.

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

значит плюсовый оператор << для всяких там потоков тоже можно считать монадой?

Спасибо, стало чуть понятнее. Теперь главное выкристаллизовать понимание оборачивания, ибо, имхо, bind понятен любому, кто делал map.

> А ничего что сами эти вызовы прибиты к стандартным классам расширяющими методами?

Вызовы расширяющих методов в свою очередь заменяются компилятором на вызовы обычных статических методов. Почему они должны быть медленнее?

> Бинго. Поэтому питонячий «for ... in ...» можно считать чем-то вроде bind.

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

> Монада - это абстрактный контейнерный тип для работы с цепочками вычислений.

Не контейнерный. Монада - это тип с кайндом * -> *, другими словами, монада должна в соответствие каждому типу ставить некоторый другой тип. Контейнерные типы ставят в соответствие типу А тип контейнера элементов типа А, но это - лишь частный случай.

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

Делается же полноценный вызов метода, не находишь что для этого нужно поиграться со стеком VM и попередавать параметры в статический метод?

> Монада - это абстрактный контейнерный тип для работы с цепочками вычислений.

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

Я так понимаю оператор << в плюсах на потоках делает некий сайд-эффект, это уже нечто идущее в разрез с ФП, т.к. << не является функцией в математическом понимании.

> Делается же полноценный вызов метода

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

> значит плюсовый оператор << для всяких там потоков тоже можно считать монадой?

Если ввести некоторый тип потока и типизировать все потоки (поток int'оф или поток char'ов) - да.

> Я так понимаю оператор << в плюсах на потоках делает некий сайд-эффект, это уже нечто идущее в разрез с ФП, т.к. << не является функцией в математическом понимании.

Не, >> вполне функционально возвращает _новый_ поток в котором уже будет лежать чего мы туда сунули при помощи этой >>. То есть на самом деле поток тот же, но можно семантически считать, что новый (так делается, например, в Clean).

Гугл говорит об обратном

о каком обратном говорит гугл?

Код с линком при компиляции станет кодом с вызовами статических методов расширения. Насколько медленнее код на линке, чем код, вызывающий статические методы расширения, написанный вручную? Ни на сколько, это один и тот же код. Это и называется «синтаксический сахар».

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

P.S. Анонимус примерно это же обясняет, я так понимаю.

Код с линком при компиляции станет кодом с вызовами статических методов расширения. Насколько медленнее код на линке, чем код, вызывающий статические методы расширения, написанный вручную? Ни на сколько, это один и тот же код. Это и называется «синтаксический сахар».

Да и не говорил я что

var lst1 = (from e in lst
            when e > 2
            select e).ToList();

быстрее

var lst2 = lst.Where(e => e > 2).ToList();

тут всё ест. одинакого.

Я ест. говорил об этом:

Никто не спорит, что ту же функциональность можно реализовать так, чтобы код работал быстрее, в том числе и на C, грамотно оптимизируя программу под особенности конкретного железа.

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

Ладно, думаю непонимание устранено и мусолить дальше эту тему бессмысленно.

п.с. вот например что выдаёт гугл по скорости Linq to Sql: http://blogs.msdn.com/b/adonet/archive/2008/03/27/ado-net-entity-framework-performance-comparison.aspx

Монада — всего лишь моноид из категории эндофункторов, что тут может быть непонятного?

> Монада — всего лишь моноид из категории эндофункторов, что тут может быть непонятного?

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

> Да не, всё понятно, для того, кто знаком с теоркатом, чем я, покачто, похвастаться не могу.

Теоркат в программировании не нужен, не думай, что ты прочитаешь «Categories for working mathematician», и тебе откроется истина. Не откроется. Все дело в том, что в хаскеле просто используются _названия_ из теорката. Но само теоркат там не используется. То есть что-то назвали «монада» и можно сказать, что это что-то удовлетворяет математическому определению монады и... на этом все! То есть никакие свойства монад или связанные с ними теоремы в хаскеле не применяются и, вобщем-то, неприменимы.

> Теоркат в программировании не нужен, не думай, что ты прочитаешь «Categories for working mathematician», и тебе откроется истина. Не откроется....

Ну так я не только программированием занимаюсь;)

Открой википедию по Linq и там внизу есть имплементации для других ЯП. Если дело в конструкторе запросов, то стопиццот ORM фреймворков есть в любом ЯП, а особенно в Java

Другое дело если нужно именно универсальное для коллекция, БД или XML. Тут тяжелее аналоги найти.

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

> Ну так я не только программированием занимаюсь;)

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