[caconym_]

It really seems like Elm should implement typeclasses. I don't know Elm, but I can't really imagine writing serious Haskell programs without them, and I've seen multiple Elm-related complaints today that were either directly lamenting their absence or lamenting difficulties that they would have solved, trivially.

[Skinney]

Keep in mind that Evan works at a company that has 55k lines of Elm in production. Neither Evan, nor the lead-developer of the company, feel that typeclasses, or something like it, needs to be in the language right now.

[caconym_]

> Neither Evan, nor the lead-developer of the company, feel that typeclasses, or something like it, needs to be in the language right now.

Need is not the word I'd use. IIRC (from some Github issue I saw recently) Evan has said they are adopting a "wait and see approach" on typeclasses and/or other type system extensions. Given how young Elm is, I see this as a careful and considered approach to its continued development, rather than a statement that its creators consider it to be finished and complete as it is at this time.

I've jumped ship on things for far less than a "need", just because there was something better. I expect that a lot of people use Elm despite any perceived deficiencies because they think it's still better than the alternatives for their application(s).

[Skinney]

Read the two last words of that sentence. I agree with you, I use Elm every day.

[caconym_]

I'm not sure what point you think I'm trying to make. A language can be better than its competitors/alternatives while still having room to improve.

I'm not saying "Elm is bad", or whatever.

[Skinney]

Here's how I view our conversation thus far. I said "Evan doesn't feel the need to add typeclasses right now." You said "He is thinking about maybe adding it in the future." Then I said "I know, that's why I ended my sentence with -- right now --" and then you said "what are you talking about? I'm not saying Elm is bad!"

> A language can be better than its competitors/alternatives while still having room to improve.

I agree with you is all I'm saying. I never tried to imply otherwise. All I said is that there is no reason to think that Elm has to have typeclasses right now to be useful, as some others seem to suggest.

[leshow]

This is unconvincing to me. Just because Evan and his friends are happy to write boilerplate and copy-paste the same stuff over and over doesn't mean it's the right thing to do.

[rtfeldman]

Hi! I work at NoRedInk, the aforementioned company with 55,000 lines of Elm in production.

We don't "copy-paste the same stuff over and over." That would suck. Why would we be excited about a language that made us do that? Our Elm code is about as DRY as our JS code was before, except the Elm code is way easier to maintain.

[leshow]

How do you compose update functions without writing the boilerplate let ... in for every Msg? How do you stop your main update function from growing endlessly as you add new Msgs?

You need only look in the standard library for examples of boilerplate and not-DRY code. The map function is implemented separately for Lists, Arrays, etc.

I really want to love Elm. But the more I wrote it the more I realised that the only answer to those questions is that you solve them with boilerplate and brute force. When I ask the community what the solution is I'm largely ignored or told it's not a "real" problem.

[rtfeldman]

> How do you compose update functions

If there's shared logic between update functions we extract it into a helper function. That also makes it easier to test.

I'm not sure how typeclasses would make composing update functions easier, but in this case we can be concrete. PureScript's Pux library implements the Elm Architecture, and PureScript has typeclasses. Would you mind showing me some Pux code that uses typeclasses to improve the situation you're talking about?

[leshow]

Extracting to a helper function doesn't change the fact that there is boilerplate that must be overcome by brute force when composing "components". Every sub update function needs to be manually wired into the main update function since the introduction of Html.app. Libraries like elm-return make this a bit nicer to work with, but because of the restrictions in what Elm will let you do with it's "magic" there is no alternative.

I don't write PureScript, I can't help you there.

[Skinney]

It should be mentioned here that if map had the same implementation for both Array and List, map for arrays would probably be 10-20x slower than what it is today.

In that case, is it really boilerplate?

[rtfeldman]

Yeah, that would be an example of where even if that langue feature existed, using it would lead to a worse implementation. :(

[Skinney]

What is "the right thing to do"? Depends doesn't it? Just because other languages have support for something like typeclasses, doesn't mean that it's the right thing for Elm to have.

The fact that NoRedInk are perfectly happy without typeclasses (or something similar) could be an indication that it really isn't as important that people would make you believe. After all, there are several languages out there with support for typeclasses (or something similar). Like purescript. And yet, people decide to use Elm.

[leshow]

Perhaps not, but it seemed like an issue even in small sized apps that I wrote.

I think that Evan and Richard are personally invested in the language and can't see it's shortcomings.