
Elm by Example - brudgers
http://elm-by-example.org/toc.html
======
ekidd
Elm is a profoundly interesting language, but I've had mixed experiences
developing in it. I've been working on a small-but-hairy web app using Elm,
and my first reactions are:

1\. Elm encourages highly-rigorous state handling, thanks to the React-like
"Elm Architecture" [https://github.com/evancz/elm-architecture-
tutorial/](https://github.com/evancz/elm-architecture-tutorial/) and features
like the Maybe type and ADTs. I rarely worry that I've overlooked some
horrible, asynchronous corner case or that something might be null.

2\. The Elm architecture requires a considerable amount of boilerplate code,
at least relative to something like Ember.js. It's often necessary to thread
significant amounts of application state through parameters, for reasons
similar to the ones here:
[https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBH...](https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBHCZkLbR1TEsRnd3yyxuSQ5YY/)
But when you combine that with the need to use "case" matches everywhere to
destructure ADTs, and the fact that you can't define guard expressions (or
destructure things nested inside record types), it tends to result in a lot of
extra typing.

3\. The Elm tooling is a mixed bag. The error message are the best I've ever
seen, but the sweet time-travelling debugger just refused to run when I tried
to use it with the Elm architecture tutorials. This pattern of brilliance and
brokenness feels fairly pervasive at this point.

4\. The Elm community can occasionally be a bit frustrating to work with as an
outsider. Sometimes, when I run into an issue, I eventually find a GitHub
discussion like this: [https://github.com/evancz/start-
app/pull/37](https://github.com/evancz/start-app/pull/37) , where somebody is
trying to address an actual issue (one that was biting me, too), and the
community is more-or-less throwing up its hands. Also, the Elm community has
an occasionally surprising tendency to close GitHub issues quickly, even if
it's known that they'll probably need to fix something someday:
[https://github.com/evancz/start-
app/issues/35#issuecomment-1...](https://github.com/evancz/start-
app/issues/35#issuecomment-148939344)

5\. For me, Elm feels considerably more restrictive than programming in
Haskell.

6\. Elm's type checker and design do have one huge payoff: Even very
complicated apps with lots of tricky asynchronous state tend to work on the
first run after they make it past the type checker. This is _hugely_ valuable,
and it makes me more inclined to forgive Elm's limitations elsewhere.

Overall, Elm is exploring some really important ideas, and it's pushing the
general React-style architecture to its logical limits. I think I'd consider
it for small- to medium-sized apps with lots of tricky state, and with
developers who are strong at functional programming.

~~~
pka
I've had a similar experience. I was ok with it though, because the pure data
-> DOM nature of Elm's architecture was better than anything else.

Until I found PureScript. Especially purescript-halogen [0], which is
basically how one might make React in Haskell. Everything is still pure, but
you can define nested state (not to be confused with React-style local mutable
state!) without Elm's boilerplate wiring.

The "update" function runs in the continuation monad, which means that one can
do something like this:

    
    
            modify (\(State s) -> State $ s { loadingUsers = true })
            users <- liftAff' $ fetchUsers
            modify (\(State s) -> State $ s { users = users, loadingUsers = false })
    

and this runs asynchronously, but it still modifies one global state. Compare
with Elm's "return fetch effect, fire event, react on event in update
function".

There's everything one might need in PureScript: functors, applicatives,
monads, so the language feels much less constraining than Elm.

Drawbacks:

\- they use bower for package management - it's ok, but elm-package's enforced
semversioning is really nice.

\- no default imports, so imports can get verbose [1]

\- the error messages might not be as nice as Elm's, but I haven't had a
problem so far, at all

\- no elm-reactor - though since halogen is just a library, the UI is pure and
there's no magic state-isolating runtime, you can probably roll your own
relatively easily

\- not as easy to pick up as Elm - but no problem for a Haskell programmer.
Elm definitely focuses more on user-friendliness and Javascript converts.

...but these are minor nitpicks - I am in the process of making the switch and
porting an app from Elm right now, and it definitely was the right decision.

[0] [https://github.com/slamdata/purescript-
halogen](https://github.com/slamdata/purescript-halogen)

[1] [https://github.com/slamdata/purescript-
halogen/blob/master/s...](https://github.com/slamdata/purescript-
halogen/blob/master/src/Halogen/Component.purs#L34)

~~~
pka
One more thing that just made my life easier: Purescript recently got generic
deriving [0], which means that one can derive Eq, Ord, JSON etc instances
easily now!

[0] [https://github.com/purescript/purescript-
generics](https://github.com/purescript/purescript-generics)

------
davexunit
Elm has neat ideas, but there's really no need for an entirely new programming
language just for functional reactive stuff, and I'm just not into languages
that don't support dynamic and iterative development at the REPL. Hot swapping
code is a poor replacement for a real REPL.

~~~
thinkpad20
I think it's great to have more choices of purely functional, statically typed
languages for web programming. The only other options I'm aware of are GHCjs
and Haste (huge runtime size, incomprehensible code, laziness), and
PureScript. PureScript to me seems like the ideal choice of the options
available, with a more powerful type system and more of a general-purpose
approach. But it doesn't have Elm's tooling, its nice error messages, or its
wealth of FRP tutorials. Certainly, PureScript doesn't obviate Elm IMO.

As to the lack of a REPL, doesn't Elm have one? [http://elm-
lang.org/blog/announce/repl](http://elm-lang.org/blog/announce/repl)

------
galfarragem
Elm with a _magic_ backend could outshine meteor. Elm apps are fast.

Edit: magic translates to instant backend and using just one language for
everything. Elm-native-ui seems like a step in the right direction:
[https://github.com/elm-native-ui/elm-native-ui](https://github.com/elm-
native-ui/elm-native-ui)

~~~
erokar
I don't know about magic, but Elm with an Elixir/Phoenix backend seems quite
nice. [http://www.cultivatehq.com/posts/phoenix-
elm-1/](http://www.cultivatehq.com/posts/phoenix-elm-1/)

~~~
Secretmapper
...and I have something new to my to-learn list

------
pionar
Too bad the Elm site is down - [http://elm-lang.org](http://elm-lang.org).

~~~
scheda
That seems to happen a lot. Every time something gets posted it seems to get
down. That said, I'm pretty sure it's just one guy managing it all as a side
project, so it makes sense that he wouldn't want to pay for an expensive host
for all the traffic he gets.

~~~
pka
Evan Czaplicki was actually hired by Prezi to work exclusively on Elm, so the
project has industry backing.

------
tetraodonpuffer
every time there is an article about elm I have to fight my first impulse
which is to wonder at it still being developed, I guess I spent way too many
years typing elm to get to my email to ever be able to associate it to
anything else

------
yjgyhj
What is the history of the `.` notation? In Javascript

    
    
      obj={key: "val"};obj.key === obj["key"]; => true
    

and the same in many other languages, like Java, C#, Elm, Haskell (I think) et
cetera. The only ones in common use I can think of now is Lisp & C (but of
course there are thousands).

This pattern of putting the key to get after the object seems popular, but
what is the history behind it?

And why is it uncommon to have something like get(obj, key)? Or like in
Clojure, `(get {:key :val} :key)`? Seems more consistent, and uses less
syntax.

~~~
michaelcampbell
Just a nit; Java does not use dot notation for map access. (Groovy can, but
can also use Java notation.)

Not that it matters, but how do you reckon

`get(obj, key)` is less syntax than `obj.key`?

~~~
masklinn
I'm guessing they're talking about the syntactic footprint of the language. Of
course that assumes:

1\. you have free functions at all (wasn't the case in Java until 1.5 and
static imports IIRC, still isn't the case in Smalltalk, and seemingly free
functions in Ruby are actually methods of Kernel, an actual free function
would be a Proc bound to a global name)

2\. you only have free functions, or all your syntax is expressed with free
function syntax (which is fairly specific to Lisps, Julia also has generic
functions but afaik still uses dotted attribute access)

------
galfarragem
IMHO elm is for haskell, what meteor is for javascript. Even without support
from purists, they conquered their market share. This irritated a lot of
people.

Politics are boring but they are important. Imagine if all these smart people
from haste, fay, purescript, ghcjs could join elm and extend it. Haskell could
finally get a (deserved) mainstream role in CS. I don't know Evan (elm's
creator) but he seems to have enough charisma for the job. Let's see if he can
play the politics.

------
ComodoHacker
HelloWorld1.html of 33KB in size irritates me. Elm should have something like

    
    
      --optimize-for=size

~~~
masklinn
Isn't it because all of the Elm runtime and all linked libraries are embedded
in the page, and Elm doesn't have DCE yet? I don't think there is much (if
any?) optimisation in Elm at that point.

------
thinkpad20
Is the CSS host down? Because I'm used to Elm tutorials being very nicely
styled, and this is... not so much.

------
michaelcampbell
Today I learned people still use full text justification. Interesting content,
but I found the actual readability a bit rough for me.

