Я где-то по лету писал о парадигмах программирования и тогда не нашёл авторитетного источинка этого термина и что-то сам выдумал. А тут случайно натыкаюсь на The Paradigms of Programming - статью в авторитетном рецензируемом журнале.

Статью ещё не читал, так что пока не рекомендую

а вот за одну цитату я глазом зацепился, пока листал по диагонали:)
» The older schools gradually disappear. In part their disappearance is caused by their members’ conversion to the new paradigm. But there are always some men who cling to one or another of the older views, and they are simply read out of the profession, which thereafter ignores their work.

> In computing, there is no mechanism for reading such men out of the profession. I suspect they mainly become managers of software development

Мораль вырваной из контекста цитаты - учись, а то станешь менеджером:)

#papers@ergonomic_code #terminology@ergonomic_code

И ещё линка
Я постоянно между делом попинываю тестирование с моками, но свой развёрнутый пост на эту тему ещё не написал. А тут мужик всё правильно написал, да ещё и на русском.

Я уже находил блог этого мужика - хороший мужик, рекомендую подписаться. Блог правда на английском

#posts@ergonomic_code #ergo_testing@ergonomic_code #terminology@ergonomic_code

Привет!

Наконец-то прочитал пару классических научных статей по ФП:
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

Привет!

Накатал потока-сознания-пост о том, что я имею ввиду под ОО-подходом.

#terminology@ergonomic_code #oop@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Я тут кажись придумал простое и понятное (по крайней мере мне 😂) определение функциональной связанности метода:)

Метод обладает функциональной связанностью, если он не обладает побочными эффектами.

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

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

Например, есть метод "одобрения" создания некоторой сущности. Он считывает сущность, меняет в ней флажёк и записывает назад - и то и то является эффектом.

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

Но как тогда реализовать эту функциональность?
Через шину событий. Метод одобрения сохраняет сущность и публикует событие "сущность одобрена".
А дальше в отдельном методе это событие обрабатывается и посылается пуш.

В чем разница между публикацией события и отпрвкой пуша?
Она, на самом деле довольно тонкая.
Но публикация события, на самом деле не разрывно связана с сохранением сущности. Мы можем не реализовывать это в коде, но при всяком сохранении сущности этим методом происходит событие "сущность одобрена".
И если нам важно, чтобы система об этом событии узнавала, то сбой в его публикации является достаточной причиной для сбоя всего метода одобрения в целом.

С другой стороны, отправка пуша разрывно связана с одобрением. Пуш можно не отправлять вообще. Его можно заменить на Email, в случае сбоя отправки пуша сейчас - его можно отправить попозже.

Таким образом помещение отправки пуша в метод одобрения сделает его методом с побочным эффектом (отправки пуша). И снизит связанность модуля до процедурной.

#terminology@ergonomic_code #cohesion@ergonomic_code #ergo_approach@ergonomic_code #design

Привет!

Предистория.

Как вы знаете, я недавно ходил в гости к javaswag. Но, возможно, вы (как и я до этой записи) не знаете, что javaswag – это не только звук, но и нарезка видео, и небольшие тексты с комментариями к ссылкам.

У меня ссылок было аж 19 штук и Дима предложил сделать развёрнутые комментарии к ссылкам.
Но внезапно оказалось, что я не умею писать комментарии к ссылкам и вместо комментариев у меня как обычно вышел небольшой пост-очерк “Что такое ООП?”.
Но пост – уже не формат для javaswag, поэтому я его представляю вам у себя.

—-

История

В книге “What every programmer should know about object-oriented design” Пейдж-Джонс на первой же странице пишет:

Термин “объектно-ориентированный”, по сути своей, бессмысленен. “Объект” — это одно из самых общих слов в английском языке. Если вы посмотрите его значение в словаре, то увидите что-то вроде:

Объект — вещь, представленная или которую можно представить чувствам [человека].

Другими словами, объект - это практически всё что угодно.

Слово “ориентированный” также не особо помогает. Опредёленное как “направленный в сторону”, оно обычно используется для превращения термина “объекто-ориентированный” в прилагательное.
Таким образом, мы имеем:

Объектно-ориентированный — направленный в сторону практически чего угодно, о чём вы можете только подумать.

Не удивительно, что наша индустрия не смогла договориться об определении термина “объектно-ориентированный”.

Наверное, если провести опрос среди разработчиков, то самым популярным ответом будет “ООП – это наследование, полиморфизм и инкапсуляция”. И последний выпуск javaswag (см. ответ на моё непопулярное мнение), кстати, это подтверждает.

Однако Алан Кей, автор термина, в одном из своих докладов заявил: “На самом деле это я придумал термин “объектно-ориентированный” и я могу сказать вам, что я не имел С++ ввиду”.
А имел он ввиду: обмен сообщениями, сокрытие состояния и экстремально позднее связывание.

И, как следствие, Джо Армстронг, создатель Erlang считает: “Erlang, возможно, является единственным объектно-ориентированным языком, потому что три принципа объектно-ориентированного программирования заключаются в передаче сообщений, изоляции между объектами и полиморфизмом. [...] ООП — это не про объекты и классы, ООП — это про сообщения”.

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

А что такое ООП для вас?

#oop@ergonomic_code #terminology@ergonomic_code #archeology@ergonomic_code #books@ergonomic_code