Виталий Брагилевский — Монады - не приговор

[Pavel]

Виталий, делайте еще. Очень классно и понятно.

[alexanderrudenko]

Я посмотрел видосов 5-7 типа про монады, я почитал разные статьи-попытки объяснить монады. И, наконец, я получил простое и очень-очень понятное объяснение, что такое монады, и как это используется!!! Потрясающий доклад!!! Огромное спасибо!!!

[Iaxls]

Шикарный доклад! Просто лучший про монады!

[МишаМихаил-фх]

Доклад- золото!, На одном дыхании хоть я и питонист

[shoomillion]

Великолепное видео, которое расставило всё по местам. Разумеется, я прочитал и другие источники и, возможно, это видео стало ключевым просто потому, что у меня уже был бэкграунд "непонятных" источников за спиной. Но чёрт возьми, вот теперь я точно понимаю что такое монада.

[KMiNT]

А мне лично комфорней читать код не задом-наперед, а слева-направо и сверху-вниз. Вот как на Clojure в виде конвееров можно записать этот пример:

(->> (-> "urls.txt" slurp (str/split #"\s"))
(filter #(str/starts-with? % "http://"))
(map #(str % "\r\n" (get-url %)))
println)

1) Певый конвеер -> (орформатирован слева-направо):
Файл - читаем - разделяем на список строк по вайтспейсу

2) Второй конвеер ->> (орформатирован сверху-вниз, тут уже каждый новый результат идет вторым аргументом для функций в цепочке, а не первым)
- список строк фильтруем
- формируем список результатов обработки
- печатаем



Вот более читабельно с одним конвеером и доп. введенным идентификатором:

(def urls (-> "urls.txt" slurp (str/split #"\s")))

(->> urls
(filter #(str/starts-with? % "http://"))
(map #(str % "\r\n" (get-url %)))
println)




Еще более развернутый вариант:

(def urls (-> "urls.txt" slurp (str/split #"\s")))

(defn process-url [url]
(str url "\r\n" (get-url url)))

(->> urls
(filter #(str/starts-with? % "http://"))
(map process-url)
println)

[СергейБарлет-чч]

Теперь я понял, что монад не существует, большое спасибо. Это просто способ говорить о чем-то как общей способности выразить решаемую задачу.

[alexanderskusnov]

А Денис Москвин объяснял проще: функция a -> b заменяется на стрелку Клейсли a -> m b.

[AlexSolomin]

Рассказывая о монаде, вы перепутали pure и return. Второй как раз в монадный контекст значение укладывает. Первый - в контекст аппликативного функтора.

[druidushkadruid]

Это как в школьной математике: так упрощено, что не пойми о чем речь идет...

[jewgenijmoldawski]

80 символов идут от перфокарт. А может быть даже от чего-то более древнего.

[phat]

Но в конце концов функциональная парадигма находится куда дальше от принципов работы компьютера. Мне кажется удобнее писать именно так, как именно было задумано на низком уровне. А на низком уровне работают именно императивные принципы. Не имею ничего против элементов функционального программирования. Но писать программы полностью на функциональных языках? Для меня сомнительное удовольствие. Сам как-то загорелся Хаскелем, хватило на 2 месяца. Понял, что не мое, хотя успел много в чем разобраться.

[sergeyinozemcev]

Видите ли в чем дело. Ваша, якобы, чистая функция map, это на самом деле не более, чем обертка над тем же самым циклом while с тем самым смешным счетчиком, который перемещает указатель по стеку или по куче, поднимает вполне конкретное количество бит и совершает с ними операции чтения / записи. В действительном функциональном программировании у вас такой возможности нет, вы должны N раз вызывать функцию, которая принимает массив как сумму бит, совершает трансформацию этой суммы по каждому конкретному полю, связанному с конкретным N и возвращать сумму бит. Иными словами, вы должны N раз сделать вызов функции и N раз двигать этот массив как сумму на входах и выходах из функции, которая рекурсивно вызывает себя N раз, что, естественно, абсолютно расточительная и неприемлемая стратегия. Это в математике можно взять число Грэма и возвести его в число Грэма и вам за это ничего не будет. Если вы тоже самое будете делать на базе какой-то реальной инфраструктуры, вы просто разоритесь. Поэтому код на условно представленном языке P просто более честный, и дает гораздо более ясное представление о том, что на самом деле происходит, тогда как код на условно представленном языке H предлагает некий почти религиозный сервис, скрывая под ним реальную суть происходящего. При этом явно лукавит, называя свои функции чистыми, потому что точно также может словить segmentation fault и underfined behavior, если разработчики компилятора для хипсторов все таки не позаботятся о безопасной обертке для своих сырых указателей.

[dmanikhine]

Плохоё объяснение. Всё очень хорошо разжёвано в

[neto]

Коды не эквивалентны. Первый обходит список один раз, второй два. Поэтому сравнивать их некорректно.

[rustonelove]

Фундаментальные ошибки автора. Первое - сравнивает жопу и палец.
Сравнивает реальный код на "императивном" ЯП и фентезийный на "функциональном".
Занимается попросту воровством понятий. ФП не имеет монополию на понятие "функция". То, что везде и всюду функция называется функция, а не подпрограммой - это лишь для унификации. Была математика с функциями. Потом появилось разделение(хотя даже тогда никто понятия подпрограммы особо не использовал).
Точно так же лямбды не имеют никакого отношения к ФП. Вариации подобного функционала существовали до/параллельно с ФП. Называются они так чисто для унификации.
Передача результата функции в функцию - не имеет никакого отношения к ФП.


Далее, он врёт/манипулирует. Есть общие моменты. Допустим, он специально наплодил множество ненужны переменных. Для чего? Для подтверждения тезиса "малая плотность". Хотя она такая же. Даже большая. Так же есть лишние строки, которых нет в псевдо-фп варианте.
Так же, есть фундаментальный подлог. Автор свалился получение и вывод результатов в функцию? И даже не потому, что он попытался обмануть с кол-во стром. Нет.
На это примере рушится его концепция. В своих изваяниях он не может так просто разослать url по 2 функциям.


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


Далее автор(15 лет на хаскеле) начал нести ещё большую херню "io ненужно" - нужно. Любое io может сломать поток вычислений. Именно поэтому там и нужна монада.


Точно так же она нужна и в других кейсах. Вообщем. Если говорить проще. Концепция ФП не подразумевает возможность сломать поток вычисления. Именно для этого и существует биндинг. Он нужен для того, что-бы обычную функцию обернуть в обёртку, которая будет поддерживать второй путь вычисления. Это действительно в какой-то мере похоже на .? и макросы в си. Но только биндинг, а не сами монады.


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


Но исключения работают на уровне ниже и делают всё тоже самое, только лучше. Именно поэтому в OOP и существуют чейны. У ФП-адептов так же существуют цепочки вызовов - она была показана. Точно такие же цепочки есть и в ООП(условном ООП). И возможны они именно благодаря исключениям. Ведь если бы не было исключений - пришлось бы городить такую же херню, как в ФП.


Т.е. по-сути - монады это такая бездарная попытка сделать убогие исключения. Она никак и нигде не нужна.


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