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!