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

(146) Память и процессор нынче не ресурс, пора привыкнуть. Для того, чтобы 2+2 посчитать - нужен минимум i9

(139) Лямбды в любом случае нужно отлаживать. А как отладить промежуточные результаты циклов? Никак. Поэтому нужно разбивать на отдельные шаги, а не лепить все в один цикл.

(148) Ты SQL запросы также отлаживаешь?
Еще раз Linq для коллекций это дополнительный бонус. Основное это SQL запросы.
Но если ты привык мыслить циклами, то декларативное программирование не для тебя.

Просто в тему https://m.habr.com/ru/company/typeable/blog/542440/

(149) Мы не про SQL запросы говорим. Если не видишь разницы, то функциональное программирование не для тебя.

(151) почему то мне кажется ты тролль

вот именно что отладка скл запросов это боль

(152) Когда кажется, крестятся.

(151) Самому то не смешно? Мы говорим про Linq. Он имеет SQL подобный синтаксис смотри (133)
вот два одинаковых запроса
первый SQL подобный
Var numQuery1 =
            from num in numbers
            where num % 2 == 0
            orderby num
            select num;
Второй обычный
        //Method syntax:
        var numQuery2 = numbers.Where(num => num % 2 == 0).OrderBy(n => n);

Если в качестве источника будет выступать не IEnumerable а таблица БД IQueryable то будет запрос к таблице
Вот пример
http://catalog.mista.ru/1c/articles/402433/

(153) Linq помогает склеивать запросы. И это удобнее чес склеивать текстовые запросы.
Отладив поодиночке можно их собирать.

(155) А, это хрень для запросов. Тогда извиняюсь, ошибся. Я думал мы говорим про функциональное программирование.

(156) >> Но если ты привык мыслить циклами, то декларативное программирование не для тебя.
https://ru.wikipedia.org/wiki/Language_Integrated_Query
LINQ к объектам
Представляет собой не что иное, как функциональное программирование, замаскированное под синтаксис SQL[8].

157+ https://rsdn.org/article/dotnet/LinqAsStapToFp.xml#EZFAC
Многим может показаться странным то, что ФП в LINQ замаскировано под SQL. Однако это не просто маскировка. Идеи ФП нацелены на то, чтобы сделать программирование более декларативным. Программируя в стиле ФП, мы как бы описываем то, что хотим получить, а не то, как мы это хотим получить. Именно это призван делать и SQL. SQL – это язык запросов, с помощью которого мы лишь описываем, что хотим выбрать из БД (или как хотим ее изменить), но при этом мы не задаем конкретный (императивный) алгоритм обработки данных.

а вот интересно. если в линк какую-нибудь функцию подсунуть что скл не поддерживает, то как оно в запрс транслируется?

(159) Там не функция а деревья выражений, хоть синтаксис и один. https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/concepts/expression-trees/
При обработке дерева выражений провайдером выдаст ошибку

(141)>> От количества циклов тут мало что зависит. Это доли миллисекунды. Тормоза тут не в циклах, а в медленных вызовах через интерфейс и замыкания всякие.
А для промежуточных результатов нужно выделять дополнительные списки и значит дополнительные расходы на память и Add в список.
Ну и конечно сравнивать инлайный   if (d < 100) count++; не совсем правильно. При сравнении строк уже разница будет минимальна.
Не говоря уже о group by, sort by, Select

(155) По сути ничего не поменялось. Ну раскрыли скобки, убрали точки. Синтаксис немного поменялся, но в остальном все так же.

(161) "Ну и конечно сравнивать инлайный   if (d < 100) count++; не совсем правильно."
Схрена ли неправильно. Очень даже правильно. Если большие объемы данных и нужна скорость, то linq использовать нельзя (если это не для SQL). Это же ясно как день.
А то, что c Linq всё красиво и понятно - это тоже вопрос. Когда по одной строчке в лямбду, то да. А если по 100 строк, то вся красота и понятность исчезает и остаются только тормоза.

(163) В лямбду и без Linq можно, см пример (155):

var numQuery2 =
            numbers
            .Where(num => num % 2 == 0)
            .OrderBy(n => n);

Это даже короче и понятнее чем link:

Var numQuery1 =
            from num in numbers
            where num % 2 == 0
            orderby num
            select num;

(161) "А для промежуточных результатов нужно выделять дополнительные списки"
А нафига промежуточные результаты? Я так же могу всё сделать в одном цикле и выделить память только под конечный результат. Можно все сделать так же как в linq, только без лишних вызовов виртуальных методов.

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

(166) "быстро тоже нужно но в последнюю очередь."
Быстро нужно когда надо, а не в последнюю очередь. Если тебе JSON гонять двум пользователям, то пожалуйста. А если у тебя игровой движок или какая нибудь 3D модель урагана Катрина, то совсем другое дело.

(167)     Преждевременная оптимизация — корень всех зол. Дональд Кнут.

(168) Правильно. Пускай 1С открывается по 5 минут. Зато всё по Кнуту :)

(168) Да и Кнут это написал, когда оптимизацией считалось переписывание куска программы на ассемблере

(167) А почему тогда для ураганов катарина, ИИ, дата майнига и других научных вычислений так популярен Питон, который совсем не про скорость выполнения.
(169) Я сейчас имею дело с конфой на 1С, которая по моим понятиям должно просто жестко висеть потому как очень много всего сделано не оптимально и не правильно сточки зрения практик и рекомендаций, но SQl каким то образом вытягивает это поделие до работоспособного состояния.

(171) "других научных вычислений так популярен Питон"
потому что в питоне используются библиотеки написанные на Си

(172) Ну вот, острые умы найдут как оптимизировать высокоуровневый код которым будут пользоваться люди с умом попроще в LInq лямдах и питонах и всем будет хорошо

(164) Ты написал два вида Linq. Какой хочешь такой и используй.
Нередко приходится использовать 2 синтасиса.
Опять же SelectMany проще и понятнее использовать в Sql синтаксисе
var selectedUsers = from user in users
                    from lang in user.Languages
                    where user.Age < 28
                    where lang == "английский"
                    select user;
Для создания аналогичного запроса с помощью методов расширения применяется метод SelectMany:

var selectedUsers = users.SelectMany(u => u.Languages,
                            (u, l) => new { User = u, Lang = l })
                          .Where(u => u.Lang == "английский" && u.User.Age < 28)
                          .Select(u=>u.User);
Правда в Sql подобном синтаксисе есть let очень удобная вещь
https://docs.microsoft.com/ru-ru/dotnet/csharp/linq/group-query-results

https://docs.microsoft.com/ru-ru/dotnet/csharp/language-reference/keywords/let-clause
string[] strings =
        {
            "A penny saved is a penny earned.",
            "The early bird catches the worm.",
            "The pen is mightier than the sword."
        };

        // Split the sentence into an array of words
        // and select those whose first letter is a vowel.
        var earlyBirdQuery =
            from sentence in strings
            let words = sentence.Split(' ')
            from word in words
            let w = word.ToLower()
            where w[0] == 'a' || w[0] == 'e'
                || w[0] == 'i' || w[0] == 'o'
                || w[0] == 'u'
            select word;

(165) Нужна скорость используй Linq Rewriter или LinqOptimizer. Только вот таких людей не очень много.
Не нужна экономия пару тактов.
Ну и конечно же ты пишешь на С++, ибо на 1С и питоне про инлайнинг не знают. А в 1С и о замыканиях и не знают, не то, что о Linq

174+ tot into
https://docs.microsoft.com/ru-ru/dotnet/csharp/language-reference/keywords/into

from row in rows
            select row.Split(',') into columns
            let identifier = columns[0].Replace("Prefix_", string.Empty)
            group columns by identifier into g
            select new Log {
                  Identifier = g.Key,
                  DurationInSeconds = (from dur in g
                                      let duration = DateTime.Parse(dur[1])
                                      select duration.Hour * 3600 + duration.Minute * 60
                                              + duration.Second).Sum()
                           }

между делом спрошу, вдруг кто посоветует книгу для котлина по корутинам?

(175) по поводу оптимизации я выше писал, что есть разница между inline  и не inline функциями (замыкания на не inline тратят время на создание оберток). по поводу циклов: есть возможность (не знаю как в C#) не создавать промежуточные выгрузки, а использовать отложенные операции через секвенции. При желании можно дальше пойти и использовать сплитераторы и многопоточную обработку stream'ов для java (но не все можно раздробить- это вопрос конурентности).  Ну и не стоит забывать, что кроме оптимизации есть стоимость поддержки. Для декларативного стиля это большой плюс по сравнению с императивным- но это уже переход в DSL.

(177) не тупи какие к черту корутины на котлине если основное применение котлина это трансляция в java совместимый байт код
короче книги по java и многопоточности в зубы и вперед

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

(177) Кто будет писать книги про корутины. На хабре статью прочитай и хватит. https://habr.com/ru/company/alfa/blog/336228/

(181) да, видел статью, но после java concurency (библиотека или книга) как-то не густо...

(177) какое то своеобразное у тебя понимание применения котлина Kotlin > Java, это как сказать зачем тебе c++ когда он всего лишь переводит в машинный код.

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

Мне в котлине понравилось легкое создание DSL. Например аналог lock в kotlin — можно реализовать просто функцией, а не отдельной языковой конструкцией:

lock(syncRoot) {
   doWork();
}


https://kotlinlang.org/docs/reference/type-safe-builders.html

(185) дык Java же

(186) хочу видеть как этот код ты скомпилишь на java

(187) https://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html

как бы наоборот котлина в яву "компилится"

я про реализацию DSL не про конкретно lock, то есть synchronized это конструкция языка а lock это функция с лямбда параметром, а внутри скорее всего и сидит synchronized
То что Kotlin ограничен JVM не спорю, просто у него уровень абстракции выше и красивее все реализовывается

(183) а что в этом странного? Kotlin создавался на основе  Java, за основу были взяты её библиотеки, требовалась прямая поддержка.
(189) реализация DSL (да и вообще большей части Kotlin) исходит из соглашений, позволяющих составлять синтаксические конструкции. те же инфиксные вызовы типа 1 to "one", можно делать в более традиционном стиле типа 1.to("one") из java и наоборот.
"а внутри скорее всего и сидит synchronized" - совсем не факт. synchronized построен на мониторе, а Lock- на парковке потока.

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

(191) ну тут фишка что последний параметр типа лямбда можно передавать не как параметр а описывать телом этой самой функции. Lock тут я понимаю как функцию
fun lock(par:Any, todo:()->Unit){
    synchronized(par) {
        todo()
    }
}

(190) lock это Monitor в try finally
https://stackoverflow.com/questions/2837070/lock-statement-vs-monitor-enter-method

System.Threading.Monitor.Enter(x);
try { ... }
finally { System.Threading.Monitor.Exit(x); }

Реализация функции естественно может быть любой, что тоже даст уровень абстракции в будущем

Вот все что в try{...} и есть лямбда,

(192) возможно.
(193) в java synchronized может быть либо методом, либо локальным блоком.
скорее всего имелось ввиду что-то такое или как в (192)

fun lock(syncRoot: Lock, action: ()->Unit){
lock.lock()
try{action()}
finally{lock.unlock}
}
вызов:
val syncRoot = Lock()
lock(syncRoot){prinln("внутри блокировки")}

в общем, особо никаких проблем с вызовом из java

(196) Java так умеет lock(syncRoot){prinln("внутри блокировки")}?

(197) lock(syncRoot, prinln("внутри блокировки")) -  то же самое

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

(199) соответствует сигнатуре параметра ()->Unit. println- стандартный метод, ничего не возвращает (в терминах Kotlin- это Unit).

Ну тебе нужна функция как параметр а ты передал ничего (передал результат println)

(201) это не так работает. ()->Unit   <=> ()->{что-то возвращающее Unit или ничего (Unit - аналог void)} <=> ()-> {println()} <=> {println()}

Где в (198) определение лямбда выражения?

(203) точно, тупанул. для java придется лямбду развернуто написать:
lock(syncRoot, ()->System.out.println("внутри блокировки"))

Вот, а если речь про dsl то в java это будет выглядеть вырвиглазно а в котлин структурно и красиво, на примере того же html что приводили выше

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

(205) но понимать-то все-равно надо что там происходит.

(206) Для погружения достаточно знать что любую лямбду можно заменить на обычную Функцию или Процедуру (с передачей параметров по значению)
Но будет "больше кода" и не так "синтаксически сахарно красиво"

(208) тьфу *с передачей параметров по ссылке

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

(208) вообще нет
1. при замыкании мы конструируем функцию, но вовсе ее не вызываем, возможно вызовем вообще в другом методе, как бы с параметром такое не выйдет
2. нарушилась бы сигнатура функций

(206) Что за книжка, автор или название?

По крайней мере LINQ мог бы избавить от вот такого:

ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "%УсловиеОрганизация%", УсловиеОрганизация);

(210) (211) Дык вы читать то умеете?

ВСЕГДА лямбду можно заменить на вызов процедуры/функции, просто будет не так красиво.
Придется например в временем жизни и сохранением параметров что то допом в коде изобретать да.

(214)+ Это как "можно ли программировать не используя GOTO"
Можно! Но иногда с "безусловным переходом по метке" проще. Аналогично с лямбдой.

Имхо для простоты поддержки λ=goto
лучше не использовать или новичкам особенно тяжко будет

(214) и получается скрытый объект с методом в виде самой лямбды и полями в виде переменных замыкания
что собственно и проделывает, например, C#

(215) конечно можно, не используя ЯВНО GOTO, но осознавая что за всеми ветвлениями и циклами лежит JMP

Кстати LINQ лишняя ненужная хрень, лучше нативный SQL разрабу подучить с особенностями реализаций конкретных серверов SQL
Или перейти на концепцию NoSQL с MapReduce понимая что это и зачем.

А не извращаться с трансляторами.

(218) каждому своё

(218) Смысл линка, что легким движением руки мы можем сменить СУБД.
При этом возможности Linq to EF значительно больше чем 1С, а Linq2DB еще больше.
https://github.com/linq2db/linq2db
https://linq2db.github.io/articles/sql/Window-Functions-(Analytic-Functions).html

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

(220) Смысл SQL в том что легким движением мы можем сменить СУБД

(221)+ Достаточно перед каждым вызовом добавить обработку текста sql чтобы особенности конкретной субд учесть
ну там limit или top и прочее типа передачи параметров
короче это пишется за полдня для каждой новой субд

(222)+ имхается уже есть готовые написанные модули для трансляции текстов sql запросов между разными популярными субд

(174) Какой же это link? Первый вариант - это обычная запись, без всякого линка. То что Линк имеет такой же синтаксис - это его проблемы. А я всегда так писал.

(221) Угу ты 1С перепиши. Есть еще куча инструкций пригодных только для каждой СУБД.
Посмотри на количество инструкций в 1С. Здесь ты не прав.
(224) Это обыкновенный Linq. То, что есть два типа линк это не проблемы а достоинства.
Посмотри на SelectMany плюс let и into

Кстати на чем писал? И можно склеивать запросы?
var query= list.Where(a=>а.поле>5);

var query2=query.Where(a=>а.поле2>5);

(224) в (174) Первый это Sql подобный, а вот второй через методы расширения SelectMany и первый значительно лаконичнее
var selectedUsers = from user in users
                    from lang in user.Languages
                    where user.Age < 28
                    where lang == "английский"
                    select user;
И на чем ты писал?

(225) >Угу ты 1С перепиши. Есть еще куча инструкций пригодных только для каждой СУБД.
>Посмотри на количество инструкций в 1С. Здесь ты не прав.

1С переписывать нет смысла а вот использовать лишнюю прокладку нафига?
Один хрен оно в sql транслируется и каким местом эта "куча инструкций"?
На другом ЯП в отличие от нативного SQL хрен используешь и переписывай все заново.

(225) Зачем тогда было писать, мол: "В линке лучше", если там то же самое что и в обычном программировании?

(225) На JS можно так склеивать, но склейка происходит по функции "И", а не "ИЛИ".

(227) >> а вот использовать лишнюю прокладку нафига?
Для интеллисенса, склеивания запросов.
Например один и тотже подзапрос встречается в несколько раз. В 1С используют временные таблицы или склейку текста, что неудобно.
Кстати на stackoverflow используют Dapper https://github.com/StackExchange/Dapper для предстаавления результата запроса в типизированную коллекцию.
На Linq2DB достаточно богатый язык. А Какие то фичи конкретного SQL языка всегда можно вынести в хранимые процедуры. При замене СУБД только переписать их.

Не прав потому, что Linq используют и очень этим довольны. И те у кто программирует на языках в которых нет Linq согласны, что Линк крутая фича.
(225) Еще раз ты можешь сделать SQL запрос?
У тебя ленивые вычисления?

Это два одинаковых Linq запроса users может быть не только коллекцией, но и таблицей бд
var selectedUsers = from user in users
                    from lang in user.Languages
                    where user.Age < 28
                    where lang == "английский"
                    select user;
Для создания аналогичного запроса с помощью методов расширения применяется метод SelectMany:

var selectedUsers = users.SelectMany(u => u.Languages,
                            (u, l) => new { User = u, Lang = l })
                          .Where(u => u.Lang == "английский" && u.User.Age < 28)
                          .Select(u=>u.User);

И тот и другой запрос может работать как с коллекцией так и с БД.
SQl синтаксис более лаконичный и читаемый

(230) Что бы понятнее, что для SQL применяются деревья выражений а не лямбда функции пример расширения  between
https://stackoverflow.com/questions/1447635/linq-between-operator

Кстати про линк на JS
https://habr.com/ru/post/261903/

(230) Из этого я понял что в Linq есть конструкция, которую можно применять как для работы с обычными структурами данных, так и с базами данных, в то время как без Linq приходилось использовать аналогичный синтаксис, но имеющий различия для структур и для БД. Верно?

(233) Так скажем до линка все пользовались Ado.Net. Строковые запросы. Ну еще делали типизированные датасеты.
С появлением в 2005 yield стало понятно, что можно  с ними можно многое сделать. Так в 2008 появился Linq как для коллекций IEnumerable, так и для Iqueryable.
Народ с настороженностью к ним отнесся. Новый функциональный подход долго принимали. Кто то принял, а кто то и нет. Но большинство приняли особенно для Sql
В студии для отладки можно было пользоваться локально БД.

Там не то что конструкция. Linq запрос склеивается. И выполняется пока явно не вызовут итератор (foreach,Count итд)
Поэтому можно склеивать запросы, передавать их в функции. Для SQL это деревья выражений которые обрабатывает провайдер и строит SQL запрос
Вот здесь наглядно видно во что преобразуется запрос к таблицам 1С
http://catalog.mista.ru/1c/articles/402433/

Просто компилятор по разному обрабатывает Linq запрос для IEnumerable и IQueryable, хотя на вид они оинаковые

Да для скорости и типизации когда мало запросов например на stackoverflow используют Dapper https://github.com/StackExchange/Dapper для предстаавления результата запроса в типизированную коллекцию.

(234) Я не использую Ado.Net, так как пишу под Веб на JS. Но там примерно все то же самое.

(212) Real World Haskell, что ли...

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

Онлайн доступна бесплатно: http://book.realworldhaskell.org/read/

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

(239) Спасибо большое! Начал читать, как раз речь про то то что я спрашивал.
Я подозревал что нужно читать что то про функциональное программирование и даже скачал пару книг но они не пошли, а твой вариант очень хорош. Прочитаю поделюсь результатом.

Так вот ради рекламы какого сайта была затеяна вся эта беседа!

(241) Но красивая же подводочка, согласись!

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

(243) Попробуй сначала https://ru.wikipedia.org/wiki/Регулярные_выражения изучить

(244) Регулярными выражениями владею, периодически пользуюсь, и из последнего например было "\s+[a-zA-Z0-9а-яА-Я_]+\.[a-zA-Z0-9а-яА-Я_]+\s+В\s*\([^\)]*ВТ_ОтборыПоПрограммам[^\)]*\)" - найти все условия в тексте запроса вида '*.* в (Выбрать ВТ.Программа Из ВТ_ОтборыПоПрограммам как ВТ)'. Конечно писать их на лету не могу, но с отладчиком еще не возникало задач которые бы не смог решить.

(243) Это хаскель. Посмотри F# https://docs.microsoft.com/ru-ru/dotnet/fsharp/