"Code is the Easy Part" by Evan Czaplicki
Why Hacker News recommends it
HN points people to it to understand Elm's design philosophy, such as favoring simplicity over type classes, when they question its choices.
What it is
Evan Czaplicki, creator of Elm, gives an elm-conf 2016 talk on the non-code side of building a language. It covers the philosophy behind Elm's development approach, including batching work and the priorities of different language communities.
Recommended by 2 HN commenters across 2 different months, 2016 to 2020.
What Hacker News said
Recommends elbear · 2016-11 · on “Elm is Wrong”
Here's how I see his point. He came to Elm expecting a Haskell for the web. Elm has the completely opposite philosophy of keeping things simple, even if it means extra boilerplate. I can understand OP's frustration, but if he watched a few of Evan's talks (like this one [this video] ), he would realise his expectations about Elm are wrong. Also, he forgot that Elm (just like any other open source project) doesn't owe him anything. That's why many people take an issue with his tone. In summary, Elm's target audience are JavaScript developers. It's developers who want their apps to be more robust and easier to refactor than in plain JavaScript. Sure, type classes are useful but they also increase c
Recommends ekoczwara · 2018-06 · on “Show HN: Why Do I Procrastinate? – Web MD for Procrastination”
Every time I hear about procrastination it reminds me about great talk by Evan Czaplicki and his approach to Elm development, actually it can be good thing ( [this video] see 19:15 Batching Work).
Cites benjaminjosephw · 2016-11 · on “Elm is Wrong”
I don't think the response was as simple as "No, you can't have that because I don't want to". Reading the discussion about removal of this feature on Github there seems to be a few more points made that the author alludes to: [LINK] Also, It's worth noting that Elm does have a BDFL. Evan makes the call and, as I'm sure a lot of python folks would agree, that setup means that the language is going to remain consistent, clean and well defined. This might be frustrating, but is part of keeping a strong design philosophy that directs the language. In that context, is it really a valid criticism? Evan actually addresses this issue directly by talking about the different communities with differen
Cites IAmEveryone · 2020-04 · on “Why I’m Leaving Elm”
This mirrors my experience quite perfectly. To add another aspect: The over-management of GitHub issues is, in my experience, borderline pathological. On dozens of occasions (no exaggeration), I've experienced the following: - I notice some bug, or some missing functionality. - After dozens of searches I finally find a relevant Github issue. It's difficult to find because it's closed, in a project with a different, former name to the current version of the package, and part of a now-defunct GH organisation. - The only comment on the issue was Evan saying the issue is being folded into some meta issue bundling "issues concerning <some broad concept>". He closes the issue and adds a line into