The reason WHY OO sucks

[Luke Gorrie]

See also http://www.elsewhere.org/cgi-bin/postmodern/

Cheers,
Luke *ducking!!*

"Dr.Dr.Ruediger M.Flaig" <flaig@REDACTED> writes:

> 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