A Farewell to FRP

I moved from React&#x2F;Redux&#x2F;Typescript to Elm a few months ago, and I&#x27;m now on my second serious project with it, making mobile application with Cordova. I&#x27;ve found it an absolute pleasure to use, and I especially like that you can be pragmatic about it; if there is something that is annoying to do in Elm then you can simply drop into Javascript&#x2F;Typescript using ports.<p>Coming from languages like Actionscript&#x2F;Javascript&#x2F;Typescript&#x2F;PHP I have found the whole Elm experience quite mindblowing; if it compiles, then it just seems to work. I hardly ever find myself poring over bits of code trying to debug a subtle error, and if I do the problem is going to be in the Javascript&#x2F;Typescript bit.<p>Basically, I&#x27;m sold :)

I am happy to see Elm evolving and it looks like a good framework, but there is a tendency in FRP articles to ignore prior work, as acknowledged at the end of the article:<p>&gt; Note: Interested readers may find Lucid Synchrone interesting. Unfortunately for me, I had no idea my thesis had so much in common with synchronous programming languages at the time, but the connections are quite striking. I might argue that Elm was never about FRP.<p>My thesis was related to synchronous programming languages and articles about FRP tend to have too little to say about them, for my taste. Yes, there is a word or two in the related work, but also it looks like some wheels are being reinvented.<p>The subscriptions model reminds me of Esterel, which is imperative and uses await&#x2F;emit pairs. In the domain of GUIs, which is related to Elm, there is ReactiveML (see &quot;ReactiveML, Ten Years Later&quot; (<a href="https:&#x2F;&#x2F;www.di.ens.fr&#x2F;~pouzet&#x2F;bib&#x2F;ppdp15.pdf)" rel="nofollow">https:&#x2F;&#x2F;www.di.ens.fr&#x2F;~pouzet&#x2F;bib&#x2F;ppdp15.pdf)</a>). Look also at Lustre or Signal, with Signal allowing directives to define multiple execution units: this is used to generate concurrent programs exchanging values with message passing.<p>The domain is different, though. Synchronous languages do not target web interfaces. They are about embedded systems and as such, they are mostly static. On the other hand, they are compilable into a simple event loop with static memory usage and constant execution time. Maybe some of the existing research could be useful to something like Elm, even if it does not target the same problems.

As someone who is just getting started with frontend development, I decided to go with Elm instead of learning JS and React. I found the whole experience very pleasant, even as a beginner.<p>Not only is the elm code I write reliable, but I&#x27;ve found that adding more features does not bloat my code. Refactoring a codebase as it grows in elm is pleasant, and following the Elm Architecture guides me on the correct structure for the app.<p>Over the weekend I made a small site to show all Elm conference videos in one place. If you want to play around with 0.17 this project is just a bit above a &quot;Hello World&quot; example. Send a PR! <a href="https:&#x2F;&#x2F;elmvids.groob.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;elmvids.groob.io&#x2F;</a>

There&#x27;s also a lot of similarity with Rx.JS and observable based (aka &quot;Reactor&quot;) patterns:<p><pre><code> Rx.Observable.fromTime().subscribe(tick) Rx.Observable.fromSocket(mySocket).subscribe(handleEvent) </code></pre> <a href="https:&#x2F;&#x2F;github.com&#x2F;Reactive-Extensions&#x2F;RxJS" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Reactive-Extensions&#x2F;RxJS</a><p>Regardless of the exact library or pattern, the broader concept of treating data sources as asynchronous event streams you can subscribe and react to definitely simplifies data flow and makes systems very robust.<p>An additional benefit of this pattern is the natural way it makes it easy to filter, chain, map, etc onto these subscriptions. Once again from the Rx world, <a href="http:&#x2F;&#x2F;rxmarbles.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;rxmarbles.com&#x2F;</a> does a great job visualizing these patterns.

This looks very cool.<p>In ClojureScript, we have the re-frame pattern&#x2F;framework, which is built on Reagent, which is a ClojureScript wrapper of React.<p>re-frame is all about subscriptions, using a &quot;big atom&quot; to hold application state client-side. Seeing Elm implement the same subscription pattern makes it look pretty tempting.<p>My understanding is that ClojureScript and Elm have some similarities - functional, pleasant to work with - with one significant difference being that Elm is typed.

Congrats to Evan. I&#x27;m still learning Elm and it has been such a pleasure. It&#x27;s so much clearer to understand the code and go back to it later. I spoke with Evan at length at one of the regular Elm &quot;hackathons&quot; in SF and was so impressed how he thinks about long-term vision of Elm and prefers to take his time to ensure he gets it right to make Elm be around for a long while. Which is the reason I&#x27;m investing time into Elm. If you&#x27;re in SF Bay area. Tomorrow (Wed) is the next Hack night a great place to talk to Evan and the small community around it.

I like Elm but its development really seems to rely on a single person. I saw this post on elm-discuss which is a pretty good summary of my thoughts <a href="https:&#x2F;&#x2F;groups.google.com&#x2F;forum&#x2F;#!topic&#x2F;elm-discuss&#x2F;AmxE3qAmtvE" rel="nofollow">https:&#x2F;&#x2F;groups.google.com&#x2F;forum&#x2F;#!topic&#x2F;elm-discuss&#x2F;AmxE3qAm...</a>

Since people in this thread are likely to be elm enthusiasts and know what&#x27;s going on in the ecosystem, what is the largest high quality elm app you know about and what is the largest high quality elm app that is open-source that you know about?<p>I&#x27;ve been doing backend work for a while and I&#x27;d like to see what is possible these days with elm.

I&#x27;m super excited for this change. I&#x27;ve been watching and waiting for a few weeks. It&#x27;s a big ordeal for me personally, because I&#x27;ve got 10 weeks of daily elm tutorial content I&#x27;ve written so far at <a href="http:&#x2F;&#x2F;dailydrip.com&#x2F;topics&#x2F;elm" rel="nofollow">http:&#x2F;&#x2F;dailydrip.com&#x2F;topics&#x2F;elm</a> that I&#x27;m now re-writing, but the changes are all for the better and the language adoption is bound to go up over time.<p>If you haven&#x27;t yet tried Elm, give it a shot. A co-worker (hi Heath!) showed it to me 4(?) years before I got interested in it, and I brushed it off as a toy because I was against Functional Programming at the time for terrible reasons. It&#x27;s actually one of the &#x27;this feels like the future&#x27; technologies that&#x27;s re-shaping how I think about programming these days. Huge kudos for the release!

I haven&#x27;t dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers:<p><pre><code> Time.every second Tick </code></pre> vs.<p><pre><code> Time.on(&#x27;everySecond&#x27;, tick) </code></pre> Beyond baking an event emitter into the Time module and having a nice looking API, is there something I&#x27;m missing?

What I really want is a language with Elm&#x27;s type system, simplicity, and syntax, but aimed for backend software instead of HTML apps and with strong support for an Erlang-style actor model of multicore, distributed concurrency. Basically something like Elixir, but with Elm&#x27;s syntax and type safety. In the meantime Elixir will do for me, but I&#x27;d really like more type safety without going full Haskell.

This is marvellous. IMO Functional has always been a bigger deal than Reactive. Great to see more of that pursuit of simplicity paying off.

There is a nice talk from Erlang Factory 2016 called<p>&quot;Making the Web Functional with Phoenix and Elm&quot;<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=XJ9ckqCMiKk" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=XJ9ckqCMiKk</a>

Stupid question from an interested outsider: how&#x27;s a &quot;subscription&quot; different from a good ol&#x27; callback?

Just out of curiosity. I&#x27;m trying to decide which client-side framework&#x2F;language to dive into, and it seems that many people consider Om Next a really nice step forward, away from &quot;giant blob of state&quot;. My (uninformed) observation is that Elm does things the way Om (previous) did it: is that correct? Is Elm aiming to incorporate Om Next&#x27;s advantages?

Say what you will about languages that compile to JS, but Elm code looks so <i>elegant</i> that I just want to use it for aesthetics alone. Major kudos to Evan for such a wonderful and powerful creation.

From the Lucid Synchrone paper referenced in the article:<p>&quot;Synchronous languages are based on the synchronous hypothesis. This hypothesis comes from the idea of separating the functional description of a system from the constraints of the architecture on which it will be executed. The functionality of the system can be described by making an hypothesis of instantaneous computations and communications, as long as it can be verified afterward that the hardware is fast enough for the constraints imposed by the environment.&quot;<p>That sounds a lot like how functional programming works in a browser. If you assume function calls take zero time (or can be optimized so they&#x27;re fast enough) then you end up with event handling and asynchronous I&#x2F;O. Preemptive multitasking becomes a non-issue. But long-running computations (where you actually want to keep some CPUs busy for a while) need to be handled outside the system.

I got into studying FRP around 3 years ago for my senior project. Aside from a decent, clear explanation, there were hardly any actual implementations of this allegedly good paradigm (something Evan covered in his thesis, and the basis for Elm). It seemed like a paradigm that was full of promise and potential but failed to deliver in any worthwhile way.<p>(Such was the case for my senior project, studying the viability of Arrowized FRP in Elm. In short, I concluded that it was nothing but hell and nobody should bother.)<p>I am happy to seem Elm drop FRP, even if I wished it could be the savior of the method. At this point I think it&#x27;s a troubled concept and should be limited to old theses.

Woah, still reading but seems like a big change considering FRP was somewhat fundamental to Elm.<p>[edit] Looks like a solid change driving Elm towards easier usage, Signals and Mailboxes were definitely something that took a while to wrangle correctly.

Elm is very cool and pleasant to use compared to JavaScript, but I have some reservations. The limited typeclass system (for numbers and such) seems... questionable. The interaction of what looks like pure declarative syntax and what is actually impure imperative semantics is confusing to me. I understand that the author wants to avoid monads and other perhaps somewhat confusing staples of functional IO, but I&#x27;m not sure the cost&#x2F;benefit of doing it this way works out.<p>I will say that Elm is the best JavaScript-targeting platform I have tried! I have hopes for GHCJS, but it&#x27;s not near Elm&#x27;s level of readiness yet.

I found that while things worked once it compiled, I spend most of my time staring at compilation errors, especially as I refactored. So I&#x27;m mostly trading time spend debugging subtle state errors with fixing compile type errors. It <i>feels</i> not as productive, since I&#x27;m usually looking at errors.<p>Also, I&#x27;m still new to FP, so if you go outside of the Elm architecture, you&#x27;re going to run into problems, which you&#x27;re use to solving with specific tools, but they won&#x27;t be available. So you&#x27;ll have to spend time learning how to compose things in a new way.

Elm has always been &quot;that language I dabble in every now and then but never have time for&quot;... good to see it&#x27;s evolving. Evan and Richard (creator and main evangelist, respectively) are a great team and I hope them the best (and I hope I get more time to mess around with Elm!).

Wow, this is a surprise. Kind of like a Haskell headline &quot;A Farewell to Immutability&quot;. But sounds like the pros and cons have been well thought out for the intended use case.

One thing I&#x27;m wondering with elm is how does it deal with state across different components? I.e. where would you put the settings of the current user and how would you access that within one component? (By component I mean the (init,update,view,subscription))

Does Elm have any nice interfaces for common JS frameworks? (like reagent &#x2F; om in clojurescript, or angular2 for dart &#x2F; typescript)

Hey! CodeHS is working on an Elm Course. The vision of the course is to make a more approachable version of SICP.<p>The course is still in development, but let us know if you&#x27;re interested!<p><a href="https:&#x2F;&#x2F;codehs.com&#x2F;info&#x2F;curriculum&#x2F;elm" rel="nofollow">https:&#x2F;&#x2F;codehs.com&#x2F;info&#x2F;curriculum&#x2F;elm</a>

Has anyone upgraded a non-trivial app from 0.16 to 0.17? Is it pretty simple to rewrite moving from Signals to Subscriptions? Any advice?

I love Elm before but now it is even better! I&#x27;ll make the switch even though I was almost done with my first app with it.

Is parsing json still an ugly mess? That was what put me off actually using it for anything.

&gt; A web handler threw an exception. Details:<p>&gt; gen&#x2F;pages&#x2F;blog&#x2F;farewell-to-frp.html: getFileStatus: does not exist (No such file or directory)<p>Some caching problem, it seems?

So, is it still true to say, &quot;You wish you could express your business logic with pure functions. But often you can&#x27;t because the lack of immutability hurts performance in various ways. But ELM creates a &#x27;sandbox&#x27; in which you <i>can</i> do so, by letting you write functions which work over time varying streams instead of stateful callbacks.&quot;<p>If not, which parts changed &#x2F; how would you revise it?

Has the elm installation on Linux improved in recent months? Last time I tried my system&#x27;s GHC was too new to install it from source and the node installation went kablooey in weird parts(too recent ncurses, the automatic &quot;reactor&quot; browser repl not finding the Html package etc...)

For those like me who aren&#x27;t familiar with Elm:<p>An Introduction to Elm<p><a href="https:&#x2F;&#x2F;www.gitbook.com&#x2F;book&#x2F;evancz&#x2F;an-introduction-to-elm&#x2F;details" rel="nofollow">https:&#x2F;&#x2F;www.gitbook.com&#x2F;book&#x2F;evancz&#x2F;an-introduction-to-elm&#x2F;d...</a>

The chat client thing is pretty interesting, but there&#x27;s this little bit:<p>&gt; Use the browser API — To get started you just create a new web socket! Well, then you need to open the connection. But do not forget to add an onerror listener to detect when the connection goes down and try to reconnect with an exponential backoff strategy. And ......<p>How does handling errors happen I wonder. If you take FB messenger for example, you would queue up a message but if the sending failed you would get an opportunity to retry&#x2F;not send it at all.<p>I suppose in FB&#x27;s case you could write your own subscription provider...

Say a magazine company wants to regularly send issues to a customer, and the customer signs up. Who has the subscription, the customer, or the magazine company? Which one subscribes?<p>According to Rx, it&#x27;s the magazine company. Which one subscribes? The magazine company subscribes. It took me a while to realize this when trying to learn Rx concepts, which made it really confusing, since I&#x27;ve always seen the customer as being the subscriber, subscribing and owning the subscription.<p>It looks like Elm is the other way around compared to Rx, I think.

FRP = Functional Reactive Programming<p>&gt; When I started working on my thesis in 2011, I stumbled upon this academic subfield called Functional Reactive Programming (FRP). By stripping that approach down to its simplest form, I ended up with something way easier to learn than similar functional languages. Signals meant piles of difficult concepts just were not necessary in Elm.

I have been learning some haskell, maybe I will dabble in elm. Watched a talk by Evan and was blown away by time-based sophistication.

FOAM is also subscription based, but then builds FRP on top of it: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=-fbq-_H6Lf4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=-fbq-_H6Lf4</a>

Can someone explain how the subscription API differs from signals, addresses, and ports? I&#x27;m not familiar with the &quot;old&quot; Elm so I can&#x27;t judge what the change is like.

I wish Elm&#x27;s blog had an RSS feed.

Are there type classes in Elm?

Looks like Elm moved closer to Pux&#x27;s API by dropping the signals for `Html action`. Check out Pux if you&#x27;re interested in the same architecture but for PureScript.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;alexmingoia&#x2F;purescript-pux" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;alexmingoia&#x2F;purescript-pux</a>

subscriptions are great for handling black hole callbacks - callbacks that you cannot return back control to the callie.<p>Examples of this would be web-socket , http-requests , etc.<p>however elm and cycle.js try to shoe-horn this idea everywhere - which I think is not needed.<p>Not every event needs to be subscribed to - it pollutes your global stream. Use global stream only when you need to deal with things that move out the execution context of your program.

Doing away with signals is a great move, everything else about the elm architecture felt so intuitive.<p>I&#x27;m excited to give elm another shot, and I yearn for the future he describes where web assembly makes elm a viable js replacement.

Looks very good. I got stuck learning elm at about the point I wanted to integrate a call to a javascript function. Can&#x27;t for the life of me remember if that involved signals or not. Will definitely try the tutorial(s) again when I get some more time because I really was enjoying everything else about the language and developing in it.

Congrats, you just invented Reactive Extensions...