From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: Is Smalltalk the language for us?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Tue, 29 Sep 1992 02:08:13 GMT

nadja@jetsun.weitek.COM (Nadja Adolf) writes:


>>>One problem with Parc smalltalk is that in the past, whenever a new
>>>rev of the interpreter is released, one had to completely revise all of
>>>one's code to use the new version. I don't recommend Parc for anyone
>>>doing real world work - it is too much hassle to do heavy duty revision
>>>for each rev.

>You are misquoting me. My point is that with C++, C, FORTRAN, or even
>(gasp, shudder) COBOL, the platform developers have made some minimal
>effort to allow old code to be used. PARC hasn't bothered to do this -
>and finding the parts to redo in several hundred thousand lines of code
>tends to be time consuming, to say the least.

I most certainly have not been misquoting you.  I may misinterpret you,
but as far as I can tell, I am only attributing to you words that you 
have typed.

ParcPlace certainly has made more than minimal effort to allow old code
to be used.  And with the great Smalltalk programming environment, an
expert does not not usually need vast amounts of time to move a 4.0
application to 4.1.  Perhaps there is someone out there who will give
a counterexample, but it was easy for us, and everyone I have talked
to says it is easy.  ParcPlace gave a clear description of what had to
be done to convert to the new image.

I can still run Smalltalk programs that we wrote 5 years ago.  Of course,
I can't run them in the same image with new code, since I have to run them
with the 5 year old images.  But this is no different from what happens
in the C++ world.  Changes in the compiler break old programs.  You fix
the programs, or you use the old compiler.

>>How does C++ make it easy?  I'm part of two projects, one in C++ and
>>on in Smalltalk, and the Smalltalk project has much less problems due
>>to many people changing the same sources.  Merging separate RCS streams
>>is much harder than merging several change-sets.

>Ever heard of the late xanadu operating company? AKA xanadu inoperative
>company?

Perhaps you could try answering questions for a change instead of just
asking them.  I have no idea what you are talking about.  What does it
have to do with C++?

Basically, you make wild claims and then when you are asked to back
them up, you just make more wild claims.

>Some of us write things that wind up being de facto real time. Things
>like transaction processors.

If throughput is your main metric, or average response time, then this
is no problem.  It is only when there is a hard minimim limit on response
time that g.c. becomes a problem.  There *are* real-time g.c. algorithms,
they just aren't as efficient as the standard ones.  I know people who
build large real-time systems (large = several millions line of code)
that have to be reliable and stay up for very long times, and they claim
that g.c. is desparately needed to improve reliability.  They are doing
things like building special purpose hardware to make their g.c. efficient,
or just getting a processor that is twice as fast as they need and then
using an inefficient but real-time g.c. algorithm.

I do a lot of interactive graphics with Smalltalk.  Every few minutes it
will pause for less than half a second.  Many people miss it.  This would
be bad if we were making movies, but that is not usually done in real
time anyway.  For most interactive programs, the performance of the
Smalltalk garbage collector is fine.  It does not seem to be the cause
of Smalltalk's performance problems.

And besides, you seemed to have missed my point.  I was the first to say
that g.c.'s weakness is real-time programming.  While there are a lot of
people who do real-time programming, there are a lot of people who don't.

>Strict type checking helps developers find merge bugs more quickly.

This is a reasonable statement, and I believe it is true.  It does not
contradict, however, the fact that merge bugs are much easier to find
in Smalltalk than in C++.  There are other things than type-checking
that make a language pleasant to use.

You keep making claims that it is easier to merge changes in C++ than
in Smalltalk.  Maybe you know something I don't.  However, I have found
the original change-list editor to be a satisfactory tool for merging
changes.  It has an option for comparing change sets for conflicts.
This is fairly crude; it just checks to see whether two change sets have
changed the same method.  However, it works well when you combine it with
the observation that if two people have had to change the same method 
the method is probably too big and needs to be split anyway.  The big
advantage of change-lists is that they are both single objects that can
be managed, passed around, and sent by e-mail, and they are also
structured objects that the change-list editor can manipulate.

I've observed large (academic) projects in C++ and Smalltalk, and it
has always seemed that merging was several times easier in Smalltalk
than in C++.  It takes hours or days in Smalltalk, and months in C++.
Naturally, each project has its own way of doing things, so it is probably
a mistake to compare them directly, but my experience is that they aren't
even close in ease of merging changes.

I'm sure there are some better tools for merging changes than the ones with
RCS, but that is all most people use, and so that is what I am comparing
them with.  I have not seen the SGI environment that you have been
advertising, but the C++ environments from Lucid, Centerline, and ParcPlace
don't seem to be all that strong in this area.  I've seen some really good
non-C++ proprietary systems, and it is only a matter of time before 
something like them becomes generally available, but they certainly weren't
around last I looked.

What kind of Smalltalk experience do you have?  How many people worked
on your project?  How long did the project go on?  When did it take place?

Newsgroups: comp.lang.smalltalk