В чём практическая полезность монад?

  1. потратил время и внимательно просмотрел курс по предмету “Теория категорий”:
    Tеория категорий. Лекция 1 (Виталий Брагилевский) - YouTube

  2. прочитал определение монады в википедии:
    Монада — Википедия
    Теория категорий — Википедия
    «Монада — эндофунктор с парой естественных преобразований в теории категорий»
    мне тут понятны все слова.

Основные понятия (слова с определениями):

объект
морфизм (стрелка)
и его разновидности
категория
функтор
и его разновидности
монада

Ок. Посмотрел видео

тут (невнятно) показывается, какая связь между паттерном программирования и понятием монады из теории категорий.

Не штырит! Непонятны мне преимущества всем сердцем. Смутно всё как-то и недоказано.
Наверное это аналогично ситуации с динамической и статической типизацией, очевидно, что статическая лучше, но не всем людям.
Вот мне не очевидна полезность монад. То есть может с ними и лучше, но фанатичной веры/уверенности нет. Из-за отсутствия достаточно полного понимания.
«Monads can also improve code readability and maintainability»
Мне непонятно, за счёт чего и каким образом это происходит, повышаются эти метрики.
То, что кривая обучения удлиняется, это я вижу.

Перечисляются области использования:

повышение уровня абстракции
повышение единообразия
«monads can also improve code modularity and reusability by providing a consistent interface for working with different types of computations»
повышение читабельности кода
«monads can simplify the code and make it easier to reason about and maintain»
формализация сторонних эффектов
«They provide a higher level of abstraction that allows architects to focus on the core logic of the application without getting bogged down in the details of managing side effects»
обработка исключений
обработка ошибок
управление состоянием
управление потоком выполнения
«they provide a way to manage and control the flow of complex computations»
«работа с асинхронными и параллельными операциями (dealing with asynchronous and concurrent operations)»
упрощение тестирования
«Monads can help with handling different test scenarios, managing test data, and handling test dependencies»

«способ управления побочными эффектами (a way to manage side effects)»
«монады позволяют разделять проблемы/аспекты/вопросы (better separation of concerns)»

«использование монад это подход, который структурен и аддитивен (композируем)»
«обработка сложных вычислений регулярным способом (handle complex computations in a structured manner)»

В общем, я ничего не понял, что тут сказали (видимо в силу недостаточности практики использования этого паттерна для разных целей). Что делать?

Про программистские Monad (functional programming) - Wikipedia

Они много где есть, просто не всегда называются монадами.
Например, промисы и подобные штуки в разных языках (Task в C#). https://javascript.plainenglish.io/monads-for-javascript-developers-af29819823c
Сильно упрощают асинхронный/многопоточный код, не надо путаться в колбэках внутри колбэков внутри колбэков.
Еще встречается в LINQ в C#. Tasks, Monads, and LINQ - .NET Parallel Programming

Да, ту английскую статью про монады я тоже читал, и русская ещё есть, программистская, а не философская.

Сразу ещё ссылок насыплю, чтобы второй раз не упоминать:
https://wiki.haskell.org/Monad
https://wiki.haskell.org/All_About_Monads
https://www.haskell.org/tutorial/monads.html
(их я тоже умеренно прочёл)

Я рад за наличие различных фич в разных местах (ещё исключения в C# и структурированные в C++/Windows тоже немного монады).

Аднако, это совсем не то, что я хочу/ожидаю услышать. А сформулировать что не так, я не могу, иначе бы я понял.

GptChat: В языке C# монады не используются напрямую для работы с многопоточностью и синхронизацией доступа. Однако, можно использовать некоторые практики и принципы функционального программирования, включая монадические концепции, для облегчения работы с многопоточностью и синхронизацией в C#.
Монады не являются прямым инструментом для синхронизации и работы с многопоточностью в C#, принципы функционального программирования, такие как асинхронное программирование, атомарные операции и параллельные коллекции, могут быть использованы для упрощения работы с многопоточностью и синхронизацией в C#.

«Посмотрите, сколько мусора натащил сишарп, чтобы выразить простую идею “Сделай что-нибудь, а затем сделай что-нибудь еще”. И асинк-авейт, и LINQ, и null propagation являются частными случаями общей идеи.»

«А еще большая проблема различного синтаксиса в том, что это всего лишь сахар: ту же функцию MapAnyFunctor написать в текущем сишарпе не выйдет. Мы годами ждали фичу async enumerable, которую наконец-таки релизнули (как всегда с кучкой костылей, все ведь например уже в курсе магических атрибутов для CancallationToken?), но сколько лет мы её ждали? Сколько человеко-лет понадобилось, чтобы её реализовать?»

«Если вы думаете, что сишарп в этом плане выделяется, то спешу вас обрадовать: это не так. Тот же Rust с удовольствием прошелся по тем же граблям, и продолжает идти. Сюда относятся: и try-блоки, и Try-трейт, и всё тот же элвис-оператор, а асинк-авейт. Уверен, в будущем кортима раста будет еще годами запиливать async enumerable»

«в хаскелле для параллелизации есть монада Par»
https://hackage.haskell.org/package/monad-par
https://hackage.haskell.org/package/monad-par-0.3.5/docs/Control-Monad-Par.html

ну дык вот например потому что вместо многоуровневых вложений колбэков в многопоточности будет что-то типа

...then(step1).then(step2)......catch(handleError)

или еще удобнее async/await.

Только что выше дал ссылку на статью, которая говорит, что сахар async/await неудобный. И вообще сама опора на неизмеримые термины “удобный”/“неудобный” неправильная.