Функционально Ориентированное Программирование (ФОП) v1.0: Релиз и план

Я бросил знакомиться с ресурсом, после того, как не разобрался во всей структуре ссылок. Книга - которая максимально пытается ей не быть.
Удачи в продвижении.

О, вот это интересный поинт

То есть, вы пишите: \"Мне непонятна и неудобна структура ссылок\" - верно? Если так, то что больше всего неудобно?

Я согласен что забил на кнопки \"следующий / предыдущий раздел\", это добавлю, что-то ещё?

Я ожида увидеть книгу, где есть структура (оглавление как минимум), вместо этого набор ссылок, часть ссылок скрыта.
Описание структуры данных (Data) - туту скрываеются примеры реализации, но потом идут ссылки на разделы книги: Дисклеймер про TypeScript -> вы узнаете в разделе “Языки программирования”. С этого места читать книгу начать? Или есть что-то перед эитм? Что идет после этого раздела ?

Хорошие замечания, спасибо!

Тогда сделаю следующее:

. Добавлю оглавление
. Пронумерую разделы и главы
. Избавлюсь от лишних ссылок
. Сделаю удобные кнопки перехода от главы к главе

Может ещё что по дороге придет в голову

Да, спасибо большое

Сделал себе подарок на др

Начал читать твою книгу, когда она была ещё циклом статей в блоге. Кажется, уже года 2 прошло 🤔
Периодически поглядывал обновления.

Для той первой серии статей структура ссылок была понятна. Для книги все же формат не очень удобен.

На досуге перечитаю последнюю версию и возможно покритикую прокомментирую уже по существу.

Поздравляю 🤝

Я недавно ознакомился с содержанием. Спасибо за популиризацию ФП! Нашел для себя несколько удобных паттернов.

У меня есть критика.

Почему ФП нужно называть ФОПом?

Тезис «Данные и поведение (функции) существуют раздельно друг от друга и любая функция может использовать в любые данные.» можно отнести к ФП.

В разделе «ФОП vs ФП»:
1. Пункт «Низкий порог входа». Монады и т.п. и в ФП особо не нужны. Это опционально, чтобы было меньше боилерплейт кода. На мой взгляд, порог входа выше из-за отсутствия документации с примерами к библиотекам.
2. Дальше просто идут сходства. 😁

Хорошо, это методология, а не парадигма, но зачем тогда ставить её напротив ФП? 🙃

Вопрос отличный)

Удалось ознакомиться с главой https://fop.davidshekunts.ru/origins/why-fp-and-pp-is-not-a-solution ?

Если после нее останутся вопросы, напишу ещё одну статью немного в другом разрезе

Прочитал. Не понимаю, почему ФОП ≠ ФП. 🙂

Мутабельное состояние и в ФП можно использовать. Монады опять же опциональны.

Тогда тут 2 поинта:

1. Если мы считаем утверждение, что мутабельное состояние норма в ФП, тогда ФОП это структурное описание принципов ФП (которые пересекаются с Процедурным Ппрограммированием), составленое по структуре описания ООП (философия, столпы, паттерны). ФОП – это наблюдение за ФП, ПП и (Anemic) ООП кодом, которые я структурно описал в одной книге, потому что нигде не нашел подобного.

2. Но лично мое мнение, ФП без стейтлесс (то есть, с мутациями) нельзя называть ФП. По факту, получится ПП с механиками ФП (что кстати и описывает ФОП), ну или же мультипарадигмальщина, если ФП язык создавался поверх ООП языков / интерпретаторов (ReScript, Scala, F#, etc.).

Вся прелесть ФП – детерминизм, безопасная и легкая паралелльность вычислений и изоляция каждой функции*, что доступно только благодаря стейтлесс, а значит особенным конструкциям языка / интерпретатора (Haskell, Erlang, Elixir, etc.). И именно стейтлесс делает использование монад и подобного обязательным.

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

* – изоляция функций лучше всего прослеживается на примере Erlang VM, которая берет ваше приложение и разворачивает каждую отдельную функцию, как "мини-приложение". При следующем деплое, VM понимает какие функции изменились, отрубает от старых трафик и запускает новые. Именно так Ericsson (создатели Erlang) добились 99.999% uptime.

Хорошо. Теперь понятно, что для ФОП важно, чтобы было только мутабельно и без сложных абстрактных структур (монад). Если рассматривать рядом с чистым ФП.

Я бы сказал: для ФОП иммутабельность – это опция, которая несет как преимущества, так и недостатки, поэтому ФОП остается полноценным и полностью мутабльным.

А монады и подобное, это вообще если всей команде прям хочется) То есть, да, их можно полностью опустить при использовании ФОП.

Одновременно с этим: если бы я использовал каноничный ФП язык, я бы не стал ориентироваться на ФОП (я бы использовал строгий ФП дизайн), а если я использую ООП язык, то я бы писал по ФОП (потому что ФОП спокойно можно использовать в полностью ООП-шном языке)

Когда книга полностью выйдет с примерами?

Ближе к концу года у меня появится достаточно много свободного времени и я планирую собрать 2 примера сервисов по ФОП для TypeScript и Golang

Там будет код + набор статей + возможно, серия видео, как я это все пилю

Мне кажется это будет самый наглядный способ продемонстрировать преимущества ФОП

Если есть классные примеры демонстрации возможностей ФП, ПП или ООП, буду признателен ссылке, чтобы я возможно написал тоже самое, но на ФОП

Звучит классно, но разве GO нормально фп поддерживает? Хотелось бы увидеть rust и python.

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

Реально в Go только не хватает паттерн мэтчинга, чтобы на нем можно было использовать абсолютно все трюки ФОП

Про Rust скажу, что опыт ФОП с TS и Go на нем вполне можно применить (потому что использование ФОП никак не пересекается с отличиями Rust от этих языков, например, в вопросах memory и concurrency management)

А вот для Python придется использовать некоторые трюки: поскольку в нем нет type / interface, надо использовать class, для pattern matching тоже нужны хитрости, а брендированные типы там возможно недоступны, ну и так далее