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

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

S>>Конкретный мой код — и "библиотеки всерьёз написаные в подобном стиле".. Мы явно о разных вещах говорим.

I>Ну да — в одном месте ты пишешь, что все в порядке и тут же добавляешь, что это всё только для блога
Мой пример и подобное ему — для блога, т.к. это не библиотека. И нормально работать (с большими данными) это может лишь за счет стека, который ограничен, т.к. в C# до сих пор не завезли хвостовую оптимизацию. Обработать 4 сообщения в день в наколенной поделке — подойдет более чем. В продакшн коммерческого продукта совать это не предлагаю. Так понятно?
Однако, против серьезных библиотек ничего не имею. Особенно, если в них есть трамполайны.

S>>Странное требование к коду, ну да ладно. В продакшне список дополняется на раз двумя методами в/из IEnumerable. Если работа рефакторингом с IEnumerable тебя устраивает, то проблем не вижу более.

I>А зачем мне эта кунсткамера если у меня и так есть IEnumerable и там уже есть иммутабельная модель вычислений? Каким образом оценить профит ?
Зачем тебе — это ты решай. Я тебе это не навязываю.
I>Аргумет "я так пишу и у меня классно" не катит. Нужна проверка временем и массами. Массы подхватили — значит это экономически состоятельно. Если нет — значит в топку.
Для меня массы не аргумент. Своя голова есть. И массы ничего и никогда не подхватят, если в массах будут лишь те, кто апеллирует к проверке массами.

I>>>Если ты про IImmutableList, то это используется местечково. Я как то не встречал больших приложений, что бы вся модель была персистентая, обычно толко кое какие части.
S>>Определись, нужно или не нужно? Может быть достаточно местячково, там, где это действительно нужно?

I>Если местечково, то хочется обоснования, почему это лучше IImmutableList и IEnumerable.
Пост назад ты рассуждал об использовании IImmutableList, но теперь спрашиваешь меня, чем ЭТО лучше, чем IImmutableList. Потерял контекст? Бывает.

I>>>Сможешь сходу представить, как будет выглядеть персистетный аналог DOM ? html dom, xml dom, etc dom и как будет выглядеть код вида "удалить элементы в поддереве по признаку xxx"? И далее, как будет выглядеть вызывающий код.
S>>Код вида "удалить элементы в поддереве по признаку xxx" будет выглядеть не сложнее, чем фильтрация IEnumerable в Linq.

I>Фильтрация в линке простая за счет yield. В DOM тебе нужно гарантировать, что пересоздадутся все узлы выше уровнем. Они ведь тоже иммутабельные. И рут пересоздаётся.
Пересоздадутся не все узлы выше уровнем, а только лишь те, которые имеют прямую связь с измененными данными. Или мы по разному понимаем уровень узла. Обычно под уровнем узла подразумевают число переходов до рута. И пересоздавать требуется лишь те узлы, которые стоят на пути от рута к изменению.
I> А теперь как быть с теми, кто удерживает ссылки на старые элементы ? Теперь такое удержание или ой-ой, или специальное решение нужно.
Полагаю, если ты удерживаешь ссылку на неизменяемый элемент, который может устареть и никто тебе об этом не скажет, то ты знаешь, что и зачем делаешь. При желании отслеживать изменения в элементе нужен способ найти этот элемент в новой версии документа.
I>То есть, речь уже про вполне конкретную архитектуру решения а не только списки.
Неужели с git-ом не знаком?

S>>В сикпе этот код понимают студенты, которые кроме факториала и метода Ньютона ничего не видели. Какие там еще все алгоритмы проекта, который они еще не писали?

I>1 Факт #1 В обычных универах нет СИКП, там дают совсем другие вещи.
Очень жаль, но это так.
I>2 Факт #2 Сикп дается в самых продвинутых, где а. жосткий отбор б. лушчие преподаватели
Сикп не преподается нигде. В программе MIT его уже нет много лет.
I>3 Факт #3 Большинству людей на рынке труда до СИКП как до луны.
Это не отменяет того, что материал Сикп преподавался далеким от IT людям с первого семестра. И большинство меня беспокоит лишь тем, что оказывает влияние на детей, которые на них ориентируются.

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

I>Ну вот ты слился на понты То есть, твои утверждения про студентов и замыкания можно игнорировать как несостоятельные, раз ты перешел к такой тактике.
Я лишь еще раз обозначил уровень моего восприятия твоей аргументации про большинство на рынке. И слегка включил тролля, что бы наверняка проняло.
Собственно, мои утверждения о студентах и замыканиях — это факты, которые очень легко проверить. Но да, тебе можно их игнорировать. Не могу же запретить. И продолжай апелляции к большинству. Очень интересно и поднимает мотивацию делать что-то не как большинство.