Tales Of The Old
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

The Old One, news:comp.object, 4.2.2002

I am of the "Old Ones". My years number sixty and one. I have spoken 
with "the machine" for nigh over forty years. Think not that my 
knowledge is outdated and I do not know the new ways. I live by the 
consultants' sword and I can UML with the best of them.

The machines are simple things. They can but Add, Subtract, Multiply, 
Divide, Compare things and move them around. Just six basic things, that 
is all (and for those of us that know the metal, they can really only 
Add). Much is spoken of the advances in our craft over the years, but I 
say to you that little has changed. The machines still do only the same 
things they did forty years ago, nothing more. True, it is on a much 
grander scale and with much more speed, but these are things of the 
realm of hardware not software.

The basic building blocks of our trade, the data structures, the 
processing algorithms were all invented many decades ago. Nothing really 
new has come forth in many many years, and yes, this includes all of the 
land of OO. Open the covers of any modern day application, compiler or 
tool and you will find only the building block of old.

How then, have we come to the place that we are today? A discipline 
filled with "isums" and "ions".  A discipline where even the simplest 
and most basic of definitions cannot be agreed upon.  The academics have 
written volumes about our craft. They have attempted to define it, to 
reduce it to equations and processes. Those of power and of management 
rank have attempted to control it, to schedule it, and to somehow mold 
it into a manufacturing like process that they can understand.  Let us 
also not forget those of Marketing. They are the ones who fuel the 
economic engine of our craft by re-inventing and re-naming that which 
already exists into something which will be perceived as new by those 
gullible enough to seek magic solutions.

Now that I have raised your eyebrows and invoked the wrath of you that 
consider yourselves experts in this field, let these words fall upon 
those of you that are followers of the Cult of Objects.

The basic premise of OOD is that by mapping the application problem into 
a model that simulates real world objects, the problem will be better 
understood and thus easier to implement and maintain. This sounds like a 
good idea and there is truth here if your objective is to truly model 
the problem. However, if you objective is simply to transform data from 
one format to another, then the solution is instead overly complex. 
Modeling and simulation are or for things like 3D action games, flight 
simulators, etc. The majority of real application programs are but 
simple data transformers. We have the data in one form and need it 
translated into another. Data is like energy, it can neither be created 
nor destroyed, only transformed. Except the time I wiped out an entire 
bank of 3330s, that time it was pretty much destroyed!

OO implementations require more machine resources than procedural. 
Anyone who tries to tell you that this can be optimized away by wise 
compilers knows not the metal. It takes extra machine cycles to call 
code from within an object. It takes extra cycles to process inheritance 
rules when birthing a new object, and that is just the tip of the OO 
performance iceberg.

But may that as it be. These arguments are old and have been debated 
without bounds here and many other places. I lay before you now other 
food for thought on the use of objects.

Object Oriented Design stifles creativity. History repeats itself. This 
is never a more clear truth than in the field of software design and 
engineering. Each time we have automated a new field by applying 
computer technology, we have started with emulation and modeling. We 
attempted to recreate and reproduce the process as it was presently done 
manually. We created user interfaces that were familiar in vocabulary 
and actions to the existing manual process. How can this be bad, you 
ask? It sounds like a logical approach to me. The answer is simply this: 
we usually discovered, after some pain and failed attempts, that the 
computer was not very good at replacing what the person was doing 
manually. The computer makes a lousy drafting table, also a lousy 
typewriter, etc. It was not until we applied the unique power and 
abilities of the computer to the domain problem that we achieved 
success. This usually involved going outside of the real world model and 
thinking abstractly about how the computer can transform and manipulate 
the domain data in new ways to help the user. Only then did we achieve 
the full potential of the man-machine interface.

The human being is not Object Oriented. We think in terms of tasks and 
actions, results and outputs. We use objects, but only as a means to and 
end. I do not go into my workshop, pick up a hammer and then try to 
decide what I could use it on. I go into my workshop with a task in 
mind, to build a table, and then I choose the tools to make it so. If my 
computer is my tool, why should I be constrained by real world mechanics?

Over time our computer automation of tasks evolve into useful ones and 
experience brings the machine into its proper role in the process. But I 
say that OOD obstructs rather than encourages this process.

Enough for now, it is time for me to go. I must take my medication and 
it's time for I Love Lucy. I leave you with these thoughts:

It can only add, subtract, multiply, divide, compare things and move 
them around, nothing more.

Antwort von RobertCMartin, 07.02.2002

>I am of the "Old Ones". My years number sixty and one. I have spoken 
>with "the machine" for nigh over forty years. 

Good.  Then you and I can probably talk.  

You've probably used jump tables in your life.  I imagine you've
written device drivers that applications accessed through indirect
pointers.  You may have burned reusable libraries into ROMs that had
to be accessed by jump tables.  You know how powerful jump tables are
for decoupling one module from another.  You also know what a pain in
the arse they are to maintain and get right.  

OOPLS are languages that manage jump tables.  That's really all they
add.  All the fancy syntax, and high falutin' vocabulary comes down to
that one thing.  OOPLS make it easy to manage jump tables.  This means
that we can cheaply employ the decoupling power of jump tables without
incurring the cost.

Structured Programming is discipline imposed upon transfer of control.
i.e. don't sprinkle goto statements around in your code.

Object Oriented Programmign is discipline imposed upon indirect
transfer of control.  i.e. don't sprinkle jump tables around in your
code.

>The basic premise of OOD is that by mapping the application problem into 
>a model that simulates real world objects, the problem will be better 
>understood and thus easier to implement and maintain. 

That's the marketting baloney.  The poor sods had to come up with
something that sounded good.  Try to explain jump tables to
non-technical mannagers who hold the purse strings.  After you try
that a few times, real world modeling starts to sound pretty good.
But it's a crock.  It says nothing about what's really going on.  

>OO implementations require more machine resources than procedural. 

Some OO languages require more machine resources than some procedural
languages.  But I can write perfectly good OO code in C++ that is just
as efficient, in both time and space, as good procedural code written
in C. 

>Anyone who tries to tell you that this can be optimized away by wise 
>compilers knows not the metal. It takes extra machine cycles to call 
>code from within an object. 

True.  But in a good OO program, those extra cycles are only employed
at a time when the equivalent procedural program would have been
executing an 'if' or 'switch' statement.

>It takes extra cycles to process inheritance 
>rules when birthing a new object, and that is just the tip of the OO 
>performance iceberg.

Yeah, and sign extension in C takes extra cycles on some machines too.
We learn our langauges, and we learn how to control what they do. 

>Object Oriented Design stifles creativity. 

Slavish reliance on modeling the real world stifles creativity.
Object Oriented Design has nothing to do with that.  Object Oriented
Design is the practice of employing jump tables to decouple modules.

>The human being is not Object Oriented. 

You got that right.  More specifially, object oriented design is not
"more natural" to human thought, is not "what we did in kindergarten",
does not have "cognitive resonance".  It's just fancy syntax wrapped
around jump tables.  

>It can only add, subtract, multiply, divide, compare things and move 
>them around, nothing more.

And even those things are result of the yin and the yang in proper
combination.


Siehe auch:


KategorieOop
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 5. Juli 2002 8:09 (diff))
Suchbegriff: gesucht wird
im Titel
im Text