Лямбда функции

(96) Неправильно. Правильно так: Процедурные языки хуже объектно-ориентированных, а объектно-ориентированные хуже процедурных.

(88) Ты не читатель. Еще раз про "не задумываясь" было про то как реализован в итоге Linq и замыкания на нижнем уровне.
Да я знаю как это работает и какие подводные камни, но мне не интересно во что конкретный Linq запрос преобразуется или async await.
Я мыслю конструкциями высшего порядка.
Мало того эта реализация меняется от версии к версии компилятора.
Ты же это слово переиначил вообще ко всему. Не надо так нервничать.
(89) Поверь можно.Есть IntPtr есть fixsed https://metanit.com/sharp/tutorial/8.4.php
есть ref return https://habr.com/ru/company/microsoft/blog/423061/

(73 ) >> Если ты пишешь цепочку типа list.filter(fn1).map(fn2).foldr(fn3), сколько в результате будет циклов по побору данных?
В .Net есть такая замечательная штука как yield return
Суть её в том, что создается итератор (класс) с MoveNext и Current

Тут подрасптсали
https://habr.com/ru/post/136828/
https://ru.stackoverflow.com/questions/505018/В-чем-польза-yield

И соответственно вычисление идет не с лева на право, а с права
то есть foldr вызовет MoveNext у map, map у filter а filter у list

В итоге будет всего один цикл.

Поэтому я и не задумываюсь как будет реализовано в итог. И какие может выполнить оптимизации компилятор для оптимизации

мап однозначно генерит новый массив

(104) Да, как и OrderBy итд (не массив а итератор).
https://metanit.com/sharp/tutorial/15.8.php
Но я про то, что вычисления идут с права на лево

(103) ну вот, а говорил "не задумываясь"

(104) от языка/среды зависит
Select в .net ленивое. То есть создаёт только обёртку над IEnumerable.

var x = new List() {1,2,3};
Console.Write(x.Count()); // 4
var y=x.Select(t=>t*t);
Console.Write(y.Count()); // 3
x.Add(4);
Console.Write(y.Count()); // 4

(107) 3,3  и 4 выдаст

(106) Я не задумываюсь как в итоге будет обработана цепочка Linq запроса, как будут преобразованы замыкания. Я знаю принципы и этого достаточно
И как я раньше писал есть много оптимизаций. Проще сосредоточиться на высокоуровневом коде.
(107) Я думал  map это (Dictionary) group by

Посравнивал linq с не linq
[1c]
using System;
using System.Linq;

namespace csh
{
    class Program
    {
        static void Main(string[] args)
        {

            int itercount = 10000;
            int numscount = 100000;

            var numbers = new double[numscount];
            var r = new Random();

            for (int i = 0; i < numscount; i++) {
                numbers[i] = r.Next(999);
            }

            Console.WriteLine("for");
            int count = 0;
            var t = DateTime.Now;
            for (int i = 0; i < itercount; i++) {
            
            for (int ii = 0; ii < numscount; ii++) {
                if (numbers[ii] < 100) count++;
            }
            }
          
            var t2 = DateTime.Now;
            Console.WriteLine(t2.Subtract(t));
            Console.WriteLine(count);

            Console.WriteLine("foreach");
            count = 0;
            t = DateTime.Now;
            for (int i = 0; i < itercount; i++) {
            
            foreach (double d in numbers) {
                if (d < 100) count++;
            }
            }        
            t2 = DateTime.Now;
            Console.WriteLine(t2.Subtract(t));
            Console.WriteLine(count);

            Console.WriteLine("linq");
            count = 0;
            t = DateTime.Now;
            for (int i = 0; i < itercount; i++) {
                count += numbers.Count(x => x < 100);
            }          
            t2 = DateTime.Now;
            Console.WriteLine(t2.Subtract(t));
            Console.WriteLine(count);            
        }
    }
}

[/1c]

for
00:00:01.7805429
100070000
foreach
00:00:01.7357639
100070000
linq
00:00:07.5117874
100070000

правда я в C# не шарю. мож чо неправильно написал

(112) Я уже писал про оптимизаторы Linq в (75) там как раз про твой случай
и про Parallel LINQ

C# конечно загадочный. Мало того, что в него понапихали кучу всего, так еще надо знать как это всё внутри работает. Иначе будут тормоза и утечки памяти.
Вот как можно догадаться что numbers.Count(x => x < 100) будет работать медленнее чем numbers.Where(x => x < 100).Count() ???

(114) Пользуйся циклами. Никто же тебя не заставляет использовать Linq. Если тебе так важна скорость. Про утечки памяти поподробнее.
(75) смотрел?

115+ https://github.com/antiufo/roslyn-linq-rewrite

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

(115) Про утечки в .NET читал где то.

(117) Суть линка не в скорости выполнения, а в декларативном написнии запроса.
Быстрее пишешьшь код, проще читать. Ты же пишешь на 1С, а не каком то супер быстром языке.
Опять же есть оптимизаторы которые ты игнорируешь.
(118) Самая простая утечка памяти это статические переменные, и соответсвенно различные подписки итд.
И если ты передаешь COM , в нативное приложение тоже понятно. Но это не утечка памяти. Утечки это когда нет статических переменных и внешних нативных приложений держащих ссылки

(121) "Суть линка не в скорости выполнения, а в декларативном написнии запроса."
Это я уже понял. Годится для тяп ляп и в кассу.

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

Переписываем, естественно, за деньги. :)

(122) Нет он годится для нормального написания кода.
В том числе и для Sql где в качестве коллекции это IQueriable и в качестве замыкания уже не лямбда выражения а деревья выражений.
И задуман он был для SQL, а для списков это приятный довесочек.
Так что любители эткономит на тактах добро пожаловать в адовый код циклов.
А вот кто хочет писать и читать лаконичный, но легко читаемый код добро пожаловать в широкий мир C# где кроме Linq есть и async await (внутри тоже итераторы используются)
(124) Тебе дан широкий спектр инструментов. Можешь вообще не писать.
Проходили это все более 10 лет назад. И большинство приняло линк, отказавшись от циклов.

(124) Не надо ничего переписывать просто подключаешь https://github.com/antiufo/roslyn-linq-rewrite
Но ты же упорно игнорируешь. Главное обосрать!

(125) "И большинство приняло линк, отказавшись от циклов." да я тоже не против. Я на питоне тоже на linq строчу тыпляпы всякие. Но я от питона скорости не жду.

(127) Опять игнорируешь (126). Легким движением руки подключаешь  https://github.com/antiufo/roslyn-linq-rewrite и твой тяп ляп превращается в высокоуровневые циклы!

(128) С костылями еще возиться. Лень

Я лучше подожду еще лет 5 пока микрософт нормальный C# сделает

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

И по поводу запроса в цикле.
В sql есть синтаксис prepare execute,который как раз предназначен для выполнения запроса в цикле.
Не забываем,что поиск по индексным полям - это все равно цикл,и если мы его выполняем один раз для всех полей,то сначала будет цикл при выборке,потом будет цикл обхода результата,где ещё чего-то нужно будет искать,т.к. мы значения куда-то пишем.
А если мы гоняем запрос в цикле,то,как ни странно,цикл-то будет один.
Ну,если поиск не по индексным полям,то тут не проблема запроса в цикле,а проблема неоптимального запроса,которую цикл просто проявляет сильнее.

(130) Не C#, а компилятор. https://github.com/dotnet/runtimelab/tree/feature/NativeAOT И не пять лет его в .Net 6 обещают во всяком случае для блазора
(131)  Еще раз Linq это прежде всего SQL а уже во вторую очередь итераторы. Если ты владеешь SQL то тебе писать и читать удобнее именно на SQL
Вот пример Linq к объектам 1С http://catalog.mista.ru/1c/articles/402433/
var qr = from Номенклатура in бд.Спр_Номенклатура

                     from единицы in бд.Спр_Единицы.Where(единица => единица.ВладелецId == Номенклатура.ID && единица.ШтрихКод.CompareTo("4") > 0).DefaultIfEmpty()

                     select new

                     {

                         Номенклатура.Наименование,

                         Номенклатура.ПолнНаименование,

                         единицы.ШтрихКод,

                         ОКЕИ = единицы.ОКЕИ.Наименование

                     };
В C# есть два вида Linq. Оди из них Sql подобный

https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/concepts/linq/query-syntax-and-method-syntax-in-linq

(133) "В C# есть два вида Linq. Оди из них Sql подобный "
C# язык хороший, но одинеснику он не нужен. На нём только какую нибудь серверную хренотень писать. Сайты там всякие... Корпоративного масштаба.  Одинесники таким не занимаются.

(134) а мне нравится идея. Тот же 1с только более развитый
Кстати как там веб страницы клиентские рисовать? Вот это всё же джаваскрипте

Скд тот же декларативный наверняка можно переложить на linq

(135) Blazor Webassembly сейчас развивается в том числе и компоненты
https://docs.microsoft.com/ru-ru/aspnet/core/blazor/components/?view=aspnetcore-5.0
И все это на C#. Можно и кроссплатформенные формы рисовать и единые классы использовать как на сервере так и на клиенте

(103) Чем больше отдельных не взаимосвязанных шагов, тем проще поддерживать код, отлаживать, и тестировать. Если все вычисление будет в одном цикле, то это боль в заднице для поддержки.
Тот же ваш пример  list.filter(fn1).map(fn2).foldr(fn3) можно спокойно отладить и оттестировать по шагам
сперва получаем list,
потом .filter(fn1),
потом .map(fn2)
потом .foldr(fn3)
И на каждом шаге контролируем результат.

(138) Был вопрос
(73 ) >> Если ты пишешь цепочку типа list.filter(fn1).map(fn2).foldr(fn3), сколько в результате будет циклов по побору данных?
В .Net в итоге будет один цикл (если map это Select). Отлаживай лямбды в чем проблема?

От количества циклов тут мало что зависит. Это доли миллисекунды. Тормоза тут не в циклах, а в медленных вызовах через интерфейс и замыкания всякие. Чем больше итераций, тем больше вызовов и тормозов соответственно.

Собственно это и является причиной того, что компы становятся мощнее, а программы тормознее. ООП с виртуальными методами и всякие Linq с замыканиями упорно стараются свести старания Intel к нулю.

(138) В .Net можно собирать несколько запросов в 1
напрммер
var query=list.Where(a=>a>0);
query=query.Where(a=>a<5).Select(a=>a+8);

В данном случае query это цепочка вызовов. Только когда вызывется MoveNext (foreach, ToList? Count итд) начинается вызов с конца цепочки MoveNext
(140) Ничего не знаю про котлин, но легко проверить последовательность вызова функций или лямбд
(142) Очень актуально на форуме 1С.

(143) " Очень актуально на форуме 1С."
нуачо. меня вот бесит, когда 1с по 5 минут открывается

(142) На самом деле сейчас с развитием компиляторв многое инлайнится даже виртуальные меоды если точно известно что через new создается.
Все течет все меняется и скорость выполнения от версии к версии языка компилятора. Ловить пару миллисекунд в ущерб скорости написания кода и удобства чтения кода
большинство не хочет.
(144) Но она написана на С++!

(145) "Но она написана на С++!"
А впечатление такое, что на питоне. И память жрет как не в себя.

(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, только без лишних вызовов виртуальных методов.

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

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

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

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

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

(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 (библиотека или книга) как-то не густо...

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

lock(syncRoot) {
   doWork();
}


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

(185) дык Java же

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

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

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

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

(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

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

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