[Haskell-cafe] who's in charge?

[Evan Laforge]

> Honestly, I think a big part of this isn't documentation practices so much
> as it is the expression problem. For a lot of the problems I tackle, the OO
> model is not appropriate for capturing program structure. Pairing this with
> Java's requirement of one class per file means that the actual functionality
> itself is spread out across a huge collection of classes and methods. The
> JavaDoc is just working with what it gets. This is one of the (many) reasons
> I prefer Haskell: the structure of Haskell programs matches the structure of
> the problems I need to solve (or at least, how I think about them).

I've also noticed this, and I agree with the above.

I track down some random type and it's just a one method interface, so
you can embed the "getter" in some random object.  In another
language, you would just pass a function.  Track down another and it's
an enumeration, to be passed to a factory, to generate subclasses of
some abstract superclass.  In another language it would just be an ADT
(the enumeration means the java can't add new subtypes anyway) and a
function to operate on it in probably 1+n lines, but in java we're
looking at 1+1+n+1 files, each with their overhead and directories,
and of course their own names, so you have to track down each one, and
remember what each name means as you try to understand the actual
logic.  In the specific example above, it was just reinventing
Data.Monoid, so in haskell you wouldn't have to remember any new
names, provided you already know 'mempty' and 'mappend'.

Also the java style OO insistence that functions go with the data
rather than with their related functions can require you to scatter
the implementation of one logical function far and wide... ostensibly
a feature I suppose, but can also be a liability.

Et cetera.

Sometimes I think it's just me, that I don't think in an OO way, but
then again, the examples above were written by someone else who has
done OO all his life.

For me it really is the explosion of names that leads to overload.

When writing haskell, I hardly ever finding myself wanting or
reinventing subtyping, so for me at least, the haskell half of the
expression problem is the practical half.