Issue #18

Issue #18

A note before you dive in: in this issue I go a little bit beyond Elm and Elm-related posts and also link other content which I think is very insightful and relevant to the topics this issue talks about.

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

By Leon Bambrick

I'd add a few more, and API design is among them. And I am not talking only about the web API, but also the libraries (for non Python-devs, requests is an HTTP client which many consider to have extremely elegant API). In "Anonymous tuples and records for designing APIs compatible by a structure, not a construction" post Marek shares his experience designing a library that gives you some flexibility in terms of implementation.

It might be easy to get lost in the article, especially if you're new to functional programming and the terms used there, e.g. functor, monad, or anonymous type. You usually have a hard dependency on libraries that define their own type, e.g. NonEmpty for non-empty lists (when you need to know during the compile time that the list has at least 1 element), and if the author abandons library you either fork it or move elsewhere. But with a different approach one could produce or consume the hypothetical NonEmpty type without having the original library as dependency. In turboMaCk/non-empty-list-alias Marek tries to do just that using anonymous types: (a, List a).

The blog post is not a regular easy-to-digest type of contents, but it gives a lot of pointers if you would like to learn deeper insights about functional programming. Inside I also found a link to an old article of Jonas Berdal about extensible records in Elm. Another worthwhile read.

Talking about functional programming, if you are new to this topic, there's a very well-written introduction by the people behind Recurse. They use Python to illustrate all of the main concepts of FP, and gradually go from very simple to more complicated problems.

If you were to write a frontend for an app that helps you search HackerNews, how would you do that? Chris Garrett tried to do that in React and Ember and compare the results. Thankfully, Éber has stepped in and documented his experience implementing the same app in Elm. The way I first heard about Elm was someone mentioning it in the context of React. It helps to learn about the different flows and approaches library authors take, and even if you're not using either of those it is still worthy to learn what's out there. Sometimes you might even ditch the framework completely and take a different approach altogether: go for vanilla JS, get rid of single-page app and use some hybrid approach. This is what Tom MacWright write about in his Second-guessing the modern web post and Uku Täht in You probably don't need SPA.

Talking about vanilla JavaScript, here Luca Mugnaini attempts to compare Elm and JavaScript side by side. Did that put a smirk on your face? Don't laugh, it's a well-written piece that I wish I had before my eyes when I just started my foray into front-end development.

Amanda Beiner has written a walkthrough on making GraphQL requests with optional args. If you previously used Apollo Tooling and thought it was cool, check out dillonkearns/elm-graphql because "pairing GraphQL’s schema definition language with a declarative and strongly  typed language like Elm in the client enhances the benefits of both by enforcing the contract between the API and the client".


Both Elm Town is out with their episode 52 "It's not like I have a stoplight on my desk" and Elm Radio with "How (And When) To Publish a Package".


For many people Elm is the first experience into the world of functional programming. And naturally people have many questions. It's not just about learning the new syntax but a whole new paradigm. Just like the article mentioned above, here's a nice intro video about FP with examples in Elm and F#.

Video starts at 31:10 mark.

Quote of the week

And here's some inspiration from Ghost in the Shell:

If we all reacted the same way, we'd be predictable, and there's always  more than one way to view a situation. What's true for the group is also  true for the individual. It's simple: overspecialize, and you breed in  weakness. It's slow death.
Show Comments