Но это не обязательно делать через монады.

Мне лично кажется, что для плюсов естесвеннее были бы scoped-continuationы.

Ну серьёзно плюсы уже язык со стейтом. Зачем мне может понадобиться монада со стейтом?

Эта концепция тоже выражается через монаду Cont. Вот посмотрите, вместо того, чтобы вводить эти концепции как отдельные синтаксические конструкции, можно было бы ввести монады, и все перечисленное (и даже больше) получить в виде библиотеки.

Стейт императивный непотокобезопасен. "Стейт", предоставляемый монадой State - потокобезопасен.

Хорошо, почему программисты продолжают использовать unsfePerformIO, продолжают использовать runST для вытаскивания значений из памяти.

Но у нас _другой_ язык.

Это неважно. Ни у кого нет мандата насаждать использование C++ так, как ему хочется. Если для кого-то неидеоматичный С++ решит проблему с ФП дешевле, - его будут использовать. И такие примеры есть, посмотрите хотя бы на то, что делает @DenisKormalev . Оставаясь в одной догме "Это не по правилам языка!" можно не заметить интересных решений, которые могут подойти конкретно здесь. Например, что если я вам скажу, что boost::spirit - это плохо? И что монадические парсеры могли бы сделать парсинг более приятным и легким? Ведь есть задачи, в которых нельзя отказаться от С++, но где позволительно выбрать такой подход, который избавит от проблем в будущем, и не важно, является ли он zero-cost или нет. Пока ниша С++ активно подвергается атаке со стороны других экосистем, новые идеи могут все еще удержать его в некоторых областях, поэтому - why not?

Why not? Потому что это core-фича языка. Не платить за то, что не используешь. С монадами притащится новый механизм обработки ошибок, когда в языке уже есть один. Притащится новый контрол флоу без циклов, но с рекурсией.

С этим никто не спорит. Речь о том, чтобы не тащить это в стандарт.

Why not? Потому что это core-фича языка. Не платить за то, что не используешь. С монадами притащится новый механизм обработки ошибок, когда в языке уже есть один. Притащится новый контрол флоу без циклов, но с рекурсией.

Не знаю насчёт Александра, но я видел пару пропозалов на добавление do-нотации в язык.

Это не главная мотивация монад сегодня. Позвольте пояснить. Изначально в Хаскеле был странный и неудобный способ делать эффекты. Все из-за него страдали, и он ощущался как костыль. Потом пришел Вадлер и товарищи, и они придумали, что тут очень подходит концепция монад из некоей математической теории. Попробовали применить, - пришлось переосмыслить, что есть чистое и нечистое в Haskell. Придумали "RealWorld" как некое немутабельное состояние, над которым эта монада (IO) бы работала. Потом придумали do-нотацию, чтобы сократить запись. А потом началось. Люди поняли, что монады - гораздо более полезный инструмент, чем просто обслуживать цепочку вычислений с эффектами ввода-вывода. Оказалось, что они эффективно выражают различные концепции, такие как состояние, а do-нотация еще и делает код кристально чистым. И монады стали ценны не потому, что они закрывают какую-то там дыру в дизайне Haskell, а потому, что являются мощной абстракцией, паттерном если хотите, который упрощает код в разы. Так, с их помощью можно избавиться от callback hell, можно сделать асинхронные вычисления не хуже, чем с async / await, которые в других языках являются частью синтаксиса. Можно хэндлить ошибки в цепочке операций (Either; в C++ это std::expected), можно явно выражать отсутствующее значение (Maybe; в С++ это std::optional), и тоже связывать операции-возможно-без-значения в цепочку, не перегружая код. А в последствии еще увидели, что с помощью монад можно делать полный аналог Dependency Injection. И нет, иметь переменные - это не мотивация для монад в Haskell. Зачем это в С++? По тем же причинам. С помощью монад упрощается код, который ранее мы бы писали очень развесисто. Посмотрите, например, на Go-шников с их вездесущей проверкой результата на err. И хотя в С++ есть исключения, возврат ошибок все же используется, и вот такой код может быть значительно упрощен для чтения и понимания с помощью монады. С помощью монад можно писать более надежный и предсказуемый код. Там, где обычный набор инструкций позволяет допустить ошибку по невнимательности, например, программист не обработал результат функции, монадический код это не позволит. Просто потому, что проверка результата функции будет вшита в конкретную монаду (std::optional, std::expected), и потому "пройти мимо" уже будет нельзя. Или взять std::future. С помощью монадического связывания очень легко пишется такой код, где таски будут вычисляться либо одна за одной, либо параллельно: программист, оперируя монадическими функциями, выбирает, что ему нужно. При этом ему не нужно специально писать, какую фьючу когда надо дождаться, где синхронизоваться и куда передать дальше. Он просто пишет монадический код, а соответствующая монада возьмет эти манипуляции на себя и сделает их "в бэкграунде". Это очень удобно, так как по сути, программист лишь работает со своей вычислительной моделью, которая не "загрязнена" деталями от std::future. На дворе 2018 год. Без монад уже нельзя, потому что более мощной и полезной абстракции еще не рождалось за последнее двадцать лет.

даже в 2018 в эмбеддеде и системном программировании обходятся без монад, скорее всего есть какая-то причина, абстракция не всегда хорошо

даже в 2018 в эмбеддеде и системном программировании обходятся без монад, скорее всего есть какая-то причина, абстракция не всегда хорошо

Мой поинт в том, что может быть плюсы плохо подходят для монадических вычислений. Почему бы просто не писать на Хаскелле? (или на других языках, которые я здесь скромно не буду рекламировать)

Да чо там рекламировать? Раст все знают. :D

стейтфул это каковские? у меня с английским не очень, всмысле прикладные? реальные?

Мой поинт в том, что может быть плюсы плохо подходят для монадических вычислений. Почему бы просто не писать на Хаскелле? (или на других языках, которые я здесь скромно не буду рекламировать)

В плюсах огромное количество более срочных дизайн проблем. Поэтом мне просто кажется нереалистичным в скором времени ожидать что-то такое в языке.

в с++ строгая типизация, так в википедии написано, в си слабая

Стейтфул — это в противовес стейтлесс. Языки с состоянием, с моделью вычисления на машине Тьюринга, а не с моделью типизированного лямбда-исчисления как в Хаскеле.

А я не про него.

Про golang?

эти ваши монады еще небось и на шаблонах все, бинарник на 100 мегабайт небось потом получается

Не. Свой язык уютный разрабатываем, куда я активно тащу фп фичи.

а потом постоянные подгрузки в кеш инструкций процессора все тормозят

котлин штоле? ты из житбрейнс?

Да, тут надо признать, что оптимизации, сделанные в С++, совсем не рассчитаны на такой код. Так что ФП, по-видимому, будет менее производителен по многим причинам.

Хаскелль тоже вынужден тормозить в рантайме из-за этого.

В каком-то смысле да. Однако быстрые вещи в ФП тоже есть, и с ними можно добиться очень интересных результатов. Например, взятие MVar стоит пару десятков наносекунд. Хотелось бы, например, сравнить со взятием std::mutex в С++.

А есть ли все еще код на С++ в местах, которые не требовательны к производительности? Или из этих ниш его вытеснили другие языки?

Я здесь вижу некоторую проблему. ranges и кое-какие другие фичи (корутины) явно таргетированы на С++ "клиентского уровня", вроде десктопных приложений или какого-нибудь бэкенда. Но если в этих нишах доля С++ сокращается, то значит, польза от нововведений будет все меньше и меньше?