Is parsing json still an ugly mess? That was what put me off actually using it for anything.
Under "other cool stuff" it's mentioned that error reporting when parsing fails is greatly improved. Not sure if that's what you meant.
A Farewell to FRP
41–50 of 246 posts
Re: A Farewell to FRP
#42Doing away with signals is a great move, everything else about the elm architecture felt so intuitive.
I'm excited to give elm another shot, and I yearn for the future he describes where web assembly makes elm a viable js replacement.
Re: A Farewell to FRP
#43I moved from React/Redux/Typescript to Elm a few months ago, and I'm now on my second serious project with it, making mobile application with Cordova. I'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/Typescript using ports.
Coming from languages like Actionscript/Javascript/Typescript/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/Typescript bit.
Basically, I'm sold :)
Re: A Farewell to FRP
#44I 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 https://groups.google.com/forum/#!topic/elm-discuss/AmxE3qAm...
Evan wants to design Elm as thoughtfully as he can, and has been deliberately resisting community evolution. Eventually it will get too big and too useful, and he'll lose the ability to make big breaking changes easily. So he's tried to maintain control of the direction of the language and community during these early years while he figures it out. He's trying to reduce the feedback loop and come up with the best possible base before it starts to scale.
It feels like it's stabilizing. I expect that over the next year or so this will change dramatically and it will become much more community driven.
Re: A Farewell to FRP
#45Is parsing json still an ugly mess? That was what put me off actually using it for anything.
Its a little wordy, but now that I'm used to it, it takes no time to write decoders/encoders. There is also a tool to automatically generate them from JSON input at http://noredink.github.io/json-to-elm/
Re: A Farewell to FRP
#46Elm 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'm not…
I don't think the semantics are any more imperative than IO in Haskell, it's just that there's a different abstraction used for dealing with it.
Moreover, Tasks are absolutely monadic, with `andThen` being the bind operator. Elm just chooses to focus on the individual use-case, as opposed to focusing on the broader abstraction.
Re: A Farewell to FRP
#47subscriptions are great for handling black hole callbacks - callbacks that you cannot return back control to the callie.
Examples of this would be web-socket , http-requests , etc.
however elm and cycle.js try to shoe-horn this idea everywhere - which I think is not needed.
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.
Re: A Farewell to FRP
#48I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers: Time.every second Tick vs. Time.on('everySecond', tick) Beyond baking an event emitter into the Time module and having a nice looking API, is there something I'm missing?
I don't know anything about Elm subscriptions yet. But there is a lot more to this stuff then just event emitters. Things like: * When an event/action/etc comes through, does it always call listeners synchronously? Can you change that and schedule events manually? * How do you compose subscriptions/event handlers? This is usually the hardest part, and where simple event emitters really start breaking * What about the…
Yeah the same questions popped up in my head. The natural end point to me looks more like Rx. Lifecycle and especially composition seem like big missing pieces.
Re: A Farewell to FRP
#49I 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 https://groups.google.com/forum/#!topic/elm-discuss/AmxE3qAm...
Evan wants to design Elm as thoughtfully as he can, and has been deliberately resisting community evolution. Eventually it will get too big and too useful, and he'll lose the ability to make big breaking changes easily. So he's tried to maintain control of the direction of the language and community during these early years while he figures it out. He's trying to reduce the feedback loop and come up with the best pos…
' during these early years' should feature prominently in their docs/website if that is case.
If you go to http://elm-lang.org/ they make it looks like its production ready. No mention of breaking changes/beta ect. You have to choose one or the other .
Re: A Farewell to FRP
#50This looks very cool. In ClojureScript, we have the re-frame pattern/framework, which is built on Reagent, which is a ClojureScript wrapper of React. re-frame is all about subscriptions, using a "big atom" to hold application state client-side. Seeing Elm implement the same subscription pattern makes it look pretty tempting. My understanding is that ClojureScript and Elm have some similarities - functional, pleasant…
Might be off topic but I was interested in the "a big atom". Reagent is using a big atom and some small atoms to simulate component state -- which breaks hot code swapping. And I tried a way to abstract out component states into a single atom to fix it by building my own React like library. Now it's "two big atoms" on my side.
Yeah, after the app grew a bit, I had state scattered here and there. re-frame solves this with a big atom, and avoids expensive rendering every time the big atom updates with subscriptions. Subscriptions hold reactions, which only update if the underlying value changes.
The re-frame readme is epic and worth reading just for its own sake: https://github.com/Day8/re-frame
Not to get off-topic though! I am used to working with dynamic languages, but I really should work with a typed language. Elm looks like it offers many of the benefits of ClojureScript, but with typing as well.
Also, ClojureScript lets you write HTML and CSS in your code, but a quick web search indicates Elm may have gone further with incorporating CSS (?).