Q>А я объяснил, почему твоё объяснение некорректное. Про straw man не только к AlexRK относилось, но и к тебе в первую очередь; почитай, пожалуйста.
Корректное. Просто тебе не нравится сама мысль о том что кто-то может прекрасно знать M-words и при этом весьма скептически на них смотреть. Я в первом же утверждении написал "людям сначала нравится элегантность и единообразность монад, моноидов и этого всего". И продолжаю придерживаться этого тезиса. Для меня эти конструкции одинаково "заражают" код. Решают местечковую проблемку, но порождают другую, которая на дистанции только растёт.

_>>Сейчас ты решил что всё понял.
Q>Да, я всё понял: ты слышал звон, но не знаешь, где он. M-word — эта сложна! Нипанятна!
Ну вот пруф. Ты решил что мне именно "сложна и нипанятна". Представить что кому-то кроме достоинств понятны и недостатки — пока никак.

Q>А, речь не про этот M-word?.. Всё равно от лукавого, буквы-то те же! Нафиг не нужон моноид ваш!
Это то что ты понял. А то что там было написано: "эти абстракции порождают похожие проблемы в большом проекте".

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

Q>Если при использовании IMonoid<T> непременно такие сложности возникнут, то они же неизбежно должны возникнуть и при использовании интерфейса IEqualityComparer<T>? Сценарии использования у них ведь строго одинаковые.
Разные. Компаратор очень ограничен в возможностях. Предел комбинирования для компараторов — библиотечка OrderBy...ThenBy, и всё. Новые экземпляры T компаратор не порождает. Моноиды гибче и в терминальной стадии распространения могут заменять собой не то что IEqualityComparer, а даже просто IComparer.