I've watched Elm since its inception when Evan was posting about his experimental FRP project on r/haskell. (Yep, Elm actually started as a functional reactive programming language. That was before The Elm Architecture was developed and all that terminology was thrown out.)

As the project has developed, I have certainly wished Evan had taken a different and more open approach to leadership. I think Elm could be 10x as big as it is right now if he had aggressively encouraged community involvement instead of trying to lock the language down so much.

That said, it's completely mystifying to me how Elm is surrounded in so much drama, and it seems implausible and unreasonable to attribute it all to Evan. In the early days, it started getting hate from some hardcore Haskellers who felt that it needed more sophisticated language constructs. They would have converted it into PureScript, which clearly has never gained any widespread traction either -- perhaps less so than Elm despite all the drama. This is probably one of the earliest sources of conflict where Evan went against what a vocal minority wanted. Since then, it seems to have just snowballed, with the Elm team getting more locked down and vocal users becoming more and more upset about not being involved.

At the end of the day I don't really know what to make of it. Elm would not be Elm if Evan had listened to all the aggressive requests to make Elm more like Haskell. It would still be stuck in FRP-land and 99% of web developers wouldn't be able to make heads or tails of it.

What I will say is this. I have written some internal tools in Elm, and it's one of the best languages I've ever used for web development. It's a revelation of what the web ecosystem could look and feel like in a parallel world. Years later, I would still pick Elm for such projects because nothing else comes close from certain perspectives. I can always go get the normal experience with TypeScript and React. Elm is what I choose for self-contained applications where I don't need and don't care to deal with all the general chaos of the web world. And, personally, I doubt Elm would be this way if the early naysayers had gotten what they wanted.

>Well, simple: think of the rest of us who don't want every user lib to define its own custom operators.

Then why not simply not use those userlibs? Now it seems you're the one draping a blanket, only yours is over a non-specific hypothetical scenario rather than a real-world problem.

The reality is that people have opinions about things. You have opinions about things. People are going to try to manipulate tools they use because nobody in open-source has any significant amount of learned helplessness over software.

> most people would agree that user packages shouldn't be able to invent yet more custom operators

I'm actually curious why; I have yet to see people actually abuse operators outside of C++, and those were in the standard library…

This can be a problem in Haskell, where you can find a library using some operator like +>>* that you haven't seen before, imported from one of its 30 odd globally addressed modules, which may just be re-exporting other modules.

Hoogle/google rarely help with such operators, so finding any documentation is often an exercise in frustration, scanning through library after library for one declaration.

How does Hoogle not help with such operators? Hoogle can search over all packages in the Stackage package set and can also be installed locally to look over all the dependencies of your project.

I'm not sure there's a meaningful difference between a strangely shaped operator and a strangely-shaped function. (Indeed they desugar to the same thing, except one is symbolic and one is alphanumeric).

Any decent library will describe the operator in its Haddock documentation, and most will export a named function with the exact same semantics and type.

Hah, you beat me to it.

I think its a bit different with a language though. Because so much of other people's work is based on it, removing a feature that was being used causes all sorts of downstream chaos. Every time a language release breaks backwards compatibility it tends to really upset people, I think maintainers always need to be cognizent that their choices effect others.

They are. They might lose some users this way. They would definitely lose some users the other way though.

I suppose it must seem pretty strange to see a programming language built on a set of technical values, instead of trying to find the subset of most-popular values (because their real goal is popularity).

I've been using Elm happily for 3 years. Thanks for posting this.

Thanks for posting this, it's important.

Thank you! Well put.

It's a peculiar demographic I've noticed amongst people who have grown up with all their software available gratis or ad-supported.

"Oh this incredibly hard work that someone else did for free isn't exactly what I wanted and they refuse to change it the way I want for free"

If Elm is so great, and if it's 99% there, and you only need "this one little custom operator" added, or this "special piece of extension code" and it's really that 1% and you can't be bothered to contribute that 1%; to do it yourself, or pay someone to do it, well, then you deserve to use whatever piece of shit you end up with.

It doesn't sound like they were expecting someone else to do it: they did it themselves but the maintainers were not open to the idea.

What you said sounds exactly like they want the “maintainers” to do something.

But I understand how it can sound like that if you’re part of the demographic I’m talking about.

And when they don't accept your contributions and lock your thread when you explain why you neeed it, what then?

If it’s a good idea your fork will survive.

If it isn’t, now you know too.