Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!Piersol
From: Piersol@apple.com (Kurt Piersol)
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk for Scientific Applications
Message-ID: <3580@internal.Apple.COM>
Date: 15 Aug 89 17:01:04 GMT
References: 
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 39

In article  
peskin@caip.rutgers.edu (R. L. Peskin) writes:
> Smalltalk has problems that would prevent its ready acceptance by the
> scientific community now. But I feel these are correctable. 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?

This is an excellent question. The major problem with implementation of 
user primitives in Smalltalk-80 from PPS is the inability to walk and 
examine the object space from the primitive. This makes it virtually 
impossibe to efficiently pass complex data to primitives, thus severely 
limiting the potential of the userPrims.The best hope is to pass arrays of 
numbers to the primitive, which is at least fairly quick. Passing compound 
objects (to e examined by the code of the primitive) is not supported.

Were this remedied, the potential would be vast indeed.  Creating 
primitives to handle expensive calculations would quickly move 
Smalltalk-80 into the big leagues of scientific computing, particularly in 
areas like visualization systems.

The other difficulty, and I think a major one, is the volatility of the 
PPS image. It changes significantly about every six months. A 
vendor-independent standard for the language would be most welcome, so 
that inherently complex systems like hypertext and visualization packages 
needn't be built on foundations of shifting sand.

--Kurt

User Programming Group
ALink: PIERSOL.K