_>>Ну так ты до этого не понял при чём там хипстеры и менеджеры
Q>Так ведь это ж ты не понял, чем отличается монада от хламидомонады : )
Нет. Это ты сначала написал что не понял при чём там хипстеры и менеджеры и я объяснил. Потом ты не понял при чём там монады, и я объяснил. Сейчас ты решил что всё понял. И сразу про хламидомонады. "Можно я уже пойду?"

Q>Внезапно, код с моноидом в стиле как на видео будет быстрее, чем стандартная лапша с делегатами : )
Ну если для сложения и умножения надо писать стандартную лапшу с делегатами...

* Код выкинут за ненадобностью.
Все и так знают что в C# делегаты сделаны через одно место.

Если мы про производительность в реальной жизни — то иногда случается что в стиле "у нас всё алгебраично" пишут алгоритм сложнее однострочника. Даже на твоём примере — допустим начали с суммы, а потом понадобилось ещё min и max посчитать. В императивном стиле найдут те 3 строчки кода, добавят ещё две и посчитают всё за один проход. В Моноидах знаешь что будет? Сделают ещё парочку моноидов, и вызовут их. И не потому что диверсанты, а просто логика подхода такая. При этом формально всё по фэншую, и сложность останется O(n). А по факту три прохода по памяти далеко не равны одному.
И через год продуктивной работы в таком стиле мы приходим к ситуации когда всё очень красиво. Но безбожно тормозит. И при этом какого-то конкретного боттлнека нету. Открываешь профайлер — а там в топах эти apply, reduce, и т.п. То один лишний проход по памяти, то два. И каждый раз спектр возможных оптимизаций сводятся к отказу от абстракций и объединению мелких кусков в более крупные, написанные в machine-friendly стиле (читай императивно).
В общем я это всё сразу и написал

Автор: hi_octane
Дата: 08.06.20

. Но стоит в объяснении упустить какую-то промежуточную мелочь, и ты сразу решаешь что я что-то не понимаю. Всё наоборот. Когда я эту магию плохо понимал — недостатков вообще не видел, кругом виделись одни сплошные плюсы.

_>>Ну так ты до этого не понял при чём там хипстеры и менеджеры
Q>Так ведь это ж ты не понял, чем отличается монада от хламидомонады : )
Нет. Это ты сначала написал что не понял при чём там хипстеры и менеджеры и я объяснил. Потом ты не понял при чём там монады, и я объяснил. Сейчас ты решил что всё понял. И сразу про хламидомонады. "Можно я уже пойду?"

Q>Внезапно, код с моноидом в стиле как на видео будет быстрее, чем стандартная лапша с делегатами : )
Ну если для сложения и умножения надо писать стандартную лапшу с делегатами...

* Код выкинут за ненадобностью.
Все и так знают что в C# делегаты сделаны через одно место. Генерировали бы они при создании лямбды интерфейс в одним методом .Invoke (как это делает один всем известный язык), и оба подхода работали бы одинаково быстро.

Если мы про производительность в реальной жизни — то иногда случается что в стиле "у нас всё алгебраично" пишут алгоритм сложнее однострочника. Даже на твоём примере — допустим начали с суммы, а потом понадобилось ещё min и max посчитать. В императивном стиле найдут те 3 строчки кода, добавят ещё две и посчитают всё за один проход. В Моноидах знаешь что будет? Сделают ещё парочку моноидов, и вызовут их. И не потому что диверсанты, а просто логика подхода такая. При этом формально всё по фэншую, и сложность останется O(n). А по факту три прохода по памяти далеко не равны одному.
И через год продуктивной работы в таком стиле мы приходим к ситуации когда всё очень красиво. Но безбожно тормозит. И при этом какого-то конкретного боттлнека нету. Открываешь профайлер — а там в топах эти apply, reduce, и т.п. То один лишний проход по памяти, то два. И каждый раз спектр возможных оптимизаций сводятся к отказу от абстракций и объединению мелких кусков в более крупные, написанные в machine-friendly стиле (читай императивно).
В общем я это всё сразу и написал

Автор: hi_octane
Дата: 08.06.20

. Но стоит в объяснении упустить какую-то промежуточную мелочь, и ты сразу решаешь что я что-то не понимаю. Всё наоборот. Когда я эту магию плохо понимал — недостатков вообще не видел, кругом виделись одни сплошные плюсы.