> (...) I don't recall where I found the following example, but copied
> it locally as compelling evidence that the functional solution can be
> much clearer and shorter than the same solution modeled with objects
> and inheritance.
Greg,
I desagree with you. Bjarne Stroustrup, the original creator of C++, is
a sensible person and I share his peacefull opinion in this matter:
http://www.research.att.com/~bs/bs_faq.html#compare
Even with good intentions, I've never seen such kind of comparison not
to fall into religious fights. (Although I'm not more than just a humble
language user.)
Functional languages are much more formalized than OO languages. The basics (i.e. lambda-calculus algebraic data-types, *morphisms) are well known and very composable. OO theory is a mess, classes and objects are different beasts on every OO language and they don't form an easily composable toolkit (e.g. the inheritance vs. composition debate, where to place methods, binary method choices). There are many (which by sheer amount of variance isn't a good sign) formalizations of OO but none that were well received by the most popular OOPLs (in contrast with FP theory and it's pervasiveness in FPLs).
In this case it isn't a religious fight.
> -- Arithmetic expression forms data Expr = Num Int | Add Expr Expr
>
> -- Evaluate expressions
> eval :: Expr -> Int
> (...)
> public abstract class Expr {
> public abstract int eval ();
> public abstract void modn(int v);
Although I'm not good enough to judge anyone's Haskell code, the Haskell
version seems nice. I don't know how someone who understands well
object-oriented code would do that. But I did C++ until around 1998,
when the first standard was set, and I can tell you for sure that, even
at that time, no one who knows at least the basics of C++ would ever
write that problem like this.
Well, any OO programmer familiar with algebraic and coalgebraic datatypes would do that, it's the best way to model this problem (unless you mix it with extensible types but then we would fall in the expression problem territory and this isn't an easy problem to solve in any mainstream languages).
Best,
Maurício