🎉 Функционально Ориентированное Программирование (ФОП) официально релизнулось! И мне нужна ваша помощь
https://fop.davidshekunts.ru
После 2-х лет написания моя книга про ФОП достигла v1.0 🎉
Это еще далеко не конец, у меня намечены еще несколько разделов (про Cohesion vs Coupling, Error Handling, etc.), также записать пару видеоинструкций и начать выступать конференциях рассказывая про ФОП.
Релиз v1.0 ознаменовался тем, что @cyberJohnny бесплатно выложил посты о моей книге в кучу его пабликов, за что спасибо тебе большое, @cyberJohnny!
Если интересно, вот ссылки на паблики: 1, 2, 3, 4, 5 Нужна ваша помощь! Во-первых, огромная помощь – это комментарии и критика написанного в книге. Я правда верю в то, что написал и уже много лет это использую. НО только благодаря обсуждению мыслей из книги я могу делать их как-либо улучшать. Поэтому любые вопросы и мысли приветствуются!
Во-вторых, мне хотелось бы как-то начать ее распространять, но я крайне туп в маркетинге... не знаю что с ней делать и как начать выводить ее в массы активнее. Поэтому, если вам понравился материал и вы можете выложить у себя в блоге или кому-то посоветовать, или посоветовать мне какой-то паблик, куда стоит обратиться за постингом, буду очень благодарен!
P.S.
Еще я сделал рекламу блога и это принесло +53 подписчика в качалку, велком, друзья 😍
После 2-х лет написания моя книга про ФОП достигла v1.0 🎉
Это еще далеко не конец, у меня намечены еще несколько разделов (про Cohesion vs Coupling, Error Handling, etc.), также записать пару видеоинструкций и начать выступать конференциях рассказывая про ФОП.
Релиз v1.0 ознаменовался тем, что @cyberJohnny бесплатно выложил посты о моей книге в кучу его пабликов, за что спасибо тебе большое, @cyberJohnny!
Если интересно, вот ссылки на паблики: 1, 2, 3, 4, 5 Нужна ваша помощь! Во-первых, огромная помощь – это комментарии и критика написанного в книге. Я правда верю в то, что написал и уже много лет это использую. НО только благодаря обсуждению мыслей из книги я могу делать их как-либо улучшать. Поэтому любые вопросы и мысли приветствуются!
Во-вторых, мне хотелось бы как-то начать ее распространять, но я крайне туп в маркетинге... не знаю что с ней делать и как начать выводить ее в массы активнее. Поэтому, если вам понравился материал и вы можете выложить у себя в блоге или кому-то посоветовать, или посоветовать мне какой-то паблик, куда стоит обратиться за постингом, буду очень благодарен!
P.S.
Еще я сделал рекламу блога и это принесло +53 подписчика в качалку, велком, друзья 😍
Комментарии: 17
A
🦾
A
Я ожида увидеть книгу, где есть структура (оглавление как минимум), вместо этого набор ссылок, часть ссылок скрыта.
Описание структуры данных (Data) - туту скрываеются примеры реализации, но потом идут ссылки на разделы книги: Дисклеймер про TypeScript -> вы узнаете в разделе “Языки программирования”. С этого места читать книгу начать? Или есть что-то перед эитм? Что идет после этого раздела ?
Описание структуры данных (Data) - туту скрываеются примеры реализации, но потом идут ссылки на разделы книги: Дисклеймер про TypeScript -> вы узнаете в разделе “Языки программирования”. С этого места читать книгу начать? Или есть что-то перед эитм? Что идет после этого раздела ?
🦾
V
Начал читать твою книгу, когда она была ещё циклом статей в блоге. Кажется, уже года 2 прошло 🤔
Периодически поглядывал обновления.
Для той первой серии статей структура ссылок была понятна. Для книги все же формат не очень удобен.
На досуге перечитаю последнюю версию и возможно покритикую прокомментирую уже по существу.
Периодически поглядывал обновления.
Для той первой серии статей структура ссылок была понятна. Для книги все же формат не очень удобен.
На досуге перечитаю последнюю версию и возможно покритикую прокомментирую уже по существу.
A
Я недавно ознакомился с содержанием. Спасибо за популиризацию ФП! Нашел для себя несколько удобных паттернов.
У меня есть критика.
Почему ФП нужно называть ФОПом?
Тезис «Данные и поведение (функции) существуют раздельно друг от друга и любая функция может использовать в любые данные.» можно отнести к ФП.
В разделе «ФОП vs ФП»:
1. Пункт «Низкий порог входа». Монады и т.п. и в ФП особо не нужны. Это опционально, чтобы было меньше боилерплейт кода. На мой взгляд, порог входа выше из-за отсутствия документации с примерами к библиотекам.
2. Дальше просто идут сходства. 😁
Хорошо, это методология, а не парадигма, но зачем тогда ставить её напротив ФП? 🙃
У меня есть критика.
Почему ФП нужно называть ФОПом?
Тезис «Данные и поведение (функции) существуют раздельно друг от друга и любая функция может использовать в любые данные.» можно отнести к ФП.
В разделе «ФОП vs ФП»:
1. Пункт «Низкий порог входа». Монады и т.п. и в ФП особо не нужны. Это опционально, чтобы было меньше боилерплейт кода. На мой взгляд, порог входа выше из-за отсутствия документации с примерами к библиотекам.
2. Дальше просто идут сходства. 😁
Хорошо, это методология, а не парадигма, но зачем тогда ставить её напротив ФП? 🙃
🦾
Вопрос отличный)
Удалось ознакомиться с главой https://fop.davidshekunts.ru/origins/why-fp-and-pp-is-not-a-solution ?
Если после нее останутся вопросы, напишу ещё одну статью немного в другом разрезе
Удалось ознакомиться с главой https://fop.davidshekunts.ru/origins/why-fp-and-pp-is-not-a-solution ?
Если после нее останутся вопросы, напишу ещё одну статью немного в другом разрезе
A
🦾
Тогда тут 2 поинта:
1. Если мы считаем утверждение, что мутабельное состояние норма в ФП, тогда ФОП это структурное описание принципов ФП (которые пересекаются с Процедурным Ппрограммированием), составленое по структуре описания ООП (философия, столпы, паттерны). ФОП – это наблюдение за ФП, ПП и (Anemic) ООП кодом, которые я структурно описал в одной книге, потому что нигде не нашел подобного.
2. Но лично мое мнение, ФП без стейтлесс (то есть, с мутациями) нельзя называть ФП. По факту, получится ПП с механиками ФП (что кстати и описывает ФОП), ну или же мультипарадигмальщина, если ФП язык создавался поверх ООП языков / интерпретаторов (ReScript, Scala, F#, etc.).
Вся прелесть ФП – детерминизм, безопасная и легкая паралелльность вычислений и изоляция каждой функции*, что доступно только благодаря стейтлесс, а значит особенным конструкциям языка / интерпретатора (Haskell, Erlang, Elixir, etc.). И именно стейтлесс делает использование монад и подобного обязательным.
Все примеры функциональных языков или библиотек для не канонично функциональных языков, дают выразительные инструменты для написания ФП-подобного кода, но не дают самого главного, что предлагает ФП.
* – изоляция функций лучше всего прослеживается на примере Erlang VM, которая берет ваше приложение и разворачивает каждую отдельную функцию, как "мини-приложение". При следующем деплое, VM понимает какие функции изменились, отрубает от старых трафик и запускает новые. Именно так Ericsson (создатели Erlang) добились 99.999% uptime.
1. Если мы считаем утверждение, что мутабельное состояние норма в ФП, тогда ФОП это структурное описание принципов ФП (которые пересекаются с Процедурным Ппрограммированием), составленое по структуре описания ООП (философия, столпы, паттерны). ФОП – это наблюдение за ФП, ПП и (Anemic) ООП кодом, которые я структурно описал в одной книге, потому что нигде не нашел подобного.
2. Но лично мое мнение, ФП без стейтлесс (то есть, с мутациями) нельзя называть ФП. По факту, получится ПП с механиками ФП (что кстати и описывает ФОП), ну или же мультипарадигмальщина, если ФП язык создавался поверх ООП языков / интерпретаторов (ReScript, Scala, F#, etc.).
Вся прелесть ФП – детерминизм, безопасная и легкая паралелльность вычислений и изоляция каждой функции*, что доступно только благодаря стейтлесс, а значит особенным конструкциям языка / интерпретатора (Haskell, Erlang, Elixir, etc.). И именно стейтлесс делает использование монад и подобного обязательным.
Все примеры функциональных языков или библиотек для не канонично функциональных языков, дают выразительные инструменты для написания ФП-подобного кода, но не дают самого главного, что предлагает ФП.
* – изоляция функций лучше всего прослеживается на примере Erlang VM, которая берет ваше приложение и разворачивает каждую отдельную функцию, как "мини-приложение". При следующем деплое, VM понимает какие функции изменились, отрубает от старых трафик и запускает новые. Именно так Ericsson (создатели Erlang) добились 99.999% uptime.
🦾
Да, если без rollback обойтись не вариант, то согласен с каждым пунктом.
Как я смотрю на парадигму "Нет пути назад":
. Если мы не ориентируемся на rollback, а значит фикс будет осуществлен поверх, тогда у меня освобождается время и появляется больше мотивации создать условия при которых мы сможем накатить этот фикс. Команда инвестирует больше времени на логи и трейсинг для быстрого дебагинга ситуации. Создается больше хранимые state machine, которые в случае неуспеха укажут на произошедшую ошибку. В каждом куске кода мы думаем: "А что если пойдет по жопе?" – и пишем код ориентируясь на это. Посвящаем больше времени и сил на e2e и интеграционные тесты.
Несомненно, это хорошая практика и в случае наличия rollback, но честно слово, одна мысль: "если что, откатимся" – очень расслабляет разработчиков.
. Если мы понимаем, что релиз крайне опасный, мы можем вместо того, чтобы инвестировать время в rollback, проинвестировать его в релиз на % аудитории, чтобы в случае проблемы, не дать пострадать всем сразу.
+ на мой взгляд, гораздо сложнее придумать правильную тактику отката, чем тактику фикса (например, то, что ты писал во 2-м пункте очень редко кто вспоминает про такой подход)
++ несомненно, это можно миксовать: в стандарте используем тактику БЕЗ rollback, но если ситуация обязывает, то подготавливаем инструменты для отката конкретно данной ситуации (потому что, на моем опыте, сложный откат – это откат чего-то крайне специфичного, чего у нас в нашем стандартном флоу rollback просто не будет и его придется делать здесь и сейчас)
Как я смотрю на парадигму "Нет пути назад":
. Если мы не ориентируемся на rollback, а значит фикс будет осуществлен поверх, тогда у меня освобождается время и появляется больше мотивации создать условия при которых мы сможем накатить этот фикс. Команда инвестирует больше времени на логи и трейсинг для быстрого дебагинга ситуации. Создается больше хранимые state machine, которые в случае неуспеха укажут на произошедшую ошибку. В каждом куске кода мы думаем: "А что если пойдет по жопе?" – и пишем код ориентируясь на это. Посвящаем больше времени и сил на e2e и интеграционные тесты.
Несомненно, это хорошая практика и в случае наличия rollback, но честно слово, одна мысль: "если что, откатимся" – очень расслабляет разработчиков.
. Если мы понимаем, что релиз крайне опасный, мы можем вместо того, чтобы инвестировать время в rollback, проинвестировать его в релиз на % аудитории, чтобы в случае проблемы, не дать пострадать всем сразу.
+ на мой взгляд, гораздо сложнее придумать правильную тактику отката, чем тактику фикса (например, то, что ты писал во 2-м пункте очень редко кто вспоминает про такой подход)
++ несомненно, это можно миксовать: в стандарте используем тактику БЕЗ rollback, но если ситуация обязывает, то подготавливаем инструменты для отката конкретно данной ситуации (потому что, на моем опыте, сложный откат – это откат чего-то крайне специфичного, чего у нас в нашем стандартном флоу rollback просто не будет и его придется делать здесь и сейчас)
A
🦾
Я бы сказал: для ФОП иммутабельность – это опция, которая несет как преимущества, так и недостатки, поэтому ФОП остается полноценным и полностью мутабльным.
А монады и подобное, это вообще если всей команде прям хочется) То есть, да, их можно полностью опустить при использовании ФОП.
А монады и подобное, это вообще если всей команде прям хочется) То есть, да, их можно полностью опустить при использовании ФОП.
🦾
Одновременно с этим: если бы я использовал каноничный ФП язык, я бы не стал ориентироваться на ФОП (я бы использовал строгий ФП дизайн), а если я использую ООП язык, то я бы писал по ФОП (потому что ФОП спокойно можно использовать в полностью ООП-шном языке)