Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk versus C++
Message-ID: <80500048@p.cs.uiuc.edu>
Date: 4 Jan 89 16:04:00 GMT
References: <447@ubbpc.UUCP>
Lines: 122
Nf-ID: #R:ubbpc.UUCP:447:p.cs.uiuc.edu:80500048:000:6665
Nf-From: p.cs.uiuc.edu!johnson    Jan  4 10:04:00 1989


This is in response to the message by wgh@ubbpc.UUCP asking about the
differences between C++ and Smalltalk.  I use both, so I'll comment.
I program the same way in each, so I believe that at a high enough
level of abstraction all object-oriented programming languages are
the same.  Of course, that level of abstraction is so high as to make
everything below look fuzzy.

The Smalltalk programming environment is much more dynamic than that
of C++ and it carries the object-oriented point of view to an extreme
(which is where I think it should be carried).  It also has no static
type checking.  This makes it very hard to implement Smalltalk as
efficiently as C++, though I don't think it is impossible to do so.

As far as language differences go, Smalltalk has 
	no compile-time type-checking,
	automatic memory management (i.e. has garbage collection), 
	closures as first-class objects (i.e. blocks), 
	everything is an object, including numbers, classes, and contexts, 
	small syntax.
C++ uses 
	static type-checking to provide a very efficient implementation
		of message-sending, 
	a moderately complicated mechanism that can be used to allocate
		and deallocate garbage collection efficiently 
		(constructors and destructors), 
	no closures, thus permitting stack allocation of contexts,
	mixture of objects and nonobjects, providing more opportunities
		for optimization
	syntax considerably larger than C

Note that most of the differences impact performance.  I'll say more
about this later.

The standard Smalltalk image supports multiple inheritance, but it is
not documented very well, is rarely used, and is reputed not to work
very well.  The version of C++ that is currently being sold doesn't
have multiple inheritance, but research versions do, and it is just a
matter of time before the commercial versions do, too.  On the other
hand, people argue a lot over how to do multiple inheritance, and some
people (like me) don't like the approach that C++ has taken.

The really big difference between Smalltalk and C++ is not the
languages, but the implemenation and programming environments.
Basically, Smalltalk is a lot more fun to use and better for
rapid-prototyping, but C++ is a lot more practical for many projects
and fits better into the traditional way of building computer systems.

Smalltalk comes with a great programming environment that lets you
examine everything, change everything, and reuse anything.  It also
comes with a large library of fairly reusable code.  C++ doesn't
have either of these features, though there is no reason in principle
that it couldn't.

Smalltalk programs require the entire Smalltalk image.  There is currently
no easy to use method of stripping a Smalltalk application out of an image,
though several research groups have built prototypes.  This makes it hard
to use Smalltalk as just another component in a large system.  Also, until
recently Smalltalk programs could not call subroutines in other languages,
though both Tektronix and ParcPlace now have "user-defined primitives"
that permit this with some degree of difficulty.  The Smalltalk image is
fairly large, so any application will also be large.  Since any application
comes with the image, and the image has tools for looking at source, it is
hard (but not impossible) to hide source code.

Many of these problems have possible solutions.  I'll describe the
ultimate solution at the end of this message.

Smalltalk is not as portable as C++.  Most implementations of C++
use the regular C compiler as an intermediate step, so any machine
with a C compiler can run C++.  Smalltalk requires an "interpreter"
(actually, what ParcPlace sells isn't really an interpreter) and the
fast ones are proprietary and are only ported by their owners.

Smalltalk and C++ are really designed for very different kinds of applications.
You would never want to design an operating system in Smalltalk.  However,
Smalltalk is ideal for prototyping, for building highly interactive programs
like hypertext-like systems, and for building large systems that will have a
small number of highly skilled users who will want to customize the system.
In these cases, you don't mind needing forcing customers to buy Mac IIs or
Suns to get good performance and the advantages of Smalltalk outweigh its
drawbacks.  There are some areas, such as research into visual programing,
where I think that Smalltalk is far and away the best system of any kind,
and I can't understand why more people don't use it.  (Actually, a lot of
the more successful people in those areas do.)  For other areas, using
Smalltalk would be a disaster.

C++ is upward compatible with C (sort of) so it is fairly easy to
train people who know C to use it.  Anyplace you can use C, you can
use C++ just as well.  It fits in with the standard software
engineering models and can use traditional tools.  Of course, I think
that the standard models and tools need a massive overhaul, and that
Smalltalk gives some good pointers on how, but lots of people only
want to change one thing at a time.  C++ is just as efficient as C,
which is certainly not true of Smalltalk at present, and it allows the
programmer complete control over machine resources.

Lots of people are working on adding Smalltalk features to C++, in 
particular, there is a lot of work on improving the environment.  C++
needs incremental compilation, browsers and on-line cross-reference
tools, and better debuggers.  Conferences have papers on all these
things, so it is just a matter of time before they become available.
The best environment for C++ might just turn out to be Cynergy, which
is written in Smalltalk.  (snicker, snicker!)

Some people are also working on making Smalltalk better suited for
traditional environments.  In particular, I am building an optimizing
compiler for Smalltalk that has the potential to solve all the problems
I listed above.  It could make Smalltalk as fast as C, let you run
programs without the development environment, let you easily call
library routines written in C or FORTRAN, and make Smalltalk more
portable.  Of course, it isn't done yet, though we are getting close.

If you are interested in object-oriented programming and can afford
the time to educate yourself, I would advise you to play around with
Smalltalk.  You may not be able to fit Smalltalk into the projects
that you are building (though you might find out it is just the thing)
but learning it will raise your expections of what computer systems
should be and what object-oriented programming should be.

Ralph Johnson -- University of Illinois at Urbana-Champaign
		 johnson@cs.uiuc.edu,   uiucdcs!johnson