Re: What is wrong with OO ?

[clovis@wartech.com]

In <32C43AC8.24E2@sn.no>, Tore Lund <tl001@sn.no> writes:

>Yes, why? The most important reason is that most programmers don't know
>assembler or bother to learn it well enough to write decent code in it.

Most "programmers" don't bother to learn ANYTHING well enough to write well in
it.  With 20 years of C under my belt, I'm still asked to write snippets when I go
see a consulting client, because most of those who have been doing it for a while
write really atrocious C.  The same is true of assembly language -- people will
ask to see a snippet to see if one has just done it, or really knows what is going
on.

>You don't agree, of course, but the point here is is that the 64k
>program written in assembler will still be < 100k when written in C.
>There is no need for "code bloat" on the scale of 8 megs for
>maintainability purposes.

Well, not under 100k.  I typically find that, because of the need for "generality" in
C, 64k of assembler -- by someone who is really hot -- turns into about 256k of
C.  About 4 to 1 -- simply because the C code has to be so generalized, and the
assembler can really tune-down by being highly algorithm specific.

The more general the assembler, the less the difference, of course, until the sizes
become truly equivalent.  The real deal with Assembly Language is tuning that
code so that one exploits the instruction set, executes many fewer instructions etc,
which is mostly a matter of concern in realtime, or OS kernels, or diagnostics, where
one has to sort of do it all oneself.

Paradoxically -- and this really is a paradox -- Smalltalk seems to be smaller and
faster both when dealing with a GUI.  Minimum size on my VA applications, the really
small little demo things, is about 1.8 megs.  But it doesn't grow much unless one is
throwing the whole kitchen sink at things.  And the debugger etc etc and the whole
runtime development environment only occupies about 15 megs on disk including
a de facto text processing system, all sorts of graphical widgets, and some very
complex connection and self-maintainance code.

Compare this to, say, the Watcom C++ compiler which, to support all environments
and stuff, occupies 380 megs on a secondary drive.  I get Windows 3.1, Windows
95, Windows NT and OS/2 for about 35 megs under VisualAge -- and more and
better Windows and OS/2 than I'd get under any other system.

And, generally, I seem not to have any performance hit (perhaps because I'm clever
enough not to execute smalltalk code every time a variable changes).

OO can be wonderfully effective.

I can't figure out what they're doing in Word that takes 8 megs.

And herein is the danger of the Ultimate Procedural Model (getting back to OO
paradigms).

In Procedural, one builds a procedure for each action. Each procedure is separate,
and shares nothing with everything else.  Voila, an 8 meg "word processor" which
could probably be done in half that with OO, and probably run more quickly besides.

This is why code re-use is so important in a design.  Generality saves space, and
very often, a good deal of time as well.