3 ms·
> Do you really believe the author ... is simply clueless about functional programming? I believe that his paper's descriptions of technical advantages of OO a
by jph 12y ago
> Do you really believe the author ... is simply clueless about functional programming?
I believe that his paper's descriptions of technical advantages of OO are not actually about OO, and instead are about FP and interfaces -- what he calls "service abstractions".
Notice this: when he describes ADTs, he glosses over their power; when he describes the evolution of object code, he glosses over the evolution of interfaces; when he describes messaging, he glosses over protocol endpoints.
IMHO his paper mostly glosses over all the actual technical advantages of OO vs. other approaches, namely OO state encapsulation, OO black boxing, OO inheritance, and OO composition.
He writes that the "key technical characteristic" of OOP is dynamic dispatch, and "is essential to supporting independent, interoperating extensions". OOP's key technical characteristic is not dynamic dispatch -- it's black boxing of data + state + methods. Moreover, dynamic dispatch is not essential to supporting extensions as he claims. To top it off, FP easily does dynamic dispatch by using higher level functions and type classes if you like.
- glurgh 12y agoyou're making a fallacy of appeal to authority. I'm not. I'm not saying anything about the quality of his argument, I'm talking about the stridently poor quality of your initial one which boils down to 'he doesn't know what he's talking about'. I think that's trivially and factually refutable. I do think what he's trying to argue is both interesting and difficult and I'm not sure I'm entirely convinced by it. It doesn't merit 'he's clueless' and saying that does a disservice to both the paper and the discussion here. Your later, concrete objections are actual objections but I don't feel I've understood the paper well enough to engage in them. I'd only say I'm also unsure whether they're really about what the paper is about. The fact that many, in fact most, programming formalisms and paradigms are largely isomorphic is both well-understood and rarely a source of practical insight, which is the stated goal of the paper. [I guess this is now also a reply to a post that was heavily edited while I was replying to it]