[Haskell-cafe] What I wish someone had told me...

wren ng thornton wren at freegeek.org
Wed Oct 15 06:18:31 EDT 2008

John Lato wrote:
> Are you advocating introducing existential types to beginning
> Haskellers?  I think something with the scary name "existential
> quantification" would greatly increase the head'splodin' on the
> learnin' slope.  Certainly there's a place for them, but I wouldn't
> want to see new Haskell programmers habitually approach problems with
> a "first create a type class, then make an existential wrapper"
> mentality.  Which is exactly what I fear is the current situation.
> Although my list example is far to shallow to make this point, it
> seems to me that it's fairly likely that somebody faced with this
> problem has had something go severely wrong at some earlier time.
> Existentials are certainly useful, but isn't it also possible that,
> for many cases, an alternative design exists which fits a functional
> idiom better and doesn't face this issue at all?
> John

I think one of the reasons more people don't highlight the differences 
is that, with all due respect, the differences are often too subtle for 
OOP programmers. That is, few OOP programmers are taught to think about 
type theory as deeply as is necessary to see why they're so 
different[1]. On the one hand, few programmers of any ilk are taught to 
think deeply about type theory so that's unfair to OOP. But on the other 
hand OO propaganda is rife with claims that the class/inheritance model 
of types is The One True Way(tm). I'm not saying this to be rude; there 
are many OO programmers who do know quite a bit about type theory. 
However, tutorials for OOP are full of indoctrination about how OO type 
systems are better than C. In my experience that tends to create 
OO-programmers who don't question the class/inheritance model or think 
about what other approaches would look like. Discussions where an OO 
type system is not assumed typically lead to talking past one another, 
as here[2]. The idea of defining allomorphic functions which don't use 
dynamic dispatch and don't use inheritance is difficult to explain 
without a lot of groundwork to undo OO assumptions.

That said, I agree it's a pernicious meme which does disservice to 
everyone. Though I'm not sure showing people Oleg's handiwork is a 
gentler introduction either ;)

[1] Consider, for example, the question of whether the arguments/value 
of a function should be covariant or contravariant in subclasses. Java 
got this wrong for arrays. Their answer seems intuitively right, but 
this is one area where intuitions are suspect.


Live well,

More information about the Haskell-Cafe mailing list