Even without talking about type classes, the lack of applicative is weird. I know: nobody understands what applicative is for, but if you have map and you are currying parameters, you're going to run into the issue ;-) Instead, you've got map, map2, map3, map4, map5 (which also, frustratingly, don't implement applicative). There are lots of validation scenarios that are just way more complex to do in Elm than they need to be.
But to be honest, it's fine because the language is not supposed to give you everything that you might want. It's geared for people who want a subset that's easy to learn. If I'm going to write code for myself in this space (functional language that compiles down to JS), I'm going to pick Purescript because it has everything that you're ever going to want. But if I'm choosing a language for my team that doesn't know functional programming and (to be blunt) doesn't really care to learn: Elm is a much better fit. They can learn just enough to get their work done.
But I just wish it was stated in those terms clearly. The premise of the article has been played out time and time again in the Elm community: "I thought this was a fully featured functional language, but when I tried to do this completely reasonable thing I got my hand slapped".
At every turn the response to, "Why can't I do X" is "Because you don't need to do X. It's much simpler to do without X" -- which usually isn't true. It's much simpler to learn something without X, but X is there to make your life much easier as long as you can deal with the complexity of learning it. It's the old "ease of use" vs "ease of learning" issue.
Instead, egos get involved and a new essay of the week appears on how Elm is doomed because it doesn't have <pet feature>. That nobody can take Elm seriously if it doesn't have type-classes, synchronous FFI, derivable JSON codecs, component state, or whatever the pyre was built on that day.
If you didn't know better, you'd think they were disgruntled paying customers.
Elm's simplicity, lack of abstraction, and resulting boilerplate have more to offer than helping beginners learn. Nothing demonstrates this better than coming back to an old Elm application and immediately making meaningful changes to the code despite a long hiatus from using Elm at all.
There are a lot of languages that continually add features in this space like PureScript, ReasonML, and even TypeScript.
Why not see where Elm ends up with its aggressive devotion to a minimal API instead of trying to turn it into a language we already have?
Some of the best aspects of Elm come from its restrictive nature. Like how every Elm application uses the same "TEA" abstraction which is a breath of fresh air for anyone who never felt particularly empowered by the paralyzing abundance of options in the JS ecosystem nor the task of webpack-plumbing them together.
If Evan hadn't wanted this to happen, he shouldn't have positioned it as the "beginner-friendly" language and then pulled the petty dictator routine out as soon as people were locked into his ecosystem.
> Nothing demonstrates this better than coming back to an old Elm application and immediately making meaningful changes to the code despite a long hiatus from using Elm at all.
Or... not having it compile because the BDFL (or, realistically, DFL) has decided to remove half the features it needed to compile.
Also, if calling this a minor release is idiotic, why was the version number then a minor increase (at least according to commonly accepted understanding, i.e. semver) and not a 0.20 or whatever else, especially if there are breaking API changes.
Native's existence was an implementation detail. no one using it didn't know it was likely to go away if they read anything about it from core. it was undocumented, but where you could find any documentation it said very clearly not to use it. people used it anyway. I was one. but I knew going in that it would likely disappear.
> why was the version number then a minor increase (at least according to commonly accepted understanding, i.e. semver) and not a 0.20 or whatever else, especially if there are breaking API changes.
https://semver.org/#spec-item-4
you not understanding semver doesn't make elm bad
But I'm still curious about exactly what people were using native for and why at least some users don't feel they can rewrite easily - care to share what you used and why, and what your thoughts are about replacing it?
(the discussion around this has, so far as I've been able to see, devoid of concrete examples, and now the question's nerd sniped me :)
Use custom operators? Fuck you. Now go rewrite all the libraries you contributed to the community.
I think you mean "immaturity of the platform".
Also, native modules weren't the only "escape hatch". An Elm application can communicate with JS through ports.
Native modules, on the other hand, let you create Elm functions that synchronously call Javascript. That means that what look like regular Elm functions can now synchronously blow up at callsite inside Elm.
The first native modules I saw in the wild as a beginner were people making shortcut functions for things like `Math.random()` instead of the proper way of threading a random seed into the entry point and keeping it in the model which has various benefits. Same with quick access to "Date.now()".
From this perspective, you can see why native module access was removed, and especially why you needed permission to publish a native module Elm's package repo. Native modules are tempting because they are easy, but widespread use eliminates one of the major upsides of Elm: no runtime errors inside Elm, or rather the ability to boundary them.
However, some forms of JS interop are hard or impossible without synchronous FFI, 1:1 JS library wrapping being the most obvious example. Having to use asynchronous ports for that is like wrapping a Javascript library's sync functions with an EventEmitter. You emit an event and then listen for the resulting event. Maybe you even decide to pass in a messageId echo for request/response reconciliation (I've seen people build this abstraction around Elm's ports!).
On one hand, a lot of people have the idea that because they are using Elm, they shouldn't have to write any Javascript at all. After all, this is what many compile-to-JS languages give you.
And on the other hand, no more synchronous FFI means that some Elm apps that exist today cannot move ahead, and some people think the approach is too heavy-handed or they disagree with the direction.
In my experience, Elm is best seen as a way to build a functional core that you wire up to an external world of Javascript. For example, a game simulation that emits game states over a port, and you write Javascript to render those updates with a JS library like Pixi.js, resisting the temptation to wrap Pixi.js in Elm and calling it from Elm.
See, this, to me, sounds quite reasonable.
A feature is potentially dangerous to the rest of the ecosystem if encountered unexpectedly: therefore, we put some extra friction on sharing code which uses those features, and made it an obvious and opt-in process if you wished to take that potential danger into your project. Great!
Given that... why on earth would it be necessary to remove the feature from the language entirely?
When you update this quickly (and for no reason), the learning resources go out of date too.
The way Elm is developed is fit for a language that has little to no users, and can take going so long between updates, that remove escape hatches needed to fill out the immaturity of the language.
It really saddens me to see it go like this, because I once had high hopes for Elm. Nowadays I see it purely as a stepping-stone into more advanced languages like PureScript and Haskell. Elm is there to hold your hand, but it seems it has no intention of ever taking you further than the basics.