4 ms·

> Well, the burden of proof should be on the proposer: that the feature is useful. A good next step would be for someone who's interested in persuading you of t

> Well, the burden of proof should be on the proposer: that the feature is useful. A good next step would be for someone who's interested in persuading you of the importance of typeclasses I agree! That would make for a much more straightforward discussion. :)

leshow 10y ago
As an example, I see code all the time with many showX functions whose sole purpose is to turn come ADT into a string, this is the kind of boilerplate that would be reduced with some kind of abstraction mechanism. Same for map operations, fold, etc. Then there's other things that would benefit from further abstraction, like being able to compose apps or update functions without boilerplate. These are just a few examples. What else do you need for it to feel like abstraction beyond simple functions is a useful feature?
- rtfeldman 10y ago
  To be clear, I'm not saying it's not useful! No need to convince me of that. :) What I'm saying is that even useful features come with both benefits and drawbacks. For example, I think user-defined typeclasses would add significant complexity to the language and especially to the library ecosystem. I'm not saying "these are worthless ideas," I'm saying "these benefits wouldn't improve my life enough to justify the cost." :)
  - leshow 10y ago
    Your claim was that Elm isn't boilerplate heavy, but without these types of abstractions, it is. Perhaps you can't see the benefit and you're happy writing 10 implementations of "show", but don't claim there is no boilerplate. For the record I don't care if it's typeclasses and I wouldn't want to see Elm turn into haskell. I'd just like some other type of mechanism for abstraction besides extracting to a function.
    - rtfeldman 10y ago
      > Your claim was that Elm isn't boilerplate heavy, but without these types of abstractions, it is. You seem very certain of this, so surely finding some real-world code examples to back it up should not be too difficult, yeah? :) > Perhaps you can't see the benefit and you're happy writing 10 implementations of "show" Like I said, I do see the benefit, but don't think it's worth the drawbacks. Also, "deriving" saves you from writing "show" implementations, not typeclasses, so I'm not sure why you're bringing that up.
- cassowary 10y ago
  Hi leshow, can you be more concrete? If I have a record `data Foo = Foo {fooA :: Text, fooB :: Text}` then I must write a method `show :: Foo -> Text` for it. It is immaterial if I write `instance Show Foo where` ` show foo = (... implementation ...)` or `shooFoo foo = (... implementation..)` I save no code with typeclasses (at this point at least). (I do save code with the magic "deriving", but that's not part of the typesystem; it's just the compiler implicitly generating a bit of code for me.) Likewise, map operations, fold. They need to be written and used. I'm sceptical of Elm's claim that typeclasses aren't useful, but your post doesn't show what it sets out to, because it lacks concreteness. Out of your post, it is only when you get to function composition that typeclasses can theoretically help — but the question isn't, can they theoretically help, it's do the help in practice. So can you show some example? To meet the challenge and provide convincing evidence that a language without typeclasses is lacking, you would need to say "This is what the code is. And this is what it could be with typeclasses". Unless you do that, Noredink's claim that their code wouldn't be simplified with typeclasses stands. I do not think you are obliged to do this. It is perfectly legitimate for you to ignore my message. But I think both sides can agree that this is what would be convincing to the anti-typeclassists.
  - marcosdumay 10y ago
    !? Of course you save no code on definitions. Some may even get more verbose. You save code on usage, because you can use generic functions that will work for any instance of Show, instead of specifying them for every type.
- deleted 10y ago
  [deleted]

leshow 10y ago

As an example, I see code all the time with many showX functions whose sole purpose is to turn come ADT into a string, this is the kind of boilerplate that would be reduced with some kind of abstraction mechanism. Same for map operations, fold, etc. Then there's other things that would benefit from further abstraction, like being able to compose apps or update functions without boilerplate. These are just a few examples. What else do you need for it to feel like abstraction beyond simple functions is a useful feature?

rtfeldman 10y ago
To be clear, I'm not saying it's not useful! No need to convince me of that. :) What I'm saying is that even useful features come with both benefits and drawbacks. For example, I think user-defined typeclasses would add significant complexity to the language and especially to the library ecosystem. I'm not saying "these are worthless ideas," I'm saying "these benefits wouldn't improve my life enough to justify the cost." :)
- leshow 10y ago
  Your claim was that Elm isn't boilerplate heavy, but without these types of abstractions, it is. Perhaps you can't see the benefit and you're happy writing 10 implementations of "show", but don't claim there is no boilerplate. For the record I don't care if it's typeclasses and I wouldn't want to see Elm turn into haskell. I'd just like some other type of mechanism for abstraction besides extracting to a function.
  - rtfeldman 10y ago
    > Your claim was that Elm isn't boilerplate heavy, but without these types of abstractions, it is. You seem very certain of this, so surely finding some real-world code examples to back it up should not be too difficult, yeah? :) > Perhaps you can't see the benefit and you're happy writing 10 implementations of "show" Like I said, I do see the benefit, but don't think it's worth the drawbacks. Also, "deriving" saves you from writing "show" implementations, not typeclasses, so I'm not sure why you're bringing that up.
cassowary 10y ago
Hi leshow, can you be more concrete? If I have a record `data Foo = Foo {fooA :: Text, fooB :: Text}` then I must write a method `show :: Foo -> Text` for it. It is immaterial if I write `instance Show Foo where` ` show foo = (... implementation ...)` or `shooFoo foo = (... implementation..)` I save no code with typeclasses (at this point at least). (I do save code with the magic "deriving", but that's not part of the typesystem; it's just the compiler implicitly generating a bit of code for me.) Likewise, map operations, fold. They need to be written and used. I'm sceptical of Elm's claim that typeclasses aren't useful, but your post doesn't show what it sets out to, because it lacks concreteness. Out of your post, it is only when you get to function composition that typeclasses can theoretically help — but the question isn't, can they theoretically help, it's do the help in practice. So can you show some example? To meet the challenge and provide convincing evidence that a language without typeclasses is lacking, you would need to say "This is what the code is. And this is what it could be with typeclasses". Unless you do that, Noredink's claim that their code wouldn't be simplified with typeclasses stands. I do not think you are obliged to do this. It is perfectly legitimate for you to ignore my message. But I think both sides can agree that this is what would be convincing to the anti-typeclassists.
- marcosdumay 10y ago
  !? Of course you save no code on definitions. Some may even get more verbose. You save code on usage, because you can use generic functions that will work for any instance of Show, instead of specifying them for every type.
deleted 10y ago
[deleted]