Avatar for squadette
короче, нужны promises, но не code-level, а data-level. Я попозже сформулирую. Также необходимо обдумать способы представления sum types в классических реляционках и прочих стандартных стораджах (а также корректная работа с батчами для скорости и вообще контролируемое нарушение уровней абстракции). Вообще это, конечно же, обобщение state machines, только при шаге может поменяться внутренний тип самой машины. Понятно, что "на самом деле" (тм) никаких присваиваний быть не должно, а все должно быть строго immutable, задача в том, как оптимизировать эту immutability для работы на неигрушечных масштабах. Также — вопрос длинной совместимости версии данных с версией кода. Также — эксплицирование эффектов.
Comment
Кстати в Telegram API прикольная идея с этими layers! Может быть, нам всем просто нужен тип данных Array7? ‎· псы в рапиде
Comment
Ух. Буду переваривать, полная каша, но я жопой чуствую у тебя тут ценный инсайт. ‎· 50% ash
Comment
@ayoshi: я прокрастинирую, но могу попробовать изложить только попозже, а иначе я никогда не доделаю ебаные упоминания. ‎· псы в рапиде
Comment
@squadette не трогаю. ‎· 50% ash
Comment
Еще меня убивает то, что на самом деле надо таскать за собой все ивенты, которые приводили к state transitions, почти для всех реальных применений (а абсолютно все тексты про state machines выбрасывают ивент сразу после императивного действия). ЧСХ, Flux-архитектура позволяет это делать, потому что опять же immutability. Кажется, мы изобрели Smalltalk-машину. ‎· псы в рапиде
Comment
@squadette так. ты пока не отвечай, но мне кажется тебе обязательно нужно посмотреть на модель в ELM ‎· 50% ash
Comment
@ayoshi: так Elm-модель это же кажется Flux и есть. Но Флюкс живет в памяти (code-level), поэтому там надо делать примерно тот же шаг, который происходит при внедрении arrows, видимо, епт (не будем упоминать тут слово на букву "М", оно лишнее). Ну и классические promises тоже живут в памяти и дохнут вместе с машиной. А я хочу чтобы они выживали, вот собственно и все. ‎· псы в рапиде
Comment
@squadette гена, на: http://db.inf.uni-tuebingen.de/staticfiles/publications/ddfp2... к сожалению пока только так ‎· 50% ash
Comment
@ayoshi: заебись. а я хотел дать ссылку на causal commutative arrows, да постеснялся. ‎· псы в рапиде
Comment
@squadette у нас в киббуце жил чувак из южной кореи, который дрочил на улице, и просто оборачивался к лицом к стене из вежливости. кидай, я видел все. ‎· 50% ash
Comment
^^^^ все. ты меня подвесил на неделю. буду думать. ‎· 50% ash
Comment
@ayoshi: это хорошее определение происходящего! ‎· псы в рапиде
Comment
@ayoshi: собственно модельный пример простой — представь себе, что типичное время settlement промиса — месяц. вся остальная проблематика вытекает. понятно, что все нормальные люди создают таблицу, но мы же выше этого?! ‎· псы в рапиде
Comment
^ все, теперь у меня все кликнуло, и даже понял почему это выскочило в контексте mention. ‎· 50% ash
Comment
@ayoshi: да, потому что я тебя могу в течение дня позвать, а потом удалить нахер пост. и в емейле который тебе придет завтра утром этого упоминания уже не должно быть. ‎· псы в рапиде
Comment
Можно для тех, кто в танке, почему самая обычная стейт машина с хранением в дб не подходит? Вроде как версионирование и хранение ивентов в целом ортогональная задача. ‎· sober, steady, good provider
Comment
@markizko: ключевое слово "мы выше этого". Кроме того, ты так говоришь, "с хранением в БД", как будто это само по себе является решенной задачей. ‎· псы в рапиде
Comment
^^^ у нас для похожих целей есть агрегаторы - сущность, которая не умеет вообще нифига, кроме как хранить детей, и которая в определенный момент "схлопывается" - рассылает емейлы, делает архив или скидывает содержимое в другой агрегатор. ‎· в чем рофел, брат?
Comment
@ai212983: теория состоит в том, что если разобраться в сущности этой сущности, то будет интереснее. ‎· псы в рапиде
Comment
^ проблема в том как история ивентов во времени мапируется на структуру данных at scale. в идеале ты хочешь иметь immutable structure, который отражает текущую ситуацию, с отыгранными ивентами. но к сожалению, операции с элементами структуры резолвятся негарантировано и за бесконечное время — соответственно требуют персистентности. у этой проблемы есть много плохих решений и нет хорошего которые помогают все это выразить идиоматически не ломая абстракции. otherwise, решения конечно есть но это сложный ад который еще и платит производительностью. для маленького количества ивентов все не проблема, для большого мы свалимся в промежуточные структуры и partitioning. я пока не могу яснее выразить, у меня в голове вся проблематика только оформляется, и на месте слов только отдельные образы. если созреет напишу. мне кажется @squadette может объяснить, он уже долго с этим воюет. ‎· 50% ash
Comment
^ ^^ Ага, теперь понятнее, спасибо ‎· в чем рофел, брат?
Comment
На макбуке option+Space - неразрывный пробел. А то тирешечки длинные, а от текста отрываются. ‎· Ivan Evtukhovich
Comment
бгггг: https://mokum.place/hotgiraffe/26956 "также у меня появилось подозрение, что Flux uni-directional data flow фактически изоморфен CQRS" ‎· псы в рапиде
Comment
Не, не могу молчать, это не совсем то, но пусть здесь полежит: http://uzh.github.io/signal-collect/ http://www.semantic-web-journal.net/system/files/swj971.pdf ‎· в чем рофел, брат?
1 2 3 4 5 6 7 8 9 10

2015-2018 Mokum.place