[tom_mellior]

> The line from Evan, Elm's creator, has always been along the lines of "show me a concrete actual use-case that you can't do without typeclasses", this article fails to clear that fairly low bar.

Translation: "I will never add typeclasses."

There is no concrete actual use-case that is impossible to implement without typeclasses. What typeclasses make possible is an abstraction over concrete actual use-cases. That is, you can always solve individual concrete actual problems with boilerplate. Typeclasses "only" give you the possibility to write that boilerplate once and for all and reuse it for every concrete actual use-case.

Evan seems to think that that's not worth it, which is a valid opinion to hold. But it would be a bit more honest to come out and say it like this.

[Skinney]

Evan has several times said that he's open for typeclasses. Problem is that they have a profound effect on the language, and so they have to be done right. He doesn't know what the right implementation of that might be at the moment, so he's waiting until he comes up with what the right thing to add for Elm would be.

[leshow]

You think Evan is just waiting around for the right abstraction to dawn on him? It's been years with not one bit of code written in the direction of adding a mechanism for abstraction in the language (whether that be typeclasses or something else)

[Skinney]

"Code is the easy part"

First you need to figure out what exactly the Elm community wants and needs. Once you have a pretty good idea of that, you can start prototyping things. Elm is still young, and the most pressing concerns for using Elm in production is not the lack of interfaces/protocols/typeclasses, but stuff like debuggers, which is what Evan is working on.

I'm sure we'll see some tool for ad-hoc polymorphism in the future, but not in the short term.

[leshow]

Blind faith might be enough for you but I don't buy it. The original issue was 3 years ago.