Experience report: Rocket lander in Elm

https://blog.wearewizards.io/experience-report-rocket-lander-in-elm

by teh • 11 years ago

67 21 11 years ago

blog.wearewizards.io

First though, why is JavaScript hard? Consider the following cases

I've never come across this problem in a real life project, and this is a pointlessly contrived example that diminishes the rest of the article. This is not hard. It might be slightly baffling at the beginning, then after ten minutes you get used to it.

tel• 11 years ago

I don't think the particular examples are pitfalls that people actually fall into, but I do think they illustrate what makes Javascript hard: it's got a lot of arbitrariness.

Arbitrariness is a constant mental penalty a programmer must pay for while reasoning in a language. It is not insurmountable, but one must wonder what could happen if the arbitrariness tax were reduced or lifted. It could be that whole realms of greater, more trustworthy abstraction are obscured by mental barriers such as this.

bshimmin2• 11 years ago

I think the seemingly arbitrary behaviour of things like `[] + []` vs. `[] + {}` doesn't really affect you, as someone writing real JavaScript in the wild, very often (but perhaps they still might do occasionally, depending on what you're doing).

On the other hand, errors in logic because of truthiness/falsiness do occur pretty regularly in real code (I'm sure every JavaScript developer has at least once forgotten to check whether an argument is really undefined and then not very gracefully handled `0` being passed to that function)... and these problems do all have the same root cause: JavaScript's type system.

pjmlp2• 11 years ago

Try to edit JavaScript code in offshored projects with 30+ developers.

jessaustin• 11 years ago

Is there any language that makes that straightforward? I trust that this scenario is common, but it seems almost comically designed for failure. Why not have someone in the same timezone as the stakeholders break the project up into smaller, more easily offshored modules?

bshimmin2• 11 years ago

The JavaScript output from Elm, in this case, is over 12,000 lines of code. I'm pretty sure you could write this in <100 lines of JavaScript, the lack of a "coherent and strong type system" notwithstanding.

phamilton3• 11 years ago

The output code is sort of a complete Elm runtime. The application itself is only a few lines of javascript.

phamilton3• 11 years ago

I.e. the help-screen at the beginning is re-rendering 30 times a second, even though nothing changes.

Not true. the nature of the virtual-dom is that it doesn't rerender if nothing changes. The implementation in elm is extremely efficient. It doesn't even diff the actual DOM, it diffs the inputs to the DOM. It can do this because of the pure functional requirements of Elm.

teh• 11 years ago

Interesting! When I check the DOM in inspector I can see it refreshing - maybe that's a bug?

phamilton3• 11 years ago

http://elm-lang.org/blog/Blazing-Fast-Html.elm

It's possible that only applies to HTML and not to canvas. If that's the case then I would hope the technique will be applied to canvas soon.

mrspeaker• 11 years ago

I wrote a mini platformer in Elm and it was great fun to make, but suffered the same problem as this demo: quite janky (seemed to suffer a lot GC hicups, especially in Firefox), and that's just at 30fps. At the time I thought it was because it was doing a lot of unnecessary canvas operations under the hood - which you just can't afford to do if you want buttery-smooth games, but figured I'd revisit Elm when it's sorted out ;)

zapu• 11 years ago

What do you mean by unnecessary canvas operations? I'm genuinely curious, as I'm very interested in elm (and FRP in general), just could not find the time yet to do anything with it.

bonn1• 11 years ago

This thing doesn't seem to run with 60fps. Why?

HTML5 offers now few ways to get easily to rock-solid 60fps considering that the graphics are very simple.

Xophmeister2• 11 years ago

In my dev team, we eschew WebSockets as it somewhat bastardises the HTTP/REST architecture. (F)RP is clearly a great UX model, but it can't be done properly without state being pushed to the client (faking it with polling doesn't really cut it)... That said, as a Haskell convert, I really like the look of Elm, but can it do backend communication via traditional XMLHTTPRequest?

EDIT I guess this[1] answers my question. Gonna have to get into this...

[1] http://package.elm-lang.org/packages/elm-lang/core/1.1.0/Htt...

deadfoxygrandpa• 11 years ago

You might be better served by waiting a little while. The Http library is going to get totally revamped soon by the new Promises API.

Xophmeister2• 11 years ago

Thanks for the tip off :)

Experience report: Rocket lander in Elm

Related Stories