Комментарии 16
Хуже $mol может быть только само-переведенный $mol)
Причём ещё и прогнанный через LLM, получивший за это кучу эмодзи и абсолютно бесполезный для читателя, ибо все это уже кучу раз опсосано со всех сторон.
Не выдержал Дмитрий, тоже ушёл в нейрослоп.
P. S. Надменный слог автора в купе с абсолютно надуманными примерами даже LLM не смогла погасить)
Это не ллм
Оригинальный оригинал https://page.hyoo.ru/#!=5sfnat_geai9k
Т.е это даже не перевод, а кросспост
прогнанный через LLM, получивший за это кучу эмодзи
Эмодзи у Дмитрия были задолго до распространения LLM.
абсолютно бесполезный для читателя, ибо все это уже кучу раз опсосано со всех сторон
Кто-либо уже публиковал на Хабре такой краткий обзор реактивных концепций?
Вообще это рафинированная версия оригинальной статьи. Но вы даже ее усвоить не шмогли. Да все мы знаем, что эмодзи изобрели ллмки. Но Дмитрий, как истинный визионер, предвосхитил их появление, буквально видел будущее.
Хорошая статья
Кто-то пользуется ещё библиотекой Vert.x ?
К сожалению, все способы реактивного программирования, что я знаю, невменяемо жрут память, так как, во-первых, логика приложения дублируется в области данных, во-вторых, дублируется весьма неэффективно в смысле расхода памяти. Я уверен, что должен быть способ эффективно выражать реактивные отношения прямо в коде, без коллбэков и связанного оверхеда, но пока не нашёл такого способа.
А ещё, однажды я решил эксперимента ради написать проект в анти-реактивном стиле: полное разделение данных от логики обновления этих данных, любое движение данных происходит только благодаря явно вызванному обновлению. И получилась на удивление приятная при сопровождения архитектура, где не надо было думать как сделать какой-то хитрый сценарий, а сразу было ясно что, где и в какой момент нужно дёрнуть. Так что реактивное программирование — не догма.
Может быть вы изобретали Entity-Component-System?
Я действительно разделил код на две части, сходные с энтити-компонентами с одной стороны и набором систем с другой. Но компонентов у меня не было и работа “систем” не сводилась к линейному пробегу. Про ECS я в то время не знал и скорее вдохновлялся некоторыми идеями аспектно-ориентированного программирования.
я решил эксперимента ради написать проект в анти-реактивном стиле
Тэкс тэкс тэкс, что тут у нас? IxJS на генераторах и итераторах?)
Мне вот по душе, что так системно все подходы раскиданы, но тоже не нравится, что в центр внимания выставлен пет-проект автора
Если я всё правильно понял, то event-ы предполагают push-направление, а список зависимостей может применяться и при push, и при pull-направлениях, при этом в push-случае это будет список зависящих, а в pull - список тех, от кого зависят.
К сожалению, проблема с потреблением памяти здесь ещё более значительна, так как для каждой ячейки создаётся несколько замыканий. Кроме того, у этого подхода есть сложности с отладкой, так как нет простого доступа через отладчик к состоянию, изолированному в замыкании.
Почему несколько замыканий для каждой ячейки? И насчёт отладки: разве фреймворки не кешируют это состояние? Если кешируют, то его можно увидеть в отладчике.
Код в этом стиле выглядит как обычный ООП-код, но с добавлением реактивных мемоизаторов.
Что такое "реактивные мемоизаторы"? Выглядит так, будто это то, ради чего писалась статья, и это не раскрыто до конца. Это что-то, что запоминает, какое значение возвращалось, когда метод вызывался с определёнными параметрами? А мутабельность this оно отслеживает? Сколько кушает памяти?
Почему несколько замыканий для каждой ячейки?
Как правило в реализациях под капотом создаются доп замыкания. Но да, теоретически можно было бы обойтись и одним в ряде случаев.
его можно увидеть в отладчике
Только это сложно и не удобно.
это не раскрыто до конца.
Это первая из большой серии статей. Можете глянуть в оригинале, или дождитесь перевода остальных.
Реактивное программирование за сутки до дедлайна )

Что такое Реактивное Программирование