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

I>>Я пишу про те кейсы, где это неуместно. Типа это надо объяснять ?
S>Конечно. Ты только сейчас оговорился, что это бывает уместно, а ты лишь про те кейсы, где это неуместно.

Вот такое, как ты показал, уместно в основном при портировании с другого функционального языка. А вот C# имеет кучу собственных вещей, которые позволяют эффективно работать со списками в функциональном стиле.
Это эффективно в силу особенностей портирования — вместо переписывания есть вариант "скопировать и подправить механически".

I>>Кроме того:
I>> — на кой ляд изобретат велосипед в ЯП с другой парадигмой, где вообще всё построено на других принципах ?
S>Что бы было чем воспользоваться, если, вдруг, понадобились принципы, отличные от безальтернативно предлагаемых в данном ЯП.

Ага, "на всякий случай"

I>> — преждевременная пессимизация "всё и так будет работать" не менее вредна чем преждевременная оптимизация.
S>Убеди количественной оценкой вредности в среднем по больнице на сфероконических проектах.

Ага, "и так сойдёт"

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

Подробнее, какие именно гарантии, если компилер C# те самые гарантии не выдаёт. До кучи, отламывается пошаговая отладка — становится неюзабельной, а так же и другие инструменты. Например, автоматический рефакторинг сильно вряд ли сможет рефакторить твои наколеночные списки.

>Как следствие, упрощает проект. Конечно, я здесь не про всевозможные велосипеды, а за те, которые обладают некими полезными свойствами как персистентность.

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

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

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

I>>Я пишу про те кейсы, где это неуместно. Типа это надо объяснять ?
S>Конечно. Ты только сейчас оговорился, что это бывает уместно, а ты лишь про те кейсы, где это неуместно.

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

I>>Кроме того:
I>> — на кой ляд изобретат велосипед в ЯП с другой парадигмой, где вообще всё построено на других принципах ?
S>Что бы было чем воспользоваться, если, вдруг, понадобились принципы, отличные от безальтернативно предлагаемых в данном ЯП.

Ага, "на всякий случай"

I>> — преждевременная пессимизация "всё и так будет работать" не менее вредна чем преждевременная оптимизация.
S>Убеди количественной оценкой вредности в среднем по больнице на сфероконических проектах.

Ага, "и так сойдёт"

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

Подробнее, какие именно гарантии, если компилер C# те самые гарантии не выдаёт. До кучи, отламывается пошаговая отладка — становится неюзабельной, а так же и другие инструменты. Например, автоматический рефакторинг сильно вряд ли сможет рефакторить твои наколеночные списки.

>Как следствие, упрощает проект. Конечно, я здесь не про всевозможные велосипеды, а за те, которые обладают некими полезными свойствами как персистентность.

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

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