Jenkster

Kris Jenkins wrote this page about functional programming, which is the best quick explanation of why functional programming languages matter: http://blog.jenkster.com/2015/12/what-is-functional-programming.html

And then you mix that with Larry Wall's famous quote: "Computer languages differ not so much in what they make possible, but in what they make easy."

So you mix these two references together and you get the idea that maybe Lisp and Scheme and ML make functional programming easy. Python, on the other hand, makes it easy to avoid the key feature of Lisp: separating concerns and managing complexity.

This doesn't mean Python is a bad language, and it doesn't mean you can't use python to craft programs in a functional style. But it's A LOT easier in Python for an inexperienced programmer to do things that Lisp and Scheme are trying to force you to avoid (by exposing unnecessary state to a function, conflating concerns and avoiding abstractions for manipulating complexity.)

I think this is why Scheme was originally chosen for SICP over contemporary languages like C or Modula-
{2|3} or Bliss. It's simultaneously good for CS pedagogy and a small team can build decent, extendible, testable and debuggable programs with it.

Elm is so amazing. It isn't as amazing when you just try out it's tutorial, but if you try to build an actual application in it, especially if you are a single programmer working on a project.

In my experience whenever I worked on a JS project on my own, there was an upper limit to how far I could keep writing the code on my own. After that, I had to spend time in doing other things (like writing Integration tests, lots and lots of unit tests, or refactor existing code because I realized that there are many issues unveiled).

But now, with Elm, it's like a whole set of unit tests are being written at the time of writing code which take care of plenty of common errors usually made due to lack of a good type system.

Add to that the usage of Maybe types (which are very beneficial in avoiding some UI antipatterns[1]), and the Reactive Programming pattern, I feel like I am writing a lot less code than what I am used to writing in JS projects.

I highly recommend Elm to anyone who wants to write a personal project, you'd see what benefits I'm talking about.

1. http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html

To keep building on this, I think the word "parsing" is just the tip of the iceberg. Parsing is one way to port data across a type boundary, where the source and dest types are optimized for different use cases (e.g. serialization vs type-safe representation). Since the semantic Venn diagrams of any two types might have areas of non-overlap, parse-don't-validate means establishing clear boundaries in your program where those translations happen, then defining the types on either side of the boundary to rule out the possibility of nonsense states elsewhere throughout the program. The idea of nonsense states is closely related and discussed more here[0] and here[1].

[0] http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html

[1] https://kentcdodds.com/blog/make-impossible-states-impossible

You never leave the loading spinner state, but you don't throw. This actually inspired the Remote Data package which encourages you to break with the UI antipattern[0] where "result not yet loaded" is conflated with "we know there is nothing there." This pattern of handling those states has made its way into the official guide too, in case you want to start without using anything outside of the core library (a common pattern for new learners)[1]

[0] http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html
[1] https://guide.elm-lang.org/effects/http.html