Привет!

Наконец-то прочитал пару классических научных статей по ФП:
1) Why functional programming matters
2) The Curse of the Excluded Middle

Начитал много любопытного, много думал.

Во-первых, на мой взгляд, их можно считать достаточно авторитетным источником для следующих тезисов:
1) Чистые функции исключают важный источник ошибок [связанных с временной связанностью] [1]
2) Модульный дизайн - ключ к успешному программированию [1]
3) Компиляторам проще оптимизировать чистые функции [2]
4) Императивные программы сложнее понимать, чем декларативные [2]

Эти утверждения не подтверждаются данными, но статьи из рецензируемых журналов - лучше, чем ничего.

При том Why FP Matters, утверждает, что FP собственно имеет значение, т.к. даёт два новых инструмента модуляризации:
1) Функции высшего порядка
2) Ленивый режим вычисления

И то и другое в более менее-аналогичном виде появилось ещё в ООП (статья 80ого года и ООП ещё не хайпануло), а в том же Kotlin сейчас есть прямые аналоги даже ленивому режиму вычисления (в виде корутин).

С функциями высшего порядка совсем всё хорошо - благодаря Stream API (и аналогам), они сейчас распространены повсеместно.

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

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

А дальше я задумался (снова), что у нас в индустрии полный бардак в терминологии.
Что значат все эти штуки:
1) функциональное программирование
2) декларативное программирование
3) процедурный подход
4) императивный подход
5) структурное программирование
6) структурный дизайн
7) объектно-ориентированное программирование
8) объектное программирование
9) объектно-ориентированный дизайн
10) модульное программирование
11) компонентное программирование

Что у них общего? Чем они отличаются?
Видимо придётся мне хотя бы для школы разработки имени себя навести тут какой-то порядок.

#papers@ergonomic_code #fp@ergonomic_code #terminology@ergonomic_code

Привет!

Это снова я:)

Анкл Боб недавно написал новый пост с восхвалением ФП.
Да-да, это тот самый Анкл Боб, который придумал SOLID - "5 основных принципов объектно-ориентированного программирования", согласно русской Википедии.

#posts@ergonomic_code #fp@ergonomic_code

Привет!

Пересмотрел старый доклад моего любимого Рича Хикки.
Он там прямым текстом говорит, что доклад не про то, чтобы попинать ООП, но получается у него очень хорошо. При том на фундаментальном уровне.

Но самая крутая на мой взгляд штука - это Эпохальная Модель Времени, кратко описная здесь.

Очень рекомендую к вдумчивому просмотру

#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code #immutable_domain_model@ergonomic_code

Привет!

Сегодня линкопост: Functional Programming for Pragmatists
Мужик говорит быстро, поэтому слушать довольно тяжело, но мне нравится его определение и объяснение ФП.

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

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

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

#talks@ergonomic_code #fp@ergonomic_code

Привет!

Линко-пост

Прикольный "научпопный" доклад для задро... нердов с версией о том, почему ООП стало мейнстримом, а ФП - (пока) нет. Спойлер - случайно и не на всегда:)

Только мужик говорит быстро и слушать сложно:(

Поэтому вот ещё ссылка из доклада на тему ОО/П.

Ну а для совсем ленивых, мой главный инсайт из этой статьи:
> Alan Kay was interested in personal computing. His work on FLEX, the Dynabook, and Smalltalk all revolve around that. In his vision, the PC would be a something totally under the user’s control, everything from core system logic to the graphic rendering tweakable and explorable at runtime. Message passing and late binding solve a lot of problems here. If a kid installs a new game, should they have to recompile the entire OS to use the new program? No: make it so that you can send any arbitrary message to any object and rely on runtime protocol-handling to fix it.1 If a person clobbers the sound logic, should the whole OS crash? Of course not, so allow objects to decide how to handle messages themselves. This is a place where objects shine.

Ole-Johan Dahl and Kristen Nygaard were trying to solve a completely different problem. They were interested in simulation. One of the case studies in the Simula manual is modeling the spread of infection across a fixed population. The system is completely closed: you have a fixed set of code, you run your simulation, you get your output. For them, message passing isn’t useful. But things like being able to define simulations in terms of other simulations, specialize entities, and model time as a first-class object are incredibly useful. This is also a place where objects shine!

И прям выжимка-перевод - Кей решал задачу с открытым миром, где новые типы объектов появлялись в системе прямо в рантайме. И тут объекты блистали. Авторы Симулы решали задачи симуляции. И тут объекты тоже блистали.

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

#talks@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code

Привет!

Наткунлся на обновлённую версию доклада Simple Made Ease с русскими субтитрами.
Доклад очень крутой, советую посмотреть, тем кто ещё не смотрел

#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code

Привет!

По совету подписчика начал читать Grokking Simplicity.

Пока прочитал 200 страниц из 600, но уже не могу удержать в себе восторг.

Это лучшая известная мне книга по функциональному стилю (или скорее data-oriented programming), с лучшим известным мне разбором двух основополагающих принципов проектирования:

1. разделение ввода-вывода и бизнес-логики
2. использование одного уровня абстракции в функции (анкл Бобовскя заметка на эту тему в чистом коде - даже близко не лежала с 1.5 главами об этом в книге).

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

#books@ergonomic_code #functional_architecture@ergonomic_code #fp@ergonomic_code #js@ergonomic_code

Привет!

Дочитал книгу. По традиции, тема разработки бэков поверх РСУБД практически не раскрыта (этому посвящено примерно 10 страниц про луковую архитектуру), но в остальном - чудесная книга, мой новый лидер среди книг по ФП.

И сейчас мой рекомендуемый трек по изучению разработки бэков в функциональном стиле выглядит так:
1. Grokking Simplicity
2. Принципы юнит тестирования
3. Domain Modeling Made Functional
4. Структура и интерпретация компьютерных программ
5. Functional Design: Principles, Patterns, and Practices
6. Structured Design

#books@ergonomic_code #functional_architecture@ergonomic_code #fp@ergonomic_code #js@ergonomic_code

Мысль четвёртая

А ну и мысль четвёртая - если вы пишите бэки - вам надо ФП/ФА, а не ООП/DCI :)

Точнее DOP/ФА как здесь, а не чистый ФП как здесь

#dop@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code