Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!scramble.lm.com!news.math.psu.edu!chi-news.cic.net!portc01.blue.aol.com!newstf01.news.aol.com!news-e2a.gnn.com!howland.reston.ans.net!vixen.cso.uiuc.edu!newsfeed.internetmci.com!swrinde!cs.utexas.edu!news.ti.com!ief!clw
From: clw@news.fhlb.com (Chris Winemiller)
Subject: Re: Dolphin Smalltalk
Sender: usenet@ief.itg.ti.com (Mr. USENET)
Message-ID: <DuowxM.1369@ief.itg.ti.com>
Date: Wed, 17 Jul 1996 13:46:34 GMT
References: <31CC4ABE.6DDE@individual.com> <31D1BF28.3BFF@terracom.net>  <31E68D9C.67D9@terracom.net>
Organization: None
X-Newsreader: TIN [version 1.2 PL2]
Lines: 65

Dave Smith (daves@terracom.net) wrote:
: Andy Bower wrote:

: [snip]
: > Dolphin aims to be a small, low cost, ANSI X3J20 standard Smalltalk
: > targetting the Win32 platforms. It does this using pure byte code
: > interpretation (although a JIT incremental compiler is on the way)
: > which gives a tremendously small image size.

: Please don't jump to the conclusion that JIT is better. Obviously, you
: need the selling point of the hot new buzzword to sell your product; but
: _Please_ keep compatibility so that those of us who think JIT is the
: wrong approach can try to maintain managable image sizes and (at least
: in theory) simple, maintable systems. The VM must be kept small at all
: costs.

: > We have a very complete
: > implementation (around 450 classes) in an image of only 1.4Mb. Total
: > footprint with VM and other DLLs is around 2.5Mb for the entire
: > development system. Image stripping will be available for application
: > deployment. It's interesting in fact that only 70K of the 1.4Mb image
: > is actually bytecodes; the rest is live objects. This just goes to
: > show how compact the bytecode form can be.

: This is really gratifying to read. I've been complaining and complaining
: (on deaf ears) about Smalltalk system image bloat for a long time. It
: looks like someone was listening, though. 

: > Dolphin does not yet
: > support COM/ OLE/OCX but will do in the near future.

: _Please_ do not screw things up by going the way of all flesh
: (apparently) and doing a VisualSmalltalk  --taking the old system and
: just dumping more and more code into monolithic image blocks that
: everyone has to port. The support you talk about could be very
: intelligently supplied via DLL's that the _small_ Smalltalk image
: manipulates via wrappers. This combination of static speedy modules
: (provided by you or third parties) and dynamic byte-code control is
: ideal. I am really excited about your product.

: > Smalltalk MT comes at the problem from a different perspective. As far
: > as I can see it provides a FULLY compiled language with a fairly small
: > set  of classes. This means that it is VERY fast, and for small
: > programs it is fairly compact. They have produced a Smalltalk with a
: > direct access to the Win32 API going for a more MFC (C++) approach but
: > no MVC style application framework. MT can produce standalone
: > applications and DLLs with native threads. The MT base class set is
: > not very standard although OLE support is included. Currently MT is
: > Windows NT only (not 95) but I think this is set to change.
: > 
: > My suspicion (correct me if I'm wrong) is that, as the class base
: > increases, in Smalltalk MT, the application size will grow
: > prohibitively large due to the fact that all code is compiled (not
: > just incrementally).

: What they're doing is called linking. This seems to be an alien concept
: in Object land (at least, Smalltalk-land). I have no idea why. Why do we
: need "image stripping?" The system itself should _start Out_ stripped,
: and the developer _adds_ incrementally, modules to the package, _if_
: they are needed.

: [Note: This is not a flame, I love the product! Keep up the good work].
: Regards,
: DS

