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

Да для того же, для чего и в остальных языках


(с) Wiki

Добавлено через 1 минуту и 3 секунды
diadiavova, по поводу примеров можно глянуть как работает List.Find с использованием лямбд...

То есть?

Что это и как с ним работать мне ясно. Мне не ясно зачем. Насчёт остальных языков - тоже не уверен. В функциональных языках они имеют явно бОльшее значение.
Кроме того, статью в википедии я читал, мне не понятен практический аспект их использования в конкретных языках. Что выиграли эти языки от появления ламбда выражений?

Добавлено через 4 минуты и 14 секунд

А без лябд он не работает?

diadiavova, лямбды, я думаю, таки пришли в ООП как раз из функциональных ЯП...
ну вот есть класс List....а теперь посмотрите как можно кастомизировать метод Find с использованием лямбд...

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

Тогда - до завтра

Добавлено через 6 минут и 42 секунды

В этом нет сомнений.

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

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

Чета у меня цитирование в хроме не работает :(

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




Лямбда ничего нового не добавляют! Это самое главное. Это фича языка С# - но не MSIL - значит принципиально ничего нового вы не получите, ведь шарп компилица в мсил. Это для удобности, быстроты набора и читабельности. Вот к примеру верхний кусок кода можно написать и так:

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

Добавлено @ 01:31
Лямбда плохи когда нужно сделать какое-то особо сложное условие. Но такие вещи достаточно редки. А в более простых случаях - это идеал. Но даж не это главное. Как по мне, так лямбда выражения очень хорошо сочитаються с другими фичами 3.5 шарпа. Их всех очень много и они все-все созданы для линка 
Особенно мне нравяться анонимные класы:

Сильно упрощают жизнь при разработке (ток не переборщить  )


Это сообщение отредактировал(а) archeg - 2.11.2008, 01:32

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

Я не пишу на C#, но в VB.Net это тоже есть. А то, что какой-то элемент отсутствует в мсил ещё не говорит о том, что он ничего нового не даёт. Удобство - тоже полезная штука, только вот не ясно в чём оно в конкретном случае. Если мне надо выделить в единый блок каку-то логику - я создаю метод. Здесь же у меня есть возможность описать только одно выражение с ограниченными функциями. 

Новое - имееться ввиду функциональность, а не удобство. Удобство - понятно. Но мсил то один и тот же  Знач ф-и новой нет.
Выделить в оддельную ф-ю? Ок. Пример из практики... Недавно писал прогу (я ее не дописал, поэтому не покажу  ) - должна работать с специфичными данными (их не много по количетсову, но много разных типов  ), кроме того она должна легко переноситься. По-скольку скорость не особо важна, данных не больше мегабайта - выбран формат хмл, для хранения. 
Но самого разнообразия даных очень много, хмл файлов до 10 планировалось. Все это парсить сложно - выбрал XmlToLinq для парса (парсить домом - самоубийство).
Если бы я создавал для каждого условия в коде, оддельный метод, у меня бы появилось больше 100 левых, никому не нужных методов. Все условия простые (для парсинга ничего и не нужно более) - в основном это строка равняеться чему-то. Можно было бы попробовать сбить такие методы, но левая сторона условия строго типизирована - даже не представляю как такое бы выглядело. Какие-то дженерики? Я бы повесился......
Писать такое - самоубийство, поддерживать - еще хуже...

Это сообщение отредактировал(а) archeg - 2.11.2008, 01:44

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

На самом-то деле, компилятор шарпа (и вб) behind the scenes создает этот метод за вас. Просто это скрываецться)

Щас подумаю... ):

Добавлено через 5 минут и 38 секунд

Вот кусочек кода. Насчитал тут 7 л.в. Тут правда в основном используеться не для отсева, а для создания новых екземпляров, но по-моему - довольно показово.
Объяснить что тут делается или и так понятно?

Это сообщение отредактировал(а) archeg - 2.11.2008, 01:48

Кстати насчёт линков, анонимных типов и прочих прелестей вопросов нет. А в VB.Net ещё и XML-литералы имеются 

Добавлено через 6 минут и 15 секунд
Попробую разобраться, хоть и не силён в шарпе, но пока не надо. Не пойму - переспрошу.

В данном случае конечно всё выглядит убедительно, но мне всё-таки этот пример представляется немного искусственным. Здесь в одном выражении многократно вызываются методы, требующие делегатов в качестве аргументов, при этом условия всякий раз формулируются компактно, и использовать в таких ситуациях ламбда-выражения удобно, потомучто это лучше, чем создавать много коротких функций. На практике либо вызовы таких методов как Select, Were и пр. не часты, либо передаваемые им методы в одном выражении не сформулируешь. 
Кроме того XML - вообще не очень убедительный пример из-за обилия инструментов для работы с ним. 

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


Это сообщение отредактировал(а) diadiavova - 2.11.2008, 04:04

Никак не искуственно, вытянул кусок кода из проекта про который я говорил. Возьму за пример линк:
1) LinqToXML. При разборе хмл, возникают условия зачастую проверки имени (просто строка == строке), особенно если хмл используеться как конфиг файл. Про изобилие тулсами для анализа хмл - первый раз слышу, всегда думал что до линка все разработчики мучаились через дом. Может что и есть, но не настолько удобное как линк. 
2) LinqToSQL. Полностью забыл про него. Тут специфика немного другая, постараюсь рассказать более подробно:
CLR при анализе линк-запроса, должен его превратить в запрос вида SQL. То есть если напишем вот такое:

CLR преобразует это в:


Допустим в Where понадобилось вставить более сложное условие. Вставить условие, которое состоит из ендов и оров - без проблем. И выглядить красиво (если отформатировать  )

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

Получим - да, нам пришлось отказаться от лямбда выражений. Посмотрим SQL запрос. Мы там увидим:

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

P.S. На самом то деле, лямбда выражения полностью заменяют анонимные делегаты (это они и есть). И в них можно написать что захочешь. К примеру:

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

Добавлено через 2 минуты и 15 секунд
Идеалогия в том что если нельзя условие сформулировать в одном выражении - то гарантия что LinqToSql не сможет его правильно транслировать - оно слишком сложное.

Ну про линк я не спорю, только через дом обработка не такая мучительная. Например для того, чтобы отобрать узлы, удовлетворяющие определённому условию, достаточно просто вызвать метод System.Xml.XmlNode.SelectNodes. Единственная проблема написать условие отбора на XPath. Да и простой рекурсивный обход узлов зачастую выглядит куда более понятно, чем такие пространные выражения как в предыдущем примере.


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

Всем спасибо. Вопрос закрываю.

Это сообщение отредактировал(а) diadiavova - 2.11.2008, 14:59

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

Это сообщение отредактировал(а) Jamon - 7.11.2008, 20:55