https://telegra.ph/CHistye-funkcii-ehffekty-i-sajdehffekty-01-05
#posts@ergonomic_code #fp@ergonomic_code
#posts@ergonomic_code #fp@ergonomic_code
Telegraph
Чистые функции, эффекты и сайдэффекты
Блог переехал на мой сайт Привет! На первый взгляд халявная тема при ближайшем рассмотрении оказалась довольно мутной. С чистыми функциями всё более-менее просто, у них на вики есть внятное определение:
Привет!
Продолжаем разбирать тему чистых функций и эффектов. Сегодня пост о чистых функциях.
И заодно хочу поделиться радостью - моя задумка с каналом как песочницей для книги похоже работает:) Я несколько месяцев не мог ничего толком написать поэтой теме в книгу, а в канал нормально пишется и по ходу дела я сам всё глужбе понимаю тему. Думаю венцом этой серии постов станет черновик ещё одного раздела книги:) Ещё раз спасибо, что вы со мной - даже просмотры без комментов дают мне мотивацию продолжать эту работу:)
https://telegra.ph/CHistye-i-gryaznye-funkcii-ehffekty-i-obrabotka-signalov-sajdehffekty-chistye-funkcii-01-12
#posts@ergonomic_code #fp@ergonomic_code
Продолжаем разбирать тему чистых функций и эффектов. Сегодня пост о чистых функциях.
И заодно хочу поделиться радостью - моя задумка с каналом как песочницей для книги похоже работает:) Я несколько месяцев не мог ничего толком написать поэтой теме в книгу, а в канал нормально пишется и по ходу дела я сам всё глужбе понимаю тему. Думаю венцом этой серии постов станет черновик ещё одного раздела книги:) Ещё раз спасибо, что вы со мной - даже просмотры без комментов дают мне мотивацию продолжать эту работу:)
https://telegra.ph/CHistye-i-gryaznye-funkcii-ehffekty-i-obrabotka-signalov-sajdehffekty-chistye-funkcii-01-12
#posts@ergonomic_code #fp@ergonomic_code
Telegraph
Чистые и грязные функции, эффекты и обработка сигналов, сайдэффекты: чистые функции
Привет! Обращаю ваше внимание, что топик расширился - помимо анонсированных вчера грязных функций, вчера же я ещё "открыл" сигналы.Заголовок конечно длинноват, но пока так:)Но обо всём по порядку и сегодня у нас чистые функции. Чистая функция - это функция…
Привет!
Сегодня подготовил вам лонгрид на 1.7К слов (обычно в районе 500) об эффектах. Если вы думаете, что его будет долго читать, то представьте, сколько его было писать:) девять часов, я замерял:)
Пока не уверен, но возможно это потому, что в этом посте изложен Самый Главный Принцип Эргономичного Подхода. Поэтому в этот раз отдельно прошу вас написать что думаете по этой теме, можно в личку, если в комменты стрёмно.
#fp@ergonomic_code
Сегодня подготовил вам лонгрид на 1.7К слов (обычно в районе 500) об эффектах. Если вы думаете, что его будет долго читать, то представьте, сколько его было писать:) девять часов, я замерял:)
Пока не уверен, но возможно это потому, что в этом посте изложен Самый Главный Принцип Эргономичного Подхода. Поэтому в этот раз отдельно прошу вас написать что думаете по этой теме, можно в личку, если в комменты стрёмно.
#fp@ergonomic_code
Telegraph
Чистые функции, эффекты, грязные функции и сайдэффекты: эффекты
Блог переехал на мой сайт Aleksey Начало темы здесь и здесь. Сегодня расскажу о том, что я понимаю под эффектами и обработкой сигналов. Что я понимаю под эффектами и сигналами Обработка сигнала - акт чтения глобальной изменяемой памяти. Отправка сигнала …
Привет!
Сегодня пост в рубрику "Актуальное":)
О том как нарушение принципов эргономичного подхода повышает wtf/s :)
#posts@ergonomic_code #ergo_approach@ergonomic_code #fp@ergonomic_code
Сегодня пост в рубрику "Актуальное":)
О том как нарушение принципов эргономичного подхода повышает wtf/s :)
#posts@ergonomic_code #ergo_approach@ergonomic_code #fp@ergonomic_code
Telegraph
Неэргономичный Jackson
В последнее вермя несколько раз писал примерно такой код для сериализации объекта в json Jackson-ом:
Привет!
По времени опубликовал пост о функциях-мошенниках. Сейчас мне эта терминология уже совсем не нравится, но я сильно долго мурыжу этот пост так что пока пусть будет так. Ну и надеюсь суть мне удалось описать.
И в эрго-постах сейчас будет некоторый перерыв. Во-первых, что-то мне стало совсем стыдно за "лого" этого канала - попробую хотя бы в векторе его перерисовать, во-вторых мне надо руками переделывать форматирование в телеграфе - поищу блог-платформу поддерживающую asciidoc, в-третьих, следующий пост будет заключительный в этом цикле и там надо будет уже утрясти терминологию наконец
#posts@ergonomic_code #fp@ergonomic_code #why_no_side_effects@ergonomic_code
По времени опубликовал пост о функциях-мошенниках. Сейчас мне эта терминология уже совсем не нравится, но я сильно долго мурыжу этот пост так что пока пусть будет так. Ну и надеюсь суть мне удалось описать.
И в эрго-постах сейчас будет некоторый перерыв. Во-первых, что-то мне стало совсем стыдно за "лого" этого канала - попробую хотя бы в векторе его перерисовать, во-вторых мне надо руками переделывать форматирование в телеграфе - поищу блог-платформу поддерживающую asciidoc, в-третьих, следующий пост будет заключительный в этом цикле и там надо будет уже утрясти терминологию наконец
#posts@ergonomic_code #fp@ergonomic_code #why_no_side_effects@ergonomic_code
Telegraph
Типы функций: функции-мошенники
Блог переехал на мой сайт Пост для канала "эргономичный код"Начало здесь, здесь и здесь.С второго взгляда терминология оказалась не такой уж чудесной, как показалась на первый взгляд, но я на этом посте засиделся, так что публикую как есть. В посте с итогами…
Привет!
Наткунлся на прикольную статью об объектах и абстрактных типах данных. Не особо практичная, именно прикольная - автор приходит к выводу, что функции высших порядков чаще используются в ОО, чем ФП программах, и что лямбда исчесления были "untyped λ-calculus was the first object-oriented language.":)
Более практично же обеъекты и АДТ рассмотрены в этой статье.
Если в кратце - объекты не должны быть единственным инструментом разработчка. Объекты надо применять, когда вероятность появления новых типов (наследников, реализаций интерфейсов), выше вероятности появления новых данных - в этом случае "данные" (Алгебраические типы данных), позволят добавить их не трогая старый код.
А иногда надо вообще запретить расширение клиентами, и в этом случае используются Абстрактные типы данных.
#papers@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code
Наткунлся на прикольную статью об объектах и абстрактных типах данных. Не особо практичная, именно прикольная - автор приходит к выводу, что функции высших порядков чаще используются в ОО, чем ФП программах, и что лямбда исчесления были "untyped λ-calculus was the first object-oriented language.":)
Более практично же обеъекты и АДТ рассмотрены в этой статье.
Если в кратце - объекты не должны быть единственным инструментом разработчка. Объекты надо применять, когда вероятность появления новых типов (наследников, реализаций интерфейсов), выше вероятности появления новых данных - в этом случае "данные" (Алгебраические типы данных), позволят добавить их не трогая старый код.
А иногда надо вообще запретить расширение клиентами, и в этом случае используются Абстрактные типы данных.
#papers@ergonomic_code #oop@ergonomic_code #fp@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
Наконец-то прочитал пару классических научных статей по ФП:
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
Это снова я:)
Анкл Боб недавно написал новый пост с восхвалением ФП.
Да-да, это тот самый Анкл Боб, который придумал SOLID - "5 основных принципов объектно-ориентированного программирования", согласно русской Википедии.
#posts@ergonomic_code #fp@ergonomic_code
Привет!
Пересмотрел старый доклад моего любимого Рича Хикки.
Он там прямым текстом говорит, что доклад не про то, чтобы попинать ООП, но получается у него очень хорошо. При том на фундаментальном уровне.
Но самая крутая на мой взгляд штука - это Эпохальная Модель Времени, кратко описная здесь.
Очень рекомендую к вдумчивому просмотру
#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code #immutable_domain_model@ergonomic_code
Пересмотрел старый доклад моего любимого Рича Хикки.
Он там прямым текстом говорит, что доклад не про то, чтобы попинать ООП, но получается у него очень хорошо. При том на фундаментальном уровне.
Но самая крутая на мой взгляд штука - это Эпохальная Модель Времени, кратко описная здесь.
Очень рекомендую к вдумчивому просмотру
#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code #immutable_domain_model@ergonomic_code
InfoQ
Are We There Yet?
In his keynote at JVM Languages Summit 2009, Rich Hickey advocated for the reexamination of basic principles like state, identity, value, time, types, genericity, complexity, as they are used by OOP today, to be able to create the new constructs and languages…
Привет!
Сегодня линкопост: Functional Programming for Pragmatists
Мужик говорит быстро, поэтому слушать довольно тяжело, но мне нравится его определение и объяснение ФП.
Отдельно крут критерий определения чистоты функции: функция чистая, только если её можно заменить на (потенциально огромную) хэшмапу из параметров функции в результаты вызова.
Наконец, мужик в части дебага классно поясняет то, что я называю "локальностью рассуждей".
В общем прям рекомендую видос, особенно тем, кто (пока что:)) не пришёл к выводу, что чистые функции - самый эргономичный способ разработки програм на сегодняшний момент
#talks@ergonomic_code #fp@ergonomic_code
Сегодня линкопост: Functional Programming for Pragmatists
Мужик говорит быстро, поэтому слушать довольно тяжело, но мне нравится его определение и объяснение ФП.
Отдельно крут критерий определения чистоты функции: функция чистая, только если её можно заменить на (потенциально огромную) хэшмапу из параметров функции в результаты вызова.
Наконец, мужик в части дебага классно поясняет то, что я называю "локальностью рассуждей".
В общем прям рекомендую видос, особенно тем, кто (пока что:)) не пришёл к выводу, что чистые функции - самый эргономичный способ разработки програм на сегодняшний момент
#talks@ergonomic_code #fp@ergonomic_code
YouTube
Functional Programming for Pragmatists • Richard Feldman • GOTO 2021
This presentation was recorded at GOTO Copenhagen 2021. #GOTOcon #GOTOcph
http://gotocph.com
Richard Feldman - Functional Programming Language Expert & Author of "Elm in Action" @rtfeldman @SoftwareUnscripted
ABSTRACT
Do you care more about how well code…
http://gotocph.com
Richard Feldman - Functional Programming Language Expert & Author of "Elm in Action" @rtfeldman @SoftwareUnscripted
ABSTRACT
Do you care more about how well 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
Линко-пост
Прикольный "научпопный" доклад для
Только мужик говорит быстро и слушать сложно:(
Поэтому вот ещё ссылка из доклада на тему ОО/П.
Ну а для совсем ленивых, мой главный инсайт из этой статьи:
> 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
YouTube
Why Isn't Functional Programming the Norm? – Richard Feldman
Richard is a member of the Elm core team, the author of Elm in Action from Manning Publications, and the instructor for the Intro to Elm and Advanced Elm courses on Frontend Masters. He's been writing Elm since 2014, and is the maintainer of several open…
👍3💩1
Привет!
Наткунлся на обновлённую версию доклада Simple Made Ease с русскими субтитрами.
Доклад очень крутой, советую посмотреть, тем кто ещё не смотрел
#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code
Наткунлся на обновлённую версию доклада Simple Made Ease с русскими субтитрами.
Доклад очень крутой, советую посмотреть, тем кто ещё не смотрел
#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code
YouTube
"Simple Made Easy" - Rich Hickey (2011)
Rich Hickey, the author of Clojure and designer of Datomic, is a software developer with over 30 years of experience in various domains. Rich has worked on scheduling systems, broadcast automation, audio analysis and fingerprinting, database design, yield…
🔥1
Привет!
По совету подписчика начал читать Grokking Simplicity.
Пока прочитал 200 страниц из 600, но уже не могу удержать в себе восторг.
Это лучшая известная мне книга по функциональному стилю (или скорее data-oriented programming), с лучшим известным мне разбором двух основополагающих принципов проектирования:
1. разделение ввода-вывода и бизнес-логики
2. использование одного уровня абстракции в функции (анкл Бобовскя заметка на эту тему в чистом коде - даже близко не лежала с 1.5 главами об этом в книге).
Настоятельно рекомендую прочитать эту книгу всем, с опытом коммерческой работы от года и до бесконечности.
#books@ergonomic_code #functional_architecture@ergonomic_code #fp@ergonomic_code #js@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
Manning Publications
Grokking Simplicity - Eric Normand
This practical guide will change the way you approach software design and development. It shows you how to write software that keeps complexity close to its inherent minimum.
👍12
Эргономичный код
Привет! По совету подписчика начал читать Grokking Simplicity. Пока прочитал 200 страниц из 600, но уже не могу удержать в себе восторг. Это лучшая известная мне книга по функциональному стилю (или скорее data-oriented programming), с лучшим известным мне…
Привет!
Дочитал книгу. По традиции, тема разработки бэков поверх РСУБД практически не раскрыта (этому посвящено примерно 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
Дочитал книгу. По традиции, тема разработки бэков поверх РСУБД практически не раскрыта (этому посвящено примерно 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
Manning Publications
Grokking Simplicity - Eric Normand
This practical guide will change the way you approach software design and development. It shows you how to write software that keeps complexity close to its inherent minimum.
👍10
Мысль четвёртая
А ну и мысль четвёртая - если вы пишите бэки - вам надо ФП/ФА, а не ООП/DCI :)
Точнее DOP/ФА как здесь, а не чистый ФП как здесь
#dop@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code
А ну и мысль четвёртая - если вы пишите бэки - вам надо ФП/ФА, а не ООП/DCI :)
Точнее DOP/ФА как здесь, а не чистый ФП как здесь
#dop@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code
GitHub
Project-Mariotte/src/main/kotlin/mariotte/apps/guest/reservations/ReserveRoomOperation.kt at master · ergonomic-code/Project-Mariotte
Демонстрационный проект Эргономичного подхода - сервис бронирования номеров в отелях - ergonomic-code/Project-Mariotte
👍1
Привет!
В комментах к прошлому посту "внезапно" (🤦♂️ ) выяснилось что разные люди под "ФП" понимают разное.
Поэтому накатал коротенький микропост о том, что я имею ввиду говоря ФП
#terminology@ergonomic_code #fp@ergonomic_code #functional_architecture@ergonomic_code #oop@ergonomic_code #ergo_approach@ergonomic_code
В комментах к прошлому посту "внезапно" (
Поэтому накатал коротенький микропост о том, что я имею ввиду говоря ФП
#terminology@ergonomic_code #fp@ergonomic_code #functional_architecture@ergonomic_code #oop@ergonomic_code #ergo_approach@ergonomic_code
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥3
Привет!
Историческая минутка.
Если вы интересуетесь функциональным стилем, то возможно слышали про статью "Can Programming Be Liberated from the von Neumann Style?"
Это опубликованная версия лекции Бэкуса - автора Fortran-а и соавтора Backus-Naur Form - прочитанной при вручении ему премии Тюринга (нобелевки в мире информатики), в которой он критикует императивное программирование с операторами присваивания и в качестве альтернативы предлагает функциональный (хотя и довольно своеобразный) стиль программирования.
И если вы интересуетесь ФП, но не слышали про статью - это уже первая полезняшка:)
Но не последняя - я тут недавно около этой статьи накопал ещё пару интересных ссылок.
Во-первых, Бэкус занимался этой темой до своего выхода на пенсию в 91-ом году и было несколько попыток реализовать систему из статьи, чему в интернете посвящена целая страница :)
На этой же странице есть ссылка на сайт некоего Paul McJones, который кажется, может быть интересен любителям ИТ-археологии, но я в него не закапывался - меня таки накрыл дефицит времени, после рождения третьего ребёнка.
Во-вторых, Дейкстра (тоже лауреат премии Тюринга и мужик, который решил, что Go To плохо, придумал стурктурное программирование, семафоры, "separation of concerns", слоёную архитектуру и много ещё чего) для своих "подписчиков" сделал разгромное ревью доклада Бэйкуса, которое дошло до самого Бэйкуса через третьи руки, после чего у них случился научный махач.
Много лет спустя, разбирая свои бумаги для Библиотеки Конгресса, Бэкус каталогизировал эту переписку с комментарием:
А Дейкста и правда был тем ещё токсиком:
—
В общем если у вас есть время - покопайтесь в этих ссылках от души за меня:)
#fp@ergonomic_code #papers@ergonomic_code
Историческая минутка.
Если вы интересуетесь функциональным стилем, то возможно слышали про статью "Can Programming Be Liberated from the von Neumann Style?"
Это опубликованная версия лекции Бэкуса - автора Fortran-а и соавтора Backus-Naur Form - прочитанной при вручении ему премии Тюринга (нобелевки в мире информатики), в которой он критикует императивное программирование с операторами присваивания и в качестве альтернативы предлагает функциональный (хотя и довольно своеобразный) стиль программирования.
И если вы интересуетесь ФП, но не слышали про статью - это уже первая полезняшка:)
Но не последняя - я тут недавно около этой статьи накопал ещё пару интересных ссылок.
Во-первых, Бэкус занимался этой темой до своего выхода на пенсию в 91-ом году и было несколько попыток реализовать систему из статьи, чему в интернете посвящена целая страница :)
На этой же странице есть ссылка на сайт некоего Paul McJones, который кажется, может быть интересен любителям ИТ-археологии, но я в него не закапывался - меня таки накрыл дефицит времени, после рождения третьего ребёнка.
Во-вторых, Дейкстра (тоже лауреат премии Тюринга и мужик, который решил, что Go To плохо, придумал стурктурное программирование, семафоры, "separation of concerns", слоёную архитектуру и много ещё чего) для своих "подписчиков" сделал разгромное ревью доклада Бэйкуса, которое дошло до самого Бэйкуса через третьи руки, после чего у них случился научный махач.
Много лет спустя, разбирая свои бумаги для Библиотеки Конгресса, Бэкус каталогизировал эту переписку с комментарием:
This guy’s arrogance takes your breath away
--
От высокомерия этого парня захватывает дух
А Дейкста и правда был тем ещё токсиком:
Object-oriented programming is an exceptionally bad idea which could only have originated in California.
—
Объектно-ориентированное программирование — исключительно плохая идея, которая могла зародиться только в Калифорнии
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
—
Использование COBOL калечит разум; поэтому его преподавание следует считать уголовным преступлением
Fascination with the equipment is the hallmark of the amateur
—
Очарованность оборудованием — отличительный признак дилетанта
—
В общем если у вас есть время - покопайтесь в этих ссылках от души за меня:)
#fp@ergonomic_code #papers@ergonomic_code
❤5👌3