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

_>Нет. Это ты сначала написал что не понял при чём там хипстеры и менеджеры и я объяснил. Потом ты не понял при чём там монады, и я объяснил.

А я объяснил, почему твоё объяснение некорректное. Про straw man не только к AlexRK относилось, но и к тебе в первую очередь; почитай, пожалуйста.

_>Сейчас ты решил что всё понял.

Да, я всё понял: ты слышал звон, но не знаешь, где он. M-word — эта сложна! Нипанятна! А, речь не про этот M-word?.. Всё равно от лукавого, буквы-то те же! Нафиг не нужон моноид ваш!

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

Хоть по этому вопросу возражений нет.

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

Если при использовании IMonoid<T> непременно такие сложности возникнут, то они же неизбежно должны возникнуть и при использовании интерфейса IEqualityComparer<T>? Сценарии использования у них ведь строго одинаковые.
Или ты из тех же соображений отказался от IEqualityComparer<T>?