DEV Community

Discussion on: Elm 0.19 Broke Us 💔

 
robinheghan profile image
Robin Heggelund Hansen

Your perspective is valid, but (my own opinion, not necessarily Evan's) since Elm is still pre 1.0, I think the perspective from the language creator is not "what can I take away" but "what should be in the language when it's done."

So while the users of the language in the current state feel som pain through breaking changes, I think Evan has a 20 year perspective on things. And in 20 years, will Elm programming be worse or better off because of custom operators? We can disagree, but my experience with Haskell is that Elm is better off without.

But yeah, I get that it's frustrating that a feature you use is removed.

Thread Thread
 
kspeakman profile image
Kasey Speakman • Edited

Ah! That's the difference. I'm coming from F#, which has custom operators. But it has not really gone overboard with them. Without HKTs/typeclasses it is not easily possible to define an operator once and have it apply to different types. You have to define the operator for every containing type, and then you can end up with naming conflicts if you overdo that.

So in practice, the operator really has to buy you something to bother, and it stays limited to a specific module. Probably the worst offenders I've seen are libraries ported from Haskell. But since they are limited to that library, I can just use a different alternative, or in small cases just write my own. So my experience with custom operators has been drastically different, and I have found them useful in F#. For example, I ported Elm's URL parsing library to F#, and because custom operators were allowed was able to use the </> and <?> operators. If I find myself in the reverse situation, I would be stuck in 0.19.

Thread Thread
 
kspeakman profile image
Kasey Speakman • Edited

But yeah, I get that it's frustrating that a feature you use is removed.

I use this feature in Elm almost not at all, currently. I could easily get by without it. (But I have needed it in F#, so view it as useful and a mistake to remove.) As mentioned in the original post, it's the overall message that we're getting from Elm that has me reeling. Not just this one piece.

Thread Thread
 
wires profile image
Jelle Herold

I wholeheartedly agree with this.

"what should be in the language when it's done."

People have been suggesting countless of things, type classes, SYTC, HKT, etc etc... those issues get closed with comments such as "use another language then" or "almost nobody uses this".

I am actually suspecting that nobody really knows how to implement these features on a theoretical level and that's why...

Thread Thread
 
robinheghan profile image
Robin Heggelund Hansen

The implementation for these things are known, there's just no pressing need to introduce them to the compiler. There's also no consensus on what the right implementation would be.

I write Elm full time, and don't miss these things. There have been times where it would be nice to implement comparable for one of my types, but I'm not convinced that type classes is the right approach for ad-hoc polymorphism in Elm.

Thread Thread
 
gonzooo profile image
Rickard Andersson

I think it's telling that less than 5 years later than this comment was made Elm has stagnated almost completely and is experiencing an almost constant exodus of users not just because of the language evolution being inflexible and impractical, but because of the "party line" behavior that can be observed in these comments.

Thread Thread
 
destynova profile image
Oisín

Perhaps, but the author of that comment also started a project called Gren which tries to address many issues with Elm which indeed seems to have stopped evolving. Although some of the design decisions seem to double down on controversial decisions in Elm (e.g. locking down the "kernel" code, banning custom operators etc).