Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!in1.uu.net!utcsri!utnut!nott!cunews!tina.mrco.carleton.ca!knight
From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: Why is Smalltalk so expensive ?
X-Nntp-Posting-Host: tina.mrco.carleton.ca
Message-ID: <knight.822607823@tina.mrco.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: The Object People
References: <25960111162652/0006786458ND1EM@MCIMAIL.COM> <4dlsh8$2luo@news-s01.ny.us.ibm.net> <4e2rgq$q5g@news2.ios.com>
Date: Thu, 25 Jan 1996 22:10:23 GMT
Lines: 60

In <4e2rgq$q5g@news2.ios.com> vlad@gramercy.ios.com (Vlastimil Adamovsky) writes:
>Now some homework has to be done in Smalltalk battlefield:

>1)  performance improvement

Always something to work on, but current Smalltalks do exhibit quite
good performance for what they're doing. They can do very well in
benchmarks that actually measure oranges vs. oranges.

>2)  easy connection to C-language.
>       a) ST/V is excellent
>       b) VW is slow

I haven't found VW slow, but there is certainly overhead in some
operations and implied overhead in jumping between different
environments with different data representations.w

>3)  easy embedding of VBX, OCX, DSOM etc..

I think Digitalk already supports OCX, VA 3.0 has VBX support, I think
VisualWorks OLE suport should be out very soon if it isn't already,

>4) better visual development environment
better environments in general

>5) loadable and unloadable modules at runtime

like SLL's?

 >6) true interpreter

If you mean what I think you mean by this, you'd be very happy with
Vwin16 or VA 2.0.

 >7) native compiler (not a byte code compiler)

The problem with this is that it's often not what you want. Digitalk's
first V/OS/2 version was completely compiled, but it took way too much
memory. ParcPlace has been talking about having fully compiled
versions for their server stuff, where it's appropriate.

 >8) possiblity to manipulate Smalltalk objects (through messaging)
from within C-language code

I think I can do this now in any of the dialects. It's painful, since
it involves C, and I have to have the C code running in the same
process with the ST, but it's certainly doable. It would be nice to be
able to write Smalltalk modules that could be linked into C programs.

>Now when memory is cheap, the memory hunger is no problem. 

that's funny. I keep seeing threads about how desperately people want
a low-memory Smalltalk.

-- 
 Alan Knight                | The Object People
 knight@acm.org             | Smalltalk and OO Training and Consulting
 alan@objectpeople.on.ca    | 509-885 Meadowlands Dr.
 +1 613 225 8812            | Ottawa, Canada, K2C 3N2

