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