[mfukar]

I think it's valid criticism. There's a (excruciating) description of a use case, (valid) attempts to build a solution, and reaching the point where someone tells you "No, you can't have that because I don't want to" - whoever that may be - is understandably frustrating.

Especially when the facility in question solves a real PITA of a problem.

Now, the author was obviously venting, he even admits it. Nonetheless, the complaint is justified.

[benjaminjosephw]

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: https://github.com/elm-lang/elm-compiler/issues/985

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] https://youtu.be/DSjbTC-hvqQ?t=178

[mfukar]

It was exactly one comment from evancz, which says: "I don't want to readd this feature...I think it makes sense to continue discussion in this issue if you think there are valid use cases". Here [1] is the actual feature request.

The existence of a BDFL is irrelevant. This rejection is frustrating whether it comes from one person, or a committee, a peer, whatever, because it is arbitrary and unjustified. The feature wouldn't compromise the design philosophy nor its consistency. "I don't want this" is not a design philosophy, and neither is "your use case is invalid".

The use case is actually solid. Writing readable, maintainable code which is conceptually easy to understand in the span of a few paragraphs, like in the blog post.

[1] https://github.com/elm-lang/elm-compiler/issues/1283

PS. I'm certain evancz has a reasoning behind his wish to keep the feature out of Elm. He just doesn't communicate it, which makes the decision seem arbitrary.

[Skinney]

When he removed the feature it was after consulting the community (https://github.com/elm-lang/elm-compiler/issues/985).

[zellyn]

Many languages with "BDFL"s have many contributors to core functionality. Elm does not seem to. For open source projects, that's pretty much a death sentence: although I appreciate Evan going off and solving hard problems with beautiful solutions, he can't do all the major work alone and expect to have a healthy, growing, open source project.

[bpicolo]

It has a dictator for life, but given the article doesn't seem like the B is earned yet :P

[cardiffspaceman]

The "B" is never earned. In OSS it's usually as ironic as the "D".