Re: What is wrong with OO ?

[Tansel Ersavas <tansel@rase.com>]

> > >The problem is bad coders.  Those of us who have been around for 20
> > >years have
> > >long ago noticed that 10% of the world's programmers could do 100% of
> > >the work
> > >and not have it spontaneously collapse, by doing it right the first
> > >time.

I have similar observations as well. However, I would think that would
be only one of the problems, and the approach we have in teaching
systems development has a great impact on these people.

> > >This has nothing to do with paradigm. It has everything to do with a
> > >quality attitude
> > >and the ability to conceptualize.

IMO that has a lot to do with paradigm. However, I won't have enough
time to explain it now. 

> > >What OO will do is help wash some of the dross out of the coding pool.
> > >
> > >But I've done enough Smalltalk in the past year to know that I can write
> > >just as
> > >sloppily in Smalltalk, and make even bigger errors, harder to correct,
> > >as I code
> > >my way along, without a previously completed design, as I can with
> > >anything.

That is exactly true

> > >If anything, Assembly Language is easier to fix, precisely because the
> > >procedures
> > >are more amenable to "redesign" and "reuse" than a single hirearchy.
> > >

I am not sure about that. I dusted out some of the games I wrote in
1982. I can't seem to easily grasp them, maybe because I completely
forgot Z80 assembly language, or maybe I don't have a Z80 machine or a
decent emulator to run. Even with an emulator, I would have had to
rewrite direct screen manipulation modules, keyboard modules and sound
modules. 

> > >>Turning a blind eye on Today's problems will not get us anywhere. First
> > >>of all, we should admit that we have a problem, then find a solution to
> > >>it. We ALL contribute to lost billions by ignoring what's happening
> > >>around us. 
> > >
> > >What problems? The lack of good software is due to the lack of good
> > >education,
> > >high levels of intelligence distributed all around in the people doing
> > >the work, and
> > >so on.  People do programming.  OO CAN be easier, in something like
> > >Smalltalk,
> > >because there is so much framework for grunt stuff like the GUI.
> > >
> > >So I greatly differ with your take on things here.

The problems I am mentioning about are collapses of big projects with a
typical 100 million waste per big project. These companies DO have very
good people, because they can afford them. And yes, there are usually
100s of people of which at least 10s are good. 

In the very beginning of the thread, I had four areas as the source of
the problem. Other three are vanished, and I have to defend only one,
namely OO approach. However, in my previous postings I stated people,
organizational structure, techniques and tools as the sources of the
problem. 

I do not think that we differ greatly, from what you see it looks like I
point procedure orientation as the only cause, which is not correct.

> > >>> Why is it that when anyone comes along with new techniques that represent
> > >>> a useful incremental advance in our knowledge in this area (e.g.
> > >>> functional programming, proof of correctness, your-favorite-fad-here)
> > >>> they feel compelled to hype them like this with the approach
> > >>
> > >>OO is not an incremental advance. It has started and continued that way,
> > >>because SIMULA was an extension to Algol, and some of the most dominant
> > >>languages are extensions of procedure oriented languages. This does more
> > >>harm than good to OO. Many professionals I have talked to told me that
> > >>until they made a switch ( or some of them call it a "click") they
> > >>weren't able to benefit from OO a lot. It is more difficult to have that
> > >>"click" if we have to work in an environment and a language which is
> > >>basically an OO extension to a procedural background. 
> > >>It is true that every newcomer announces that it is a significant
> > >>advancement over procedure orientation. This is because people are
> > >>worried about the current paradigm, and they in search for a better one. 
> > >
> > >Smalltalk and other OO paradigms are an unmitigated disaster at certain
> > >kinds
> > >of problems.  Ask me about Modified Midpoint integration or, say,
> > >adaptive Runge-
> > >Kutta under Smalltalk.  We give up as much as two orders of magnitude in
> > >computational efficiency.  The more a tool does for you, the more it
> > >also does
> > >to you.

The numerical number crunching problems are perfect problems that a von
Neumann machine is designed for, so can be handled quite elegantly with
procedural languages. They are well defined algorithms that take up a
very reasonable number of lines of code. However we need Runge-Kutta in
our real life even less than we need our calculator. I use Smalltalk
extensively, but revert back to C or even assembler when I need
procedural number crunching, and offer these as DLLs. On the other hand,
a simple ORB is reasonably trivial in Smalltalk, but if you want to
develop in any procedure oriented system, even in C++, it takes a lot of
time and effort.

I think people tend to see black and white. When I sent my first replies
to this thread, I made my postion clear by first defining the von
Neumann machine and what it was initially designed for. Anything that is
suitable to this initial design purpose should be handled by the
procedural approach, which IME&O is just about 10% of all our problems.
Anything beyond that is an abuse of the initial design purpose, and
requires much greater effort to get the same work done in a procedural
environment.

> > >
> > >What is being complained about here is that you treat OO as though a
> > >pure OO
> > >language "gives" all this good stuff without a price.  And, in reality,
> > >the price is
> > >quite high.

If you are talking about 20MB image Smalltalk systems, or 80MB Borland
compilers, I tend to agree with you there. They could have been done
simpler, and less complex. There is also another price that I will
mention later.

> > >>> The trouble with such hype is that inevitably it does not deliver, and then
> > >>> there is a danger of throwing out the baby with the bathwater and
> > >>> discarding what is useful along with the hype.
> > >>
> > >>OO as is now, is a struggling, and not much appreciated figure around.
> > >>It has its troubles, but they are slowly being ironed out. Yes, there
> > >>may be a short term backlash against OO, it may even go back a couple of
> > >>years. This is not important. It will come back, and will eventually
> > >>dominate.  
> > >
> > >I don't find anything "struggling" about using VisualWorks or IBM's
> > >VisualAge on
> > >Windows, OS/2 or OSF/Motif platforms -- they are basically just
> > >extentions of
> > >GUI paradigms built on top of Smalltalk/80 to begin with, so they are
> > >quite
> > >natural and straightforward to use -- ONCE ONE HAS CRACKED INTO THE
> > >HIREARCHY.
> > >
> > >The chief complaint I have about OO is that one has to learn a
> > >hirearchy, and one
> > >which is in the general case sloppily and amateurishly documented,
> > >instead of the
> > >better understood and generally much better documented procedural
> > >library.

It parallels my observations that the most difficult part of learning
OOP environments is their class hierarchy. Our company is working
towards visualizing these class hierarchies that in our experience
increase the learning curve no matter what other people say about
visualization. 

> > >This inferior documentation is, in my view, the reason for OO's lack of
> > >popular
> > >success.  It is, much as you are displaying here, more of a religion for
> > >its 
> > >adherents than it is regarded as what it should be -- a convenience
> > >tool.

I think it is a misunderstanding that I take OO as a religion. However,
in my position after observing how much better a decent OO approach is,
I see current defenders of the "existing system" much more religious
than I can ever be. In our company, we do not only practice OO, we also
experiment heavily with neural computing, genetic programming and fuzzy
logic, and use them in projects. OO has its shortcomings, but only one
of these shortcomings namely number crunching can be remedied by a pure
procedural approach.   

There are certain very serious problems though. First of all, people
don't even know why do we program the way we program, and think that
must be the right way to do it. I first wanted to indicate that by
pointing to the birth of procedure oriented programming, and I raised
the voice of its inventor to the dangers of using it at wide scale. 

> > >There is nothing OO can do that pure object code can't do.
                                          ^^^^^^
Was that ment to be procedural? If so, it is true. In fact it is being
done everywhere, everyday. However, there is a price that we all pay.
Again I'll explain in my posting later.

> > >All we're doing is adding the hirearchy to raise the level of
> > >abstraction, so one
> > >doesn't have to spend as much time fussing with daily details.
> > >

I will explain one very important difference between PO and OO approach
after the new year. I'll prepare and send a post when I have time. 

> > >>> The fact of the matter is that there is NO giant shift of paradigm involved
> > >>> here, despite what anyone says. Just look at the OO programs that people
> > >>> produce. They are not radically different from conventional procedural
> > >>> programs, and one would not expect them to be.
> > >>
> > >>Unfortunately, many OO programs that people produce are produced by
> > >>people who are learning. They will be better and better, the gap will be
> > >>larger and larger, and differences will be more and more obvious.
> > >
> > >Duh! This is arrogant nonsense, sir. OO cannot and will not make a case
> > >for itself
> > >until it can demonstrate to the average working programmer something in
> > >the way
> > >of return for the struggle to learn the hirearchy.

I could not possibly agree with the "arrogant nonsense" bit but the rest
is true. If you can see that learning the class hierarchy quicker can
accelerate the results, it is very positive. In fact this will be an
important area, but there are more, again I will explain in my upcoming
post. 

> > >>People have short memories. A very similar sort of discussion with
> > >>similar tones was done when first high level languages were introduced.
> > >>Proponents of machine code and assembly languages said, this new
> > >>paradigm was nothing new, just a bigger, bulkier way of doing the same
> > >>thing with speed penalties, it was not practical, people would never
> > >>program with them in masses, etc, etc. Now we see everything has settled
> > >>down, there are still people write code in assembly and nothing else,
> > >>however they are the minority.
> > >
> > >Yes, Assembler is the minority.  And as a result Microsoft Word wants
> > >120 megs on
> > >a disk, where WordStar lived comfortably in 64k, code and data both. 
> > >Word does
> > >very little more.
> > >
> > >Seems we were told the truth to begin with, eh?
> > >
> > >Word barely runs in 8 megs of RAM.
> > >
> > >You started out talking about waste.  Why 8 megs instead of 64k?

This is one of the kind of waste I am mentioning. I hope that you are
not claiming Microsoft uses OO to create Word. No way! The entire
Microsoft suite is a good example of how procedure oriented systems can
get out of control. 

If they had used a true OO approach from their operating system on, they
would have a much leaner system with a component architecture, and very
high degrees of reuse.

> > >We have some differences of opinion here.

And it is very healthy, we can learn from each other, and enlarge our
horizons. Without differences of opinion, the world would be such a
boring place. 

> > >
> > >Regards,
> > >
> > >Frank


> 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.

I don't really think that you need to know assembler to develop good
compact systems. In fact, we recently developed one of the most useful
visual development tools in existence. It is written in Smalltalk, and
developed in record time. The SLL of our VSE version is under 300KB
before compression. In fact, there was a debate in our company that if
we distributed our product in one floppy, nobody would take it
seriously, there were serious suggestions to bump it up to offer in
several floppies or offering a CD-ROM version only.

There are two types of waste we are mentioning here: 
1) The time and resources required to develop and maintain that system
2) The hardware demands of that system

By far the first item has the biggest impact. If the trends go like they
have been going in the past ten years, we will have about half of the
world's economy chewed by our blown computer costs of which about 75% or
more will be software development and maintenance costs around 2030
(down from 5% of the world economy in late 80s). Any savings we start
making now will have a huge impact on our future. 

The hardware demands of the systems also add to the waste, through to a
lesser degree. I will write about these when I prepare my post about the
subject of this thread.

Please hold on to your questions and objections till I have time to
prepare my posting, so that you have a whole perspective of what I am
talking about, then I will gladly accept any flames, as well as positive
comments. Taking out one statement I say and flaming it out of context
doesn't do much justice.

Kind Regards
Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------