Basically, Evan decided he wanted Elm to be a pre-packaged closed ecosystem where it was easy to develop very simple standalone apps, but made it very difficult to impossible to actually integrate with any existing JavaScript code or libraries. This was a baffling decision to people who thought Elm was supposed to be a practical language.
Blaming everything on "entitlement" from people who bought Elm's marketing about "making functional programming practical" is ridiculous. Thankfully there are now plenty of languages with better type systems than Elm (Rust, OCaml) that deploy to the web just fine.
The entitlement doesn't come from thinking "dang, the project doesn't do what I want".
It comes from getting worked up that it doesn't. And it comes from getting worked up that your github/forum/slack correspondence doesn't go in your favor just because you really want something, even if you think you should have more clout because it's a small community.
Elm made a controversial but reasonable trade-off for its packaging ecosystem: No synchronous FFI, only async FFI (over ports or web components). That means that you can count on Elm packages to not have runtime bugs due to sync JS which is a reasonable guarantee with reasonable workarounds.
As for whether Elm is impractical or impossible to integrate with JS code because of it, did you try? To me this complaint is like when I used to read people saying JS Promises led to worse code than JS callbacks early on in Javascript's transition. I couldn't relate to it much. You learn the idiosyncrasies and you move on.
I think part of the entitlement is the people who choose to never move on. Elm sucks, it's impossible to integrate, it's impractical, nobody should use it. Or... exit the theater and let the rest of us enjoy the show?
Actually, it comes from the concrete complaints specified in the article, such as the total exclusion from official Elm spaces if you try to fix your own problems. If it was what you described, i.e. the inability to do things within the packaging ecosystem, that would be acceptable; that was the status quo in 0.18 and everyone dealt with it.
The basis for calling complaints about functionality 'entitlement' is that you put it into the world because you want to, and the default avenue for other people getting what they want is to put it into the world themselves. If you lure people to get invested in your project, cause a problem for anyone invested in your project, and attempt to prevent them from solving their problem themselves, then you are behaving irresponsibly and complaints about this do not stem from 'entitlement'.
To Elm's supporters, Evan can do no wrong (because anyone who disagrees is ejected from the community, of course), creating a cult-like following that only gets more insular as times goes on. Thankfully, it seems to have gotten so insular that the language has essentially now died out.
Yeah I think you summed this up nicely. "Entitlement" is an easy go-to explanation since the internet is filled with it, but it's one sided. If you're pitching a language to people and they put a lot of energy into building on it, only to have their work permanently broken with no workarounds, you're going to get blowback. At the end of the day, Elm core team is free to make their own decisions, but they have to live with the consequences of those decisions. They are no more entitled for their users to remain silent than their users are to demand a certain technical direction.
This is why open source governance is so important. Technical excellence is orthogonal to community management excellence, and you can't scale an open source project without some measure of the latter.
You can do something like this with OCaml/SML's module system.
And certainly from an abstraction point of view you can do this in any dependently typed language like Idris/Agda/Coq, but these don't have great implementations.
Typed functional languages like Haskell (data)/ML (type) do have a built-in way to define new tree types, and so does Rust (enum). It's one of the biggest things I miss when I'm not using these languages, especially when combined with some metaprogramming (deriving/derive) to get some functions defined for these new types very quickly.
I think we might be speaking past each other? How is enum in Rust a tree type? You might be able to use it to create a tree type, but that's no different from using struct to make struct Tree : std::vector<Tree> {}; in C++. That wouldn't mean C++ has a tree type, it just means it's not hard to create your own. Whereas std::list is actually a linked list type that's already there.
Well, std::list is something you can create with C++ code (and likely is in most implementations of C++?), it doesn't need any special support. So I can see why someone might not treat std::list as any more special than a tree datastructure supplied by a different library?
However, algebraic data types really make your life easier, and more languages should have them.
I'll be surprised if none of the bigger beer companies ends up buying it for the brand and history alone. But maybe it doesn't have as much name recognition as I thought.
Anchor Steam had its place, 20+ years ago. It had a long-standing tradition of being a beer that stood the test of time, head and shoulders above the usuals of the time.
The problem is they failed to continue to keep up with the times as the proliferation of truly fantastic beers hit and later dominated the scene. Take a look through their flagships; they look more like what any new and likely-soon-to-close brewery will start with (a hazy, a west coast, a porter, a lager, and an ale) rather than a brewery steeped in 100+ years of history and brewing mastery.
Anchor Steam may have had the brand recognition necessary to survive in an overcrowded market say 10 years ago, but now people are flocking to the breweries themselves and are not as tied down into a single brand as they used to be.
It's sad but in the same way that any long-standing brand that couldn't keep up with the Joneses and went out of business is sad. Not really in any other way.
It really is remarkable. I think the most remarkable fact about it is that the intensional identity type was invented by Martin Lof in the 70s, the groupoid model was discovered in the 90s and then finally in the late 2000s various people made the connection that Martin Lof's original system from the 70s was in a sense already a type theory for abstract homotopy theory. This led to an explosion of new ideas in type theory (univalence, higher inductive types, modalities) that took a somewhat obscure field of math/cs to the thriving research community it is today.
I’ll admit to coming late to the party (when a friend introduced me in 2013), but what’s amazing to me is when you take the step of encoding your cellular structures as adjacency matrices.
You can visually see structures of your theory (eg, facts about groups) in the patterns of terms in the matrix.
Eg, diagramming a cyclic group ends up with a banding pattern in the portion of your matrix denoting equivalent pairs under the operation… which shows that in some sense, the level maps of + on Zn x Zn form a twisted torus. (Which makes sense in hindsight, as you have the product of two loops with the level maps wrapping around non-trivially.)
That you get ideas such as that by chasing through a purely abstract definition (groups -> diagrams) is wild to me.
Edit:
I actually built a simple case (Z4) in Minecraft — just because I found it surprising.
> How can roots be changed without a redo of the universe?
This is a very interesting question and I think reflects a mismatch between how we commonly think about of foundations of mathematics and what role foundations actually play in mathematics. There's no recording online but I recommend looking at the slides to Mike Shulman's talk from JMM 2022 where he discusses this point: http://sigmaa.maa.org/pom/Slides/shulman-2022jmm.pdf . Mike works on, among other things, homotopy type theory, the subject of the original article.
His basic point is that we should think of math more like programs that we can "compile" to various backends. If your math is high level it's not necessarily tied to a particular "architecture" like ZFC.
