"Code is the Easy Part" by Evan Czaplicki

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 [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 complexity. Evan wants to see if there's a better solution and the Elm community generally accepts that.

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 ( [VIDEO] see 19:15 Batching Work).

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 different aims. He says that having these different communities with different design decisions makes the whole scene a lot stronger[1]: > if you go back a year so on the mailing list you'll see a lot of people talking about type classes "when are we going to have this in Elm?", "we need this", "this is the most important thing", and a language came out that had different priorities and all the people who wanted that kind of feature started using that language and so now that's not to say one of the communities is making a better choice than the other, it just means we can all experiment with a different philosophy and way of thinking and do well." [1] [VIDEO]

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 the meta issue. - Any discussion of individual items on the meta-issue is blocked - Work on that collection of issues is not going to happen "right now" because "it's so much more efficient to work on sets of related issues". - 14 months or so later, some work is done on <general concept>. The issue is closed (& locked) - My original issue obviously persists Evan seems to consider open issues as accusations or personal failures, or otherwise I can't understand why this is happening. When some recent version broke the existing support for WebSockets, the issue was immediately closed (making it, again, invisible to people experiencing this problem and searching with default options). The most constant output of Elm leadership are long-winded essays explaining how, specifically, you're stupid