{"id":3669,"date":"2016-04-14T11:50:21","date_gmt":"2016-04-14T11:50:21","guid":{"rendered":"http:\/\/www.garysieling.com\/blog\/?p=3669"},"modified":"2016-04-14T11:50:21","modified_gmt":"2016-04-14T11:50:21","slug":"philly-ete-talk-notes-adventures-elm-events-reproducibility-kindness","status":"publish","type":"post","link":"https:\/\/www.garysieling.com\/blog\/philly-ete-talk-notes-adventures-elm-events-reproducibility-kindness\/","title":{"rendered":"Philly ETE Talk Notes: “Adventures in Elm: Events, Reproducibility, and Kindness”"},"content":{"rendered":"

One of the ETE talks I attended was called “Adventures in Elm: Events, Reproducibility, and Kindness”, by Jessica Kerr<\/a>. She has several more talks available1<\/a><\/sup><\/p>\n

Elm is one of a number of languages that compiles to Javascript (Coffeescript, ScalaJS, ClojureScript, TypeScript, etc). It adds types and strict immutability, and an event loop that appears to take control of the entire page (you can call out to Javascript if you get stuck). From the outside this appears to me to be a bit similar architecture to using ClojureScript + Om + React. <\/p>\n

Elm has a virtual DOM and event loop, which is familiar coming from having used React + my vague understanding of Redux \/ Flux. The event loop concept is neat, and there is a fairly well-known talk that shows the mind-blowing utility of this2<\/a><\/sup>, though I think that demo of Elm to make a game makes some people think it’s not for them.<\/p>\n

The biggest problems I personally have currently with React on it’s own is that if I just write Javascript code, the only way to tell if it’s correct is to step through the code, and the architecture is nearly impossible to enforce, so is Elm is one of several potentially appealing answers.<\/p>\n

To see an example of some Elm code, there is a utility that converts JSON to typed ELM objects3<\/a><\/sup><\/p>\n

\nimport Json.Encode\nimport Json.Decode exposing4<\/a><\/sup>\n-- elm-package install --yes circuithub\/elm-json-extra\nimport Json.Decode.Extra exposing5<\/a><\/sup>\n\ntype alias Something =\n    { \n    }\n\ndecodeSomething : Json.Decode.Decoder Something\ndecodeSomething =\n    Json.Decode.succeed Something\n        |: (\"\" := decode_Unknown)\n\nencodeSomething : Something -> Json.Encode.Value\nencodeSomething record =\n    Json.Encode.object\n        [ (\"\",  encode_Unknown <| record.)\n        ]\n<\/pre>\n
The compilation step is done through \"elm make\"6<\/a><\/sup>. There is also an elm-format7<\/a><\/sup> that does auto-formatting for you like Scalariform. This which has some benefits, e.g. moving the argument about formatting into it's own little hole on the internet where you can safely ignore it. Apparently one of the goals of elm-format is to make source control history better by preferring more lines over longer ones, which is fantastic (as a counter-example, compare this to the combinable Scala imports, which make for a truly miserable merge process).<\/p>\n
\nimport a.b.c\nimport a.b.{c, d}\n<\/pre>\n
The Elm compiler also enforces semantic versioning, so you can safely depend on a version range. I don't know of another technology that has a feature like this to compare, it sounds like a great idea, although it's the sort of thing that could be challenging on a large project. Specifically this means you can add APIs in a point release, but not take them away, and depend on other people to do the same.<\/p>\n
The compiler prevents circular dependencies at the module level, and even better, prevents you from directly accessing a transitive dependency without directly requiring it (one of the meta-themes of this year's ETE was \"things you wish NPM had\")<\/p>\n
The compiler is designed to give error messages that help the developer, rather than punishing them. The inclusion of \"kindness\" in the title of the talk is a neat choice: collectively the tools in the Elm ecosystem are designed around kindness toward the programmer, a goal more tools should have. <\/p>\n
  1. http:\/\/jessitron.com\/talks.html [↩<\/a>]<\/span><\/li>
  2. https:\/\/www.youtube.com\/watch?v=RUeLd7T7Xi4 [↩<\/a>]<\/span><\/li>
  3. http:\/\/noredink.github.io\/json-to-elm\/ [↩<\/a>]<\/span><\/li>
  4. := [↩<\/a>]<\/span><\/li>
  5. |: [↩<\/a>]<\/span><\/li>
  6. https:\/\/github.com\/elm-lang\/elm-make [↩<\/a>]<\/span><\/li>
  7. https:\/\/github.com\/avh4\/elm-format [↩<\/a>]<\/span><\/li><\/ol>","protected":false},"excerpt":{"rendered":"
    This talk discussed an interesting ecosystem for Javascript development, aimed at being a pleasant and predictable programming environment.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[4],"tags":[112,244,302,400,455],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t