Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!magnus.acs.ohio-state.edu!csn!ccncsu!purdue!news.cs.indiana.edu!samsung!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!bloom-beacon!eru!kth.se!sunic!mcsun!ukc!mucs!logitek!hrc63!mrcu!paj
From: paj@mrcu (Paul Johnson)
Newsgroups: comp.object
Subject: Re: The Emperor Strikes Lethe
Message-ID: <890@puck.mrcu>
Date: 9 Apr 91 09:39:08 GMT
References: <43.UUL1.3#913@acw.UUCP>
Reply-To: paj@uk.co.gec-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, UK
Lines: 230

In article <43.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes:
[Brief summary of events wrt his `Doctor Dobbs' article]
>1) Where's the evidence?
>
>Some is starting to come in.  OOP seems to make writing code a little easier.
>It certainly gives us the opportunity once again to rewrite everything and
>this means job security for programmers.  About every 10 years in programming
>we have to change syntax and OOP is the change for the 90's.  OOP does seem
>to be harder to debug, harder to test, and harder to maintain when the
>maintainers are not the developers.

Umm.  Can you provide references?  How was complexity measured?

One of the points made earlier on this group is that SLOC seems to
stay constant across languages.  The difference is that a given
problem seems to need fewer SLOC in an OOPL than in conventional code
and that changes in the OOP version are easier.

You say we have to "change syntax" about once every 10 years.  I
assume the previous changes were HLLs and structured programming.  Do
you write everything in assembler?  Fortran?  Do you feel that HLLs
and structured programming have not been useful?  Maybe this change
will be useful as well.

>2) What is an object?
>
>There seems to be general agreement on what object classes and instances
>ought to be in theory but practice is something else as witness the debate
>over my definition of an object.  There are still a lot of new words being
>invented for old ideas.  An object class is a coding form or an 029 keypunch
>control card and an object instance is a tab card.  And, yes Virginia, tab
>cards did inheritance. (What? You don't remember the 029?)

I think the argument was more on what your term `lexical closure'
meant (don't you know what it means?  Down the pub, we talk about
nothing else...)

In the OO paradigm, classes inherit, not instances, so I cannot see
that your tab card analogy is meaningful.  Anyway, we are talking
about describing behaviour here.  All you are saying is that objects
are partly data structures and data structures are not new, which we
know.

>3) What's the cost of OOP code reuse?
>
>We still don't know mainly because we're seeing about the same style and
>level of reuse of OOP code as we do with non-OOP code.  Everybody and his dog
>has done a C++ string class.  After 10 years of Objective-C there are still
>just two Objective-C IC Packs.  We still mostly copy source code, hack and
>go.  Unfortunately, there is still enough slop in the definition of the most
>widely used OO language, C++, that getting one C++ compiler to accept what
>another will pass is a large problem so even classical reuse is harder in OOP
>land.

This is because C++ is a brain damaged language.  Go look at Eiffel or
Smalltalk.  Objective-C I do not know about.  Its used a lot less than
C++, so there is probably not much call for new IC packs.  I expect
that companies using Objective-C have reused their own code though.

You may case-and-paste source code, I do not.  I gave that up when I
started OOP.

>4) How does one combine object heirarchies?
>
>One big hierarchy is still the only way to get objects to communicate within
>the rules of the game since the whole point of hidden internal structure is
>to make communication with "outsiders" impossible.  On the other hand, there
>are a growing number of practical work-arounds ... friend objects, neighbor
>objects, significant other objects, passing acquaintance objects, etc.

How do you mean "combine object heirarchies"?  Are you complaining
that OOP languages do not let you break encapsulation?  Sure, thats
the idea and it is a Good Thing because it reduces complexity.  If
that is not what you are complaining about, then what is it?  What do
you want to do?  If you want generics and multiple inheritance then go
look at Eiffel (yes, I am an Eiffel partisan)

>5) How does one tune an OO program?
>
>Well, the way you tune any other program.  The program structure itself has
>to absorb information about how it is being used.  Since OO programs are
>bigger and slower because so much of the development scaffolding is left in
>the runtime image more of this usage information has to be put into the
>program.  Thus, the complexity of the program increases due to programmer
>laziness.  Of course, since increased complexity means more programmers and
>job security for existing programmers the reward for this laziness is
>continued employment.  Nice scam.

Hang on a minute, what "increased complexity"?  Where did that come
from?  You seem to be saying that because OOPLs "keep development
scaffolding" in place (and hence provide flexibility and avoid
complicating the program itself with details), tuning requires more
hard-coded details in the source of the program.  Surely not.  A
structured language program would have those details hard-coded into
the program in the first place (rather than in the `scaffolding').
Fine if the designer has guessed right when specifying performance
enhancing details, but bad if s/he guessed wrong.

>6) How does one manage an OOP development team?
>
>Very carefully and very closely.  Since adding new code to an OO system can
>change the behavior of (i.e. break) old code every programmer essentially
>needs to know the whole system in order to add code to it.  This is
>particularly the case if polymorphism is used since each programmer has to
>understand and build on the puns being perpetrated by all the others.

"Very carefully and very closely" i.e. the same as ever (see the TOOLS
91 on Hewlett-Packards experiences with OOP).  "...every programmer
essentially needs to know the whole system..." WRONG.  That is what we
are getting away from.  When using a class, one only needs to know its
interface (can you say "encapsulation is a good thing"?).  When
creating a new class by inheritance one only needs to know about its
ancestors.  As long as the new class honours the old classes
interfaces, polymorphism is safe (Meyer's concept of Software
Contracting).

>7) Do OO programs coexist?
>
>Nope ... C++ objects can't inherit from Eiffel objects; Loops objects can't
>inherit from Smalltalk objects.  Each OO technology is a programing bunker
>world unto itself.  This is true in practice only, of course.  In theory the
>world is always exactly as we wish it to be.

No, not even in theory.  We knew that.  So what?  Most languages
(interpreted ones such as Smalltalk mostly excepted) have C language
interfaces).  If you REALLY need to do it, you can build wrappers
around the modules in the other language and carry on from there.  If
you have a class library in a given language and want to enhance it,
it is better to do it in that language.

Of course, you can always use the existing libraries in other
languages via C language interfaces, although it is certainly not easy
or clean.  How is this worse that existing systems?  Ever tried using
X from Pascal?

>8) What are the consequences of persistent state?
>
>Mostly it makes testing a lot harder and a lot more unreliable since every
>possible combination of retained state must be checked.  But then, heck, an
>object-oriented program is so clean and clear that we don't really need to
>test it so who cares how hard it is, right?  Have you heard of the Parnas
>test?

No, I have not heard of the Parnas test.  Why is this a problem?  All
non-trivial computer programs have state, and it is necessary to work
through a large number of state transitions to test them properly (it
would be nice to test every possible combination of existing state,
but I want to finish before the heat death of the Universe).
Persistent state does not change any of this, it just means that the
programmer does not have to design, write, test and debug code which
saves and restores data structures.

>9) Can you get the development system out of the production system?
>
>Nope.  The uniform response of the OO community to the runtime overhead
>problem is "buy a bigger machine" or, in translation, "the hardware guys will
>have to save our butts again".  It seems to come as a shock to OO programmers
>that the folks buying these machines expect to be the beneficiaries of the
>hardware curve not the programmers ... afterall it's their money.  People who
>buy cmoputer to solve their problems don't expect the curve to be eaten up
>(and then some!) by having to constantly slog through leftover
>development-time scaffolding.  (Do you know what happens to surgeons who
>leave the tools of their trade inside their patients?)  OOP imposes a runtime
>tax that end-users aren't interested in paying even with weak excuse that the
>tax pays for more frequent updates since it makes maintenance easier.
>End-users don't want more frequent updates; they want it right in the first
>place.

Actually, it depends on the language.  C++ has no development system
overhead apart from virtual functions which are not optimised out of
the run-time system.  Smalltalk is an interpreted language for
prototyping, so this is not a problem.  Eiffel is currently in between
but improving.  Note that while with C++ the language is improving, in
Eiffel the implementation is improving.  There is no reason why one
day Eiffel-generated C code should not be as tense as hand-coded C.

>The OO community will be forced to discover that software consumers won't pay
>development-time taxes at runtime the same way the Lisp community did.  If
>you write your product in some OO language, I'll come out with a competing
>product in written C or maybe even assembler, give all those cycles back to
>the customer, and whip you in the marketplace.  I might thank you for
>defining the product and opening the market which I understand you did by
>using OO technology.  But a thank you and a cloud of dust is all you'll get.

It depends on the application.  For large volume apps on PCs you have
a point.  Hand-coded C can be made more efficient than
Eiffel-generated C at present.  That will change.  For small volume
stuff, the extra cost of coding in C or assembler makes it cheaper to
buy more computer.  If your high speed assembler product costs 10-100
times as much as my Eiffel product but runs only twice as fast, people
might well buy mine, especially if they only run it a couple of times
a day.

>In closing, I note that a non-upward compatible version of the most popular
>OO language, C++, is due out "real soon now".  After 11 years of trying C++
>still doesn't have a stable semantics.  This, more than anything else,
>convinces me that OOP still isn't ready for production use ... unless, of
>course, your boss still thinks paying her programmers for constantly changing
>the syntax of her code is progress.

Like I said earlier, C++ is brain-damaged.  Do not tar all OOPLs with
the same brush.  An improved version of Eiffel is also due out "real
soon now".  Most of the changes will be syntactic improvements and a
script will be provided to convert from Eiffel 2 to Eiffel 3.

>There is very little really new in OOP.  As I indicated above, classes,
>instances, and inheritance go back to tab card decks of the 1940's.  Lexical
>scoping was used in Algol in the 1950's.  Polymorphism is found in Fortran 0.
>Even decomposition by type, which Piercarlo Grandi says is the basic idea of
>OO, can be found in the programming language, database, and graphics
>literature of the 1960's.

Simula 67 was the first generally available OOPL (I think).  Sure, we
know its not new.  The recognition that these techniques are of
general use is new.  See the interview with Meyer in one of the back
issues of JOOP.  I will ignore that bit about card decks, since I
already pointed out the fallacy.

OOP is a paradigm shift.  As such it subsumes existing paradigms (such
as structured programming and functional decomposition).  It does not
replace them.  We still need programmers, but OOP will make those
programmers more productive.

[Final paragraph of rhetorical questions deleted].

Paul.
-- 
Paul Johnson                               UUCP: <world>!mcvax!ukc!gec-mrc!paj
--------------------------------!-------------------------|-------------------
GEC-Marconi Research is not 	| Telex: 995016 GECRES G  | Tel: +44 245 73331
responsible for my opinions.	| Inet: paj@gec-mrc.co.uk | Fax: +44 245 75244