Hacker News Reader

Comment by didyoucheckthe | Hacker News Reader

> The first question I usually get ... is “Why not Haskell?”.

> The answer is JavaScript.

My current favorite language for this is Elm[1]. It compiles to JS, is based on Haskell, and has a few simple differences between either[2].

Elm doesn't let you use the tons of available Haskell libraries, and makes it slightly painful to integrate with JS. But it's the coolest thing for the web so far. And here's why:

It uses a completely declarative state machine to model a fully interactive and complete GUI! This is the dream React.js and Om didn't even know they were heading towards! And yes, it is as good as it sounds.

[1]: http://elm-lang.org/

[2]: http://elm-lang.org/learn/FAQ.elm

EDIT:

Also, Elm fixed Haskell's awful syntax record name collision problem, and awesomely too!

View on HN

Purescript[1] is also gaining some traction and even has a pretty nice looking book out. [2]

It has some changes however; most notably it's strictly evaluated rather than lazy, and there are differences in how it handles type variables. [3]

Personally though, I've grown more fond of F# than Haskell; I only wish the documentation for Websharper and Funscript was more solid.

[1] http://www.purescript.org/ [2] https://leanpub.com/purescript/read [3] https://github.com/purescript/purescript/wiki/Differences-fr...

Elm is actually 3 things rolled into one:

1. an language very similar to Haskell

2. a set of runtime libraries

3. a technique for modeling a GUI as a declarative state machine

PureScript only competes with #1 and #2 here. Where Elm really shines is #3, which #2 helps with a lot.

Technically #3 could be done in any language. But it really helps to model it in such an expressive language with immutable data and no side-effects (except via Signals).

I won't argue that Elm does anything other than an exemplary job at #3, but it is worth noting that there are some interesting efforts to build similar functionality in PureScript libraries:

https://github.com/paf31/purescript-thermite

https://github.com/kRITZCREEK/reactive-psc

https://github.com/bodil/purescript-signal

https://github.com/michaelficarra/purescript-demo-mario

https://github.com/mechairoi/purescript-frp-rabbit

To me, this is the benefit of PureScript - yes, you have to do a little more work, because you don't get these things for free from the compiler and tools, but you gain complete control over your application structure. You're not forced to work in some ambient Signal category.

You can probably implement Elm in PureScript pretty trivially, AFAICT. AFAIK Elm doesn't have any static guarantees about lack-of-space leaks or lack-of-time leaks. Or, maybe it just lacks higher-order-signals? (Which would mostly prevent those sorts of things happening). I found Neel Krishnaswami's papers on a static way to decide/prevent these things statically very interesting. I haven't found any implementation of his ideas, but they seem pretty solid: http://www.cs.bham.ac.uk/~krishnan/

Time to plug Kris' blog post about Haskell in the browser: http://blog.jenkster.com/2015/02/a-brief-and-partial-review-...

TLDR: he thinks elm's the most practical approach right now.

Could anyone summarize how well PureScript and Elm treat sourcemaps/debugging in the browser? For a while I thought that js_of_ocaml didn't support sourcemaps, but it turns out, one of my dependencies wasn't compiled with debug flag (-g) and I was able to get a pretty good sourcemaps/debugging experience in Chrome dev tools once I fixed that issue. Is there something js_of_ocaml can learn from PureScript/Elm's JS compilation toolchain? Or should we look to CLJS (which I'm also really excited about) as the best example?

I can't really comment on source maps in Elm, but the approach in PureScript has been to generate clean, readable JS which is debuggable directly. Source maps are on the roadmap, but not really a priority right now. I haven't heard any complaints about the ability to debug compiled PureScript yet.

That's a nice approach for debugging! If the mapping is close enough, I don't mind reading the JS output. I'm curious about the general approach to compilation, though. It seems like a statically typed language could take advantage of the knowledge of types to generate an even more efficient version of the program that uses typed arrays and views (though, yes, it would require implementing a garbage collector unless relying on some kind of WeakMap in the JS engine). I've heard of garbage collected languages compiling to LLVM which would allow Emscripten to assist you, but I've also heard that LLVM has a really hard time with GC languages.

Right now, the translation is very direct. My basic rule of thumb is - only perform those optimizations which the user opts into. Some things are standard though, like a few inlining rules and tail call elimination, but the plan is to provide a rewrite rules engine so that the developer can be as fine-grained as they like when it comes to optimizations.

As far as I can tell Elm is more of a GUI focused language, when I was evaluating AltJS languages I was looking for something a bit more low level. The JS and DOM bindings of js_of_ocaml were what really sold me although I didn't mention this in the post.

hey didyoucheckthe I'm working on a new programming language that I think you may be interested if you like Elm. Couldn't find your email in your profile, but mine is cammarata.nick@gmail.com. I'd love to show you

Reply on news.ycombinator.com