Монада в непрограммировании условий [дубликат]

В непрограммных терминах:

Если F и G - пара смежных функторов, причем F левый смежный с G, то композиция G.F - монада.

Из этого отличного поста Майка Ваньера,

Одна из ключевых концепций в Haskell,

которая отличает его от других языков программирования, является концепция "монады". Люди считают, что это сложным для изучения (я тоже), и в результате в сети появилось множество учебников по монадам в Интернете, некоторые из них которые очень хороши (мне особенно особенно нравится "Все о монадах" Джеффа Ньюберн). Говорят даже, что написание учебника по монадам - это обряд для новых программистов на Haskell. Однако, одна большая проблема многих учебников по монадам заключается в том, что они пытаются объяснить, что такое монады, ссылаясь на существующие концепции, которые читатель уже понимает (я даже видел это в презентациях Саймона Пейтон-Джонса, главного автора компилятора GHC и генерального гранда Хаскеля). ). Это ошибка, и я расскажу вам, почему.

Естественно, когда пытаешься объяснить. что такое что-то, объяснять это с помощью ссылаясь на вещи, о которых другой человек о которых другой человек уже знает. Это хорошо работает когда новая вещь в чем-то похожа на то, с чем другой человек с которыми другой человек уже знаком. Он полностью разрушается когда новая вещь полностью из опыта человека. изучающего его. Например, если бы вы пытаетесь объяснить, что такое огонь пещерному человеку, который никогда не видел огня, что бы вы сказали? "Это что-то вроде нечто среднее между воздухом и водой, но но горячая..." Не очень эффективно. Аналогично, объяснение того, что такое атом в терминах квантовой механики проблематично, потому что мы знаем, что электрон не действительно вращается вокруг ядра, как планета вокруг звезды, и понятие "делокализованное электронном облаке" на самом деле не означает многого. Фейнман однажды сказал, что никто по-настоящему не понимает квантовую механику, и на интуитивном уровне это правда. Но на математическом уровне квантовая механика хорошо понятна; мы просто у нас нет хорошей интуиции для того. что на самом деле означает математика.

Как это связано с монадами? Время снова и снова, в учебниках, сообщениях в блогах и в списках рассылки по Haskell, я видел, что монады объясняются одним из двух якобы интуитивно понятных способов: монада - это "как бы действие" или "как бы как контейнер". Как может что-то быть одновременно действием и контейнером? Разве это не отдельные понятия? Является ли монада - это своего рода странный "активный контейнер"? Нет, но дело в том, что утверждение, что монада - это вид действие или своего рода контейнер, является неверно. Так что же такое монада?

Вот ответ: Монада - это чисто абстрактное понятие, не имеющее фундаментального отношения к чему-либо о чем вы, вероятно, когда-либо слышали раньше. Понятие монады происходит из теории категорий, которая является самая абстрактная ветвь математики, которую я которую я знаю. На самом деле, весь смысл теории категорий заключается в том, чтобы абстрагироваться от всей структуры математики, чтобы выявить сходства и аналогии между, казалось бы, несхожими областями (например например, между алгеброй и топологией), чтобы сжать математику до ее фундаментальных и, таким образом, сократить избыточность. (Я мог бы продолжать об этом довольно долго. долго, но лучше вернусь к тому. к тому, что я пытаюсь сделать). Поскольку я предполагаю, что большинство программистов изучающих Haskell, не знают многого о теории категорий, монады не будут для них ничего не значат. Это не означает, что им нужно изучить всю теории категорий, чтобы использовать монады в Haskell (к счастью), но это означает, что означает, что им нужно научиться думать о вещах в более абстрактным способом, чем они, вероятно. привыкли.

Пожалуйста, перейдите по ссылке в верхней части поста, чтобы прочитать полную версию статьи.

На практике большинство монад, с которыми я работал, ведут себя как своего рода неявный контекст.

Это как когда вы с другом пытаетесь поговорить об общем друге. Каждый раз, когда вы говорите «Боб», вы оба имеете в виду одного и того же Боба, и этот факт просто неявно передается в вашем разговоре из-за того, что Боб является вашим общим другом.

Вы, конечно, можете поговорить со своим боссом (а не с другом) о вашем менеджере пропущенного уровня (не о друге), которого случайно зовут Боб. Здесь вы можете провести еще один разговор, опять же с некоторой подразумеваемой коннотацией, имеющей смысл только в контексте разговора. Вы даже можете произносить те же слова, что и в разговоре с другом, но они будут иметь другое значение из-за разного контекста.

То же самое и в программировании. То, как tell ведет себя, зависит от того, в какой монаде вы находитесь; способ сбора информации ( >> = ) зависит от того, в какой монаде вы находитесь. Та же идея, другой способ общения.

Черт возьми, даже правила разговора могут быть монадическими. «Не говори никому, что я тебе сказал» скрывает информацию точно так же, как runST предотвращает экранирование ссылок из монады ST .Очевидно, что у разговоров могут быть слои и слои контекста, точно так же, как у нас есть стеки преобразователей монад.

Надеюсь, что это поможет.

Ну, вот хорошее подробное описание монад, которое определенно находится за пределами программирования. Я знаю, что это вне программирования, потому что я программист и не понимаю даже половины того, о чем там говорится.

На YouTube также есть серия видео, объясняющих монады этого типа - вот первое в последовательности.

Я предполагаю, что это не совсем то, что вы искали, хотя...

Есть ли какая-то концепция / вещь вне программирования (вне всего программирование, а не только FP), которые можно сказать, действующие или монадоподобные в существенным образом?

Да, действительно существует. Монады совершенно напрямую связаны с «возможностью» в модальной логике посредством расширения изоморфизма Карри-Ховарда. (См .: Судебная реконструкция модальной логики. )

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

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

С этой точки зрения монада p означает «в возможном достижимом мире из текущего мира».

В частности, если t является типом, то:

x :: t означает, что что-то типа t напрямую доступно в текущем мире
y :: pt означает, что что-то типа t доступно в мире, доступном из текущего

Затем return позволяет нам использовать текущий мир как достижимый.

return :: t -> p t

И >> = позволяет нам использовать что-то в доступном мире, а затем достигать дополнительных миров из этого мира.

(>> =) :: pt -> (t -> ps) -> ps

Итак, >> = можно использовать для построения пути в достижимый мир из более мелких путей через другие миры.

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

Для непрерывности достаточно двух миров - обычного и бесконечно далекого будущего. (Применение >> = со вторым миром разрешено, но вы вряд ли заметите, что происходит в этом мире.) Для монады продолжения мир остается таким же, когда продолжения используются нормально, и есть дополнительные миры, когда они нет (например, для callcc).

Это зависит от того, с кем вы разговариваете. Любое объяснение должно быть подано на нужном уровне. Мое объяснение инженеру-химику будет отличаться от объяснения математику или финансовому менеджеру.

Лучший подход - связать это с чем-то из опыта человека, с которым вы разговариваете. Как правило, последовательность действий - это довольно универсальная проблема, поэтому постарайтесь найти что-то, о чем знает собеседник, где вы говорите "сначала сделайте X, затем сделайте Y". Затем объясните, как обычные языки программирования сталкиваются с этой проблемой; если вы говорите компьютеру "сначала сделай X, потом сделай Y", он немедленно делает X и Y, не дожидаясь дальнейших действий, но он не может в это время сделать Z для кого-то другого; представление компьютера о "сначала сделай X, а потом сделай" отличается от вашего. Поэтому программисты должны писать свои программы иначе, чем вы (эксперт) объяснили бы это. Это создает разрыв между тем, что говорите вы, и тем, что говорит программа. Преодоление этого разрыва стоит времени и денег.

Монады позволяют вам вложить в компьютер свою версию "а затем сделать", так что вы можете сказать "сделать X, а затем сделать Y", а программист может написать "сделать {x ; y}", и это будет означать то, что вы имеете в виду.

Мне нравится думать о них как об абстракциях вычислений, которые можно "связать". Или, буррито!

Да, монады происходят из концепции вне haskell. В Haskell есть много терминов и идей, которые были заимствованы из теории категорий. Это одна из них. Так что если этот человек, который не является программистом, окажется математиком, который изучал теорию категорий, просто скажите: "Монада - это моноид в категории эндофункторов"

Да, есть несколько вещей вне программирования, о которых можно сказать, что они похожи на монады. Нет, ни одна из них не поможет вам понять монады. Пожалуйста, прочитайте Абстракция, интуиция и "заблуждение учебника по монадам":

Джо Хаскеллер пытается узнать о монадах. После того, как он пытался понять их в течение недели, рассматривал примеры, писал код, читал то, что написали другие люди, у него, наконец, наступает момент "ага!": все вдруг становится ясно, и Джо понимает монады! На самом деле, конечно, произошло то, что мозг Джо соединил все детали в абстракцию более высокого уровня, метафору, которую Джо может использовать для интуитивного понимания монад; предположим, что метафора Джо звучит так: "Монады - это как буррито". Здесь Джо сильно ошибается в понимании своего собственного мыслительного процесса: "Конечно!" думает Джо. "Теперь все так просто. Ключ к пониманию монад в том, что они похожи на буррито. Если бы я только подумал об этом раньше!". Проблема, конечно, в том, что если бы Джо и подумал об этом раньше, это бы не помогло: неделя борьбы с деталями была необходимой и неотъемлемой частью формирования интуиции бурито Джо, а не печальным следствием того, что он не додумался до этой идеи раньше.

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

Как я уже давно сказал в другом ответе, статья sigfpe You Could Have Invented Monads! (And Maybe You Already Have.), а также оригинальная статья Филипа Вадлера Монады для функционального программирования, обе являются отличным введением (которые дают не аналогии, а множество примеров), но после этого вы просто продолжаете кодить, и в конце концов все это покажется тривиальным.

[Не совсем верный ответ: Одно место, где монады существуют вне программирования, конечно, в математике. Как указывает этот уморительный пост, "монада - это моноид в категории эндофункторов, в чем проблема?" :-)]

Edit: Автор вопроса, похоже, интерпретировал этот ответ как снисходительный, сказав что-то вроде "Монады настолько сложны, что не поддаются аналогии". На самом деле, ничего подобного не подразумевалось, и именно монады-аналогии часто кажутся снисходительными. Возможно, я должен переформулировать свою мысль так: "Вы не обязаны понимать монады". Вы используете определенные монады, потому что они полезны - вы используете монаду Maybe, когда вам нужны типы Maybe, вы используете монаду IO, когда вам нужно сделать IO, аналогично другие примеры, и очевидно в C#, вы используете паттерн Nullable<>, LINQ и понимания запросов, и т.д. Теперь, понимание того, что существует одна общая абстракция, лежащая в основе всех этих структур, которую мы называем монадой, не является необходимым для понимания или использования конкретных монад. Это то, что может прийти после, после того, как вы увидели более одного примера и узнали закономерность: обучение идет от конкретного к абстрактному. Прямое объяснение абстракции, путем обращения к аналогиям самой абстракции, обычно не помогает ученику понять, что является абстракцией.