I am sure many, especially in the FP community know the difference between imperative and declarative programming. A simplified explanation of the difference would be questions "how" and "what". Here's an example:
open file "data.csv" read file contents into array iterate over each line and count them
Which is an imperative way that answers the question "how". A declarative approach would be just saying "what" you want to get:
get number of lines in "data.csv"
A good example of declarative languages that most of developers are familiar with is SQL or HTML:
SELECT COUNT(id) FROM `users` WHERE first_name = 'Joe';
Creating user interfaces is easier using declarative approach, e.g. the way you build UI in Android using XML. An opposite would be using Java Swing.
Philipp has shared his thoughts about bringing more delcarative approach to designing UI. He has interactive widgets where you can disable code line by line to see what gets drawn to the screen.
In the two-part series (first, second) Dirk is going throught the steps needed to setup FaunaDB, GraphQL, and Elm in order to build a web service for scheduling game nights with friends. You can see the final results here. Dirk's tutorials are extremely extensive, ie. he goes through every little detail to explain the what and why so you don't have any questions left: how do you install and configure FaunaDB, how forms in Elm are built, and btw, what is Elm's data flow. It's a good intro to the language if you're just starting.
Remember the cows from Elm Game Jam? I've mentioned it in issue #27. Well, Wiktor has written the second part in a series where he explains how the game was built. If you didn't skip the first few paragraphs of this email where I tried to explain the difference between imperative and declarative approaches, Wiktor also talks about the two, and how using imperative approach to placing a cow randomly on the screen might have been easier (if it weren't Elm). Have a read to see which approach he chose instead.
Duncan Malashock is continuing his deep dive into the API design. This time he is using phantom types. Even though phantom types is an advanced technique, it is pretty common. When I was first introduced into Elm, understanding phantom types in the beginning helped me along the way. For another view on this topic have a look here. Duncan, however, is applying this pattern to a more interesting and complicated problem: building a query API.
Something I never paid attention to and used as granted: testing. But there's so much more under the hood than just comparing the returned value to expected. If you read the discussion on Elm-minithesis and papers linked there, e.g. test-case reduction via test-case generation [link]. Turns out that writing test software is not as simple as it might sound. I have also learned about Hypothesis from the discussion.
Martin has released elm-serialize - a library to quickly handle serialization of Elm data structures.
Quote of the week
Thomas Edison once said:
I have not failed. I've just found 10,000 ways that won't work.
Think about it next time you try something new. When you try and fail at yet another startup/business. Few are lucky enough to succeed at the very first attempt. And learning how not to do is also extremely valuable.
Have a great week!