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