И как же?

reactive programming тоже под капотом на них основан

Я вот описал задачу и как решается она проксированием эвентов

Проксирования — это метод chain

Блин, я не буду сейчас тебе всё концепцию с нуля объяснять)) Загугли

Так не интересно :D

Ну прост это всё на примерах кода только объясняется, а в чате это как-то ту мач 😃

Просто люди как-то посмотрели на концепцию эвентов и подумали, что они могт тут улучшить. Так то ничего нового не будет, просто удобнее)

В принципе прекрасно представляю, почему от ооп без инноваций можно устать и потянуться к простоте))

Ну ты как адепт ФП мне расскажешь, да

Come to the dark side 😁

То что я заюзал jQuery - это не значит что уменя там олдскульные функции и процедурный стиль :D Те же классы, только данными я манипулирую руками, без автобиндингов.

Я уже не смогу на темную сторону, у меня бекенд на руби :D

Не, руби это сатанизм)) Это другая шкала: явное vs неявное

Там зато нельзя сложить число со строкой и пострадать

И я в своей жизни уже достаточно огреб от неявного, чтобы не подходить к такому на километр 😁

Там зато нельзя сложить число со строкой и пострадать

В моём жс тоже)

Чему я очень рад

Переопределил тустринг на вызов ошибки?

Ахах

Мне нравится ход твоих мыслей 😂

Просто заюзал flow, он ругается на это и на всю прочую жс вжух-магию

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

Ну это решение частной проблемы, я подумал, что мне нужен более универсальный подход)

Как минимум тот же принцип распространяется на необязательные аргументы, если flow видит, что у тебя тут может быть null/undefined, то будет ргаться на любые попытки заюзать это как объект, пока не сделаешь проверку

В обещем за всё время юзания руби у меня был только вот 1 баг из-за неявности и только потому что я переставил 2 слова местами в ключе хеша, из-за чего оное выдавало нил и зло аффектило. Так что думается мне что проблема про неявное - надуманное. Также как боязнь некоторых юзать JS из-за непонимания асинхронности

В общем мне нравится мой текущий стек :D

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

Но не навсегда

Однако я могу сказать что есть некоторая усталось и она больше про типизацию. Я ещё на тайпскрипте пишу... ну как пишу, писал. Ангуляр второй на фронте, просто тайпскрипт на беке. И с одной стороны ты как-то увереннее чувствуешь себя от такого кода, есть некоторая приятная сторона описывать каждый параметр, каждый вот метод, вот это всё

Но... не зашло.

Типичная вторая стадия)) За кем не наблдал — у всех так было

Первая стадия — вау, можно щас затипизировать ВСЁ! Вторая стадия: задолбался описывать каждый параметр, а ошибок меньше не стало, я ливаю Третья - хм, а можно ведь не описывать каждый чих 🤔

Всё-таки философия того что нужно говорить компютеру что нужно делать, а не как это делать - хорошая философия.

Да

Поэтому между заэнтерпрайзить своего торгового бота на тайпскрипте или переписать понятно и читаемо на руби - победил руби

Неа

Если ts плох — это не значит, что на жс это невохможно

Это значит, что просто можно отказаться от ts

А я и не говорил что JS это плохо

JS между этим всем

Была вторая проблема конечно, которая увы не решается ибо дизайн языка

У flow другой подход к типам, он многое выводит правильно сам

Нужна была строгая синхронность

Это тоже реально (только зачем)

Понятно что async наше всё, но тем не менее

А вот задача такая - именно синхронно

Можно жонглировать nextTick

100500 запросов и синхронно, каждый следующий меняет стейт и зависит от предыдущего

Вот, жанглировать там и прочее

То есть это реально, но, как-то про молоток и микроскоп получилось

100500 запросов и синхронно, каждый следующий меняет стейт и зависит от предыдущего

Не вижу тут требования к синхронности

Внешний мир не статичен

still

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

То есть у меня есть что-то, что должно опросить что-то, принять решение, сделать действие, опросить что-то другое и ещё кучу мест и так вот шаг за шагом

По прежнему не вижу синхронности)

Ну не знаю, она есть :D

Только неявное полагание на особенности архитектуры)

Мне нужно узнать что-то во внешнем мире. Я делаю запрос. Получаю ответ, пишу в стейт, делаю нужные мне действия. Потом ещё запрос, основанный на предыдущих данных. Потом всё тоже самое, только запросы в другие места и ответы тоже разные

Если тебе нужен мьютекс, то стоит его явно описать, а не расчитывать на синхронность подхода)

Нельзя сразу всё опросить

У меня просто вообще нет понятия нескольких потоков

Я просто пытаюсь понять, откуда из вышеописанных требований вдруг был сделан переход к "а теперь делаем всё синхронно"

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

Пока я первый не получил - я не могу слать остальные

Так что нет необходимости юзать асинхронность когда всё синхронно

Это не синхронно, лол

Это последовательно

Синхронное исполнение, не запросы, да

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

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

В общем на JS это было не так удобно, хотя хотелось бы чтобы так было

async await

Да

И будет у тебя твоя последовательность)

Я писал про это

я не видел

Но это всё-равно побеждание того что не нужно побеждать

Ещё есть другая штука

Декларативность описания