The reason WHY OO sucks

[Dr.Dr.Ruediger M.Flaig]

Dear Joe, 
dear Erlangers,

let me return once more to the "Eppur si sugat" thread. A number of things have recently moved me to sum up a few of my thoughts about OO vs. FP, which I would like to share with you. What do you think about this?


**
In OO, it is often pretty difficult to decide where to attach a method which is not tied to an object by logical necessity; and when there is a pyramid of objects always appearing together, shall we attach a method to the higher components (wool = shepherd.shear( shepherd.sheep[ n ] )) or to the lower ones (wool = shepherd.sheep[ n ].shear(), or rather wool = shepherd.sheep[ n ].get_shorn())? Does the shaving method logically belong to the sheep  (get_shorn) or to the shepherd (shear)?

For example, the proper placement of a ``dice'' wrapper function built around the system random generator is a matter of creed. From outsourcing it into a different module to implementing it separately in every object type, all things are possible and equally justificable.

The textbook example for OO programming -- a presentation or graphics program where a ``redraw yourself now'' message is sent to all the objects in memory upon receipt of a window event (for graphical_object in object_list: graphical_object.redraw()) -- emphasizes the advantages of the latter, but it is of fallacious simplicity. Actions which affect one shred of data only, like the redraw message, are not that frequent; most things happening inside a program establish some kind of relation between previously unconnected items of data.

Moreover, most real-life agglomerates of data are less clearly discriminable than a simple list or array of graphical objects. Apart from the problem with shear, does it make sense to place the sheep array directly in shepherd, or is it preferable to create an intermediate level shepherd.flock? Are there any attributes, modofications or accidentia which belong to the flock as a whole without affecting the individual sheep? In the Middle Ages, half a millenium of philosophical debates was wasted on this question, and the solution agreed upon in the end (Abaelard's) bears all the hallmarks of a silly compromise.

Human thinking is based upon the concept of an action flowing from a subject to an object; ever since Kant's times, the phrase ``The sun warms the stone'' has been used as the favourite example for this, and it was Schopenhauer who traced this back to the dependence of human thinking on causal connections: Observation 1 -- the sun shines upon the stone; observation 2 -- the stone gets warmer; causal connection -- the stone gets warmer because the sun shines upon it; (re)construction of an action -- the sun warms the stone.

This notion is therefore so dominant that even statements where no action is described are formed by projecting the content upon auxiliary verbs such as ``to have'' or ``to be'': Remus erat vir fortissimus, Remus was a hero -- the Latin version shows that a ``nominative object'' is needed for this projection. Still the ``active'' nature of the statement is there, and the thing may even be put into the passive voice, odd though that appears -- the normal Sanskrit form for expressing the past is by means of a passive participle: Ramena bhuto virah, literally ``By Ramah [was] performed the hero-being''.

OO programming, however, does not fully acknowledge this. In OO, the basic structure is reflexive, as in graphical_object.redraw(). It is the subject of the action whose state may be changed by the invocation of a method, not the optional object which may be passed as a parameter to the method! Thus, the common x.y(z) formula does not mean ``x does y to z'' but ``x is modified by y'ing z''. This must be kept in mind when dealing with OO.

Personally, I prefer a structure which emphasizes the predicate, such as wool = map( shear, shepherd.sheep ) and thus keeps apart things and actions. (Haskell type declarations were chosen to represent currying, but they also indicate the logical direction, even though Haskell rejects the concept of action: shear::Animal->Product and tend::[Animal]->(Animal->Product)->[Product].) Using this approach, shear may be passed as a functional parameter without the need for a subject. Who cares about the shepherd? Let him go to the pub as long as somebody will shear his flock for him. His state is not altered by the action (as he probably won't shear himself), so there is no need for him to be involved. It's the wool we are interested in.

In general, data should be considered as an attachment to code, not vice versa. Though being an OO language, Python partly takes this into account by ``defining'' variables only by assignment. In this respect, it is very different from -- and superior to -- C++ and Java.
**

Maybe this will be good as a bit of "selling ammunition", or at least to stimulate a few discussions...

Lookign forward to hearing from you,
   Ruediger Marcus Flaig

Am Dienstag, 3. Juni 2003 23:19 schrieben Sie:
> Hi Ruediger,
>
> Nice mail, I like the bit about orks ... :-)
>
> My latin/Italian is non-existent - I wanted
> to say "and yet it still sucketh" ...
>
> I entirely agree re: java C++. IMHO the *important* thing is
> total isolation between "things" and "pure message passing" - hence Erlang.
>
> The language for sequential computations is irrelevant.
>
> I build systems from "communicating black boxes". COPL etc *is* the point
> only achieved in languages like Erlang/Oz/Occam/PLITS
>
> cheers
>
> /Joe
>
> On Thu, 29 May 2003, Dr.Dr.Ruediger M.Flaig wrote:
> > Hi all,
> >
> > from my bit of Italian, I think it ought to be "Eppur suga" -- the Latin
> > -t is dropped in the 3rd person singular AFAIK, and it is certainly not
> > reflexive... it does not suck itself, that were recursion. ;-)))
> >
> > Now for something more serious... I think the basic sentiment we all
> > share is that Java sucks, and that C++ sucks. They do, and very badly
> > too, and it is annoying to see that they have become a kind of de facto
> > standard.
> >
> > I have used both (more than Erlang, I am afraid -- as a molecular
> > biologist, I have to deal with megabyte arrays, and that is not quite
> > what Erlang was designed for -- sinner repent -- well Ocaml is quite nice
> > too ;-) ), and I am equally fed up with the cobolesque boilerplate of
> > "private final static paralyzed karl.otto.gustav emil =
> > (karl.otto.gustav) ((egon.kasimir) foo.bar().blah[anything])" and the
> > orkish scrawls of
> > "#define n<m>(x,i,j) {*++(*x)->y %= (i>j)?&i--:--&j}", not to mention
> > memory leaks and, and, and... Maybe OO itself does not suck but a concept
> > without implementation is void.
> >
> > But I think we are missing the point. The important thing is not that OO
> > is an inferior concept but that FP (or COPL, if you please) is a superior
> > one. Erlang were still great even Stroustrup and Gosling had never come
> > near a computer -- because it enables you to be productive, to write
> > clear and concise code, to cope with errors and, last but not least,
> > because it allows reasoning.
> >
> > This latest thing is what I have really been missing. Erlang is a
> > functional language, so it should be possible to employ automatic theorem
> > provers and all that kind of stuff. Cummings wrote about ML: "We are not
> > trying to develop 'safer' programs by testing, but developing SAFE
> > programs by reasoning." This is a very philosophical matter. Let me say
> > that Java and C++ rely on induction, Erlang allows deduction, and Sir
> > Karl Popper has said the rest about that, decades ago. So are there any
> > theorem prover
>
> s for Erlang, as there are for Lisp and ML? Can we prove a program's
> correctness by reasoning? If not, let's do that!
>
> > The other point is that the power of Erlang's concurrency is often
> > underestimated by folks who are not interested in parallelism itself. I
> > am a complete layman to that field but I think that neuronal networks
> > would be a great thing do with Erlang. Has anybody tried this before? Are
> > there any projects in similar fields? Personally, I was attracted to
> > Erlang because I felt that simulation of complex biological processes
> > would be easy to implement. Imagine you have a microbe with some 4000
> > genes, each with
>
>  a state of activity and each influencing a couple of others. In Erlang,
> this would be straightforward... I met a guy who did the like and spend a
> year on that programming the basic mechanism in Java! So I think we could
> get away from that "Erlang? Oh, that's for telephones only" image.
>
> > Has anybody worked on this yet?
> >
> >
> > Skål,
> >    Ruediger Marcus Flaig
> >
> >
> >
> >
> >


Dr. Dr. Ruediger Marcus Flaig
Institute for Immunology
University of Heidelberg
Im Neuenheimer Feld 305
D-69120 Heidelberg
<flaig@REDACTED>
Tel. +49-172-7652946 
  | +49-6221-56-5402 
  | +49-6221-432963

_____________________________________________________________
Free eMail .... the way it should be....
http://www.hablas.com

_____________________________________________________________
Select your own custom email address for FREE! Get you@REDACTED, No Ads, 6MB, IMAP, POP, SMTP & more! http://www.everyone.net/selectmail?campaign=tag