

Article 1456 of comp.lang.smalltalk:
Path: mimsy!haven!rutgers!dptg!ulysses!andante!alice!bs
>From: [email-masked] (Bjarne Stroustrup)
Newsgroups: comp.lang.smalltalk
Subject: Re: Questions from a novice on development environments...
Summary: easy now
Message-ID: <[email-masked]>
Date: 2 Oct 89 01:28:38 GMT
References: <[email-masked]>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 107

There seems to be a misconception that C++ is supposed to be Smalltalk
(or that Smalltalk and C++ are in some way supposed to be the same).
It follows from that view that you should be able to work in exactly
the same way with implementations of the two languages, that you should
be able to acomplish the same tasks with the two languages, and that
when you cannot someone has goofed.

I disagree with this premise.

People who naively approach C++ and Smalltalk with this premise are
going to be disappointed.

C++ was NOT designed as an immitation Smalltalk. Had I tried that,
I would naturally have produced something much closer to Smalltalk.
Actually, I do not see a need for immitation-Smalltalks. Smalltalk is
still the best Smalltalk around; it is a very nice language/system
and its evolution is in very capable hands.

So, C++ is not a very good Smalltalk; it was not meant to be.
Similarly, Smalltalk is not a very good C++; it was not meant to be.

There are two fundamental differences between C++ and Smalltalk:

	C++ is a language; Smalltalk is a system.
	C++ is statically typed; Smalltalk is dynamically typed.

These first order differences follow partly from needs and application
areas, partly they represent alternative strategies for attacking problems.
Many differences follow from them. For example, in general

	- it is harder to built a high-quality (``modern,'' ``Smalltalk-like'')
	programming environment for a statically typed language.

	- it is harder to provide a high-quality programming environment
	for a language used on a diverse range of systems (rather than
	being a system in itself).

	- it is easier to design ``standard libraries'' in a dynamically typed
	language.

	- it is harder to produce efficiently running code for a dynamically
	typed language.

	- it is harder to cooperate with ``traditional'' systems from a
	dynamically typed language embedded in a non-traditional standard
	environment.

	- it is easier to manage the integration of large systems written
	by many programmers if statically typed interfaces are used.

The list could be made much longer, but as it becomes more specific the
specifics become hard to understand in isolation, data is harder to come
by, and the issues gets more sensitive to matters of system maturity,
application area, economics, and the background of the users.

It is clear that both classes of languages/systems evolve to compensate for
their weaknesses.

The style of programming and the approach to design is (and I think ought
to be) strongly influenced by the language/system used. The choice of
language/system chosen for a job should be done with a degree of
understanding of both the strenghts and the weaknesses of the alternative
languages/systems. There is no reason to believe that a single language/
system will be the best choice for all applications - even if a particular
user may have the luxury of working exclusively on projects where a single
language/system has a fairly constant overall advantage.

A novice's questions deserve a better answer than a polemic blast. The
various ``object oriented'' languages do have something basic in common
(for example, see my paper `What is Object-Oriented Programming? in IEEE
Software Magazine, May 1988) and if people apporaching OOP is wellcomed
by a blast from a parochial regigious war it reflets badly on all such
languages.

There is no language/system in existence that can serve the range of
applications/needs that is currently served by various ``OOP languages''
- let alone the range of needs they could serve. C++ and Smalltalk
were DELIBERATELY placed at the extreemes of the spectrum of reasonable
design choices for practical languages at the times they were developed.
That makes comparisons between them interesting (but tricky) and they
support each others' growth as much as they compete for resources.
I conjecture that there are many more Smalltalk programmers now than
there would have been had C++ not existed - and visa versa.

I suspect we could have a rather interesting debate about these issues,
but I and many others will be at OOPSLA all of next week so we might have
to wait a bit.

One thing I'm looking forward to at OOPSLA is a panel/debate on almost
this topic. The basic observation is that there are far too many
silly ``religious'' arguments over language choices and that many such
unconstructive debates are based on ignorance of and disrespect for other
peoples' problems, needs, basic assumptions, backgrounds, and strenghts
(and worse: often heavily influenced/biased by commercial interests).

Dan Bobrow (from PARC) proposed a panel where people would present what
they like about each other's languages:

	Gregor Kiczales (PARC) will present Smalltalk,
	Peter Deutsch (ParkPlace) will present C++,
	I will present CLOS.

This could be interesting and definitely a change from the more traditional
``technical panels'' that IMHO are often no better than the commercial hype
found on the exhibition floor.