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

I>>Наоборот. IQueryable это гораздо более сильная ленивость, и гораздо ближе к идее Linq. И что интересно, безо всяких yield.
S> Где я говорил про ленивость для IQueryable. Речь там шла совсем не про IQueryable. Там про то что
S>

S> var n =
S>        from c in 1.ToMaybe()
S>        from s in "2".ToMaybe()
S>        from x in 2.ToMaybe()
S>        select s + c + x;
S>

Что это меняет? Здесь пример query comprehension, который показывает, как можно сделать linq для чего угодно.


S>преобразуется в

S>

S>var n = 1.ToMaybe().SelectMany(u => "2".ToMaybe(),
S>                            (c, s) => new { c, s })
S>                .SelectMany(u => 2.ToMaybe(),
S>                            (t, x) =>  t.s + t.c + x);
S>

И что с того? Ты видишь здесь свои yield ?

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

I>>Такой вот дотнет целиком — приходится платить то тут, то там за определенные преимущества.
S>Так и пиши на голом С. Однако ты же используешь и динамические языки

Когда пишешь на менеджед, нужно помнить про это, а не утверждать "у нас тут всё классно".

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

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

I>>>Наоборот. IQueryable это гораздо более сильная ленивость, и гораздо ближе к идее Linq. И что интересно, безо всяких yield.
S>> Где я говорил про ленивость для IQueryable. Речь там шла совсем не про IQueryable. Там про то что
S>>

S>> var n =
S>>        from c in 1.ToMaybe()
S>>        from s in "2".ToMaybe()
S>>        from x in 2.ToMaybe()
S>>        select s + c + x;
S>>

I>Что это меняет? Здесь пример query comprehension, который показывает, как можно сделать linq для чего угодно.
То, что это не IQueryable!!

S>>преобразуется в

S>>

S>>var n = 1.ToMaybe().SelectMany(u => "2".ToMaybe(),
S>>                            (c, s) => new { c, s })
S>>                .SelectMany(u => 2.ToMaybe(),
S>>                            (t, x) =>  t.s + t.c + x);
S>>

I>И что с того? Ты видишь здесь свои yield ?
С того, что это то как раз частный случай, а Linq для коллекций испольцется ну как минимум 50% использования Linq.
А в нем напрополую используется yield

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

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

I>>>Такой вот дотнет целиком — приходится платить то тут, то там за определенные преимущества.
S>>Так и пиши на голом С. Однако ты же используешь и динамические языки

I>Когда пишешь на менеджед, нужно помнить про это, а не утверждать "у нас тут всё классно".
И где я это утверждал?? Ты сам выдумал проблему и обвиняешь меня и ставишь минусы.

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

I>>Что это меняет? Здесь пример query comprehension, который показывает, как можно сделать linq для чего угодно.
S> То, что это не IQueryable!!

Цитирую себя:

RX, XML, WMI, IQueryable и тд и тд и тд.

Можешь вписать вместо итд свой пример с монадами


S>>>преобразуется в

I>>И что с того? Ты видишь здесь свои yield ?
S> С того, что это то как раз частный случай, а Linq для коллекций испольцется ну как минимум 50% использования Linq.
S>А в нем напрополую используется yield

Хоть 90% Это не делает iEnumerable общим случаем.
IQueryable можно натянуть на что угодно, хоть на коллекции, хоть на базу данных. Потому это гораздо больше похоже на общий случай. А вот IEnumerable это просто последовательность, и даже нужды коллекций покрывает не полностью.

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

I>>Когда пишешь на менеджед, нужно помнить про это, а не утверждать "у нас тут всё классно".
S>И где я это утверждал?? Ты сам выдумал проблему и обвиняешь меня и ставишь минусы.

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

То есть, ты или пишешь сообщения ногой, не думая, или такое вот у тебя содержимое головы. Выбирай.

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

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

I>>>Что это меняет? Здесь пример query comprehension, который показывает, как можно сделать linq для чего угодно.
S>> То, что это не IQueryable!!

I>Цитирую себя:
I>

I>RX, XML, WMI, IQueryable и тд и тд и тд.

I>Можешь вписать вместо итд свой пример с монадами
Xml там IQueryable на самом то деле. Смотрим исходники https://referencesource.microsoft.com/#System.Xml.Linq/System/Xml/Linq/XLinq.cs,3354dac0913e417b
и считаем количество yield, что только подтверждает мои выводы
Что такое RX и WMI даже я не знаю но наверняка итераторы с yield
Вернее RX я еще помню по использованию в TS. Но и там yield напрополую используются
https://github.com/dotnet/reactive/tree/9f2a8090cea4bf931d4ac3ad071f4df147f4df50/Ix.NET/Source/System.Interactive.Async/System/Linq/Operators

Еще раз каков процент в коде используется?

S>>>>преобразуется в

I>>>И что с того? Ты видишь здесь свои yield ?
S>> С того, что это то как раз частный случай, а Linq для коллекций испольцется ну как минимум 50% использования Linq.
S>>А в нем напрополую используется yield

I>Хоть 90% Это не делает iEnumerable общим случаем.
I>IQueryable можно натянуть на что угодно, хоть на коллекции, хоть на базу данных. Потому это гораздо больше похоже на общий случай. А вот IEnumerable это просто последовательность, и даже нужды коллекций покрывает не полностью.
Кто тебе запрещает писать расширения используя yield?
IQueryable это вообще деревья выражений. B и обрабатывать их то еще удовольствие.
А yield с парой строчек написал любое расширение!

Да но Linq включает IEnumerable и он основной в использовании. Нахрен он тогда нужен.
Всякое EF и Linq2DB появились значительно позже хотя IQueryable был. Опять же Expression trees никакого отношения не имеют к IEnumerable, однако ты же согласен, что без него не было бы Linq
Самому то не смешно.

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

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

I>>>Когда пишешь на менеджед, нужно помнить про это, а не утверждать "у нас тут всё классно".
S>>И где я это утверждал?? Ты сам выдумал проблему и обвиняешь меня и ставишь минусы.


I>В одном месте ты пишешь, что это yield делает итератор ленивым. В другом — отрицаешь издержки на сам yield.
Я с тебя хренею.
yield делает итератор. Итератор то сам ленивый.
Где я писал про издержки? Я писал про вычисления с права на лево!!!
Для достижения ленивости ты сам ручками будешь писать писть то, что за тебя делае yield

I>То есть, эдакое чудо — если пишем yield то издержки итератора становятся равными нулю
Было написано про вычисления с права на лево!!!!! Именно оно дает на каждый Where не делать новых циклов.
Да берем несколько цепочек where и в конце FirstOrDefault. В данном случае вообще блики к 0 если 1 строка удовлетворяет условию.
Но ты этот посыл игнорируешь полностью.
А это было основным посылом. Потому, что многие считают, что вычисления идут с лева на право и не считают Linq в этом плане отличными огт других языков.
Но ты свалился на какую то мелочь и до сих пор за эту мелочь цепляешься
I>Далее ты задним числом патчишь сообщения, хотя само по себе это нормально, но вот понять тебя трудно.

I>То есть, ты или пишешь сообщения ногой, не думая, или такое вот у тебя содержимое головы. Выбирай.
.

Элементарные вещи можно и не писать. Они сами собой подразумеваются.
"Поймет не только взрослый , но даже карапуз"
Но я извинился. Но ты и дальше гнешь свою линию, заявляя что yield это отстой ибо издержки.
А то, что ленивость это MoveNext и Current которые в одну строчку реализует yield.
И которые создатели Linq и все остальные писатели расширений должны писать ручками ну никак не издержки.
По твоему ленивость в Linq не нужна?

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

I>>В одном месте ты пишешь, что это yield делает итератор ленивым. В другом — отрицаешь издержки на сам yield.
S>Я с тебя хренею.
S> yield делает итератор. Итератор то сам ленивый.

А теперь читай себя же:
"Да но именно yield и создает IEnumerable ленивым."

А теперь сравни с тем, что тебе пишу:
"Ты в любой момент можешь отказаться от вызова MoveNext, а следовательно, IEnumerable сам по себе ленивый, безо всякого yield."

Ты сам то видишь, как ты переобуваешься? Вот я и говорю — или ты ногой сообщения строчишь, или вот такой порядок у тебя в голове.

S>Где я писал про издержки? Я писал про вычисления с права на лево!!!

Когда я пишу про издержки, ты их усиленно отрицаешь.

S>Да берем несколько цепочек where и в конце FirstOrDefault. В данном случае вообще блики к 0 если 1 строка удовлетворяет условию.
S>Но ты этот посыл игнорируешь полностью.

Ты приводишь бенефит итератора, а не yield
Ты что, сам не можешь понять чего пишешь?

S>Но ты свалился на какую то мелочь и до сих пор за эту мелочь цепляешься

На счет мелочей — ты считаешь что yield/IEnumerable и есть общий случай. IQueryable для тебя, похоже, не существует.
И это у тебя "yield делает IEnumerable ленивым"

S>Но я извинился. Но ты и дальше гнешь свою линию, заявляя что yield это отстой ибо издержки.

Мои слова — yield имеет ценую — ты интерпретируешь, как "yield отстой". Ты адекватен?

S>А то, что ленивость это MoveNext и Current которые в одну строчку реализует yield.

Правильно — ленивость это итератор. А вот yield это сахар, об чем я тебя пишу давным давно.

S>И которые создатели Linq и все остальные писатели расширений должны писать ручками ну никак не издержки.

Ты путаешь рантайм с разработкой.

S>По твоему ленивость в Linq не нужна?

Похоже, раз я с чем то не согласен, значит я вобще ни с чем не согласен?

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

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

I>>>В одном месте ты пишешь, что это yield делает итератор ленивым. В другом — отрицаешь издержки на сам yield.
S>>Я с тебя хренею.
S>> yield делает итератор. Итератор то сам ленивый.

I>А теперь читай себя же:
I>"Да но именно yield и создает IEnumerable ленивым."

I>А теперь сравни с тем, что тебе пишу:
I>"Ты в любой момент можешь отказаться от вызова MoveNext, а следовательно, IEnumerable сам по себе ленивый, безо всякого yield."

I>Ты сам то видишь, как ты переобуваешься? Вот я и говорю — или ты ногой сообщения строчишь, или вот такой порядок у тебя в голове.
yield это конструкция создания класса обертки енумератора. Да yield создает енумератор.
Но создать енумератор можно например создав List да он будет вызываться как энумератор, но создание List нихрена не линиво!
А ведь многие, в том числе и других языках, как раз и используют создание Lista для создания IEnumeratora и нихрена это не лениво получатся!!

S>>Где я писал про издержки? Я писал про вычисления с права на лево!!!

I>Когда я пишу про издержки, ты их усиленно отрицаешь.
Где я отрицал!!
S>>Да берем несколько цепочек where и в конце FirstOrDefault. В данном случае вообще блики к 0 если 1 строка удовлетворяет условию.
S>>Но ты этот посыл игнорируешь полностью.

I>Ты приводишь бенефит итератора, а не yield
I>Ты что, сам не можешь понять чего пишешь?
Еще раз смотрим исходники и смотрим что практически все енумераторы создаются через yield!!!!!

S>>Но ты свалился на какую то мелочь и до сих пор за эту мелочь цепляешься

I>На счет мелочей — ты считаешь что yield/IEnumerable и есть общий случай. IQueryable для тебя, похоже, не существует.
I>И это у тебя "yield делает IEnumerable ленивым"
Да да да!! Он создает иэнумератор через отдельный класс, а не через List или массив!!!

S>>Но я извинился. Но ты и дальше гнешь свою линию, заявляя что yield это отстой ибо издержки.

I>Мои слова — yield имеет ценую — ты интерпретируешь, как "yield отстой". Ты адекватен?
Вот ты и не показал показал как программировать енумератор без yield.
Ручками создавать все тоже, что и делает компилятор обрабатывая yield

S>>А то, что ленивость это MoveNext и Current которые в одну строчку реализует yield.

I>Правильно — ленивость это итератор. А вот yield это сахар, об чем я тебя пишу давным давно.
Но без этого сахара практически нахрен не нужен Linq. List тоже итератор, но его то нужно нелениво заполнить!
S>>И которые создатели Linq и все остальные писатели расширений должны писать ручками ну никак не издержки.

I>Ты путаешь рантайм с разработкой.
В чем!!
S>>По твоему ленивость в Linq не нужна?

I>Похоже, раз я с чем то не согласен, значит я вобще ни с чем не согласен?
Да непонятно с чем ты не согласен!!
Для тебя yield сахар ненужный и тормозящий. Нужно работать через List я так понимаю.
В нем можно обращаться по индексу, о чем ты так восхищался!

yield сам по себе вносит потери. Неважно, есть лишние циклы, или нет. x[i] заменяется на доступ через итератор. Вот уже проблема.

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

I>>Можешь вписать вместо итд свой пример с монадами
S>Xml там IQueryable на самом то деле. Смотрим исходники https://referencesource.microsoft.com/#System.Xml.Linq/System/Xml/Linq/XLinq.cs,3354dac0913e417b

Сам подумай, что же значит.

S>и считаем количество yield, что только подтверждает мои выводы

Количество yield ничего не значит. IQueryable можно прикрутить поверх чего угодно. А раз так, то это и есть общий случай.

S>Что такое RX и WMI даже я не знаю но наверняка итераторы с yield

Не знаешь, но мнение имеешь. RX еще назывался linq2events.

S>Вернее RX я еще помню по использованию в TS. Но и там yield напрополую используются
S>https://github.com/dotnet/reactive/tree/9f2a8090cea4bf931d4ac3ad071f4df147f4df50/Ix.NET/Source/System.Interactive.Async/System/Linq/Operators

Браво, ты узнал, что Обсервер и Итератор дуальны, а раз так, то можно один сводить к другому.
Ровно то же можно написать и без yield, с таким же количеством кода.
вместо yield a будет observer.next(a)

I>>IQueryable можно натянуть на что угодно, хоть на коллекции, хоть на базу данных. Потому это гораздо больше похоже на общий случай. А вот IEnumerable это просто последовательность, и даже нужды коллекций покрывает не полностью.
S> Кто тебе запрещает писать расширения используя yield?

Ок. Покажи пров для mssql на yield. Валяй.

S>IQueryable это вообще деревья выражений. B и обрабатывать их то еще удовольствие.
S>А yield с парой строчек написал любое расширение!

Покажи пров для mssql на yield. Хотя бы идею выдай.

S> Да но Linq включает IEnumerable и он основной в использовании. Нахрен он тогда нужен.

Ты путаешь "основной" и "общий случай", а так же "yield" и "IEnumerable".

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

S>Всякое EF и Linq2DB появились значительно позже хотя IQueryable был. Опять же Expression trees никакого отношения не имеют к IEnumerable, однако ты же согласен, что без него не было бы Linq

Без IQueryable не было бы, да. Именно это позволяет прикрутить Linq к чем угодно. А вот yield для BD — хоть раком встань, ничего не выйдет.

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

I>>А теперь читай себя же:
I>>"Да но именно yield и создает IEnumerable ленивым."

I>>А теперь сравни с тем, что тебе пишу:
I>>"Ты в любой момент можешь отказаться от вызова MoveNext, а следовательно, IEnumerable сам по себе ленивый, безо всякого yield."

I>>Ты сам то видишь, как ты переобуваешься? Вот я и говорю — или ты ногой сообщения строчишь, или вот такой порядок у тебя в голове.
S> yield это конструкция создания класса обертки енумератора. Да yield создает енумератор.

Это ты уже переобулся. А днём ранее утверждал совсем другое "Да но именно yield и создает IEnumerable ленивым."
Эта фраза означает, ни много ни мало, что это благодаря yielf IEnumerable становится ленивым.


I>>Ты приводишь бенефит итератора, а не yield
I>>Ты что, сам не можешь понять чего пишешь?
S> Еще раз смотрим исходники и смотрим что практически все енумераторы создаются через yield!!!!!

Именно. Их используют ради бенефитов IEnumerable. FirstOrDefault() — такой фокус появился еще до появления yield.
Практически сразу, как некто начинает использовать итератор, приходится решать задачу "первый или дефолтный"
Такое писали ещё в 90х.
А теперь чудо — всё это стало возможным благодаря yield


I>>На счет мелочей — ты считаешь что yield/IEnumerable и есть общий случай. IQueryable для тебя, похоже, не существует.
I>>И это у тебя "yield делает IEnumerable ленивым"
S> Да да да!! Он создает иэнумератор через отдельный класс, а не через List или массив!!!

IEnumerable ленивый всегда, независимо от способа создания. Всегда, потому как ты в любой момент можешь отказаться от MoveNext.
Ты похоже сам не понимаешь своей фразы.

I>>Мои слова — yield имеет ценую — ты интерпретируешь, как "yield отстой". Ты адекватен?
S> Вот ты и не показал показал как программировать енумератор без yield.
S>Ручками создавать все тоже, что и делает компилятор обрабатывая yield

Ты снова подменяешь тему. Цену в рантайме ты подменяешь ценой в разработке. Похоже, если цена и там, и там, то для тебя это одно и то же.

I>>Правильно — ленивость это итератор. А вот yield это сахар, об чем я тебя пишу давным давно.
S> Но без этого сахара практически нахрен не нужен Linq. List тоже итератор, но его то нужно нелениво заполнить!

Вот еще одно заблуждение. С С++ и джавой ты не знаком?

I>>Ты путаешь рантайм с разработкой.
S> В чем!!

А чуть выше ты соскакиваешь с цены в рантайме на цену в разработке.
Например, когда я пишу, что IEnumerable имеет свою цену, ты начинаешь вещать про разработку.

I>>Похоже, раз я с чем то не согласен, значит я вобще ни с чем не согласен?
S> Да непонятно с чем ты не согласен!!

А ты пробуй читать внимательно.

S>Для тебя yield сахар ненужный и тормозящий. Нужно работать через List я так понимаю.

Это нужный сахар. И тем не менее его нельзя использовать бездумно. В числодробилках он может давать конские потери.

S>В нем можно обращаться по индексу, о чем ты так восхищался!
S>

S>yield сам по себе вносит потери. Неважно, есть лишние циклы, или нет. x[i] заменяется на доступ через итератор. Вот уже проблема.

Именно. Профайлер утверждает, что экономия может быть и полтора, и два, и даже десять раз.

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

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

I>>>Можешь вписать вместо итд свой пример с монадами
S>>Xml там IQueryable на самом то деле. Смотрим исходники https://referencesource.microsoft.com/#System.Xml.Linq/System/Xml/Linq/XLinq.cs,3354dac0913e417b

I>Сам подумай, что же значит.

S>>и считаем количество yield, что только подтверждает мои выводы

I>Количество yield ничего не значит. IQueryable можно прикрутить поверх чего угодно. А раз так, то это и есть общий случай.
А ну да молодец. То есть все твои примеры используют yield но ты переходишь на IQueryable. Но
IQueryable<out T> : IEnumerable<T>, IQueryable

S>>Что такое RX и WMI даже я не знаю но наверняка итераторы с yield

I>Не знаешь, но мнение имеешь. RX еще назывался linq2events.

S>>Вернее RX я еще помню по использованию в TS. Но и там yield напрополую используются
S>>https://github.com/dotnet/reactive/tree/9f2a8090cea4bf931d4ac3ad071f4df147f4df50/Ix.NET/Source/System.Interactive.Async/System/Linq/Operators

I>Браво, ты узнал, что Обсервер и Итератор дуальны, а раз так, то можно один сводить к другому.
I>Ровно то же можно написать и без yield, с таким же количеством кода.
I>вместо yield a будет observer.next(a)
Дохрена чего можно только это все трудоемко. На том же JS нет нормального Linq
Пишем LINQ на JavaScript с нуля
То, что на C# делается в 2 строчки кода, в других надо писать кучу кода. Поэто в большинстве просто используют List
I>>>IQueryable можно натянуть на что угодно, хоть на коллекции, хоть на базу данных. Потому это гораздо больше похоже на общий случай. А вот IEnumerable это просто последовательность, и даже нужды коллекций покрывает не полностью.
При чем тут IQueryable, слишком дорого его использовать для коллекций и смысла то особого нет, только лишние накладные расходы.
То ты ратуешь за скорость то сам добавляешь дополнительную сложность и тормоза
S>> Кто тебе запрещает писать расширения используя yield?

I>Ок. Покажи пров для mssql на yield. Валяй.
Я тебе уже кучу привел примеров использования yield

S>>IQueryable это вообще деревья выражений. B и обрабатывать их то еще удовольствие.
S>>А yield с парой строчек написал любое расширение!

I>Покажи пров для mssql на yield. Хотя бы идею выдай.
Да легко. Получаешь результаты порциями. Держишь на сервере энумератор. Итд

S>> Да но Linq включает IEnumerable и он основной в использовании. Нахрен он тогда нужен.

I>Ты путаешь "основной" и "общий случай", а так же "yield" и "IEnumerable".

S>>Всякое EF и Linq2DB появились значительно позже хотя IQueryable был. Опять же Expression trees никакого отношения не имеют к IEnumerable, однако ты же согласен, что без него не было бы Linq

I>Без IQueryable не было бы, да. Именно это позволяет прикрутить Linq к чем угодно. А вот yield для BD — хоть раком встань, ничего не выйдет.
Но деревья выражений не использутся для коллекций!!!

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


I>>>Правильно — ленивость это итератор. А вот yield это сахар, об чем я тебя пишу давным давно.
S>> Но без этого сахара практически нахрен не нужен Linq. List тоже итератор, но его то нужно нелениво заполнить!

I> Вот еще одно заблуждение. С С++ и джавой ты не знаком?
Ииииииииииииии. Охренительный ответ.
Приводи код!! Знаком и там нет yield там и Linq нет!!

I>>>Ты путаешь рантайм с разработкой.
S>> В чем!!

I>А чуть выше ты соскакиваешь с цены в рантайме на цену в разработке.
I>Например, когда я пишу, что IEnumerable имеет свою цену, ты начинаешь вещать про разработку.
Какую!!! Ты хоть напиши какую!!!
I>>>Похоже, раз я с чем то не согласен, значит я вобще ни с чем не согласен?
S>> Да непонятно с чем ты не согласен!!

I>А ты пробуй читать внимательно.
Да извини но херню ты как раз пишешь. Никакой конкретики
S>>Для тебя yield сахар ненужный и тормозящий. Нужно работать через List я так понимаю.

I>Это нужный сахар. И тем не менее его нельзя использовать бездумно. В числодробилках он может давать конские потери.
Причем тут числодробилки! Ты ратуешь за IQueriable. Вон Sinclair пришпондорил Linq.
Главное как использовать
S>>В нем можно обращаться по индексу, о чем ты так восхищался!
S>>

S>>yield сам по себе вносит потери. Неважно, есть лишние циклы, или нет. x[i] заменяется на доступ через итератор. Вот уже проблема.

I>Именно. Профайлер утверждает, что экономия может быть и полтора, и два, и даже десять раз.
Ну то есть ты за выполнение слева направо. Никто
же не заставляет использовать тебя IEnumerablt используй IList и обходись без ленивости.
Только то вот Linq ленив и ленивость эту в основном создает yield с созданием определенных классов автоматов с сохранением состояния

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

Тоесть итог всей этой болтовни таков. Ты против yield потому, что он с ленивость привносит накладные расходы.
Какие именно? MoveNext и Current я так понимаю. Но на этом Linq то и основан.
А List этих расходов не привносит, хотя нужна лишняя память для заполнение Lista даже если эти данные не понадобятся и лишние вызовы лямд если эти данные уже и не нужны
Зато можно обращаться по индексу.
В этом основная суть минусов?

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

I>>Количество yield ничего не значит. IQueryable можно прикрутить поверх чего угодно. А раз так, то это и есть общий случай.
S>А ну да молодец. То есть все твои примеры используют yield но ты переходишь на IQueryable. Но
S>IQueryable<out T> : IEnumerable<T>, IQueryable

Ты пока не показал, как xml, db и подобные вещи читать твоим IEnumerable, что бы это было максимально эффективно.

I>>Браво, ты узнал, что Обсервер и Итератор дуальны, а раз так, то можно один сводить к другому.
I>>Ровно то же можно написать и без yield, с таким же количеством кода.
I>>вместо yield a будет observer.next(a)
S> Дохрена чего можно только это все трудоемко.

В JS, раз уж ты вспомнил, есть yield. Однако же, в RX процессинг ленивый, а обходятся без yield
https://github.com/ReactiveX/rxjs/search?q=yield
Ажно 11 раз, и те в документации и тестах
Теперь тебе понятно, что yield для RX это вещь сильно опциональная?

S>То, что на C# делается в 2 строчки кода, в других надо писать кучу кода. Поэто в большинстве просто используют List

Покажи, где здесь куча кода:
https://github.com/ReactiveX/rxjs/blob/master/src/internal/operators/filter.ts

Ровно то же у тебя и в C#, в т.ч. OperatorSubscriber, т.к. ктото должен конвертить последовательность значений в последовательность эвентов.

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

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

S>То ты ратуешь за скорость то сам добавляешь дополнительную сложность и тормоза

Ну и логика Я озвучиваю простой факт, а ты додумываешь, будто я весь код так пишу. Ты адекватен?

S>>> Кто тебе запрещает писать расширения используя yield?

I>>Ок. Покажи пров для mssql на yield. Валяй.
S> Я тебе уже кучу привел примеров использования yield

То есть, слив Или ты считаешь свой код примерами работы с mssql ?

I>>Покажи пров для mssql на yield. Хотя бы идею выдай.
S> Да легко. Получаешь результаты порциями. Держишь на сервере энумератор. Итд

Каким образом по IEnumerable построить SQL ?

I>>Без IQueryable не было бы, да. Именно это позволяет прикрутить Linq к чем угодно. А вот yield для BD — хоть раком встань, ничего не выйдет.
S>Но деревья выражений не использутся для коллекций!!!

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

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

I>> Вот еще одно заблуждение. С С++ и джавой ты не знаком?
S> Ииииииииииииии. Охренительный ответ.
S> Приводи код!! Знаком и там нет yield там и Linq нет!!

Ты адекватен, в джаве Linq искать? Там есть streams, которые покрывают твой любимый linq2objects

Employee employee = Stream.of(empIds)
      .map(employeeRepository::findById)
      .filter(e -> e != null)
      .filter(e -> e.getSalary() > 100000)
      .findFirst()
      .orElse(null);

I>>А чуть выше ты соскакиваешь с цены в рантайме на цену в разработке.
I>>Например, когда я пишу, что IEnumerable имеет свою цену, ты начинаешь вещать про разработку.
S> Какую!!! Ты хоть напиши какую!!!

Четвертый раз — вместо x[i] у тебя MoveNext, проход через switch, присваивание Current и чтение Current
И вот эта каша крайне плохо инлайнится, а следовательно ест больше чем весит.
Заметь — это уже в четвертый раз я пишу, а до тебя не доходит.

S> Да извини но херню ты как раз пишешь. Никакой конкретики

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

I>>Это нужный сахар. И тем не менее его нельзя использовать бездумно. В числодробилках он может давать конские потери.
S>Причем тут числодробилки! Ты ратуешь за IQueriable. Вон Sinclair пришпондорил Linq.

IQueryable нужен там, где будет обработка Expression и нужен единый подход вне зависимости, BD или коллекции.
То есть, избавляет от дублирования.
Если это не является узким местом для перформанса — используй сколько хошь.

I>>Именно. Профайлер утверждает, что экономия может быть и полтора, и два, и даже десять раз.
S>Ну то есть ты за выполнение слева направо.

Откуда такой вывод? Я и слева направо обгоню это IEnumerable с не меньшим бенефитом.

S>же не заставляет использовать тебя IEnumerablt используй IList и обходись без ленивости.

Если собираешся итерировать по индексу, лучше запрашивать массив явно — исключается целый класс ошибок.

S>Только то вот Linq ленив и ленивость эту в основном создает yield с созданием определенных классов автоматов с сохранением состояния

Вот снова ересь — ленивость создаёт сам IEnumerable и никак иначе. Вобщем, каша. То одно пишешь, то другое, прямо противоположное

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

S>Тоесть итог всей этой болтовни таков. Ты против yield потому, что он с ленивость привносит накладные расходы.

Очевидно, это не так. Я спокойно использую yield там, где это не является узким место. И я точно знаю, где начинается это узкое место.

S>Какие именно? MoveNext и Current я так понимаю. Но на этом Linq то и основан.

Linq основан на IQueryable, а IEnumerable нужн рассматривать как оптимизацию частного случая.

S>А List этих расходов не привносит, хотя нужна лишняя память для заполнение Lista даже если эти данные не понадобятся и лишние вызовы лямд если эти данные уже и не нужны

В большинстве случаев дополнительная память не нужна. В остальных случаях тоже не все однозначно. Ленивый процессинг можно сорганизовать самыми разными способами с производительностью не хуже IEnumerable.
Естественно, я не предлагаю везде заменить IEnumerable массивом. Это стоит делать в числодробилках, когда устраняем узкое место.
Чтото мне подсказывает,через три сообщение напишешь "а ты предлагаешь везде отказаться от IEnumerable и перевести всё на массивы"

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

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

I>>>Количество yield ничего не значит. IQueryable можно прикрутить поверх чего угодно. А раз так, то это и есть общий случай.
S>>А ну да молодец. То есть все твои примеры используют yield но ты переходишь на IQueryable. Но
S>>IQueryable<out T> : IEnumerable<T>, IQueryable

I>Ты пока не показал, как xml, db и подобные вещи читать твоим IEnumerable, что бы это было максимально эффективно.
Ты чего издеваешься!!! Я тебе ссылку на Linq to XML давал!!!!!
I>>>Браво, ты узнал, что Обсервер и Итератор дуальны, а раз так, то можно один сводить к другому.
I>>>Ровно то же можно написать и без yield, с таким же количеством кода.
I>>>вместо yield a будет observer.next(a)
S>> Дохрена чего можно только это все трудоемко.

I>В JS, раз уж ты вспомнил, есть yield. Однако же, в RX процессинг ленивый, а обходятся без yield
I>https://github.com/ReactiveX/rxjs/search?q=yield
I>Ажно 11 раз, и те в документации и тестах
I>Теперь тебе понятно, что yield для RX это вещь сильно опциональная?

Еще раз писать ленивые итераторы это ручная работа того, что делает yield.
Что и как генерит yield копируй и вставляй в код. В свое врямя то же самое развертывался async await в JS

S>>То, что на C# делается в 2 строчки кода, в других надо писать кучу кода. Поэто в большинстве просто используют List

I>Покажи, где здесь куча кода:
I>https://github.com/ReactiveX/rxjs/blob/master/src/internal/operators/filter.ts
И что там фильтры. Аналог Where. Смотри реальный итератор
https://github.com/ReactiveX/rxjs/blob/23bc7fdc16acd76dd71a4faf57b8b949684c3249/src/internal/operators/OperatorSubscriber.ts#L7
В C# это 2 строчки

I>Ровно то же у тебя и в C#, в т.ч. OperatorSubscriber, т.к. ктото должен конвертить последовательность значений в последовательность эвентов.

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

I>Дорого, я в курсе. Иногда это обосновано, если перформанс не актуален, а нужно иметь один и тот же код против разных источников данных.

S>>То ты ратуешь за скорость то сам добавляешь дополнительную сложность и тормоза

I>Ну и логика Я озвучиваю простой факт, а ты додумываешь, будто я весь код так пишу. Ты адекватен?

S>>>> Кто тебе запрещает писать расширения используя yield?

I>>>Ок. Покажи пров для mssql на yield. Валяй.
S>> Я тебе уже кучу привел примеров использования yield

I>То есть, слив Или ты считаешь свой код примерами работы с mssql ?

I>>>Покажи пров для mssql на yield. Хотя бы идею выдай.
S>> Да легко. Получаешь результаты порциями. Держишь на сервере энумератор. Итд

I> Каким образом по IEnumerable построить SQL ?

I>>>Без IQueryable не было бы, да. Именно это позволяет прикрутить Linq к чем угодно. А вот yield для BD — хоть раком встань, ничего не выйдет.
S>>Но деревья выражений не использутся для коллекций!!!

I>Используются, просто ты про это ничего не знаешь. Если код написан для BD, нет никакого смысла городить огород, если в некоторых случая нужно таскать данные из коллекций.
I>Используем один и тот же код против BD и коллекций, всех делов.

Я с тебя хренею. Почитай себя. Все твои доводы против yield.
yield это херня так как не используется в IQueryable. Но IQueryable хотя и не используется в IEnumerable хотя IQueryable наследуется от IEnumerable
Зачем использовать IQueryable для коллекций!!! Только для совместимости в итоге генерить Linq IEnumerable.
Не ну чувствуется подход к опитимизации по скорости!!!

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

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

I>>> Вот еще одно заблуждение. С С++ и джавой ты не знаком?
S>> Ииииииииииииии. Охренительный ответ.
S>> Приводи код!! Знаком и там нет yield там и Linq нет!!

I>Ты адекватен, в джаве Linq искать? Там есть streams, которые покрывают твой любимый linq2objects
I>

I>Employee employee = Stream.of(empIds)
I>      .map(employeeRepository::findById)
I>      .filter(e -> e != null)
I>      .filter(e -> e.getSalary() > 100000)
I>      .findFirst()
I>      .orElse(null);
I>

И. Еще раз там используются ленивые иераторы?
Сколько в итоге будет итераций?
https://stackoverflow.com/questions/21782380/are-java-8-streams-the-same-as-net-ienumerable

You would expect the stream() method to be on Iterable, in the same way as LINQ operates on IEnumerable, but it's on Collection instead. Perhaps it's because Java lacks yield-return semantics, so Iterable is just less interesting or useful in Java.

I>>>А чуть выше ты соскакиваешь с цены в рантайме на цену в разработке.
I>>>Например, когда я пишу, что IEnumerable имеет свою цену, ты начинаешь вещать про разработку.
S>> Какую!!! Ты хоть напиши какую!!!

I>Четвертый раз — вместо x[i] у тебя MoveNext, проход через switch, присваивание Current и чтение Current
I>И вот эта каша крайне плохо инлайнится, а следовательно ест больше чем весит.
I>Заметь — это уже в четвертый раз я пишу, а до тебя не доходит.

Ну в итоге вывод один. Ты против yield, но сам то Linq построен на ленивом создании итераторов.
А yield как раз этим и занимается. Так понятнее.
Для тебя лишние итерации, вызов лямбда выражений, селекты ничего не стоят!!!
S>> Да извини но херню ты как раз пишешь. Никакой конкретики

I>Наоборот. Трижды пишу цену использования энумератор, но ты никак не поймешь.

I>>>Это нужный сахар. И тем не менее его нельзя использовать бездумно. В числодробилках он может давать конские потери.
S>>Причем тут числодробилки! Ты ратуешь за IQueriable. Вон Sinclair пришпондорил Linq.

I>IQueryable нужен там, где будет обработка Expression и нужен единый подход вне зависимости, BD или коллекции.
I>То есть, избавляет от дублирования.
I>Если это не является узким местом для перформанса — используй сколько хошь.

I>>>Именно. Профайлер утверждает, что экономия может быть и полтора, и два, и даже десять раз.
S>>Ну то есть ты за выполнение слева направо.
Где и какой профайлер?? Покажи данные!
I>Откуда такой вывод? Я и слева направо обгоню это IEnumerable с не меньшим бенефитом.
Даааа!! вот твой же пример с миллионами строк пр этом первая же строка удовлетворяе условию.
Вот такие у тебя профайлеры. Но минус то ты мне ставишь!!

S>>же не заставляет использовать тебя IEnumerablt используй IList и обходись без ленивости.

I>Если собираешся итерировать по индексу, лучше запрашивать массив явно — исключается целый класс ошибок.
Даа. А если нужно передать из метода и вернуть из вызываемого метода.
Ты никогда с не работал с пользовательским выбором условий и выводом, когда вариаций куча, а пользователь интерактивно, динамически сам выбирает конструкцию запроса.

S>>Только то вот Linq ленив и ленивость эту в основном создает yield с созданием определенных классов автоматов с сохранением состояния

I>Вот снова ересь — ленивость создаёт сам IEnumerable и никак иначе. Вобщем, каша. То одно пишешь, то другое, прямо противоположное
Нет. Заполнение List не лениво!!!!!
Вот именно, сам разберись. Пока все не в тему. И ну и явно ты не разобрался с темой.
Почитай https://pvs-studio.com/ru/b/0808/#ID4EFF844D56