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

Виталий Брагилевский на митапе Tver.io Pure Meetup 25 июля.
Слайды: tver.io/meetup/2019/07-pure-me...

[@Pavel1915]

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

[@alexanderrudenko170]

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

[@ilya9485]

Классный доклад

[@Iaxls]

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

[@user-mb2so1tg5u]

Большое спасибо за ваш труд!

[@colorofadog]

Отличный доклад!

[@user-ey7rd9ih4g]

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

[@musicthreads]

Питонист на попу не чист!

[@channel-6824]

Виталий вдохновляет!

[@ultraon83]

Amazing!

[@shoomillion]

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

[@garrysimonoff818]

80 символов - ширина перфокарты

[@pick-pock]

Ze best! 👍🏼

[@user-rg6kj3vx3o]

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

[@AlexSolomin]

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

[@easylaneof]

pure и в контест функтора уже тоже укладывает

[@alexanderskusnov5119]

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

[@alexanderrudenko170]

да, именно так) я видел объяснение Дениса Москвина, но тут надо сказать, что в случае со стрелкой Клейсли надо знать, что такое стрелка Клейсли))) а тут Виталий объяснил до такой степени просто, в то же время точно, да еще и не лез в другие категории. Это высший пилотаж в плане объяснения сути чего угодно)

[@jaypacsky]

Как же постарел лысый из Glo Academy

[@user-tu3ld7kh3q]

80 - это пошло от перфокарт!!!

[@jewgenijmoldawski3306]

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

[@phat80]

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

[@nekosora6036]

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

[@phat80]

@@nekosora6036 Нет, для программиста крайне важно понимать, что происходит на низком уровне. В этом и есть удобство. Не спорю, есть куча программистов, которым плевать, что там происходит в самом низу и их все устраивает. Но не имея базовых знаний об основах, ты вряд ли сможешь писать самый эффективный код и вообще стать профессионалом в этой области. Да, для математика может быть удобнее использовать функциональный язык. Ему по идее все-равно, будет программка что-то рассчитывать минуту или две. Главное, чтобы ему удобнее было писать и понимать. Но какому-нибудь системщику важно знать, что его программа отработает за 10 мс, а не за 2 секунды. Потому, что в этой области это критично. В функциональных языках, так как они далеки от принципа работы самого железа, труднее будет писать эффективный код. Многое, наверное, можно понять только протестировав некоторые функции. Т.е. там с ходу трудно сказать, почему программа работает достаточно медленно. В любом императивном языке опытный программист часто сможет указать на проблему, взглянув на код. Особенно, если этот код на каком-нибудь С, без ООП и функциональных подходов.

[@nekosora6036]

@@phat80 поэтому системный код нужно писать на каком-нибудь Си. Но большинство программистов не пишет системный код. Поэтому, далеко не всем "крайне важно понимать, что происходит на низком уровне". Программирование в общем случае решает практические задачи реального мира, где нет байтов и указателей

[@phat80]

@@nekosora6036 да ну... ))) отсюда и лезет говнокод, если человек не понимает, что у него в памяти происходит и какие операции дорогие, а какие нет. По своему опыту скажу, что изучение С и ассемблера до некоторой степени очень помогает в дальнейшем. Я сам склоняюсь к вэбу, который вроде очень далек от системного программирования. Но то, что я копал С и ассемблер, не считаю лишним. Многое стало более понятно. А я такой человек, что не могу просто принять что-то как данность, мне важно понимать, как это работает. Поэтому стараюсь не тупо копипастить код, а понимать что вообще в нем происходит. Но да, большинству это не важно. Это как в свое время все учили jQuery и мало кто вообще понимал, как писать то же самое на чистом JS. Да и сейчас такие еще встречаются, кто не то, что языками мыслит, а вообще библиотеками и фреймворками, в принципе не понимая, что там происходит под капотом. Но это не мой подход. Именно поэтому понимаю некоторых работодателей, которые требуют профильного образования, чтобы человек не только синтаксис знал того или иного языка, но и базу.

[@hongaslahoenvaara]

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

[@dmanikhine]

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

[@druidushkadruid7569]

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

[@user-lu3to5mg6b]

Обьясняй уже!

[@sergeyinozemcev1070]

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

[@rshirkhanov]

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

[@ne4to777]

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

[@user-dn7qr7vs1h]

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

[@ne4to777]

@@user-dn7qr7vs1h , при чем тут байткод? Второй код будет всегда медленнее первого. Всегда!

[@artsiomivanou6438]

Много `map`+`filter` не значит много итераций: В Питоне map, filter возвращают итераторы Хаскель язык с lazy evaluation да и трансдьюсеры же есть

[@ne4to777]

@@artsiomivanou6438 , значит. Я не вижу нигде fork.

[@MultiOpachki]

@@ne4to777 Оба имеют сложность O(n), а остальное не особо важно.

[@oleksandrklimenkov5988]

Очень плохо и непонятно.

[@KMiNT21]

А мне лично комфорней читать код не задом-наперед, а слева-направо и сверху-вниз. Вот как на Clojure в виде конвееров можно записать этот пример: (->> (-> "urls.txt" slurp (str/split #"\s")) (filter #(str/starts-with? % "")) (map #(str % " " (get-url %))) println) 1) Певый конвеер -> (орформатирован слева-направо): Файл - читаем - разделяем на список строк по вайтспейсу 2) Второй конвеер ->> (орформатирован сверху-вниз, тут уже каждый новый результат идет вторым аргументом для функций в цепочке, а не первым) - список строк фильтруем - формируем список результатов обработки - печатаем ======================================================================== Вот более читабельно с одним конвеером и доп. введенным идентификатором: (def urls (-> "urls.txt" slurp (str/split #"\s"))) (->> urls (filter #(str/starts-with? % "")) (map #(str % " " (get-url %))) println) ========================================================================= Еще более развернутый вариант: (def urls (-> "urls.txt" slurp (str/split #"\s"))) (defn process-url [url] (str url " " (get-url url))) (->> urls (filter #(str/starts-with? % "")) (map process-url) println)

[@rustonelove]

Фундаментальные ошибки автора. Первое - сравнивает жопу и палец. Сравнивает реальный код на "императивном" ЯП и фентезийный на "функциональном". Занимается попросту воровством понятий. ФП не имеет монополию на понятие "функция". То, что везде и всюду функция называется функция, а не подпрограммой - это лишь для унификации. Была математика с функциями. Потом появилось разделение(хотя даже тогда никто понятия подпрограммы особо не использовал). Точно так же лямбды не имеют никакого отношения к ФП. Вариации подобного функционала существовали до/параллельно с ФП. Называются они так чисто для унификации. Передача результата функции в функцию - не имеет никакого отношения к ФП. Далее, он врёт/манипулирует. Есть общие моменты. Допустим, он специально наплодил множество ненужны переменных. Для чего? Для подтверждения тезиса "малая плотность". Хотя она такая же. Даже большая. Так же есть лишние строки, которых нет в псевдо-фп варианте. Так же, есть фундаментальный подлог. Автор свалился получение и вывод результатов в функцию? И даже не потому, что он попытался обмануть с кол-во стром. Нет. На это примере рушится его концепция. В своих изваяниях он не может так просто разослать url по 2 функциям. Далее начал нести откровенную херню. Про какое-то обобщение. Никакого обобщения там нету. Есть просто кейс который не помещается в базовую методичку(почему я скажу далее). Нам нужно сделать f3(f2(f1())) - очевидно, что это не проблема для всякой скриптухи. Но дело в том, что в том же си(и всём, что он породил) void не является значением. А значит его нельзя передать и подобный код не работает. Поэтому в фп существует своя трактовка void и на самом деле void там нету. Но проблема не в этом. Далее автор(15 лет на хаскеле) начал нести ещё большую херню "io ненужно" - нужно. Любое io может сломать поток вычислений. Именно поэтому там и нужна монада. Точно так же она нужна и в других кейсах. Вообщем. Если говорить проще. Концепция ФП не подразумевает возможность сломать поток вычисления. Именно для этого и существует биндинг. Он нужен для того, что-бы обычную функцию обернуть в обёртку, которая будет поддерживать второй путь вычисления. Это действительно в какой-то мере похоже на .? и макросы в си. Но только биндинг, а не сами монады. Далее, автор фундаментально врёт. А вернее игнорирует то, что пытаются в жалких попытках эмулировать монады - это исключения. Когда есть исключения - точно так же скрывают в второй путь вычисления. Т.е. когда произошла где-то в цепочке ошибка - нам нужно как-то пройти всю цепочку/завершить, вернув результат. Именно для возможности возврата результата и нужно биндить все функции, что-бы они получали новый функцинал - проброс результата. Но исключения работают на уровне ниже и делают всё тоже самое, только лучше. Именно поэтому в OOP и существуют чейны. У ФП-адептов так же существуют цепочки вызовов - она была показана. Точно такие же цепочки есть и в ООП(условном ООП). И возможны они именно благодаря исключениям. Ведь если бы не было исключений - пришлось бы городить такую же херню, как в ФП. Т.е. по-сути - монады это такая бездарная попытка сделать убогие исключения. Она никак и нигде не нужна. Точно так же, данный эксперт врёт, когда рассказывает про какие-то монады и прочую херню. Но об этом я уже говорил. Ни в какой императивщине никаких монад нет. Там не нужны настолько мусорные и примитивные решения. Точно так же, императивщина не подпадает под классификацию данного учения, т.к. существует параллельно. Все попытки как-то классифицировать императивщину от адептов данного учения - должны вызывать только одно - смех.

[@user-nl8cn6tu8v]

WOW ;)

[@glebdanichev9956]

А где почитать лучше?

[@sergueyz]

Ознакомьтесь с историей программирования. Лямбда-исчисление Чёрча появилось на несколько лет раньше работ Тьюринга и представляло собой инструмент конструктивной математики, которая началась ещё раньше. Ну, и желаю вам прочитать сайт lambda-the-ultimate,org с начала до конца, а также узнать, откуда взялось его название.

[@rustonelove]

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

[@rustonelove]

@@sergueyz Кстати, тут можно заметить именно то, о чём я говорил. Именно так действуют адепты и эта пропаганда мусорная. Как я уже говорил, да и как очевидно всем - лямбды в контексте текущих ЯП не имеют НИКАКОГО отношения к ФП. Это просто просто имя нарицательное. Как и функция. Никто и нигде не понимает эти явления как ФП и не соотносит с определениями локальными ФП. Но, адепты данной веры постоянно пытаются все убедить, что это не так. Что какая-то функция в си - это функция ФП. Хотя она клала не некие базовые свойства функций в ФП и вообще определяется иначе. Но адептов это не останавливает. И именно на это данный персонаж ссылается. Он пытается рассказывать о своём понятии. Но его понятие(вернее даже не его, а совершенно из другой (над)области) не имеет отношение к обсуждаемому. В данном контексте это просто имя нарицательное, как я уже говорил. Никогда не нужно ловиться на эти манипуляции. Функция - это не определение. Это просто имя. Определение из ФП той самой функции никакого отношения к функциям не имеет и не определяет функции нигде за рамками ФП. Все определения из мира ФП существует только в рамках этого мира и за этим мира все ими жопу вытирали и вытирают. Поэтому, как я уже говорил. Попытки адептов проецировать свои локальные определения на весь мир - должны вызывать только смех. Это концепция целиком и полностью несостоятельна. Даже попросту потому, что описываемые определениями явления попросту им не соотносятся. От того мы и видим эту клоунаду с "ну определение ничего не определяет - то просто в языке неправильно реализовали". Нет, в языке реализовали правильно. Просто они жопу вытирали твоими определениями. И правильно делали.

[@sonatamebel5]

Феерически напыщенный докладчик

[@donpedro2125]

Зря держался... Следующий...