41–50 of 79 posts
For a beginner, it just means being able to write filter instead of List.filter or whatever.
Earlier quoted context omitted.
And yet plenty of programmers somehow manage to ship perfectly good solutions to everyday problems without "generic programming" capabilities as you define them. The author of "Elm is Wrong" might have good intentions but the tone of that post is so condescending and inflammatory that all the points being made are lost. The title alone already starts everything on the wrong foot. Instead of sitting on such a high hor…
I don't think you get to call people condescending when you just generalised "the academics" to be ignorant of the "real world". > Instead of sitting on such a high horse the more constructive approach is to outline the shortcomings, implement the solution, and contribute it upstream. That's not what I see though. That's what the "Elm is wrong" post did though. It outlined the shortcomings and showed how it was impos…
Those are your words, not mine. My comparison wasn't about ignorance but of a different value system that is consistently substituted in discussions about programming languages and the substitution is then swept under the rug. The substitution being as I said theoretical concision and expression vs more easily understandable boilerplate and pragmatism.
Earlier quoted context omitted.
My major question is: how do you write reusable code without type classes? It's not really possible, as far as I can tell.
Are you trying to say that in the 30 years of time between the discovery of Lisp and the discovery of typeclasses, no one wrote reusable code?
Earlier quoted context omitted.
> Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple. I just straight-up disagree with this. If Elm added Haskell-style typeclasses today, and we refactored our whole code base at work to use them, I bet it would save us less than 1% LoC. This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the p…
Yes, that's true, but I bet you some of the functionality that you wrote can be factored out into a more generic library that applies to everyone's use case. So it could be that half of your code is "library" code that could be open sourced - if it could be written generically with typeclasses. For example, Rust has typeclasses (called traits) and Rust has a lot of libraries that do the right thing for you. fn accumu…
Of course. We publish quite a few such libraries, in fact. :)
Search for "NoRedInk" on http://package.elm-lang.org
Earlier quoted context omitted.
> Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple. I just straight-up disagree with this. If Elm added Haskell-style typeclasses today, and we refactored our whole code base at work to use them, I bet it would save us less than 1% LoC. This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the p…
> This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the parentheses, and accusing JavaScript developers of sticking their fingers in their ears about the most obviously glaring weakness in the language. That's a straw man which isn't directly analogous to the question of typeclasses. The reason is because parens are a syntax concern, wh…
I agree! That would make for a much more straightforward discussion. :)
Earlier quoted context omitted.
> Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple. I just straight-up disagree with this. If Elm added Haskell-style typeclasses today, and we refactored our whole code base at work to use them, I bet it would save us less than 1% LoC. This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the p…
> This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the parentheses, and accusing JavaScript developers of sticking their fingers in their ears about the most obviously glaring weakness in the language. That's a straw man which isn't directly analogous to the question of typeclasses. The reason is because parens are a syntax concern, wh…
Earlier quoted context omitted.
> This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the parentheses, and accusing JavaScript developers of sticking their fingers in their ears about the most obviously glaring weakness in the language. That's a straw man which isn't directly analogous to the question of typeclasses. The reason is because parens are a syntax concern, wh…
> 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. :)
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?
Earlier quoted context omitted.
> 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. :)
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 examp…
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." :)
Earlier quoted context omitted.
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 examp…
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 co…
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.
Earlier quoted context omitted.
> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…
My major question is: how do you write reusable code without type classes? It's not really possible, as far as I can tell.
-- Monoid as a record type
type Monoid a = {
empty: a,
append: a -> a -> a
}
-- Using this to make a generic concatenator
mconcat : Monoid a -> [a] -> a
mconcat m = foldl m.append m.empty
-- Instance of Monoid for strings
MString : Monoid String
MString = {
empty = "",
append = (++)
}
-- Instance for ints
MInt : Monoid Int
MInt = {
empty = 0,
append = (+)
}
-- Use the generic function
unlines : [String] -> String
unlines = mconcat MString . intercalate "\n"
Of course the downside is that you have to pass in the instance argument to any "type class polymorphic" function, so you lose a bit of conciseness but not much in the way of expressiveness. And you actually gain a bit, because instances are explicit (for example, you could make an instance of Monoid Int which used 1 and (*) instead).
I'm not sure if this pattern is used anywhere in extant Elm code, but this is a common way to implement type classes under the hood in languages that support them, and the approach seems doable in elm.