Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!usc!aero!aerospace.aero.org!obrien
From: obrien@aerospace.aero.org (Mike O'Brien)
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk for Scientific Applications
Message-ID: <56023@aerospace.AERO.ORG>
Date: 15 Aug 89 19:58:56 GMT
References: 
Sender: news@aerospace.aero.org
Reply-To: obrien@anpiel.UUCP (Mike O'Brien)
Organization: The Aerospace Corporation, El Segundo, CA
Lines: 55

In article  peskin@caip.rutgers.edu (R. L. Peskin) writes:
>
>What about Smalltalk for the scientists?

I can agree with this.  It's the best programming environment I've
hit (I don't LISP).  However...

>Smalltalk has problems that would prevent its ready acceptance by the
>scientific community now.

No kidding.

>Lack of
>double precision (here now in SmalltalkV, and coming soon from PPS), lack
>of more complete numerical classes such as complex numbers (also easy to
>add and coming soon), lack of mathematical fonts, etc. are just some
>examples. Two major criticisms, slow numerical operation and poor
>graphics are more difficult to solve. But the access to user primitives
>show the way toward solution. (We have demonstrated feasibility of fast
>numerical performance by use of user primitives to access method
>proceedure on high speed computers via distributed computing. We have
>also shown the feasibility of user primitives to allow integration of
>"real" hardware level graphics into Smalltalk.) The technical
>underpinnings are here, but is the commitment?

Well, this is where I might disagree a little.  I too have added RPC
to PPS Smalltalk, using user primitives, to interface to a Prolog
engine.  The problem is that no matter how you slice it, RPC can be
s-l-o-o-w.  And when you add the overhead of argument type checking
in user primitives, even doing your arithmetic there can be awfully
time-consuming, unless you limit it to higher-level procedures like
FFT and statistical techniques.

Smalltalk needs to beef up its run-time compiler (thank you again,
Mr. Deutsch) to be able to do double-precision arithmetic speedily.
And user primitives have to be very carefully thought out, and very
fast.  Otherwise it's just useless for number-crunching.  The notion
of having all the number-crunching done in separate modules held
at arms' length just falls apart when you realize that it's the creation
of those self-same modules that we're trying to optimize, here.

Objectworks for C++ seems to be a step in this direction.  I've not
used it (yet) so I don't know how good of an attack on the problem
it represents.  I'm not just totally wild about C++, though, I can
say that.

>How many of you out there in "Smalltalk net-land" are interested in these
>problems associated with scientific use of Smalltalk? Let's hear from
>you. Also, is anyone interested in a "bird-of-a-feather" session on this
>topic at OOPSLA this Fall? If so let's here from you also.

Sounds like a plan to me.
--
Mike O'Brien
obrien@aerospace.aero.org