I usually put videos in the middle or in the end of this email, but not this time. Recently Evan gave a keynote at ICFP. Here it is:
In addition to giving a brief history of Elm, how and why it was developed, Evan also mentioned the recent points of conflicts, so to say, that the community had. And these actually answered some of the questions I had, e.g. why Elm didn't adopt the development path of Python. Or why we might never see the version 1.0.0.
At ~52:00 mark he discusses different arguments engineering teams have when discussing the new tech. And many boil down to the following: a programming language should resemble a startup that has a public roadmap, a marketing and support team, an agile development model with weekly or bi-weekly releases and fast iterations. I saw many of these points mentioned in Discourse, Slack, and blog posts. Evan then goes on to talk about funding models and what each brings to the table: the pros and cons of funds coming from a research organization, a big corporation, or a small business, and what he chose to do as a result. The decision he made reminds me of the growing community of indie hackers, people who opt to bootstrap their business instead of taking the venture capital. And I respect him for that decision.
Moving further, this week has been very fruitful when it comes to the content, package updates and releases.
Last week I mentioned an app from Matias where you draw the road and then watch the cars drive around. While my 4 yo wasn't as hooked to learning traffic rules as she is to watching toy unpacking vids, we still spent some quality time discussion why it's important to know the road signs, why and when some cars stop. Matias has released a follow-up post about the development of this app.
Choon Keat in this "Make bugs into type errors" post discusses how to you can make Elm compiler even more helpful than it already is. With too many state changes for each API requests you might lose the track of when to update what, then extract the common code and unify the return type so the compiler could raise an error whenever there's an issue.
elm-make --optimize you type
...a data structure which promises the same speed of operation wether you’re modifying or reading from the front or back of the deque. This in comparison with the builtin
List, which is only fast if reading/modifiying from the start of the list.
and also elm-webpack-loader. I envy the productivity of Robin.
...a static code analysis tool for Elm, which looks at your Elm project, and reports patterns that you configured it to find using “rules” in a friendly Elm compiler-like way.
Then there are also IDE updates:
What a great and productive week it has been the last week of summer (or winter, depending where you are on this planet). And here's a short motivational quote from "The Untouchables" for you all to finish this week:
Never stop fighting till the fight is done