Xref: utzoo comp.lang.smalltalk:672 comp.lang.c++:1587
Path: utzoo!attcan!uunet!tektronix!tekcrl!tekgvs!jans
From: jans@tekgvs.GVS.TEK.COM (Jan Steinman)
Newsgroups: comp.lang.smalltalk,comp.lang.c++
Subject: Re: Re: OO debuggers
Message-ID: <3941@tekgvs.GVS.TEK.COM>
Date: 14 Sep 88 17:59:02 GMT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 95

<<jans@tekgvs.GVS.TEK.COM (Jan Steinman)>>
<henry@utzoo.uucp (Henry Spencer)>

<<C++... provides nowhere near the productivity nor capability (except in 
execution speed, the least important metric in the present "software crisis") 
of even a moderate Smalltalk implementation...>>

<Au contraire, execution speed is a major metric in the software crisis... 
because lack of it leads to otherwise-promising software tools being rejected 
as impractical...  Smalltalk's performance problems, more than anything else, 
have given it its reputation...>

This is close to what I was describing:

<<C++ has a lot of catching up to do, but it seems to be evolving strictly in 
the  incestuous C-Unix environment...>>

Smalltalk is rejected for its reputation, not for anything based in recent 
fact.  Most people who have seriously considered Smalltalk for projects, and 
then rejected it, have a slew of other problems with it, but they generally are 
willing to take a modest performance hit for what it buys them.  Let's look at 
a few cases:

Garbage collection: yes, it's a pain when it fires off in the middle of some 
critical code.  It's more of a pain when, through "programmer garbage 
collection" you destroy an object that still has references, or when unused, 
undestroyed objects fragment memory space, or when a project runs over because 
destructor conventions were not followed consistently, none of which happens in 
Smalltalk.  The solution is not to throw out GC as performance-costly, but to 
build better collectors, and to give users some degree of control.  Most who 
gripe at GC would be satisfied with some kind of "don't you dare interrupt me 
till I'm through with this stuff" directive.

Run-time binding:  in my opinion, any C++ application that does not use virtual 
functions is not object oriented, and those that do are difficult to design, 
and often lack the flexibility of true polymorphism.  In Smalltalk, the 
programmer doesn't even have to think about it -- it just happens.  By 
dispatching through function tables instead of truly implementing run-time 
binding, C++ gains only slightly.  Typical Smalltalk run-time binding enjoys a 
97% method cache hit rate, negating most of the arguments of those who claim 
run-time binding is a major performance bottleneck.

Byte-code interpretation: this is the one that makes C++ers laugh!  How dare 
anyone use a system that "wastes" so much time simply figuring out what it has 
to do!  However, look what it buys Smalltalk: incremental compilation (yes, I 
know there are other ways to do this, why doesn't Unix/C do them?) and true 
object-oriented control over the execution state.  It can be argued that the 
first (in combination with run-time binding) is a major source of productivity 
in Smalltalk -- you can change and run a method of a moderately sized 
application ten times in the time consumed by one C++ edit-compile-link-run 
cycle.  I don't expect those who's experience is limited to "traditional" 
debuggers to truly understand the enormous power the latter gives you: to carry 
on a dialogue with an execution state is much more than finding new ways of 
changing memory locations and breakpointing!

Hardware is getting faster and faster.  Let us be reminded that the first 
FORTRAN compilers were greeted with contempt by those who said they wouldn't 
produce adequately performing code.  "Adequately performing" is a relative 
constant in many, many fields, and the leaps in performance that hardware is 
giving us should be put to use reducing the software life-cycle cost.  If a 
spreadsheet that took two months to build in Smalltalk performs just as well as 
an identical one that took two years to build in C++, who cares if some 
interpreter somewhere is chewing up 15% of the cycles?  By emphasizing "the 
performance issue", people do stupid things like make benchmarks run fast, 
rather than making systems more usable.

The big win is an area that is receiving distressing little research or 
attention: hybrid systems.  "Smalltalk as a controller" is showing big success 
with the work of Dave Thomas at CMU and Dick Peskin at Rutgers, among others.  
Smalltalk appears to be ideally suited for rapidly assembling (an 
re-assembling) optimally performing "computational units", whether they be 
multi-processor nodes or snippets of assembly/C/C++ generated code.  PPS shows 
little interest in this area, preferring to "protect their users from 
themselves", while Digitalk has provided the hooks, but is too busy shipping 
orders to put it all together.  Tektronix is the leader here, but is 
unfortunately limited to Tektronix platforms through oppressive licensing.

<Let us not forget how C became a major programming language, while many 
prettier languages were forgotten, by being more practical.  C++ is "the next 
C" in more ways than one.>

And just as C was "a smart assembler" before it, C++ is simply providing a 
prettier face for the same set of problems that are causing software costs to 
go out of control.  I am not a Smalltalk chauvinist.  It is not without its 
problems.  I even happen to like Unix and C++.  What I argue against is the 
narrow-mindedness that many in the Unix/C community show for "other" conceptual 
models; such thinking keeps them from even considering the next set of 
problems.

(OK, I'd better say it: the above statements are my personal views only, and 
some of them most certainly do not reflect the views of Tektronix.)

:::::: Software Productivity Technologies -- Experiment Manager Project ::::::
:::::: Jan Steinman N7JDB	Box 500, MS 50-383	(w)503/627-5881 ::::::
:::::: jans@tekcrl.TEK.COM	Beaverton, OR 97077	(h)503/657-7703 ::::::