Скажи, bleeding edge! У нас тоже веб-сокеты, тоже SQL (гг, опять в моде?), кеширование в памяти с помощью кложурных атомов и миграции моей личной библиотекой, гг.
Надо сказать, что идея мне ваша нравится, но я пока не нашëл у себя репозиторий с TODO/FIXME, что мешает его потестировать. :\
Касаемо циклов — теоретически можно и проблем нет. Практически FRP-системы так не работают (точнее, их создатели не рекомендуют так их использовать). Надо поэкспериментировать. :)
Но в целом я прочитал комментарий и не понял, почему не надо пользоваться. Но окей, выводы каждый делает сам для себя. :)
Без понятия, честно говоря, ни разу не видел Qt вблизи. Может, но если интересно — то лучше почитать что-нибудь серьëзное про FRP, не наблюдая кода идею тяжело оценить.
Пока мне кажется, что таки да, любую программу (я тут хотел сделать оговорку, но не придумал) можно сделать проще. Но длинного опыта продакшена с помощью FRP у меня нет пока. :)
Надо свыкнуться с мыслью, конечно, что это не unobtrusive JS, а прямая противоположность — хтмл внутри жс, но потом всë идëт хорошо. Более того, мне кажется, что unobtrusive JS в случае с полноценными внутрибраузерыми приложениями не работает, и то, что делает реакт — правильно (хотя хоплон делает еще правильнее, имхо — делит на внутреннее апи и внешний интерфейс).
Основное — это то, в каком стиле он побуждает людей писать (и как написаны основные приложения). Но я так и не взялся на нëм ничего писать, поэтому технических нет ни одного (в отличии от бэкбона и ангуляра).
Если порядок нам важен, надо сделать так, чтоб второе обновление не пришло раньше первого (или как там нужно). Короче, рассчитывать на разные данные — фича в том, что у нас всегда есть какие-то данные, мы работаем со всегда существующими данными.
Т.е. прикол не в том, что с событиями так нельзя писать, прикол в том, что это тяжело делать и в эту сторону никто не направляет.
> Мне все-таки кажется, причина этого содома не в JS, а в людях. Ну даже во время вашего доклада было видно, что уровень аудитории довольно не высокий.
Надо сказать, что это была самая классная аудитория этого доклада (я его в общей сложности 5 раз рассказывал). Но на тему «не в жс, а в людях» — я пытался обсуждать проблему с людьми, которые пишут традиционные ГУИ — они ж там должны были всë порешать давно, да? Та же жопа, те же ивенты, такая же лапша.
Я вот в новый проект взял фейсбуковый React и пока доволен, он в целом как компромисс между практичностью и разумностью вроде бы ничего, но еще рано что-то утверждать, 3 недели пока код пишем только. :)
> Такая система с одной стороны остается более-менее декларативной и наглядной, как и реактивная, с другой — дает больше свободы действия.
Это да, без некоторого состояния в паре мест ну просто очень тяжело будет. Если что, я не за то, чтоб всë сделать идеально, pure shit, иначе я был бы фанатом Хаскеля. А так как мне нравятся более простые и близкие к жизни решения, то я не против того, что надо сделать рабочую систему. Просто то, что сейчас происходит в написании приложений на жс — это содом и гоморра, и надо чота решать.
> Если мы хотим сделать что-то более сложное, чем валидацию формочек
Я бы так словами не разбрасывался, валидация формочек это в целом показательная задача, там довольно много состояний и это не самая простая вещь в мире. :)
На Эльм еще посмотрим. Но освоить его очевидно тяжело, может позже, когда раздуплятся на внятный туториал, а не «введите эти 3 строки вот в это место; смотрите — мячик прыгает; введите еще 2 строки — и он прыгает иначе!»
Да, я вот на clojurecup планирую попробовать интерфейс на core.async построить и посмотреть, как оно. А вот пьедесталом я что-то пока совсем не проникся, может тоже попробовать надо, но вот читал туториал — и сложилось впечатление, что слишком много слов.
Ага, прикол. Ну, я про скалу читал и чуть разбирался, но презентации не смотрел и этот момент умудрился пропустить абсолютно. Сейчас глянул — даже в википедии есть Influenced by Erlang, глаз замылен.
Да, срыва покровов нет, у меня нелюбовь к Ерлангу больше от того, что его парят как светлое будущее, а он не только не лучше альтернатив, а зачастую заметно хуже. И софт-прорыв-в-мейнстрим, написанный на нëм — Ejabberd — внутри довольно-таки страшен после всех лет развития. Prosody на мой вкус ровнее, а написан на совершенно непримечательной Lua.
Если Qt Quick это только property binding, то не совсем, это часть, хоть и важная (важная для юзабельности, для концепции это как раз мелочь и не основное). Я рассказываю про то, что в .NET называется Reactive Extensions (Rx.NET), про ReactiveCocoa, про Flapjax/Bacon.js, про Rx.Java, больше не знаю сходу названий. Trellis в питоне еще есть, но он мог бы быть и попрямее (у меня не получилось его использовать нормально :\).
> Непонятно, как в общем случае прибиндить данные к комментариям, не обновляя всю структуру DOM каждый раз при редактировании комментария, и без нереактивных хаков.
Да, это очень тяжëлый вопрос и у меня (как в целом и у всех, вроде бы — я пытаюсь следить, что там люди выдумывают) нет ответа. Мне кажется, что можно забить на правильность и внутри реализации списка схачить и завязать его жестко на DOM.
> К слову, раскритикованные вами elm таки решает эту проблему. Правда создает при этом другие.
btw, он серьëзно обновился месяц-два назад и теперь чуть прямее работает. Но всë равно он недохаскель и это немножечко страшно (и то, что хаскель, и то, что недо), и всë равно дока говно, примеры говно (впрочем, я 2 месяца назад последний раз смотрел, но лень уже)…
> В общем, хотелось бы услышать вашу точку зрения как вы видите решение проблемы в нечистых функциональынх языках, таких как та же Кложа.
Для прототипа/концепта сгодится перерисовывание, для рабочих вещей — инкапсуляция работы с домом внутри итерации. Вот как в фейсбуковом React'e, снаружи всë ровно, а внутри хитрые пляски с домом.
Хотела сделать, точнее. :)) А так до часу субботы возились — github.com/piranha/pump/commit/6ea166a9e883992a1a130d765bc9f4934443625c
Надо сказать, что идея мне ваша нравится, но я пока не нашëл у себя репозиторий с TODO/FIXME, что мешает его потестировать. :\
Но в целом я прочитал комментарий и не понял, почему не надо пользоваться. Но окей, выводы каждый делает сам для себя. :)
Ссылки вот: piranha.github.io/slides/frp/#18
Основное — это то, в каком стиле он побуждает людей писать (и как написаны основные приложения). Но я так и не взялся на нëм ничего писать, поэтому технических нет ни одного (в отличии от бэкбона и ангуляра).
Т.е. прикол не в том, что с событиями так нельзя писать, прикол в том, что это тяжело делать и в эту сторону никто не направляет.
Надо сказать, что это была самая классная аудитория этого доклада (я его в общей сложности 5 раз рассказывал). Но на тему «не в жс, а в людях» — я пытался обсуждать проблему с людьми, которые пишут традиционные ГУИ — они ж там должны были всë порешать давно, да? Та же жопа, те же ивенты, такая же лапша.
Я вот в новый проект взял фейсбуковый React и пока доволен, он в целом как компромисс между практичностью и разумностью вроде бы ничего, но еще рано что-то утверждать, 3 недели пока код пишем только. :)
Про angular хочется молчать.
Это да, без некоторого состояния в паре мест ну просто очень тяжело будет. Если что, я не за то, чтоб всë сделать идеально, pure shit, иначе я был бы фанатом Хаскеля. А так как мне нравятся более простые и близкие к жизни решения, то я не против того, что надо сделать рабочую систему. Просто то, что сейчас происходит в написании приложений на жс — это содом и гоморра, и надо чота решать.
> Если мы хотим сделать что-то более сложное, чем валидацию формочек
Я бы так словами не разбрасывался, валидация формочек это в целом показательная задача, там довольно много состояний и это не самая простая вещь в мире. :)
На Эльм еще посмотрим. Но освоить его очевидно тяжело, может позже, когда раздуплятся на внятный туториал, а не «введите эти 3 строки вот в это место; смотрите — мячик прыгает; введите еще 2 строки — и он прыгает иначе!»
На тему джавелина еще надо упомянуть хоплон (который в марте еще хлиспом назывался) — github.com/tailrecursion/hoplon
И вообще, спасибо за отзыв! :)
Да, срыва покровов нет, у меня нелюбовь к Ерлангу больше от того, что его парят как светлое будущее, а он не только не лучше альтернатив, а зачастую заметно хуже. И софт-прорыв-в-мейнстрим, написанный на нëм — Ejabberd — внутри довольно-таки страшен после всех лет развития. Prosody на мой вкус ровнее, а написан на совершенно непримечательной Lua.
Да, это очень тяжëлый вопрос и у меня (как в целом и у всех, вроде бы — я пытаюсь следить, что там люди выдумывают) нет ответа. Мне кажется, что можно забить на правильность и внутри реализации списка схачить и завязать его жестко на DOM.
> К слову, раскритикованные вами elm таки решает эту проблему. Правда создает при этом другие.
btw, он серьëзно обновился месяц-два назад и теперь чуть прямее работает. Но всë равно он недохаскель и это немножечко страшно (и то, что хаскель, и то, что недо), и всë равно дока говно, примеры говно (впрочем, я 2 месяца назад последний раз смотрел, но лень уже)…
> В общем, хотелось бы услышать вашу точку зрения как вы видите решение проблемы в нечистых функциональынх языках, таких как та же Кложа.
Для прототипа/концепта сгодится перерисовывание, для рабочих вещей — инкапсуляция работы с домом внутри итерации. Вот как в фейсбуковом React'e, снаружи всë ровно, а внутри хитрые пляски с домом.