👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Чистое ФП это такая религия для недопрограммистов, которым хочеться чем то выделиться, быть загадочным, и казаться умным (по крайней мере самому себе). А за пределами чистого ФП, хорошие фишки из ФП вполне адаптируются в индустриальном программировании.

У нас таких называли в школе «системные программисты», позже я познакомился с ихними братьями меньшими по разуму «системными администраторами», сейчас самые близкие не знаю кто, компании стали больше уже и обидеть легче :-) Архитиекторы наверно.

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

Подход к проектированию в чисто функциональных языках совсем другой. Например структура может быть выражена в категориальной форме т.е. в виде обьектов(!) и морфизмов между ними. Для точек расширения используются тайпклассы и функции высшего порядка, т.е. там же где в Java 7 и ниже используются интерфейсы, стратегии и прочие дизайн паттерны.
Дядя Боб прав в том что принципы построения систем одни и те же, просто язык на котором проектируется и реализуется — разный.
Но есть один ньюанс при использовании ОО подхода нужно больше внимания проектированию, но меньше дизайну. В Haskell к примеру надо проектировать все заранее и дизайнить реализацию под уже заложенную архитектуру. Это кстати обьясняет почему библиотеки или ad-hoc решения написанные на хаскелл выглядят очень элегантно, а вот большие продакшен системы писать выходит долго и затратно.

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

p.s. Из этого вывода не следует что ФП лучше ОО при одинаково высокой квалификации получиться одинаково хороший результат.

p.p.s Любителям ООП обратить внимание на Model Driven Engineering.

«Категориальная Форма» выражает не структуру, а программу.
Структуры выражаются алгербаическими типами данных,
а классы и генерики выражаются сигнатурами и модулями,
при этом без динамического связывания.
Тайп-классы — один из минусов Haskell по сравнению с категориальными ML функторами.
Ничего хорошего в ООП нет, ни в Смолтолке, ни в Java, ни в Обероне, ни в CLOS.

Я имел ввиду структуру системы, а не данных, наверное при редактировании потерялось слово «системы».

p.s. Функтор реализован как тайпкласс :).

Функтор T между катеориями С и B (T: C→B) существует т.т.т., когда: ∀f∈Hom© ∃q=Tf∈Hom(B) ∀g•f∈Hom© ∃h=Tg•f∈Hom(B) : Tg•Tf=h.

Что тут реализовано как тайпкласс?

Кто напишет такое же определение тайпкласса по компактностит получит зачет.

Максим, ты какой-то блаженный. Сравниваешь конструкцию языка программирования и понятие из математики.
В хаскелл функтор определен так:
class Functor f where fmap :: (a -> b) -> f a -> f b

А че нельзя сравнивать? А почему? А какая разница?

потому что на математику принято молиться. с придыханием, о-о-о, Математика, и со звоном в пол лбом.

а вы — ее используете. нехорошо. кощунство просто!

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

А функторы в ML — не то же самое, что функторы в Haskell. К слову.

“Is there really so much difference between f(o), o.f(), and (f o)? Are we really saying that the difference is just about the syntax of a function call?”

Я надеялся увидеть в статье partially applied object method call. Увы.

Как написать статью, и не сказать в ней ничего.

Да на функторах я ваши паттерны вертел.

Пять сотен сыру автора сего опуса!

Підписатись на коментарі