From: nadja@jetsun.weitek.COM (Nadja Adolf)
Subject: Re: Is Smalltalk the language for us?
Organization: WEITEK Corporation, Sunnyvale CA
Date: Mon, 28 Sep 92 22:43:49 GMT

In article <1992Sep25.180331.9582@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) 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.

>And would your life have been any better if you were using MacApp
>when 2.0 came out?  Or 3.0?  You can stick with the old rev forever
>if you like; nobody forces you to upgrade.

Excuse me?

>There are two points of view.  One is that once code is published, it
>cannot change because people depend on it.  You seem to have this point
>of view.  The other is that it is so important for code to be "right",
>that when you find out that you made a mistake then you have the
>obligation to correct it.  Unfortunately, we are not very good at making
>code right the first time (or even the second) and it often is not until
>people start to use our system that we find out its problems.  Thus, 
>reused libraries will continually be upgraded, though hopefully there
>will be fewer and fewer changes as time goes by.   This is my view.

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.

>And if I was a ParcPlace rep (which I am not) then I would remind
>you that their virtual machine isn't really an interpreter.

And neither is it a 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?


>And what do allocs and frees have to do with OO?  And what do you lose
>by not being able to do them explicitely?  Unless you want to do real-time
>programming, there is no reason to dislike automatic garbage collection.
>If someone could just figure out an efficient real-time g.c. algorithm
>then nobody would have to manage memory allocation anymore.

As soon as we solve the halting problem, I'm sure that will happen. :-)	
Some of us write things that wind up being de facto real time. Things
like transaction processors.

>Smalltalk does limit your scope by forcing everything to be an object.
>You can make your C++ program look just like a C program, but you
>can't make a Smalltalk program look like a C program.  Whether this is
>good or bad is a matter of opinion, of course.

Since I have never seen the point of writing C++ as C (why pay more
for the C++ facilities if you aren't going to use them?) I will suggest
that making either C++ or smalltalk look like C isn't a very useful
idea.
 
>I agree that Smalltalk does not support OO better than C++ or
>Modula-3.  So what?  The question is which system is best for a
>particular job.  Class libraries, programming environment, what your
>programmers know, existing code, all are important factors.

Since OO is usually harder to learn than the language syntax, starting
with C++ and smalltalk should give close to the same learning curve. Strict
type checking helps developers find merge bugs more quickly.


-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com