Xref: utzoo comp.lang.smalltalk:3124 comp.object:3838
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!fernwood!portal!cup.portal.com!Will
From: Will@cup.portal.com (Will E Estes)
Newsgroups: comp.lang.smalltalk,comp.object
Subject: Re: Smalltalk scaleability & IdentityDictionaries
Message-ID: <43766@cup.portal.com>
Date: 28 Jun 91 05:39:43 GMT
References: <1991Jun26.193441.28581@bqnes74.bnr.ca>
  <286A46DC.72E9@deneva.sdd.trw.com>
Organization: The Portal System (TM)
Lines: 65

<It that sense of scaleability, Smalltalk fares well. But when I hear
<the term scaleability, I think of bigger issues such as how does the
<Smalltalk *environment* scale up to large projects of the hundreds of
<thousands or millions of lines. In this case, Smalltalk fares very
<poorly. Large projects require multiple user concurrency, distributed
<data, schema evolution, versioning, support for persistent storage and
<managability of non-code artifacts, support for testing and
<maintenance and support for process. In all of these areas the
<Smalltalk environment performs poorly or not at all.
<--
<Scott SimpsonTRWscott@coyote.trw.com

I think these are all extremely good points.  I have yet to meet a
programmer who has worked on a project of any size who would not agree
with the statement that the image is far too large a granularity at
which to save changes to a system.

When developing C programs for MS-DOS or UNIX, would we accept any
scheme that required us to save changes to code modules in a monolithic
library with core operating system routines and required us to save
the entire OS to effect a change?  Smalltalk is much like an
operating system, and if we would not accept such a large granularity
of change for another OS, why do we accept it for Smalltalk?

I for one am very concerned about this issue, and I feel it is the one
and only impediment to wide-scale commercial use of the Smalltalk language.
What concerns me most is that Digitalk and ParcPlace seem to be doing very
little to address this issue.  On the CompuServe forum, when I and others
have raised this issue it either goes without any response at all from
Digitalk, or it gets the response "we can't fix these problems without
changing the Smalltalk definition."

I have two problems with that response: 1) it tells me that Digitalk is
more concerned with strict adherence to a standard than it is with solving
its customers' business problems; 2) it tells me that Digitalk doesn't have
a proper sense of proportion about just how bad this problem really is, and
just how much it cuts into their potential sales.  I think if someone could
prove to them that their sales might increase by factors of five or more 
if they addressed this issue effectively, then they might start to sing a 
different tune.

I know that there are third-party products to address version control
and multi-user, networked use of an image by programmers making changes
to that image, but frankly that just isn't good enough.  This whole area
points to problems with the language definition, and the solution
needs to come from the language vendor and be integrated thoroughly into
the core product.  I do not know any responsible MIS manager who is going
to risk a large-scale, long-term project on a third-party utility for a 
language which is itself considered leading-edge and somewhat risky.

What can we do to convince the Smalltalk vendors that this problem
merits significant, and immediate, attention?  I think the primary
reason that the vendors do not see the magnitude of the problem is that
most of the early adopters of the Smalltalk technology are single-person
shops or small prototyping groups in larger companies that only require
a tool that one person can use effectively.  But to define the customer
as one person working on his own is to miss out on the real mass-market
opportunity for Smalltalk: the hordes of large-team Cobol programmers
who weigh down most MIS shops.  Smalltalk as it stands today is not
a substitute for Cobol on very large projects, and that is a damn shame,
because it could and should be.


Will Estes          Internet: Will@cup.portal.com
                    UUCP: apple!cup.portal.com!Will