http://www.tiobe.com/tiobe-index/ говнорейтинг, но кложура на 47 месте (раньше вроде в топ 50 даже не была) ну и да

The main drivers behind Go's success are its ease of learning and pragmatic nature. It is not about theoretical concepts such as virtual inheritance and nomads (!?) but about hands-on experience

beating averages ;)

а когда обычно результаты по клоджар сюрвей?

интересно же

Господа, а у кого-нибудь случается низкоинтенсивный, но перманентный баттхёрт из-за того, что всякие реагенты всё ещё заставляют разбивать логику на куски "нажали кнопку -> вызвался хэндлер, чего-то посчитал, обновил shared state; нажали другую кнопку -> вызвался другой хэндлер, поднял из shared state недосчитанное, чего-то ещё посчитал"?

А бывает не так? ;)

Я пытаюсь понять, как скрестить Ричевую идею "вернуть всю логику в одно место" из его core.async-презенташки и при этом сделать это так, чтобы персистентные данные а-ля Ом были синхронизированы с этой логикой даже при рефреше страницы (когда состояние сохраняется, а весь core.async-стейт теряется).

Ивент заэмитили и все пересчитали?

Нет. Эвент заэмитили, создался го-блок, который внутри себя все взаимодействия целого куска программы держит.

Проблема в том, что этот го-блок что-то рисует (через стейт), и если стейт персистить в localStorage, а страничку обновить, то будет десинхронизация.

Конечно, можно забить и сказать "всё, что складывается в этот кусок стейта - транзиентное, его мы не сохраняем; всё, что складывается в другой кусок стейта - персистентное, мы его через refresh тянем", и тогда, например, диалог, привязанный к go-блоку, после рефреша пропадёт. Но хочется же лучше.

Превратить в данные

Ты типа про некий воркфлоу?

Бинго. Я уже смотрел в потроха core.async, но они слишком запутанные, чтобы их сторадж данных целиком положить в атом реагента 🙂

Пример приведи

Например, диалог аплоада фоток. Нажал кнопку, получил диалог с какими-то взаимодействиями в нём: добавить то, повернуть сё, это залить, это убрать.

Не хочется это размазывать на сто спагеттин.

Вариант 1: весь этот state - transient, после рефреша страницы пропадёт. ОК, жить можно.

Вариант 2, holy grail: весь этот state, включая стейт go-блоков его обслуживающих - persistent, после рефреша страницы продолжает, как был (если были XHR в полёте - отвалятся, но UI останется как есть, можно продолжать работать).

Я нашёл Dragonmark и ago, которые делают что-то в этой же области, но ещё не покопал.

Нужны чекпоинты для state и их сохранять как данные

Там стейт хитрый - стектрейсы стейт-машин.

Но твой-то стейт простой - или тоже сложный?

Мой стейт может быть каким угодно, он под моим контролем.

А вот стейт кор.асинк -- не совсем.

А что у тебя в каналах живет?

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

функции перекладывания данных из канала в канал - стейтлесс, каналы - стейт.

@nicola События от UI

Есть у меня на экране открытый диалог аплоада фоток. Есть go-блок, который от этого диалога кучку хэндлеров к каналам привязал.

И что будет после рефреша?

Диалог будет (если он в состоянии хранится), а go-блока не будет.

дак сделай что евент меняет стейт

И будет такой зомбик.

И получится лапша "onclick=сделай мне так". это плохо.

Получится вот эта картинка из Рича: http://endot.org/notes/2014-02-14-core-async-clojure/problem.png

А я хочу это получить: http://endot.org/notes/2014-02-14-core-async-clojure/result.png

не очень понимаю. Тут вроде просто - либо персистишь значения либо нет, либо имеешь их после рефреша или нет

ну в таком подходе либо persistence либо каналы с салатовой логикой

логику вообще лучше как можно pure сделать

а что у тебя там за логика?

Я ж выше приводил пример - логика аплоада картинок. Вот есть картинка, мы её повращали, пообрезали, но ещё не зааплоадили.

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

Ну это вполне себе state который можно персистеть - если ты фотку можешь сохранить?

Вот если я нахожусь в середине диалога редактирования, то у меня код находится в каком-то состоянии стейт-машины.

Если зарефрешить, то это состояние пропадёт.

Поэтому я и думаю, как персистить все эти отложенные стеки из core.async.

Давай есть фотка, я ее повернул - у меня есть фотка + повернуть на 90%

где state-machine?

Хорошо. Юзер нажал кнопку аплоада, рисуется прогрессбар, аплоадятся фотки. Тут жмакнули рефреш.

Прогрессбар остался (он же в стейте хранится).

А код, который аплоадил, не остался.

Кто будет его убирать?

upload на сервер?

Да.

Те в этот момент у тебя рассинк

Да. И это просто пример.

Есть код, который что-то делает. Если его убить, то некому прибираться.

ты можешь записать что собирался делать на клиенте - write ahead log

Ну нет, это фигня.

спросить что из этого уже сделал сервер

Тогда я могу и лапшу сделать.

Это всё не для того, чтобы сделать мою жизнь сложной, а наоборот 🙂 Если сделать мою жизнь простой не получается, то тогда я это делать не буду, а буду делать "discard transient on refresh"

тогда выбрасывай этот стэйт - нафиг возится - если не важно

Это и есть вариант 1 выше.

я думал ты хочешь его сохранить - но если можно не сохранять - зачем заморачиваться

Если не сохранять, то UI получается менее интересный.

Но это не так страшно, можно и обойтись.

ну вот и заходим на второй круг

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

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

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

Ну вот я вижу, как это можно решить - засушиванием стейта core.async и регидрацией потом.

ну ты не даешь гарантий на refresh - и все

а как ты upload в серединке востановишь?

после восстановления upload отвалится с ошибкой, это ясен пень. но upload может отвалиться с ошибкой и без рефреша.

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

а разве можно заретраить file upload?

не, другая задача: клиент выбрал пачку фоток и они улеглись в локальный стейт, а потом по upload они поехали XHR-ом на сервер.

XHR после рефреша отвалится, как по ошибке сети.

если есть логика retry т.е. есть и стейт (не явный наверно) который говорит о том что картинка ушла на сервак или нет. В чем проблема сделать этот стейт явныМ и персистить? при рефреше логика та же как при ретрае - есть чо не загруженное - загружаем

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

ручками заново их запускаешь

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

я не хочу руками писать код, который смотрит "ага, мы дошли досюда".

дак а как ретрай работает у тебя?

Потому что весь этот код уже есть в core.async

Ну вот сидит себе код на канале и ждёт, пока ему придёт событие "закончили" от коллбэка XHR, завёрнутое в канал. В цикле повторяет, если ошибка или таймаут.

Как будто шелл-скрипт и wget, всё синхронное.

ну вот, не явный стейт ага

Когда управление доходит до точки, в которой core.async паркует го-блок, core.async сохраняет этот стейт куда-то.

без кор.асинка по мне дак просто решается, а как с ним хз

И я не хочу руками за кор.асинк делать то же самое 🙂

Ну он не совсем это делает

Потому что лапша!!!

Нужен более детальный пример - так слишком абстрактно

фоточка - upload - поворот - и посмотреть как ты это по каналам распихиваешь

тебе может core.async не нужен 🙂

Нужен. Если без него, то это пачка эвентхэндлеров. Я не хочу эвентхэндлеры писать, это код, вывернутый наизнанку.

Рич тут всё правильно говорит: https://www.infoq.com/presentations/clojure-core-async

В общем, проще забить. При рефреше недоделанное пропадает.

да по мне core.async как замену коллбеков тащить это из пушки по воробьям. Я по началу тоже его везде тащил, но счас сто раз подумаю

Корасинк это оркестрация множества процессов, и это стэйтфул причем имплицитно

тебе стейт нужно поделить на сохраняемый и несохраняемый. повороты/ресайзы картинки - сохраняемый, флаг "начался ли аплод" - нет. показывать прогресс бар - зависит от флага. при рефреше: ресайзы все восстановятся, а флаг начала аплода заресетится в false ==> прогресс бар не появится

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

он только поможет заменить прямые вызовы функций на непрямые/ивенты/чо там еще

если ты хочешь востанавливать состояние - то тебе нужно его и трэкать - @misha прав

стейт в атоме, и атому пофигу кто и откуда его обновляет: из колбека или из канала

но я бы и сам посмотрел, как взрослые дядьки используют корасинк "по-назначению". в юае пока что я видел только юзкейс заменяющий {:on-click #(logic)} на {:on-click #(tell that channel I want to execute logic)}

окей, я ещё поковыряюсь, и как у меня будет что-нибудь полезное/вечное/светлое - покажу.

у меня есть ещё один вариант, где такое было бы просто очень нужно: слаковый бот, который тоже event-based, в котором stateful-взаимодействия с клиентами, и которому было бы очень клёво переживать рестарт сервера.

Ну можно еще в хэндлере написать (let [res (<! ch (xhr)] do something), посмешивать их и тп

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

тоже кор-асинк задача?

Таки-да. И с теми же проблемами.

привет! а я пришёл порыдать. автор микрофреймворка-для-веб chestnut сейчас впиливает 'system', и не любит библиотеку 'mount' 😞 https://github.com/plexus/chestnut/issues/184

Вот не хочу я персистить 100500 чатов с клиентами руками, и делать стейтмашину руками на эвентхэндлерах.

это проблемы разделения стейта на восстанавливаемый и нет, типа (defonce) и (def)

только в этом случае "рефреш страницы" - это рефреш кода фигвилом

принцип тот же

Ну да. Точнее, проблема того, что состояние программы не reified.

Так что я не могу сделать снэпшот.

@leov дак это вроде же темплейт просто? Инит сделал, потом поменял чо надо не?

мало, значит, в атом напихал всякого

состояние программы

если ты следишь за своим состоянием - то всегда из него можешь востановится - программа должна быть подчинена данным

данные можно сериализовать и сохранить локально или на сервере

и гранулярность ты выбираешь сам

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

это шаг назад 🙂

ты жеж должен стремиться к pure-functions и минимизировать сайд эффекты. например с аплодом - единственный сайд эффект - аплод. всё остальное можно сериализовать в атом (реф)

это и будет https://clojurians.slack.com/archives/clojure-russia/p1483970628002071

дак человек не хочет руками все делать, в атомы класть и доставать. Кор.асинк юзать для хранения стейта, хопа-хопа и само и без атомов. Проблема тока что стейт не явный и достать его из каналов никак, зато не руками. Ну это я так понял)

как это?

@artemyarulin да, но следующая версия будет на системе. я не понимаю, почему просто люди могут любить систему вместо маунта. это же джава джава джава джава джава борщ борщ.. (

@leov вкусовщина. Форк тебе в помощь.

я не один из них не юзаю, мне норм

рельсы меня сильно "испортили".. (

@artemyarulin не достать из каналов, если эти каналы кто-то уже нахачил, и впадлу переделывать

а с нуля запекать стейт в каналы - это жеж тоже самое "руками"

с форками какая беда - если ты делаешь форк в такой штуке, как веб микрофреймворк - ты сразу теряешь в безопасности и совместимости. это не та вещь, которых можно иметь миллион

@misha ну оно уже есть, выкидывать код жалко может 🙂

что же теперь делать?

делать костыль, хлоп-хлоп-и-в-продакшен 🙂

хлоп-хлоп 🙂 лайт версия 🙂

главное назвать его "следующий уровень абстракции"

цензура, вдруг тут дети 🙂

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

как хорошо что я сразу пришел в ре-фрейм

а там есть чо для контекста?

ну там вьюха сама подписывается на что ей надо

не надо ниче ей пробрасывать

ну надо будет ID какой пробросить все равно ж

https://twitter.com/tpolecat/status/704694589605588992

а там вчера было обсуждения на тему дерева вроде как

<Root id=‘main’>
  <Link id=‘1’>
    <Link id=‘2>
      <Link id=‘3’/>
   </Link>
  </Link>

я про это

а ну ок, я краем глаза все читал, сори

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

ну да 🙂

гм. вопрос по кложе - я пробрасываю в джавный интерфейс листенеров каких-то событий свою функцию, которую в reify этого интерфейса дёргаю

когда я обновляю код этой функции - он не обновляется а каким-то образом дёргается код старой функции

это чем-то можно объяснить?

или без кода сложно понять что происходит

попробуй вирджил

https://github.com/ztellman/virgil

o_O

господи. я бы наоборот избавился от джавы раз и навсегда 😃

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

я вообще не уверен что вирджил будет работать под андроид..)

под андроидом какая-то полная ж. единороги, волшебство и радуга.

@leov Какой тип у объекта, который нужно пихать джаве?

Runnable какой-нибудь?

@leov Происходит следующее, если я правильно расшифровал подземный стук - когда ты даёшь джаве свою функцию, ты даёшь ей IFn, который значение функции. Когда ты обновляешь функцию - ты меняешь состояние Var, в котором начинает лежать новое значение.

Т.е. это то же самое, что сначала сказать (def myvar 42), потом передать myvar в джаву, а потом удивляться, что после (alter-var-root #'myvar 43) джава продолжает использовать старое значение.

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

@leov чтобы этого избежать, достаточно передавать в джаву вместо myfun – #(myfun %), который каждый раз будет разыменовывать Var, а не в момент засовывания значения в листенер.

В кложе всё – неизменные данные, и функции тоже 🙂 При переопределении функции меняется только Var.

@leov А ещё Var реализует IFn, поэтому вместо анонимной функции в джаву можно передать #'myfun

@misha по поводу ссылки на твиттер. там один чувак спросил: what's so complex about abstract proxy bean factory factories? мне показалось это смешным, т.к. ответ: Все!

современное OOP таких монстров породило вида "ООП ради ООП", что отношения бизнеса и программистов похожи на отношения светской власти и шаманов. Шаманы просят дофига ресурсов ибо ООП код пухнет и требует больше помощников и ресурсов для шамана. Бедный бизнес платит за это. По моему мнению Рич вернул программирование на ту дорогу, с которой когда-то свернули. То есть признал шаманов шарлатанами и сказал "в жопу тайп корректнес - даешь business корретный код в массы".

в общем кложа екзистенциальная угроза религиозным фанатикам ООП.

ну не получается у них переписать сервис из 2000 строк на кложе меньше чем 6000 на скала и не менее чем в 2 раза дольше по времени.

@mike1452 Не для всех компаний это проблема. Но да, это отличное конкурентное преимущество.

Есть и недостатки — для того, чтобы компания, использующая Clojure, могла расти, ей нужно либо быть распределённой, либо быть готовой заниматься импортом программистов.

Даже Cognitect с самого начала был распределённым, а они-то могут себе позволить снять сливки 🙂

хм, а я могу как-нить из мапы достать значения по ключу но не fully qualified?

(def x #:person {:id 1 :identity 42 :name "Sam" :on? true :age 23 :friend [:person/id 2]})
(def y #:company {:id 1 :name "Co#1" :team [[:person/id 1] [:person/id 2]]})

;; Нужно достать :id, префикс для ключей допустим я не знаю, можно вот костыльно, ничо лучше нету?
(filter #(= "id" (-> % first name)) (seq x)) ;;> ([:person/id 1])
(filter #(= "id" (-> % first name)) (seq y)) ;;> ([:company/id 1])