Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!pasteur!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.c++
Subject: Re: Current O-O Languages as Software E
Message-ID: <77300015@p.cs.uiuc.edu>
Date: 14 Nov 88 16:45:00 GMT
References: <5155@thorin.cs.unc.edu>
Lines: 100
Nf-ID: #R:thorin.cs.unc.edu:5155:p.cs.uiuc.edu:77300015:000:5671
Nf-From: p.cs.uiuc.edu!johnson    Nov 14 10:45:00 1988


bs@alice.UUCP (Bjarne Stroustrup) answered 
coggins@retina.cs.unc.edu (Dr. James Coggins) with

>Alternatively we could use the trick of never allocating class objects on
>the stack. This is the strategy of Simula and most of its decendents.
>The snag is that if we did that we would incur an overhead of two memory
>management operations per function call and the cost of indirecting every
>access to a class object. Measurements on Simula indicates that this cost
>is at least a factor of 2 in run-time. Most of Simula's decendents pay
>an even higher price. Accepting this overhead would imply giving up large
>application areas to C, assembler, and Fortran. C++ was specifically designed
>to preserve efficiency in this area. The apparant cost is recompilation time.

I don't believe this.  The reason is that the mature C++ systems I have
seen allocate very few "class objects" (why aren't these just "objects"?)
on the stack.  Almost all are allocated dynamically.  Procedure calling
takes a fairly small percentage of time, especially when low-level
functions are in-lined, so the factor of 2 seems way out of line. 
The cost of indirect access to these objects is repaid by the elimination
of copying them later.

> > 2. Smalltalk-like languages are better tools for developing small
> > programs because of their massive built-in class libraries and their
> > more flexible (later, dynamic) binding which allows polymorphic types. 

>Again I must disagree. Of course you can throw a small Smalltalk program
>together to do many things that would be painful to build from scratch in
>C++. However, the massive libraries and the wonderful program development
>environment of Smalltalk is not something that C++ lacks because of some
>inherent defect. Rather, Smalltalk is about 10 years older than C++ and
>have had something like 100 times more effort and resources lavished on
>its environment and libraries.

I understood Jim Coggins to be saying that he thought that C++ DID have an
inherent defect that prevented the large class libraries from being created.
I don't really understand what it is about C++ that he thinks causes this,
nor am I convinced that C++ has any fatal errors in this regard, but that
was his claim.

My experience is that Smalltalk is better for prototyping a design, but
that once it is finished it doesn't matter that much which language you use.

The Smalltalk's that are available now have class libraries that are little
changed from what was available in 1982.  Thus, it isn't fair to say that
Smalltalk is 10 years older than C++.  My understanding is that there were
only a dozen or so people at Xerox PARC who worked on the Smalltalk 
programming environment directly (other people were just users).  When
you count all the people in universities who are using C++, the number
of man-years invested in C++ can't possibly be an order of magnitude less
than for Smalltalk, and in a year it will be an order of magnitude more.
Everywhere I go people are switching to C++, and there are groups of more
than a hundred people using C++.  There is nothing at all like this for
Smalltalk.  However, it will take more than a year or two for the
C++ programming environment to surpass that of Smalltalk.

The reason that Smalltalk programming environments are so good is the same
as why Lisp programming environments are so good.  Programmers can access
contexts and classes from inside Smalltalk so they can easily write
debuggers and browsers.  A similar system for C++ will require a lot of
interaction with the operating system, which will be more complicated and
less portable.  Thus, making a nice programming environment for C++ is
a harder job than making one for Smalltalk, so it will take longer.

>There is absolutely no basis for this conjecture and the absense of really
>large projects successfully developed and supported in a Smalltalk-like
>language is a contraindication. After 16 years of Smalltalk variants and
>offshoots we should not be conjecturing on this point. Smalltalk has a
>string of spectacular successes to its credit, but as far as I'm aware
>large scale systems development isn't among them. Nor was it mentioned
>among the things Smalltalk was supposed to be especially good at.

I suppose that it depends on what you mean by "large".  Smalltalk itself
is pretty large.  The Analyst is twice as large as Smalltalk.  There is
a VLSI design system at Tektronix that takes 12 or 16 megabytes (I forget
which).  I doubt if there have been many C++ systems of this size yet.
Smalltalk certainly has some faults when it comes to building large
systems, primarily in its support for mulitperson projects, but I think that
Dr. Coggins was speaking of "Smalltalk-like" languages (whatever that
means) and not Smalltalk itself.

I am a great fan of type systems, primarily because I am a fan of good
optimizing compilers.  The reason that Smalltalk is slow is primarily 
because it doesn't have an optimizing compiler.  Indirection, method-lookup,
garbage collection, etc. are all just excuses.  Of course, C++ can be 
efficient without a great optimizing compiler, though a good compiler 
certainly helps.

Type systems are also important in ensuring that components are used
correctly.  This is especially important when components are used by
one group and implemented by another.

Type information also makes it much easier to read code.  O-o programming
increases code reading, so this is important.

My type system for Smalltalk is much more flexible than the one for C++.
I am curious about Dr. Coggins's explanation of why C++ is not as good
for reuse, and wonder how types fit in to it.

Ralph Johnson