re: Elm 0.19 Broke Us πŸ’” VIEW POST

VIEW PARENT COMMENT VIEW FULL DISCUSSION
 

Well.

I can't disagree with you that experimentation with operators is now harder. But the reason for their removal is that operators is very rarely more readable than named functions. While you're right that there is a lot of prior art when it comes to good custom operators, most of the custom operators in Haskell (for instance) are, imho, horrible.

Operators can make reading code easier, but only when everyone immediately understands what the operators mean and this is only true for a very small set of operators. When Evan decided to remove custom operators it was because he scanned through the packages repo and found operators like -~>... what does that even mean?

Regarding the "this is a pretty intense way to deal with your users." comment, we need to focus on what Elm 1.0 should look like. At that point, things like this won't change anymore, but before that point Elm should remove things which isn't necessary to the language. That's the only way to make it easier for professionals and beginners alike.

For JSON encoding/decoding, I understand your pain as I initially thought about them that way. But I've come to view them as assertions that what I'm given from the backend (or browser) as correct, and makes me write code that deals with them if not. I also use them to convert certain constants into union types. Besides, encoders/decoders rarely change, so they're low maintenance. There are several code generators for encoders/decoders (like this one noredink.github.io/json-to-elm/), but I've not really felt the need for them.

File uploads is something that is lacking from Elm, and I hope that it's something coming soon. However, you don't need native/kernel code for this. A port should work just fine for this use case.

A lot of opinions here that are different from my experiences. Some people use odd operators. We don't -- just the common ones for bind and map. But even if they do, who cares? It's not likely to be used when people are intimidated by the operators. It's a freedom that really didn't have to be taken away. Some people really need encoders/decoders. 99% of our API calls don't -- the types always line up exactly, and we do adjust types regularly. So maintaining co/decs has only downsides.

For files, I agree a port is perfectly fine. At the time I could not find a succinct example for that, and it was just quicker to do what I did. But were I doing it again, I would probably use this as a guide.

They're not my opinions, it's my experience. I came to Elm from languages which much more constructs. Nowadays I spend most of my time in languages which are very small (Elm, Go...). I don't miss the days of C++, C# or JS.

"It's not likely to be used when people are intimidated by the operators." <--- This is wrong. If there's really only one library which provides what you need, and that library uses operators, you have to use them. If you're fixing bugs some other developer wrote, and that developer is fond of operators, you have to use them. There are other situations as well, but the idea that people who don't like a construct will avoid it, just doesn't work out in practice.

Operators, while nice in certain cases, doesn't enable something that wasn't possible before. Unless they're universally understood, writing a function with an easily understood name that can be used in a pipeline is just much easier.

I can agree with you that operators can make code more cryptic and should be used sparingly. But I disagree that everyone's choice about using them should be taken away. It would be one thing if they were blocked from published packages, but they are not even allowed in my app code now. That's just being controlling.

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.

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.

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.

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...

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.

code of conduct - report abuse