"Как чистая функциональщина императивных мутантов побила"

[thedeemon]

Похоже, не все еще знакомы с этими классическими историями:
http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/
http://elm-lang.org/blog/blazing-fast-html

Comments

[levgem.livejournal.com]

вот ты прям так хочешь взять и сказать, что Эльм это типа круто и мы зря всё переделывали на реакт? =))

[thedeemon.livejournal.com]

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

[theiced.livejournal.com]

выводы в принципе очевидны - берем om и не выебываемся. ибо по скорости ок, либы всяческие, все работает.

[swizard.livejournal.com]

Ого, ничё себе, а я как раз Elm решил освоить — переписал тут по-работе пару админок (достаточно сложных, надо сказать), и ща пытаюсь ещё один побочный проект домучить.

Пока впечатления немного смешанные, но скорее ближе к восторженным :) Правда, я нерепрезентативен, и ничего другого из списка бенчмарка тупо не пробовал.

Мож попозже попробую мысли в пост оформить.

[deni-ok.livejournal.com]

type Fix f
    =  Mu (f (Fix f))

SYNTAX PROBLEM
I ran into something unexpected when parsing your code!

Не, ну так неинтересно.

[maxim.livejournal.com]

Можно ризонить!

[swizard.livejournal.com]

Можно грабить корованы.

На самом деле там даже нормальных тайпклассов нет.

[maxim.livejournal.com]

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

[deni-ok.livejournal.com]

fix : (a -> a) -> a
fix f = f (fix f)

id : a -> a
id x = x

f = fix id

Maximum call stack size exceeded

Open the developer console for more details.

[maxim.livejournal.com]

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

[nivanych.livejournal.com]

Тема Mithril или даже какого-нибудь snabbdom не раскрыта ;-)

[thedeemon.livejournal.com]

Если хочется шоб как Elm, но с продвинутыми типами, для этого есть PureScript. Но смысла никакого: за те же деньги функциональность типы неоправданно сложнее, а компиляция на два порядка дольше.

[maxim.livejournal.com]

Да нет, нехватает как раз еще функциональных фреймворков, а не джаваскриптовых.

[nivanych.livejournal.com]

Вообще да, а для "императивных мутантов побила" это неправильно.

[maxim.livejournal.com]

WebSharper Ocsigen Lift N2O, каждый язык имеет свой, некоторые по несколько.
Сколько веб-фреймворков надо для функционального языка чтобы победить Джаваскрипт? :-)
(На Эрланге больше четырех)

[deni-ok.livejournal.com]

Не, я так, с целью классификации.

[nivanych.livejournal.com]

Да уже хватит существующих.
Но очень не всё приведено.

[binf.livejournal.com]

а зачем Elm, если есть кошерный websharper?

[thedeemon.livejournal.com]

А зачем websharper, если есть кошерный Elm?

[binf.livejournal.com]

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

[maxim.livejournal.com]

WebSharper — недосягаемый космос, F# чувакам повезло на CLR, в отличие от JVM пацанов.

[binf.livejournal.com]

Да. Ну Om например тоже неплох пачеснаку. и Ring весьма удачная идея, а в том же Websharper протокол свой, закрытый

[maxim.livejournal.com]

Кложа охуенна, базара нет.

[kodt-rsdn.livejournal.com]

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

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

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

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

[swizard.livejournal.com]

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

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

В императивных подходах там не всё так очевидно — нужно морочиться с диффами деревьев, и тд.

[vinslivins.livejournal.com]

кстати, как там ом некст?
для него обязателен датомик или можно всё-таки с постгресом?

гм. и есть ли уже для ом некст фигвил и чтобы оно ещё под андроид и под айос хот релод работал?

[thedeemon.livejournal.com]

Чисто как язык Elm, конечно, небыстрый, и там много что можно оптимизировать. Но тут история не об этом, а о том, что применение иммутабельных струкрур для Virtual DOM дало большой выигрыш по сравнению с обычным порошком, т.к. вопрос "были ли изменения в этом дереве" решался сравнением одного указателя, без прохода по дереву.

[justy-tylor.livejournal.com]

Ну, в "классическом" Virtual DOM мусора многовато, во всех смыслах. Тут вопрос в другом, если взять типичный UI где "таки данные меняются", то быстрее будет пересоздавать кусочки иммутабельного датасета или писать позиции изменений со времени последней перерисовки к мутабельному. Потому что должно быть второе (меньше копирований, меньше GC), но приличных реализаций пока не наблюдается.

[avnik.livejournal.com]

Еще есть haste, у которого вроде полноценные типы.
Я правда дальше helloworld'а из коробки не заходил -- что у него с производительностью и объемом кода на выходе?

[sorhed.livejournal.com]

Скобки фу!

[sorhed.livejournal.com]

Реакт посоны (вроде меня) тоже в основном иммутабельно используют, что, возможно, тоже что-то там ускоряет (даже наверняка, потому что hasComponentUpdated не нужен).

[sorhed.livejournal.com]

Но я согласен, эльм крутой.

[sorhed.livejournal.com]

Персистентные структуры не копируются!

[sorhed.livejournal.com]

Это сейчас касается вообще всего (исключение — мой любимый Riot.js). Чёрт возьми, react-redux с ES6 и scala.js сейчас компилируются примерно в одинаковых размеров блоб (!!!)

[justy-tylor.livejournal.com]

Копируется старое в клон при каждом изменении. Понятно, что для хороших контейнеров затрагивается только (log N), но жабаскриптовые object придётся пересоздавать, с соответствующей нагрузкой на GC.

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

[dewshick.livejournal.com]

красота спасет мир(от жаваскрипта)!

[maksenov.livejournal.com]

А разве для Om'а обязателен Datomic? Там весь стейт можно в атоме хранить. К серверу он вообще никак и нигде.

На кложескрипте еще очень хорош reframe. В новых проектах наша команда старается его пихать везде. Ну и с sente становится совсем хорошо.

[vinslivins.livejournal.com]

есть некий om-next в альфа-версии

вкратец я его понял так: адресуемую часть клиентского стейта (гм, ну, видимую) мы начинаем называть "запросом даталога", и держим по-прежнему в урле

ну и, собственно, под каждый реакт компонент тоже пишется свой запрос на языке датомика, которые (дальше не дочитал, и предполагаю) КАК-ТО объединяются в то, чем клиент обменивается с сервером.
(по сравнению с RESTом, где запрос за один раз только на одну сущность, неважно, чтение или изменение)

[maksenov.livejournal.com]

Опять же это не относится к серверу. Каждый компонент описывает что ему нужно, при этом источник данных неважен. Этот запрос поступает в реконсайлер, который решает куда обращаться. То есть Datomic Pull Syntax доходит только до рекосайлера, а там работает с пользовательской функцией parse для каждого источника данных. Тащемта, хорошо показано это в:

https://medium.com/@kovasb/om-next-the-reconciler-af26f02a6fb4#.7fiwi0lbu
http://codebeige.net/talks/om-next-dataflow/#/

А вообще, советую спрашивать сразу на слэке: clojurians.slack.com. Часто на идеологические вопросы отвечает сам Девид.