Разбираемся с монадами с помощью Javascript

[e_asphyx]

Зачем ломать голову над тем, что непонятно? Ну не лежит душа, и фиг с ним, с Хаскелем.

[maxatwork]

Странный подход, мне вот наоборот — непонятное обычно кажется очень интересным.

[e_asphyx]

Интересно — это когда вау-эффект. Когда чувствуешь, что это круто. А это головоломка ради головоломки.

[maxatwork]

Был код с побочными эффектами, стал без побочных эффектов, не потеряв в красоте и элегантности — по мне так очень круто и вау-эффект.

[Ataraxer]

Это не вау-эффект. Это типобезопасное программирование без NullPointerException'ов, например.

[MostovenkoAlexander]

путь джедая опасен и тернист…

[mayorovp]

Мне кажется, шаги здесь немного перепутаны: каррирование надо делать раньше перехода к продолжениям, иначе продолжения выглядят бессмысленно.

[SamKrew]

Так вот оно как оказывается называется.

[gatoazul]

Сначала из языка выкидывается состояние как вредное, опасное и чреватое ошибками. Потом оно тайком вносится в язык, только обернутое плотным туманом ничего не делающих функций, вызывающих функции и передающих им функции, а под этим флером скрывается банальное копирование всех меняющихся объектов с тайным убиением старых, чтобы никто не заметил, что смена состояния из отдельных объектов переносится в смену состояния всей исполняющей системы.

Таким образом, мы приходим все к тому же банальному а:=2, но выполненному per anum, требующему x10 ресурсов для своей работы, непонятному для простых смертных и сакральному для непростых.

Автору и переводчику спасибо за то, что тайное сделали явным.

[MostovenkoAlexander]

Состояние остается, выкидывается только изменяемое состояние.

[gatoazul]

Вы правы. К сожалению, отредактировать уже нельзя. Так что следует читать: «выкидывается изменяемое состояние»

[mikhanoid]

Там ничего не выкидывается. Просто изначально, в математической модели языка, никаких изменяемых состояний нет. Монады его в язык опять же не вносят. Монады — это просто один из pattern-ов функционального программирования, чтобы вручную не протаскивать аргументы между вызовами функций.

А сразу сделать изменяемые состояния с сохранением строгости математического подхода не получается. Не умеет математика адекватно описывать изменяющиеся сущности (пока или принципиально — это вопрос). Если пытаться начать это делать, всё равно, придём к тому, что надо будет описывать состояние системы какой-нибудь функцией, задающей значения в ячейках памяти, менять эту функцию целиком при записях, протаскивать её между операторами (для этого как раз монады и нужны) и т.д. и т.п.

Так что, корень проблемы в математике и в том, как мы формально рассуждаем, а совсем не произволе авторов Haskell.

[gatoazul]

Скорее, корень проблемы в неумеренном пиаре языка Хаскель как очередной панацеи и must-know. Впрочем, ни язык, ни его авторы в этом не виноваты — это был всего лишь эксперимент.

[mayorovp]

Вынесенное состояние, которое затем внесли обратно через монады и линзы — это не только лишняя сложность, но и удобная абстракция.

Для таких состояний проще хранить историю, реализовывать операцию отмены, такое состояние проще сохранять в файл…

[gatoazul]

Достаточно спорно. В приведенной статье исходный стек сохраняется в файл банальным образом. А вот последняя версия — сразу и не сообразишь как.

[mayorovp]

Пока стек один — да. Как только объектов, хранящих в себе состояние, становится много — уследить за всеми сложнее. Хотя тоже возможно, не спорю.

[gatoazul]

Вы имеете в виду, если они будут ссылаться друг на друга? Не приведете ли пример, как эту проблему решают в чистом ФП?

[sekrasoft]

Главная причина, почему на Haskell это выглядит лучше, это поддержка монад на уровне синтаксиса в виде do-нотации.

С помощью ловкости рук и небольшого мошенничества с eval можно реализовать что-то подобное на JS и писать код вида:

var getUser = eval(async(function (eMail) {
  id <- db1.getID(eMail);
  user <- db2.getData(id);
  return user;
}));

Это оказалось побочным эффектом идеи, с которой я пришёл на хабр.
P.S. maxatwork, спасибо большое за перевод интересной статьи!