FP design patterns

[thedeemon]

Неплохое и не без юмора совсем вводное введение в ФП для ОО программистов, верующих в дизайн паттерны:

Comments

[maxim.livejournal.com]

Очень круто, я бы совсем немного поправил и в школу в производство программистов!

[kodt-rsdn.livejournal.com]

Удручающее введение, если честно.
Если реверсировать, представь себе, как это будет выглядеть "введение в ООП для знатоков ФП-дизайна".

Перечеркнуть все известные плюшки функциональщины и "давайте начнём с азов".

Карринг - втопку: интерфейс! Монады - втопку: интерфейс! Стрелки - втопку: интерфейс! (как? да хз, но в принципе ведь можно). Сплав функций - втопку: пусть у оптимизирующего компилятора голова болит. Тайпклассы - втопку: дженерики или вообще не надо. И т.д. и т.п.

Серьёзно? Сделать обзор хотя бы книги Гаммы+3 за час трындежа с шуточками-прибауточками? Да максимум, что будет - это осветим какие-то совсем уж основные основы, про синтаксис, триаду структура-состояние-поведение и принцип подстановки.

Паттерны структурируют видение предметной области.

Если мы скажем, что абсолютно все паттерны РЕАЛИЗУЮТСЯ через объекты и/или классы, - родим трюизм и потеряем понимание: вот здесь вот этот класс работает декоратором, а вот там - фабрикой, а вот там - ещё чем-нибудь.
Будем тупить, как на дизассемблер обфусканного ява-пакета.

А если мы скажем, что абсолютно все паттерны РЕАЛИЗУЮТСЯ же через функции, - ахъ, какъ прелестно! Но чем это отличается от предыдущего? Да ничем, кроме того, что писанины меньше.

[maxim.livejournal.com]

Ты кто, заслуженный деятель Энтерпрайза?
Тайпклассы кстати втопку.

[sober-space.livejournal.com]

А мне понравилось, поржал.

[thedeemon.livejournal.com]

Так он из ФП лишь самых азов касается, значит, ежели оборотить, то будет час рассказа про самые основы ООП, до банды четырех даже не дойдет.

[binf.livejournal.com]

== Тайпклассы кстати втопку.

а трэйты можно?

[binf.livejournal.com]

рассказал всё, что можно в F#) дальше - ад-хок полиморфизм, которого там нет

[kodt-rsdn.livejournal.com]

Я скромный кодер на плюсах, одно время даже MS MVP был. А что?

Чем, кстати, тайпклассы не удружили?

[thedeemon.livejournal.com]

А вот если бы ты хотя бы первые пять минут посмотрел, не пришлось бы писать столько букв.

>Если мы скажем, что..

Так он явно говорит, что это бесполезное занятие, и нет смысла переводить ОО паттерны в ФП. Вместо этого в ФП надо вообще иначе о программировании думать, и вот как... Дальше идет час рассказа уже безотносительно ОО паттернов.

[kodt-rsdn.livejournal.com]

Вот именно это я и имею в виду. Перечёркивает структурированное знание одного аспекта и даёт азы другого. Несоразмерно.

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

[kodt-rsdn.livejournal.com]

Я просмотрел всё видео, хотя и перематывал там, где он льёт воду.
Конечно, надо думать по-другому.

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

Интересно же другое: как и что функциональщики выделяют в сложных программах.

[kodt-rsdn.livejournal.com]

А дальше начинается боль и унижение, потому что ад-хок там чисто ООП-шный, дотнетовский.

Но делать интерфейсы, жалко уподобленные тайпклассам, - это... это какой-то позор!

[binf.livejournal.com]

Кроме интерфейсов есть ещё дак-тайпинг, работающий через дженерик-ограничение по методу класса. Обещают в 5 версии значительно прокачать эту фичу

[kodt-rsdn.livejournal.com]

Где можно прочитать об этом?

[binf.livejournal.com]

да бес его знает ,вероятно где-то в мсдн. что вроде такой вот функции

let inline getLength< ^a when ^a : (static member Length : string -> int)> str =
    ( ^a : (static member Length : string -> int) str)

[109.livejournal.com]

> мап-редюс и в продакшен

в аналы!

[kodt-rsdn.livejournal.com]

А, этот фокус с инлайном, т.е. с чистым компайл-таймом.

Чем это лучше старых добрых плюсовых шаблонов?! Ничем, только ещё хуже. В плюсах-то все эти подстановки и вывод типов на ходу - будь здоров как проработан.
Прокачают до плюсов - будет круто :)))

[maxim.livejournal.com]

Ну будем говорить, так что паттерны — это система типов базовой библиотеки.
В ООП языках они одними генераторами строятся, а в FP другой — полиномиальный базис.
Если кратко то есть всего две метатипа полиномиальных функторов: data и record или union и struct или деревья и их слагаемые с именоваными полями. И на этом всем уже растет FP и OOП, так как классы, структуры, интерфейсы и сигнатуры из ML — это надстройка над слагаемыми, типы классов — это тоже надстройка над рекордами, делегирование управления и уровни индирекшина, как говорят в ООП.

В некоторых языках нет слова data, например в таких как Erlang, но как мы знаем мы можем дату имитировать через кодату (это все виды кодировок, а кодировки как мы знаем всегда находятся в "дне" лямбда куба, нетипизированном исчислении) поэтому в эрланге мы свободно имитируем data (если нам нада), в основном работая с record как с базовым типом.

Лисперы убедились в свое время, что всего нужно 12 уровней индирекшина, чтобы писать софт. А сейчас тема такая, что оказывается что тректрейсы в продакшине могут ограничиваться до 5 или 4 уровней (как у меня) — и все это благодаря именно "функциональному паттерну" "композишин" и "абстракция" (как синоним функции). Конечно в ФП дофига паттернов, но так получилось, что эти паттерны все записаны в учебниках по алгебре. Так что ФП программсты просто перепечатывают запылившиеся книги :-)

Т.е. суть действительно в диком и чрезмерном упрощении. Как только базис твоих примитивов или форм языка сокращается до нужного минимум — все остальное отбрасывается или является украшениями этих двух или трех или пяти простых сущностей.

[sassa-nf.livejournal.com]

как у вас одновременно уживаются

"Если мы скажем, что абсолютно все паттерны РЕАЛИЗУЮТСЯ через объекты и/или классы, - родим трюизм и потеряем понимание: вот здесь вот этот класс работает декоратором, а вот там - фабрикой, а вот там - ещё чем-нибудь.
Будем тупить, как на дизассемблер обфусканного ява-пакета."

и

"Карринг - втопку: интерфейс! Монады - втопку: интерфейс! Стрелки - втопку: интерфейс!"

[kodt-rsdn.livejournal.com]

Прекрасно уживаются, это называется переупрощение.

Можем фп-программу перепереть на каноническом ооп? Да, можем. Разглядим ли при этом фп-паттерны, и дадим ли им адекватное ооп-представление? Как повезёт.
Если перед этим долго курили алгебру и теоркат, то есть шанс. (Но нужно ещё будет отличить, воткнуты там разные навороты от нужды или от эстетики).

Человек, не знающий о паттернах, глядя на хорошую ооп-программу, воскликнет: "а! узнаю! это же всё объекты, классы и иерархии!"
И дальше что? Это позволит ему вручную оттранслировать её в машинные коды, и всё.
И глядя на фп-программу, - "а, это функции до самого низу, тоже всё понятно".

[sassa-nf.livejournal.com]

Гм. Я не вполне понял смысла переупрощения. С одной стороны - вы назвали все "интерфейсами", а с другой - что интерфейсами все подряд называть негоже. Тогда не понятно, зачем монады, карринг, стрелки называть одним общим словом?

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

Адекватного представления ФП паттернов в ООП не будет в частности оттого, что функции не являются равноправными объектами. Тут, действительно, как повезёт. А в языках, где функции таки объекты, паттерны ФП проявляются и узнаваемы.

Например, на днях порефакторил код с колбеками - получил код, где колбеки являются tail call, увидел continuation monad. Пора вводить Promises.

[zeit-raffer.livejournal.com]

> Но не надо думать, что люди просто так тратили силы, выделяя закономерности архитектуры в ООП.

Что значит "не надо думать"? :)
А я скажу, надо думать! :)))

ФП не использует паттерны ООП - значит, ООП-шники старались зря.
ООП не используют конструкции ФП - значит, ФП нинужно.
Так?

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

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