Cory Knapp wrote:
Actually, that was part of my point: When I mention Haskell to people, and when I start describing it, they're generally frightened enough by the focus on pure code and lazy evaluation-- add to this the inherently abstract nature, and we can name typeclasses "cuddlyKitten", and the language is still going to scare J. R. Programmer. By "inherently mathematical nature", I didn't mean names like "monoid" and "functor", I meant *concepts* like monoid and functor. Not that either of them are actually terribly difficult; the problem is that they are terribly abstract. That draws a lot of people (especially mathematicians), but most people who aren' drawn by that are hugely put off-- whatever the name is. So, I guess my point is that the name is irrelevant: the language is going to intimidate a lot of people who are intimidated by the vocabulary.
Oh, I don't know. I have no idea what the mathematical definition of "functor" is, but as far as I can tell, the Haskell typeclass merely allows you to apply a function simultaneously to all elements of a collection. That's pretty concrete - and trivial. If it weren't for the seemingly cryptic name, nobody would think twice about it. (Not sure exactly what you'd call it though...)
A monoid is a rather more vague concept. (And I'm still not really sure why it's useful on its own. Maybe I just haven't had need of it yet?)
I think, as somebody suggested about "monad", the name does tend to inspire a feeling of "hey, this must be really complicated" so that even after you've understood it, you end up wondering whether there's still something more to it than that.
But yes, some people are definitely put off by the whole "abstraction of abstractions of abstraction" thing. I think we probably just need some more concrete examples to weight it down and make it seem like something applicable to the real world.
(Thus far, I have convinced exactly *one* person to start learning Haskell. This person being something of a maths nerd, their main complaint was not about naming or abstraction, but about the "implicitness" of the language, and the extreme difficulty of visually parsing it. Perhaps not surprising comming from a professional C++ programmer...)
At the same time, I think everyone is arguing *for* better documentation. And you're probably right: better documentation will bring the abstract nonsense down to earth somewhat.
Amen! _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
