Re: What is wrong with OO ?

[tbushell@fox.nstn.ns.ca (Tom Bushell)]

On 31 Dec 1996 06:54:51 GMT, clovis@wartech.com wrote:

>You're quite right.  Tansel is acting like quite a pretender on this one, and he 
>obviously doesn't know what either a Von Neumann machine is, or what a Turing
>machine is.  

Let's wait until he gets his article together before slagging him, eh?
Although he may be guilty of a bit of hyperbole, I have a hunch he may
be on to something - time will tell.


>A Von Neumann "machine" is really a recommended architecture,
>and really, there aren't many of them.  They feature regular instruction sets,
>with zero duplication of function, and all operations being orthogonal.  

As other postings have said, my understanding was that shared program
and data memory is the defining characteristic.


>None of this is really rocket science.  And it's never ceased to amaze me how many
>of the "hip" guys can't even define the basic terms.

Seems to be a problem with the field in general, not just a few hip
guys.  Terminology and concepts havn't stabilized.  Witness your own
statement about the "true" meaning of von Neumann architecture,
extended discussions about what OO "really" means, and so on.


>Assembler will ALWAYS be the most efficient language.  The more you abstract the
>problem, the more you "generalize" the solution to a given problem, the more you
>necessarily give up in efficiency.

Agreed, if you define "efficency" as "doing the most computation with
the fewest instructions".

>C takes a minimal 3x hit on integer arithmetic,
>10x on more complex stuff; and OO, because of the overhead interpreting where
>to send things, is 10x on top of that.

Saying that there is a 10x hit for using OO is a pretty sweeping
statement.  May be correct for a Smalltalk message send, which is late
bound.  But an early bound C++ call just requires one more indirect
jump through the vtable, so the performance hit is more like 3
_percent_ according to what I've read, which is trivial.


>I personally use all three in Smalltalk applications which involve a variety of
>disciplines.  Smalltalk handles the GUI, but engines in C and ASM are also required
>in some cases.  Any realtime requirements point to ASM, and any number crunching
>points to C most of the time (Assembler if the computation must be made in
>realtime, and be interruptable in mid-stream).

I agree 100%.  The huge reduction in development time for the 90% of
the system that doesn't need speed more than repays the extra effort
and complexity of a multi language solution.


>Smalltalk itself is not entirely Smalltalk.  It contains both procedural (often C), and
>frequently ASM routines at the kernel since no general purpose machine ever
>built comprehends objects -- all the underlying hardware knows about is basic
>arithmetic, compares, and jumps/branches based on flags settings.

As an aside, many Forth compilers are written in Forth.  The Forth
stack based virtual machine is coded using the Forth postfix assembler
for the target machine.  The result is a programming system that is
completely able to regenerate itself (wasn't that one of the
definitions of a von Neumann machine?)


>ASM is REALITY.
>
>>In this thread someone said assembler was "real" and higher level
>>languages were abstractions above that.  I always thought voltage
>>states/levels were real and that assembler was an abstraction of voltage
>>states/levels. 
>
>Elliott

Have to agree with Elliot on this one - assembler is just a textual
abstraction for the binary numbers that are computer instructions.
And the binary numbers are abstractions for voltages, and the voltages
are...it's elephants all the way down.

If you are saying assembler is the lowest abstraction we can program
in under normal circumstances, I agree.  (Although I wrote a Forth in
hex on a KIM-1, back in the bad old days.)


>It's a tradeoff, and if we want to represent ourselves as real computer scientists,
>and real computing professionals, it behooves us to be able to explain in clear
>terms why one paradigm is better, where it is better, and the details of why it is
>better AT A GIVEN TASK.

I agree, but IMO the field has a lot more maturing to do before this
will happen.


>We can get by without smalltalk if we must.  If we try to do without Von Neumann,
>there isn't such a thing as a working computer.

True for current computers, and one of the reasons I'm a little
skeptical about what I _think_ Tansel is saying  - the implication
that we need a whole new hardware architecture before we can benefit
from OO.

But he claims von Neumann himself was dissatisfied, and if there is a
much better architecture for CPUs, we can assume it will be built and
commercialized - eventually.

-Tom


----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------