Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!news.mathworks.com!uunet!in1.uu.net!165.254.2.53!nonexistent.com!not-for-mail
From: vlad@world2u.com (Vlastimil Adamovsky)
Subject: Re: Response to PC Week article on Java
X-Newsreader: Forte Free Agent 1.0.82
X-Nntp-Posting-User: (Unauthenticated)
Message-ID: <E66sJL.A01@nonexistent.com>
References: <01bc2330$066f96b0$ed22109b@russ-mc-laptop>
X-Trace: 856921081/12936
X-Nntp-Posting-Host: i123.148.world2u.com
Date: Wed, 26 Feb 1997 01:40:48 GMT
Lines: 93

"Russ McClelland" <russmc@netbox.com> wrote:

>Here was my response to Peter Coffee....

Here is my response to your response to P.C.

>Development environment.  

Optima, Borland C++ developer, Dephi, VB5 ........

>Because of the Smalltalk architecture, testing
>and developing is much more rapid in ST than Java or C++.  

VB5

> Only ST breaks the type/compile/link/test cycle.  

Is it really so big advantage?

>I can creat classes and
>test them with having access to the entire project.  I no longer have to
>wait for "Harry" to get back from lunch to test my code.

ActiveX

>ST is dynamic and flexible.  For any development language that incorporates
>the compile/link phase, the application must be stopped in order to effect
>change, regardless of how trivial the change is.  Now consider a Smalltalk
>system which lets users add new classes, change the behavior of a class, or
>change the behavior for one instance of a class.  This application does not
>need to be stopped.  

It makes the bed for a disaster.

>Clearly this has real significance in OLTP and mission
>critical systems that must never stop.  


Do you really want to change "mission critical" systems while running? 

>Whats more important is that
>systems that have rapidly changing rules (like tax and accounting systems)

They usually change only once a year.

>can be modified without shipping a new product to the customer.  

ActiveX, OCX, Plug-ins, DLL etc... do the same job

>One the
>strategies that I have seen very prominate in ST development is to create a
>"programming language" within an application that allows users to change
>how the system behaves.  

Should I allow users to change behaviour of my programs? And while running the
program? Who will be responsible for disasters? How would you report bugs?
What would be my bugs and what theirs?

>Our development team doesn't ship them a new
>"version" of the application, they change it themselves.

??????

>These are just a few of the benefits that ST has over other languages, but
>alas, I am a realist.  This would not be the first time that a superior
>product was nixed because of bad marketing.  

The bad marketing has nothing to do with it. Simply Smalltalk, how we know it
today, is outdated. I am sure we will see new versions of Smalltalk and then
people will jump over to it back from Java , then later back to Java , later
back to Smalltalk until they realize that it is not to blame the language itself
as to blame  the ability to master the given language and technology.

>But I do believe that the
>biggest problem for ST is twofold:

>1.  Editors who are quick to believe that Java will save the world. 
>Everytime you learn something new about Java, before writing an article
>about how keen Java is ask yourself if Smalltalk has had the feature for
>the last 25 years.  The answer will be yes.

No.

>2.  Editors who believe that the only Smalltalk vendor is ParcPlace.

I must have missed such an article
>-- 


 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *

