Когда анонс пройдёт?

Тоже жду его

Что думаете об ООП говорят что критичные системы и системные программы лучше писать в функциональном стиле? В ООП очень много мутации и недетерминированности?

А кто так говорит ?

Во превых, само определение "функционального стиля" слишком размыто, надо понимать что "функциональный стиль" подразумевает потокобезопасность и стэкобезопасность, потому требует реализации соответствующих тайпклассов для параметрического полиморфизма. Нужно понимать что в "Функциональном стиле" есть "наследование" и "полиморфизм" просто это разновидность свободных структур данных и свободных преобразований (Free Monad, Free Applicative), в рамках соответствующих алгебраических типов данных. Т.е. само наследование становиться значением, точно так же как и функция... а параметрический полиморфизм напрямую зависит от соответствующих неявных реализаций и неявных внедрений зависимостей - обычно делается с помощью плагинов к компиляторам, или уже встроено в языки.

Side effect'ы и мутации есть и в функциональщине, просто шутка про "как функциональный программист меняет лампочку" (сначала копирует мир, а потом меняет в новом экземпляре) в ряде случаев не позволяет писать эффективные реализации - для подобных случаев есть ряд абстракций, которые делают сам побочный эффект и мутацию значением.

В "функциональном стиле" тоже есть недетерминированность, всякие race condition'ы, dead lock'и, live lock'и, double acquisition и прочее... просто для управления ими есть соответствующие типы данных и на уровне статического анализа можно принимать решения как именно с этим нужно работать.

Другое дело конкретные реализации TypeClass'ов, которые уже требуют формальной верификации и соответствующих тестов.
Благо проверки законов (laws check) могут быть выполнены в тестах неявно, для всех существующих внедряемых реализаций.

Для пример, что Scala что Kotlin вроде бы и являются функциональными языками... но никто толком на них не пишет в "функциональном стиле", просто потому что привыкли к концепциям ООП. А для "функционального стиля" используется обилее макросов, пару плагинов к компилятору, и соответствующие правила формальной верификации алгебр и законов... люди редко хотят в такое окунаться, но и обратно не вылазят %)

Для ознакомления стоит познакомится с принципом параметрического полиморфизма на TypeClass'ах в функциональном программировании и шаблоном Концепт (Concept), на котором, кстати, работает большинство интерфейсов того же golang'a.

Короч хоть .map .flatMap и был проклят, но без понимания и использования TypeClass'ов в стэкобезопасном и потокобезопасном окружении, о "функциональном программировании" лучше не вспоминать.

Да, Option / Either удобен, но магии в нем нет. Магия есть в Free монадах и в IO монадах (как в частном случае Free монад), можно вспомнить про Йонеды/Койонеды... но это уже для посвящёных.

Вот простенький пример тайпклассов на интерфейсах в TS
https://paulgray.net/typeclasses-in-typescript/

кстати fp-ts довольно крутая штука

Да, но Variadic Kinds завезли и для TS4 немного непонятно как оно будет позиционироваться...

* ни в скале ни в котлине Variadic Kinds до сих пор нет

кстати пойду погуглю. а то недавно в тс столкнулся с потребностю в хайер кайндед

Это чуть другое... стоит глянуть Monad Transformers сначала, например EitherT а потом и EitherK

да. уже вижу что это не про ХК

Хочу заметить что конкретно для JS есть замечательнейшие cпецификации Static Land и Fantasy Land - там хоть и нету всех этих формальных верификациий, свободных монад и йонед, но для старта это очень и очень хорошая основа, т.к. описаны основные тайпклассы.

https://github.com/fantasyland/fantasy-land
https://github.com/fantasyland/static-land/blob/master/docs/spec.md

Магии и корректности точно не прибавит, но размер кода сократит и значительно упростит понимание… для тех кто спеку знает и понимает, конечно.

как бы фп "надежней" не из-за хороших систем типов, а из-за чистых функций и иммутабельности

Есть понятие «типобезопасности» - позволяет отваливаться прямо во время компиляции с ошибками которые в противном случае бы ушли в рантайм… даже сепарационную логику и Calculus Of Constructions можно выразить специализированными функциональными типами данных (завести borrow check’и в ту же скалу или котлин).

От этого пошли в своё время Typelevel и яко бы Typesafe Foundation’ы…

спасибо, кажется в функциональном стиле мало кто пишет потому что она сложнее для понимания и для того что бы привыкнуть к нему требуется дольше времени и практики

А вот объекты более легче понять и думать на них и реализововать

конечно есть, только есть еще мнение, что это не увеличивает надежность программы

> мало кто пишет

Ну в Киеве десятка три продуктовых компаний и пол сотни проектов в аутсорсах нашкрябать можно…

> требуется дольше времени и практики

В нормальной компании - пару месяцев.

> А вот объекты более легче понять и думать на них и реализововать

Субъективно да, но и абстракции текут тоже «намного легче», и сложность долгосрочной поддержки покрыта туманом войны.
Я к тому что на все существующие шаблоны проектирования достаточно 2-3 функциональных структур данных, что бы покрыть все edge case’ы…

Смотря чем писать и чем верифицировать корректность.
Та же сепарационная логика поверх refined типов имеет много тонких моментов которе можно решить только плагинами к компилятору и расширением существующей системы типов в языках, но на выходе получим просто набор свободных монад…

еще есть подход писать абстракции функциями, а не типами.

Почитайте что-то про Coyoneda и Coyoneda Trick в контексте свободных монад.

* у Алексея Авраменка была хорошая статья
https://medium.com/@olxc/yoneda-and-coyoneda-trick-f5a0321aeba4