Xref: utzoo comp.lang.smalltalk:3125 comp.object:3839
Newsgroups: comp.lang.smalltalk,comp.object
Path: utzoo!utgpu!cunews!bnrgate!bqnes74!news
From: CWatts@BNR.CA (Carl Watts)
Subject: Re: Smalltalk scaleability & IdentityDictionaries
Message-ID: <1991Jun28.160020.13809@bqnes74.bnr.ca>
Sender: news@bqnes74.bnr.ca
Organization: Bell Northern Research
Date: Fri, 28 Jun 91 16:00:20 GMT

"... the image is far too large a granularity at which to save changes
to a system..."

"... one and only impediment to wide-scale commercial use of the
Smalltalk language..."

"This whole area points to problems with the language definition ..."

My, my, my, Will, what an expert you've become on Smalltalk, the
problems with it, and what needs to be done considering that only two
days ago I had to explain to you what the difference between a String
and a Symbol was and how a Dictionary worked.

But the concerns you mentioned are very common concerns with neophyte
Smalltalk users.  I had many of the same problems when I first started
using Smalltalk 4 years ago.

One has to remember is that Smalltalk is a fundamentally different kind
of beast from languages like Fortan, COBOL, Pascal, C, C++, etc.
Smalltalk has a different point.  Comparing the two is like the
proverbial comparing of Apples and Oranges and lamenting the faults of
Oranges in that they have a thick outer covering you have to remove
before you can eat it and you can't make applesauce with them.

Smalltalk has much more in common with Lisp and APL.  Both languages
have virtual machines and the idea of an image (called a Workspace in
APL).

The problems you are lamenting with Smalltalk are not things that any
other language (that I can think of) integrates solutions into itself.
C is perhaps the classic example.  It has no integrated version control
or multi-user development environment support inherent in the
language.  It defines no granularity of change inherent in the
language.  The language itself has no inherent development support at
all.  All of these must be provided by outside applications (typically
in Unix if at all).

Smalltalk was meant to be its own operating system, language,
development environment, everything!  Thats why there is a "Virtual
Machine".    An image is not an inherent concept of the Smalltalk
language.  It is what is needed when operating under a foreign
operating system.  When Smalltalk was developed, no machine could
provide the support needed so a Virtual machine was built to emulate
the real machine.  The virtual image represents a snapshot of what the
memory of this virtual machine looked like when it was last running.
This is common in other languages like Lisp, APL, etc.

It almost makes me want to cry when someone says they want to turn
Smalltalk into something like C or Pascal; where you write canned
applications that run under a foreign operating system like Unix or
OS/2.  That was not the point of Smalltalk.  While that is the point of
something like C.  If thats what you want to do, then you can do it but
you will be pounding Smalltalk's round peg into a square hole.  You can
do it if you pound hard enough.  And considering the beauty of
Smalltalk compared to C, its still usually better than using C's square
peg.

This from someone whose department supported 50 developers working on
the same application, all in Smalltalk with less
multiple-developer-conflict problems than I would have thought possible
using any development environment.  This thanks to the encapsulation
that Smalltalk classes support so well, and to some small development
environment tools (based on ChangeSets) that we developed in Smalltalk
to manage many concurrent developers.  As Peter Goodall pointed out
there are several excellent commercial products available to provide
extremely sophisticated support for large multi-developer groups.  And
these are far more sophisticated than Unix and all the standard Unix
development tools combined.