Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!godot.cc.duq.edu!newsgate.duke.edu!news.mathworks.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!psgrain!qiclab.scn.rain.com!gemstone.com!servio!servio!aland
From: aland@servio.slc.com (Alan Darlington)
Subject: Re: Java vs. Smalltalk vs. C++ vs. OO COBOL
Message-ID: <1996Jul8.185105.21925@gemstone.com>
Sender: news@gemstone.com (USENET News)
Nntp-Posting-Host: servio
Organization: GemStone Systems, Inc., Beaverton OR, USA
References: <2.2.32.19960703141916.006c4198@www.objectpeople.on.ca> <31DB0F1D.532F@terracom.net>
Date: Mon, 8 Jul 1996 18:51:05 GMT
Lines: 40

Dave Smith <daves@terracom.net> writes:
<snip> 
> I think the mythology of the runtime-error-as-dynamic-system-weakness
> (how it came about) is as follows. In my experience (using Digitalk
> products) the runtime will often generate runtime error messages that
> did not occur during the development process, under the development
> system there was no sign of a problem, but then you get that runtime
> error dialog. I don't know how to explain this behavior, but it is 
> well documented (for instance, in an article in Object by the people
> from Heastead, where runtime errors are listed as a downside to ST
> development) and well supported by my personal experience. Any ideas?
> If the problem is not in the dynamic patch up then where _is_ the
> problem? What makes the dev environment more robust? Isn't it 
> the same VM? Same code? Just looking for the answer...
> 
> Regards,
> DS

I have worked on three commercial Smalltalk applications, and I have
also run into this problem.  My personal belief is that the vendor's
insistence on stripping out parts of the image prior to the release of
an application is a (if not "the")  major problem.  All the vendors
seem to require this, and I have seen lots of cases of released
application code failing because it relied on methods (or even classes)
that were stripped out by the vendor's pre-release code.

Even worse (to me, at least) is that by stripping out the compiler,
the vendors prevent me from shipping source-code fixes to problems
found by our customers.  Also, I cannot use any techniques that
require creating classes and/or methods dynamically.  Sigh...  I
wish the vendors were not so paranoid (and don't get me started on
the topic of "hidden" code).  :-(

  Cheers,
  Alan

P.S.  We have even a worse problem at GemStone, since we not only
      support VA, VS, and VW, but also ENVY-ized versions of them.
      Trying to keep track of which methods are safe to use is a
      nightmare - only our QA people can keep us going.  :-)
