On Mon, 2008-11-17 at 16:04 -0800, Jonathan Cast wrote:
On Mon, 2008-11-17 at 21:49 -0200, Maurício wrote:
(...) 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
I think his creation of C++ is evidence against that view...
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.
How do you recommend selecting a language? Stroustrup, in my experience, seems to think the answer is `any method but technical merits', which would make me suspicious of the technical merits of his solution even if I knew nothing else about them (and I know all too much...). Ask yourself: what is he hiding?
-- 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.
Of course not. But their solution wouldn't be object-oriented, either; this is just an example where OO solutions don't make sense. (And the example code is Java; I've been wracking my brain, but I can't come up with any other way to do it in that language).
Jonathan is spot on. The OO solution is an elegant approach. I can definitely see a C++ programmer writing it. If they didn't write it that way, it would be because, as Jonathan says, they didn't use an OOP approach. Note that this particular example is usually used to show the duality between FP and OOP. To add a prettyPrint function to the FP version, one need simply write another function while the OOP version will require changes to all the classes. To add a Mul constructor to the OOP version, one need simply write another class while the FP version will require changes to all the functions. This example illustrates (and is the namesake of) the expression problem.