SB

Я сейчас рассказываю про вещь, которую сам плохо знаю, т.к. уверенно использовать всё это я так и не научился.

Основной идеей вокруг монадок (с точки зрения software engineering) является такая формулировка типов, которая позволяет описывать реальный мир с высоким формализмом (т.е. без "подхачили бизнес-логику в самом сердце DSL'я, чтобы у клиента 1213 не списывались деньги раньше срока").

Ярким примером является энкапсуляция ошибок и обязательности возможности наличия данных - монадки Must и Maybe. Типы данных требуют для Maybe, чтобы все обработчики этих данных умели обработать случай None (т.е. реальных данных нет), а Must - не даст сделать код, который "иногда, очень-очень редко" вернёт None вместо файлового дескриптора.

Ещё интереснее обработка ошибок. Если мы описываем монадку, которая состоит из Data|None|Error, то если мы в каком-то месте забудем сказать, что делать если там ошибка (например, на пятом уровне по стеку вверх), то программа не скомпилируется.

Отсюда поговорка "компилируется, значит работает" (что неправада в контексте правильности алгоритма, но более-менее правда в вопросах "всё предусмотрели и нет неопределённых поведений").

Принудительное разделение на "чистый" код и код в монадке IO позволяет легко рефакторить этот самый чистый код, потому что его элементарно покрыть тестами и там нет ничего, чтобы могло "сломать что-то другое".

Другими словами, с точки зрения инженерной практики, это набор машинно-enforced правил, которые позволяют избежать дурацких ошибок и "плохо продумал", но при этом не слишком тормозят процесс бюрократизацией.

Ах, да, ещё pattern matching - это когда у компилятора достаточно информации о типах, чтобы сказать, что мы "забыли" какой-то из case'ов в switch'е (если на сишном языке говорить).

От массового расползания по индустрии его останавливает только взрывание мозга у обучающихся. А кусочки проползают в новые языки (тот же Rust - на монадках, только слова такого не произносят).