Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!cit-vax!oberon!brand.usc.edu!barad
From: barad@brand.usc.edu (Herb Barad)
Newsgroups: comp.lang.smalltalk
Subject: Re: Severe Limitation of Smalltalk for Big Projects
Message-ID: <3065@oberon.USC.EDU>
Date: Sat, 27-Jun-87 19:16:49 EDT
Article-I.D.: oberon.3065
Posted: Sat Jun 27 19:16:49 1987
Date-Received: Sun, 28-Jun-87 04:48:10 EDT
References: <3005@oberon.USC.EDU> <1384@tekchips.TEK.COM>
Sender: nobody@oberon.USC.EDU
Reply-To: barad@othello.usc.edu.UUCP (Herb Barad)
Organization: University of Southern California, Los Angeles
Lines: 23
Summary: Oops...

In article <1384@tekchips.TEK.COM> allenw@tekchips.TEK.COM (Brock) writes:
>With Smalltalk, like all languages, care must be taken to distingish
>between between the characteristic of a particular implementation
>and the fundamental limitations of the language.  Some commercially
>available Smalltalk implementations have much more severe limitations
>than those attributed to PS (its HARD to support a 16meg object
>space on a PC) while others do not have this particular limitation.

Sorry, you are absolutely right.  I did not mean to imply the
limitation was in the language itself (it certainly isn't), I meant
the particular implementation.  Also, this type of restriction does
apply to many implementations, but I hope not to all.

I know that Tektronics supports a version.  I assume from your response that
it doesn't suffer from this limitation.  Would you please enlighten me
(and the other readers) as to Tektronics' implementation?

Herb Barad	[USC - Signal and Image Processing Institute]

USENET:		...!sdcrdcf!oberon!brand!barad			or
		...!mcvax!seismo!sdcsvax!sdcrdcf!oberon!brand!barad

ARPANET:	barad@brand.usc.edu