Недостатки реактивного программирования

Недостаток в том, что веб-макаки его не осилят

Оно повсеместно используется. Rxjs и обвязки вокруг нее, одна из самых популярных библиотек в web2k. Весь ангуляр построен на явных реактивных потоках. Реактовские стейты построены на этих потоках неявно. К реактовским сторам привязывают явные потоки, чтобы менеджить экшены. Сам по сеье дата биндинг, который используется уже очень давно и всеми осилен, построен так или иначе на этих самых потоках распространения.

Как и всегда - люди, которые суют его в дело и не в дело. В результате выжирание ресурсов на «растекание» изменений, которое в 95% никому не нужно, и засирание кода обвязками для биндингов т.к. не везде есть синтаксический сахар для таких вещей.

Успешного опыта у меня нет но вот мои негативные впечатления от попытки.

Cons:

1. Если в языке нет поддержки await/async то код превращается в нечитаемую хрень с замыканиями/лямбдами. В рантайме цепочки обработчиков формируются динамически, логика может пойдет по A->B->C, а может по A->B->E->F. Смотришь в код и не понимаешь как именно все будет.

2. У тебя нет стека несущего текущее состояние, только контекст на уровне фрейморвка. Теперь попробуй поставить брейкопинт.

3. Из-за пункта 2 остается дебагинг через логирование.

Жду опровержений, интересен опыт товарищей добившихся успехов.

Больше вреда, чем пользы. Код читать невозможно. Мобильщики пихают свои RxSwift/RxJava куда попало, а потом удивляются, что получилось говно.

Пять-шесть лет уже как осилили

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

Значительно меньше в абсолютных числах людей ими пользовалось. Сейчас мы можем наблюдать, как даже конченые дегенераты спокойно пишут как минимум мидлвари под редакс, и им норм.

В абсолютных числах в то время и веб писало меньше людей, да и программировало в целом меньше.

Да. И реактивное программирование в разных видах таки пережило переход в массовость.

Ну судя поэтому треду у него нет никаких существенных минусов и это поистине идеальная парадигма. Достаточно сравнить сколько критики вываливается на любую другую парадигму программирования.

никто нигде не пишет о подводных камнях.

Их нет.

Если в ИТ что-то не обсерают, значит оно мертво.

никто нигде не пишет о подводных камнях.

Их нет.

Только скалы. ;)

о подводных камнях.

не вижу «сап, ананасы» и том как ты собираешься куда-то вкатится

Как РП может быть мертво, если по крайней мере в вебе сегодня оно используется повсеместно, а судя по переодическому нытью разработчиков других платформ, его тащат куда угодно.

Я бы в явные минусы записал сложности с отладкой. Это как правило ни о чем не говорящие stack trace, трудности с остлеживанием цепочек событий по системе, размеров очередей и прочего.

Понятно что все это зависит от языка программирования и фреймворка, и готовности к такому подходу средств диагностики.

Если объективно, чем эти сложности сложнее аналогичных при любом ином подходе для программирования систем заточенных на события? ТО есть буквально любая сложная система, которая состоит из множества взаимодействующих асинхронно сервисов или компонент. Все, что сложнее «утилиты делающий ровно одну вещь». Они же дебажатся и тестятся так же декомпозиционно, а в случае реактивных потоков, при этом есть возможность оттестировать любой такой поток событий\данных отдельно от этих компонент, которые его используют.

Ты — ололошка, оно в основном на фронте и используется на сегодняшний день.

Ты тупой качок, откуда тебе знать?

И чо? Можно подумать вебмакаки знают что такое backpressure, hot and cold publishers и прочие ньюансы. Они тупо копи-пастом из туториалов занимаются, а потом у них SPA тормозит.

Кто-то же пишет им фреймфорки, так что твоё заявление априори абсурдно.

Недостаток самый главный, который я для себя увидел - в чистом виде оно нахрен не нужно.

Отладка превращается в ад.

В общем, никаких существенных камней нет, одни удобства. Яснопонятно.

Учитывая что у тебя слэш написан не православно тематике данного ресурса - твоим мнением можно пренебречь.

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

Короче для человека удобно ибо это тупо программируемая цепочка действий на основе переходов и состояний где суть кишков скрыта, для процессора это постоянные срывы вычислений.

Ещё короче. Тупо тормоза как там by design.

Для небольших вещей типа чатов или таблиц вычислений ок, для прям чего то шибко широкого по данным это боль, ад и садома.

Эммм, невозможность или крайне завтруднителная возможноть отладить, а так же самый неоптимальный способ работы по отношению ко всем современным процессорам это не камни?

• 1 У тебя релально большая программа и баг который просто нельзя отловить явно

• 2 У тебя реально большая программа и она тупит и ты с этим НИЧЕГО не сможешь поделать кроме как переписать целиком или добавлять хаки вносящие ограничения в саму концепцию реактивности от чего в документации нужно указывать что вот там тат тут и там можно только так, а не иначе.

Если у тебя небольшое приложение и/или реактивных подход идёт в отношении малого объёма данных. То всё хорошо. Но всегда будет момент когда шаг в сторону большего рождает ад.

Например у тебя 100 пользователей когда 1 дарит подарок другому у всех повляется сообщение об этом и каждому предлагается тоже сделать подарок при этом проверяется был ли отправлен он после события или просто так иначе не появляется и так далее. При 100 человек и 10 разных событиях типа подарков получаем 100 * 10 * 100 * 10 действий. При тысяче человек ты начнёшь городить дичайшие костыли сортировки/выборки/фильтрации. Переносить часть логики на клиента и так далее.

Через год подобного ты взвоешь. Хотя если у тебя как было 100 человек так и осталось, то всё будет замечательно.

дебагинг через логирование.

это единственно правильные дебагинг.

рп - удобно, а за удобство всегда приходится платить - кишки платформ сложны и не читаемы; чего и как в кишках платформы происходит, никто не понимает; всё это требует тонну памяти; огромные накладные «эффекты», когда простые с виду операции приводят к выполнению 100500 строк кода; если есть gc у него просто крышу сносит - память течёт. Но на рп пара тройка толковых спецов могут за пару недель сделать то на что раньше нужны были месяцы и большие команды.

Но на рп пара тройка толковых спецов могут за пару недель сделать то на что раньше нужны были месяцы и большие команды.

Ок, они написали корректный реактивынй код, но как его другим людям прочитать? Я вспоминаю webflux фрейморк в spring, а именно часть авторизации, я просто не осилил. Смотря на это мне стало страшно что если я что-то рожу реактивное, через пару месяцев я просто буду боятся этот код, это как sql, написать легче чем понять написанное.

Ну ладно, наверное все таки это зависит от того встроено ли в язык async/await/suspend. Может в ts/js/kotlin все не так страшно с точки зрения восприятия реактивного кода.

Даже если им пообещать, что веб станет ещё медленнее?

Для рп не нужны никакие async\await в синтаксисе языка.

РП это про

 a = 1
b = 2
write(a + b)

И теперь у тебя write будет выполняться при каждом новом значении a или b. Всё.

В ФРП это все выражает простой цепочкой трансдьюсеров, вида

flow( of(1, 2), sum(), write() ).subscribe()

Что именно тут может быть сложного? Это просто удобная запись (абстракция над) эммитером сообытий, где тебе не надо ручками создавать сотню другую жммитеров, выстраивать между ними связи, подписываться в ручную на собыятия каждого, навешивать и удалять слушателей. Observable потоки просто заворачивают все это врнутрь, предоставляя тебе интерфейс для подписки и отписки сразу на ПОТОКИ этих событий. Никакие авайты тебе тут не нужны. Когда именно произойдет событие тебе уже не важно, ты просто описываешь поток преобразования этого события.

Веб термозит только у колясочников с ЛОРа. У всех нормальных людей с вебом всё в порядке.

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

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

Речь само собой о реактивных потоках этих самых данных/событий, шаблоне наблюдателе и вот этом всем

Это не реактивное программирование. На этом можно и закончить тред.

Если в языке нет поддержки await/async то код превращается в нечитаемую хрень с замыканиями/лямбдами. В рантайме цепочки обработчиков формируются динамически, логика может пойдет по A->B->C, а может по A->B->E->F. Смотришь в код и не понимаешь как именно все будет.

А вот тут ты правильную проблему подымаешь. Вообще-то код как раз и должен быть достаточно гибким, ограничивать свои эффекты неким локальным действием и не зависеть от других побочных эффектов. То, что нет инструментов для описания таких вещей и нет инструментов для их отладки — это проблема. Та же проблема повторяется и для хардварных потоков, где выполнение A->B->C может пойти на ARM-е и вовсе как B->A->C, если операции короткие и неатомарные.

Сейчас мы можем наблюдать, как даже конченые дегенераты спокойно пишут как минимум мидлвари под редакс, и им норм

Им не норм, получается долго, тяжело, и глючно. Но да, конченные дегенераты очень активно накинулись на редакс.

Я бы в явные минусы записал сложности с отладкой. Это как правило ни о чем не говорящие stack trace, трудности с остлеживанием цепочек событий по системе, размеров очередей и прочего

Я в таких случаях люблю говорить «инструменты отладки и тестирования — это половина проекта». Есть RxJavaDebug, но оно крайне примитивное, дает возможность только повесить DebugHook/DebugNotificationListener и потом руками обрабатывать/логировать происходящие события. Никаких просмотрщиков и организаторов логов нету. Отсюда можно сделать вывод, что RxJava реализовано только наполовину, а потому для продакшена не годится.

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

Ты не задумывался о том, что кэши и разные оптимизации современных центральных процессоров делались под убогие однопоточные алгоритмы? То есть, привязываясь к ним ты остаешься навсегда к 80-90-х годах.

Я только заметил, но, пардон: при чем тут Web-development? Реактивное программирование появилось, когда никакого веба еще не было.

Реактивное программирование появилось, когда никакого веба еще не было.

А что конкретно под этим подразумевается? Зеленые потоки и кооперативная многозадачность это не реактивное программирование. Под реактивный подход больше подходят аналоговые компьютеры, типа арифмометр, аналоговые ic, конечные автоматы без памяти.

Речь само собой о реактивных потоках этих самых данных/событий, шаблоне наблюдателе и вот этом всем

Это не реактивное программирование. На этом можно и закончить тред.

Это реактивное программирование. В который раз ты подтвердил свою некомпетентность.

Эмм, ты розовые очки сними и приезжай из страны единорогов назад.

• 1 Границы странц памяти никто не отменял
• 2 Разбиение их на кэш-линии тоже
• 3 Вымывание кэш-линий когда получая 8 байт по указателю забираешь с собой 56 байт мусора который никак не будет использован и если это происходит в цикле переходов (а это фундамент реактивности) то например твой L1d размером от балды (64 байта1024)=65536байт - (561024) станет жалкие 8192 байт. А если данные будут лежать в от балды в куче с аллокацией на каждое значение (привет листы) то они будут с вероятностью 50 на 50 в разных TLB и для получения нового нужно будет дропать все кеши от L1 до L3 включительно конкретного ядра. Тут можно продолжать ещё долго, но суть в том что подобный подход работы процессоров как был так и есть, никуда не делся и не денется. Кривая организация памяти это всегда тормоза, и если твой проц просто грубой силой позволяет пока что этого не замечать, то это только потому что не весь софт пишется что-бы человекам видители было удобно, большая часть его слава инженерам пишется с пониманием того что вычислительные системы работают конкретным образом и будет крайне тупо без сильной на то необходимости делать так что-бы на ровном месте был вычислительный ад, лишь только потому что так удобно.

Вот когда компьютеры обретут по настоящему произвольный доступ к данным за константное время вот тогда уже можно будет организовывать код и применять метадологию исключительно на хотелках и удосбтвах людей. А пока что мы пишем программы для работы на конкретном железе которое в массе своей мало чем отличается касаемо работы с данными.

А что конкретно под этим подразумевается? Зеленые потоки и кооперативная многозадачность это не реактивное программирование. Под реактивный подход больше подходят аналоговые компьютеры, типа арифмометр, аналоговые ic, конечные автоматы без памяти

https://sci-hub.do/10.1002/spe.4380210406 — Boussinot, F. (1991). Reactive C: An extension of C to program reactive systems. Software: Practice and Experience, 21(4), 401–428

Примерно та же участь постигла полиморфизм, который у школьников приравниваниется к таблицам виртуальных методов, и даже такой отвлеченный пример, как «джип = внедорожник».

Из документации шпринга:

«In plain terms reactive programming is about non-blocking applications that are asynchronous and event-driven and require a small number of threads to scale. A key aspect of that definition is the concept of backpressure which is a mechanism to ensure producers don’t overwhelm consumers.»

В статье про Reactive C последний тезис также подчеркивается: кооперативная многозадачность очень кооперативна, одна задача перетекает в несколько задач и снова сливается в одну задачу, взаимосвязанные задачи интенсивно кооперируют друг с другом. То есть, это не абстракторная акторная многозадачность, где один актор посылает другому сообщение и дальше хоть солнце не свети. Это скорее одна единая задача, которая выполняется в асинхронной форме.

Вымывание кэш-линий когда получая 8 байт по указателю забираешь с собой 56 байт мусора который никак не будет использован и если это происходит в цикле переходов (а это фундамент реактивности) то например твой L1d размером от балды (64 байта1024)=65536байт - (561024) станет жалкие 8192 байт

Всё, что ты пишешь, в равной степени актуально для языков с JIT-компиляцией, без которой они представляют собой те самые бесконечные переходы и объекты по 8 байт. Однако же, JVM, V8, CLR вполне себе живут, развиваются, и вполне быстро бегают. Да что там, даже для питона есть PyPy.

Такое должно аппаратно поддерживаться. Подразумеваться в идеале там может всё что угодно и определения даваться могут такие что не в сказке сказать ни пером… хотя. Но всё это падает на землю реальности и релизируется через обыденные вещи как абстракция над ними. Так что как бы не прискорбно, эти определения просто на данный момент пустые слова имеющие отношение к реальности только на уровне концепции и/или прямой работы с кодом в виде абстракции. Внутри же всё то же самое что и у всех. Короче на деле в селе только Джип и он у нас если надо внедорожник, а если надо кобыла на поле.

Короче на деле в селе только Джип и он у нас если надо внедорожник, а если надо кобыла на поле

Не надо мне тут. Школоопределения из вики подразумевают «реактивное программирование = ReactiveX». Примерно так же, как полиморфизм подразумевает C++ и Java. При том, что ReactiveX является далеко не единственной реализацией чего-то реактивноподобного. В статье даже плашку поставили модеры «помогите школьнику внятно изложить свои мысли», и вся статья утыкана «citation needed».

На самом деле мой личный интерес к теме проистекает из банального события: когда я только начинал изучать SPA либы, то, естественно, наткнулся на понятие «реактивные либы», а потом на обильные испражнения школьников по этим темам. Именно школьников, потому что в том 1991 году, когда писалась статья про Reactive C, авторы ReactiveX ходили даже не в школу, а под себя. Гештальт (анус) у меня так и не закрылся — вот я теперь хожу и рассказываю, что же на самом деле есть реактивность. Сам-то я довольно давно уже разобрался, что в тех же React/Vue/Angular/Svelte доля асинхронности весьма скромная, там нет никаких «data streams», декларативности там маловато, в основном вполне себе процедурность с императивным управлением состоянием и вычислением производных значений.