Зачем мне свой язык? Я не собираюсь делать язык ради языка, возможно я смогу обойтись без самодельного языка - и это было бы хорошо. Но пока не очень получается.

Много думая об управлении состоянием приложения (в общем про то что делают ваши всякие flux/redux и так далее, в которые я тоже не вдупляю) я все чаще и чаще попаю на статьи о self-adjusted или incremental computations. Сейчас у вас популярны всяческие RxJS и подобные, и честно скажу я сам зафанател от ориниального Rx (Microsoft) в году так 2008, но все же по этому пути я не пойду: Erich, создатель Rx сделал выдающуюся вещь показав реактивные (асинхронные) counterparts синхронным примитивам типа Enumeration, которые мы пользовали всю жизнь, и он гений.

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

Для тех кто впервые слышит о self-adjusting computation, го на сайт Umut Acar - сайт Umut Acar, это чувак много лет занимающийся этим вопросом, там же можно найти некоторые статьи по теме.

Self-adjusting computation refers to a model of computing where computations can automatically respond to changes in their data

Я пролистал довольно много статей о self-adjusting computations, штука эта действительно выглядит мощно для UI приложений и не только, но и с первого взгляда не нова - грань между FRP и self-adjusted computation довольно тонка: и то и другое можно применять, и применяется для одних и тех же целей - декларативно описать вычисления и пойти курить оставив компьютер заниматься персчетом результатов при изменении входных данных (я сейчас очень грубо).

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

• Жемчужина - это, конечно, Flapjax. Как это часто бывает с жемчужинами - они опережают время (готовность масс понять и принять), и умирают раньше чем стать тем, что пользует весь мир. Так было с объектно-ориентированными базами данных, да и много с чем. В общем очень достойная вещь и на пейпер flapjax есть много ссылок из вполне себе научных статек, жаль только то что самого flapjax уже нет.
• Есть на первый взгляд хороший выходец из практических кругов MobX - они себя называют TFRP (transparent functional reactive programming), пусть будет так - о терминах я спорить не буду.

Ну и куча других проектов на различных языках, которые гуглятся по словам reactive и functional, но так легко докатиться до Elm. Я сознательно не упоминал Elm упоминая FRP. Elm - фантастическая вещь, лично для меня понятная и приятная тем, что у меня очень быстро получилось написать и запустить простенькую программу на Elm, чего я не смог сделать с помощю довольно мейнстримовых React, Cycle.js и подобное - количество пиздеца которое у меня не работает и количество обращений к гуглу бъет по моим нервам так что я бросаю это дело.

Так, Elm можно считать эталоном FRP в вебе на данный момент. У проекта есть все - и сильный теоретический бекграунд (ссылок на Elm папер не меньше чем на flapjax) и прекрасная реализация. Все же, несморя на то что я часто говорю о теоретических основах, я чел необразованный – просто практик. Со всем уважением относясь к мотивации создателя Elm не делать first-class сигналы (ее невозможно оспорить, по крайней мере такому неспециалисту как я) - я чувствую, что на практике мне Elm не хватит. Мне хочется решения, которое позволит мне сколь угодно сложно менять граф вычислений во время исполнения, а это как я понимаю - главная проблема всех FRP решений на данный момент. Поэтому мне очень хочется выйти за рамки FRP (в понимании Elm) и я хочу посмотреть в какие-то другие стороны. Отсюда MobX и self-adjusting computation.

Назад, к записям