Hello Elm and Haskell!

Briefly describe my first Elm application and list the reasons why I decided to programming exclusively in Elm.

Why Elm?

I am by no means a JavaScript expert. I’ve built a total of four commercial applications; one with Backbone and three with ExtJS. For my day job I primarily code in Java and ExtJS.

My Elm experience was a side-project where I wanted a calendar widget where people could quickly pick multiple dates from the next three months as a way of filtering local events.

Over the course of a month or so, I was able to learn enough of Elm that I could build this date picker. I enjoyed programming in Elm so much that I decided to work 100% with Elm and to learn Haskell.

Here are the reasons why.

There are great learning materials.

I started with the free, on-line class Elm For Beginners, Start Building Web Apps using Elmlang Today. Short video lessons, ranging in length from three to eleven minutes long, each focusing on one specific topic was a great introduction.

I made it up through lesson 13 (out of 18) before I started coding.

The compiler was a revelation

It is hard to overstate this. I ended up writing about 600 lines of Elm code in all to accept today’s date, render the next three months, respond to clicks on the dates and keep track of which dates were currently selected.

The process of writing in Elm was different than any other language I have written in before. Typically, I use TDD: write a stubbed function, write a test, and then flesh out the feature. In Elm, I wrote the code and then “just” had to get the code to compile. Just is in quotes because it initially it took me a long time to figure out the compilation issues.

So … write a basic feature, spend a long time getting it to compile. Then, write the next feature, and spend a little less time getting it to compile. Finally, after getting the last feature to compile, I tested it in a browser.

It worked.

Java is strongly typed, but Elm felt so different.

• every if requires an else⊕, Of course you can do this with Java, and it’s good practice, but it is required by the compiler with Elm. otherwise the compiler fails.
• it is so easy to define a type: type alias Year = Int; now you can use that type as function argument or return value, which is very expressive at a small cost
• union types (AKA algebraic types) are really useful; for example, the compiler will fail if you have a case statement that ignores one of the types in the union.
• partial functions are handy, compact, clever and expressive; they feel comfortable very quickly.

Similarities with CQRS

The whole model/view/update pattern felt very similar to the command/query pattern. The Elm model defines state, the update step takes a command and updates state, and the view step takes state and renders a view.

In the command/query responsibility separation pattern, one object processes commands and a different object responds to view requests. Very similar in how responsibilities are split up.

I’m a fan of CQRS, so this was a plus.

And now onto Haskell!

I think people in the Haskell world that criticize Elm do Haskell a disservice. Elm is an easy gateway to Haskell and there are lots of JavaScript programmers. Perhaps the visual of a herd of JavaScript programmers flooding to Haskell is not a pretty picture.

After my experience with the Elm compiler, I wanted to get the same benefits when writing back end code, so I picked up Haskell. My experience with Elm (and Erlang before that) made it easier to start being productive with Haskell.