[Edu-sig] More OOP bashing (& which metaphor is best?)

[Paul D. Fernhout]

I just came across these links (bearing indirectly on the value of
Python emphasizing both procedural and Object-Oriented Programming
support as a language good for beginners and experts):

See:
  "Object Oriented Programming Oversold!"
  http://oop.ismad.com/
Or:
  "Guide To Myths"
  http://www.geocities.com/tablizer/myths.htm

And:
  "Why I Prefer Procedural/Relational Over OOP"
  http://www.geocities.com/tablizer/whypr.htm
>From the last, for example: "It is my opinion that the division between
data and behavior in procedural/relational (p/r) applications also has
software design benefits. It allows a certain "contract" between the
database and the database user (application programmer). Contracts
usually have certain obligations and costs, but these costs are
worthwhile for the parties of the contract or else the contract would
not be entered into. The relational paradigm involves just such a
contract. If you follow your end of the bargain, then the other party,
the relational paradigm, will provide wonderful benefits. The
"limitations" required are not arbitrary, for they provide a powerful
intellectual rigor which is one of the greatest tools of modern software
technology in my opinion. Along with GUI's, relational technology is one
of the rare "wow!" technologies that is a fundamental leap forward in
software design. ... The contract of the relational paradigm basically
says, "If you put or keep your information (data) in a certain given
structure, then there are powerful and concise operations that you can
do on this information."  E. Codd, the inventor of relational algebra,
opened the world's eyes to a powerful kind of "math" (with some help
from more practical-minded collegues). This math can reduce complex
structures and patterns into relatively simple formulas, or "relational
math"."

Of course, one might argue relational databases are just well defined
objects... :-) But then the object paradigm starts to break dawn -- and
one is really thinking more in terms of "modules" then how "objects" are
usually discussed. As I previously wrote here (and on the Squeak list a
long while back):
  http://mail.python.org/pipermail/edu-sig/2006-December/007483.html
"Personally, one way my opinions differer from Alan Kay's in a deep way
is on his, I think mistaken, notion that an object (or a class) can have
any  meaning apart from the ecology of objects (or really classes) it is
 embedded in. I think there is a deep philosophical (and practical)
point  there which he is perhaps only slowly beginning to see. :-) But
it is reflected in the superiority of, say, Python's modularity in
practice  compared to early Smalltalks, that is, if you think classes
stand alone, then there is no need for a higher level of "module",
whereas if you think  classes need to be clustered to support each
other, than modules make a lot of sense."

Still, I think the more general issue, present even in AK's new
proposal, is how one can simulate the world by objects but one also can
simulate the world (perhaps more accurately, if with more effort) as a
set of fields defined by relations (or by any other method). Whether
such fields are best implemented procedurally or via OOP is another
question. Anyway, when one delves this, it gets murkier and murkier --
in part because people often confuse having a modeling layer of discrete
objects somewhere as meaning the models are all about Objects and OOP,
but there is no reason one cannot use objects to model other things
(fields) -- or even vice versa. Still, from a beginner point of view,
why should you have to get the metaphor of "objects" if what you are
interested in are "fields" (e.g an astrophysics simulation of particles
in an electrostatic gradient and/or gravity well)? I think the appeal of
APL based on arrays is in part the appeal of fields.

One thing that makes this all confusing to understand is the human mind
has a layer (or module) that models the complex real world in terms of a
simplified representation of "objects" (as I wrote in my undergraduate
thesis in 1985: "Why Intelligence: Objects Stability Evolution and
Model"). William Kent explored this in his book _Data and Reality_:
  http://www.bkent.net/
For example, by numbers, people are about 90% bacteria, but we generally
don't see other people as walking bacterial colonies. :-)
  "People Are Human-Bacteria Hybrid"
  http://www.wired.com/medtech/health/news/2004/10/65252
Yet if you want to understand some branches of holistic medicine (and
why using antibiotics might have lifelong health impacts) then you need
to think about people this way, as hard as it is.
  http://www.findarticles.com/p/articles/mi_m0NAH/is_2_32/ai_83316363
And then, if you want to understand bacteria, you have to see them more
as a vast worldwide supercomputer than isolated individuals:
  "New Science Of Metagenomics to Transform Modern Microbiology?"
  http://science.slashdot.org/article.pl?sid=07/04/02/2017249
So, as Plato's "Allegory of the Cave" suggest it is sometimes hard to
see past these shadows (objects) to realize that reality is something
fundamentally different (deeper, more complex, more interrelated) than
the simple parsing into objects we do routinely. [Plato's analogy breaks
down here though in that he still thought of *ideal* forms of objects,
whereas I'm more arguing against even ideal forms, except perhaps in a
statistical sense sometimes.) Seeing the world in terms of objects may
have enormous survival value to life forms with big brains, but that
does not mean it is completely accurate (even as objects being a useful
idea does mean there is likely some statistical truth there (e.g.
statistical clustering), in terms of a field of relationships).

Still, and I don't have it anymore, but about fifteen years ago I made a
list of about 20 reasons why (VisualWorks) Smalltalk was better than a
typical C++ (of the time) from a developer and maintainer point of view
-- intentionally not bringing in OOP specifically as a reason (although,
in retrospect, many of the benefits were enabled by OOP). Stuff like the
integrated debugger, the browser, the inspector, refactoring support,
garbage collection, the GUI library, edit/continue, and so on. Of
course, C++ now apes many of those features, but without the integration
or elegance.

Still, having explored relational programming (via Pointrel) I can say
both approaches (OOP and Relational) have their merits. The right tool
for the right job. Or in this case, a flexibility with metaphor, so "teh
right metaphor for the right job". Or, looking at it even more
abstractly, "the right mathematical abstraction for the right job". And
from that point of view, should not a goal of computer education (and
CP4E) be to have people able to handle multiple metaphors as appropriate
for the situation? Programming a digital thermostat might require
thinking in terms of one kind of metaphor, whereas programming the GUI
on your car smith require a different kind of metaphor?  Perhaps the
conflicts about "which programming language is best" really are just
obscuring the issue of "which metaphor is best" and the answer to that,
like when looking at a large library of fiction, is that lots of
metaphors are useful in the right situations, and only being able to
understand one kind of metaphor would mean you would not get very much
out of most fiction. So a programmer only capable of working within one
metaphor is not a very capable programmer. Still, if that metaphor is
very powerful, like with OOP, a single-metaphor programmer could still
get pretty far and do lots of useful things. And likely further than
simple relational programs.

Anyway, food for thought.

--Paul Fernhout