FP design patterns
Apr. 26th, 2016 08:28 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thedeemonНеплохое и не без юмора совсем вводное введение в ФП для ОО программистов, верующих в дизайн паттерны:
thedeemonthedeemon
Profile
Dmitry Popov
Page Summary
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Style Credit
- Style: Neutral Good for Practicality by timeasmymeasure
Expand Cut Tags
No cut tags
no subject
Date: 2016-04-26 03:24 pm (UTC)no subject
Date: 2016-04-26 03:29 pm (UTC)Если реверсировать, представь себе, как это будет выглядеть "введение в ООП для знатоков ФП-дизайна".
Перечеркнуть все известные плюшки функциональщины и "давайте начнём с азов".
Карринг - втопку: интерфейс! Монады - втопку: интерфейс! Стрелки - втопку: интерфейс! (как? да хз, но в принципе ведь можно). Сплав функций - втопку: пусть у оптимизирующего компилятора голова болит. Тайпклассы - втопку: дженерики или вообще не надо. И т.д. и т.п.
Серьёзно? Сделать обзор хотя бы книги Гаммы+3 за час трындежа с шуточками-прибауточками? Да максимум, что будет - это осветим какие-то совсем уж основные основы, про синтаксис, триаду структура-состояние-поведение и принцип подстановки.
Паттерны структурируют видение предметной области.
Если мы скажем, что абсолютно все паттерны РЕАЛИЗУЮТСЯ через объекты и/или классы, - родим трюизм и потеряем понимание: вот здесь вот этот класс работает декоратором, а вот там - фабрикой, а вот там - ещё чем-нибудь.
Будем тупить, как на дизассемблер обфусканного ява-пакета.
А если мы скажем, что абсолютно все паттерны РЕАЛИЗУЮТСЯ же через функции, - ахъ, какъ прелестно! Но чем это отличается от предыдущего? Да ничем, кроме того, что писанины меньше.
no subject
Date: 2016-04-26 03:57 pm (UTC)Тайпклассы кстати втопку.
no subject
Date: 2016-04-26 04:41 pm (UTC)а трэйты можно?
no subject
Date: 2016-04-26 04:45 pm (UTC)Чем, кстати, тайпклассы не удружили?
no subject
Date: 2016-04-26 08:44 pm (UTC)В ООП языках они одними генераторами строятся, а в FP другой — полиномиальный базис.
Если кратко то есть всего две метатипа полиномиальных функторов: data и record или union и struct или деревья и их слагаемые с именоваными полями. И на этом всем уже растет FP и OOП, так как классы, структуры, интерфейсы и сигнатуры из ML — это надстройка над слагаемыми, типы классов — это тоже надстройка над рекордами, делегирование управления и уровни индирекшина, как говорят в ООП.
В некоторых языках нет слова data, например в таких как Erlang, но как мы знаем мы можем дату имитировать через кодату (это все виды кодировок, а кодировки как мы знаем всегда находятся в "дне" лямбда куба, нетипизированном исчислении) поэтому в эрланге мы свободно имитируем data (если нам нада), в основном работая с record как с базовым типом.
Лисперы убедились в свое время, что всего нужно 12 уровней индирекшина, чтобы писать софт. А сейчас тема такая, что оказывается что тректрейсы в продакшине могут ограничиваться до 5 или 4 уровней (как у меня) — и все это благодаря именно "функциональному паттерну" "композишин" и "абстракция" (как синоним функции). Конечно в ФП дофига паттернов, но так получилось, что эти паттерны все записаны в учебниках по алгебре. Так что ФП программсты просто перепечатывают запылившиеся книги :-)
Т.е. суть действительно в диком и чрезмерном упрощении. Как только базис твоих примитивов или форм языка сокращается до нужного минимум — все остальное отбрасывается или является украшениями этих двух или трех или пяти простых сущностей.
no subject
Date: 2016-04-26 04:38 pm (UTC)no subject
Date: 2016-04-26 04:43 pm (UTC)no subject
Date: 2016-04-26 05:28 pm (UTC)Но делать интерфейсы, жалко уподобленные тайпклассам, - это... это какой-то позор!
no subject
Date: 2016-04-26 05:35 pm (UTC)no subject
Date: 2016-04-26 05:45 pm (UTC)no subject
Date: 2016-04-26 06:13 pm (UTC)let inline getLength< ^a when ^a : (static member Length : string -> int)> str = ( ^a : (static member Length : string -> int) str)no subject
Date: 2016-04-26 08:08 pm (UTC)Чем это лучше старых добрых плюсовых шаблонов?! Ничем, только ещё хуже. В плюсах-то все эти подстановки и вывод типов на ходу - будь здоров как проработан.
Прокачают до плюсов - будет круто :)))
no subject
Date: 2016-04-26 05:09 pm (UTC)Конечно, без азов говорить не о чем, т.е. нужна преварительная подготовка.
Но после этого лекция будет выглядеть не "паттерн А, паттерн Б, паттерн В - фигня-война, засуньте это в какую-нибудь монаду", а "зато у нас вот такие и вот этакие типичные ситуации возникают, которые красиво укладываются в монады L, S, T, а вот другие ситуации, для которых лучше изобрести вообще другой математический аппарат"...
no subject
Date: 2016-04-26 04:51 pm (UTC)>Если мы скажем, что..
Так он явно говорит, что это бесполезное занятие, и нет смысла переводить ОО паттерны в ФП. Вместо этого в ФП надо вообще иначе о программировании думать, и вот как... Дальше идет час рассказа уже безотносительно ОО паттернов.
no subject
Date: 2016-04-26 05:21 pm (UTC)Конечно, надо думать по-другому.
Но не надо думать, что люди просто так тратили силы, выделяя закономерности архитектуры в ООП. А тут прибежали функциональщики, фигак-фигак, карринг, мап-редюс и в продакшен.
Фигак-фигак, это если данная конкретная программа изначально была проста, а паттерны в ней находили от праздной прозорливости.
Интересно же другое: как и что функциональщики выделяют в сложных программах.
no subject
Date: 2016-04-26 06:33 pm (UTC)в аналы!
no subject
Date: 2016-04-27 12:19 pm (UTC)Что значит "не надо думать"? :)
А я скажу, надо думать! :)))
ФП не использует паттерны ООП - значит, ООП-шники старались зря.
ООП не используют конструкции ФП - значит, ФП нинужно.
Так?
И тот, и другой вывод, конечно, безоснователен. Люди старались, использовали силу своей мысли, чтобы производить конкретные продукты и, раз они их произвели, то уже не зря, в этом смысле.
С другой стороны, если задуматься, что из этих наработок перейдет в завтрашний день, что принесет плоды, превышающие сиюминутную выгоду от глючащего ширпотреба "сложных программ"... В общем, я не Ванга, но есть подозрение (и Вы с такой точкой зрения, несомненно, знакомы), что это будут не паттерны ООП. История рассудит.
no subject
Date: 2016-04-26 09:39 pm (UTC)"Если мы скажем, что абсолютно все паттерны РЕАЛИЗУЮТСЯ через объекты и/или классы, - родим трюизм и потеряем понимание: вот здесь вот этот класс работает декоратором, а вот там - фабрикой, а вот там - ещё чем-нибудь.
Будем тупить, как на дизассемблер обфусканного ява-пакета."
и
"Карринг - втопку: интерфейс! Монады - втопку: интерфейс! Стрелки - втопку: интерфейс!"
no subject
Date: 2016-04-26 11:58 pm (UTC)Можем фп-программу перепереть на каноническом ооп? Да, можем. Разглядим ли при этом фп-паттерны, и дадим ли им адекватное ооп-представление? Как повезёт.
Если перед этим долго курили алгебру и теоркат, то есть шанс. (Но нужно ещё будет отличить, воткнуты там разные навороты от нужды или от эстетики).
Человек, не знающий о паттернах, глядя на хорошую ооп-программу, воскликнет: "а! узнаю! это же всё объекты, классы и иерархии!"
И дальше что? Это позволит ему вручную оттранслировать её в машинные коды, и всё.
И глядя на фп-программу, - "а, это функции до самого низу, тоже всё понятно".
no subject
Date: 2016-04-27 06:36 am (UTC)Или вы возмущены тем, что автор доклада на видео всё назвал функциями? По-моему, в докладе он сначала объяснил, что не будет обсуждать паттерны ООП - в частности, потому что паттерны ФП не пересекаются с паттернами ООП, и потому что все паттерны ООП выглядят довольно единообразно (например, потому что ФП фокусируется на другом подходе к структуризации вычислений и размышлять, визитор ли это, декоратор ли, не приходится).
Адекватного представления ФП паттернов в ООП не будет в частности оттого, что функции не являются равноправными объектами. Тут, действительно, как повезёт. А в языках, где функции таки объекты, паттерны ФП проявляются и узнаваемы.
Например, на днях порефакторил код с колбеками - получил код, где колбеки являются tail call, увидел continuation monad. Пора вводить Promises.
no subject
Date: 2016-04-26 04:34 pm (UTC)