Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!haven.umd.edu!hecate.umd.edu!bloom-beacon.mit.edu!news.mathworks.com!fu-berlin.de!unlisys!blackbush.xlink.net!ins.net!heeg.de!uucp
From: Hasko Heinecke <hasko@heeg.de>
Subject: Re: New Smalltalk root (was Re: X3J20 and isNil (wasRe: Conclusion: etc..))
Content-Type: text/plain; charset=us-ascii
Message-ID: <329EF33D.41C67EA6@heeg.de>
Sender: uucp@heeg.de
Content-Transfer-Encoding: 7bit
Organization: Georg Heeg - Object-Oriented Systems
References: <329B3FDB.2AC1@parcplace.com>
Mime-Version: 1.0
Date: Fri, 29 Nov 1996 14:29:17 GMT
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3 sun4c)
Lines: 67

Allen Wirfs-Brock wrote:
[...stuff about static class declarations...]
> While this may seem unusual from a Smalltalk perspective, there is actually nothing very
> special about this approach.  It's the way almost every other langauge in existance works.
> The only real innovation, if any, is the recognition that reflection and incremental
> development can still be supported.

I thought Smalltalk's reflective and incremental nature made such an
"external" syntax unnecessary, and this was a major innovation. I know,
these ideas existed before Smalltalk. But still: What is the advantage
of having this "external" description of class hierarchies. Read this
as: Was that introduced because all the other languages have it or why?

Sometimes I fear Smalltalk will degrade and become a C++ dialect. :-) I
think, much of the power Smalltalk gives you comes from the notion of a
competent developer sitting in front of the screen. That means, the
developer can him/herself decide wether changing a system method or
changing an existing class' semantics is a good idea or not.

There is a correlation to the strong/weak static/dynamic
implicit/explicit typing discussion that frequently arises in this
group. Smalltalkers say: We don't want your weak static explicit types
(or whatever you call C++ types) because our strong dynamic implicit
types (or whatever you call Smalltalk types) give us much more power
through flexibility.

There are problems, of course. How can I integrate third party
libraries? How can several developers cooperate? But these are not
essential. The one essential problem behind the Smalltalk approach as I
understand it is:

	How can I guarantee software quality?

I.e. how can I make sure that the Smalltalk powered nuclear power plant
does what I'd like it to do? How can I make sure that XYZ Cars Inc
doesn't lose millions of bucks because their production chain comes to a
grinding stop?

Of course you can set up rules that restrict the devlopers so that you
won't get a #doesNotUnderstand: or crash your image when filing in
another developer's code. But what do you do with Smalltalk? Smalltalk
contains its own meta-language and basically allows you to change the
language itself, so you cannot _make_ _sure_ a developer can't do this
or that and break your system. So we have to make these reflective and
incremental mechanisms _optional_. To overcome the non-reflectiveness of
the resulting language we simply invent a new one. Call it IDL or
whatever. Only competent and responsible people are allowed to change
things defined in this IDL, the ordinary developer must stick with
Smalltalk "only".

But is this really the right way? Assuming that software quality is the
real issue, we should ask ourselves what we can do about that without
losing our powerful language. And this is a question of production
processes and of integrating QA into the analysis, design and
implementation phases. Lots of issues there, but we should try not to
let Smalltalk become a C dialect.

Now that's a long article. Do you think I completely missed the point?

Hasko

PS: Speaking for myself only.
-- 
+------------------------------------------------------+
| Hasko Heinecke, Georg Heeg - Object-Oriented Systems |
| mailto:hasko@heeg.de or try http://www.heeg.de/      |
+------------------------------------------------------+
