peskin@caip.rutgers.edu (R. L. Peskin) (08/14/89)
What about Smalltalk for the scientists?
While one can argue that what Smalltalk really needs to be "accepted" is
a "real" application (Analyst, PPS's C++ Object-Works?), I believe the
real test of an environment's acceptance is its use by the scientific and
engineering community. The software crisis in science and engineering
computation has become a critical matter; we can no longer afford to
divert our technical professionals away from their main tasks just
because they are saddled with 30 year old software technology. This
situation offers a unique chance for the Smalltalk community.
Smalltalk already has many of the features needed for modernization of
the scientific software environment. Dynamic binding together with
incremental compilation, integral graphical interface and MVC (or its
equivalent), simple language syntax, system access and extensibility all
are ideal for the "prototyping" of scientific simulations. Smalltalk's
extensive class structure offers the scientist access to the fruits of
many years of computer science labor; i.e. Smalltalk can be a vehicle to
effect the interdisciplinary interface between the scientists, engineers,
etc. and the computer science community. This interface is a major goal
of current research support policy.
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?
Scientific and engineering Smalltalk suffered a real setback when
Tektronix decided to discontinue its product. This leaves PPS and
Digitalk to carry the ball, but unless there is some interest from the
Smalltalk community at large, will these firms want to commit to the
changes needed for acceptance by the scientific community? Our group is
getting calls almost daily from physicists, engineers, etc. interested in
the possibility of using Smalltalk.
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.
--dick peskin <peskin@caip.rutgers.edu>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Richard L. Peskin CAIP Parallel Computing Lab
CAIP Center CN - 1390 Rutgers University
Piscataway, N. J. 08855-1390
net: peskin@caip.rutgers.edu
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--
goodbypeter@celia.UUCP (Peter Farson) (08/15/89)
In article <Aug.14.11.34.54.1989.15094@caip.rutgers.edu> peskin@caip.rutgers.edu (R. L. Peskin) writes: > > > > >What about Smalltalk for the scientists? > ........... > >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 > The issue of efficiency is certainly one that I think is one of the biggest potential obstacles to the more widespread use of Smalltalk. While the sort of work I do (computer animation) is not really science or engineering, many of the same concerns come up in my line of work. I find that the usual C language environment is very inflexible. It is usually difficult or impossible to have a compiled module load in an independently compiled module at runtime. The standard C library does not include the C compiler as one of it's functions. The UNIX environment is poorly integrated when compared to the Smalltalk environment. A lot of this is not necessarily a characteristic feature of the C language, but just a holdover from earlier days, when more computing was done batch-style. I believe that the qualities that make C very efficient can be retained while implementing it in a way that is more conducive to interactive development. What I would like to see is Smalltalk that had a good optimizing C compiler function, so that the software developer could compile a C primitive just as conveniently as a Smalltalk method. I somehow don't expect that this will be available very soon. -- Can a bee be said to be Peter Farson An entire bee if celia!peter@tis.llnl.gov Half the bee is not a bee ...{ihnp4,ames}!lll-tis!celia!peter Due to some ancient injury?
Piersol@apple.com (Kurt Piersol) (08/16/89)
In article <Aug.14.11.34.54.1989.15094@caip.rutgers.edu> 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
obrien@aerospace.aero.org (Mike O'Brien) (08/16/89)
In article <Aug.14.11.34.54.1989.15094@caip.rutgers.edu> 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
peskin@caip.rutgers.edu (R. L. Peskin) (08/16/89)
> 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. Agreed. We have also found that effective use of the userPrims generally means restricting them to cases where computation time dominates over "communication" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Richard L. Peskin CAIP Parallel Computing Lab CAIP Center CN - 1390 Rutgers University Piscataway, N. J. 08855-1390 net: peskin@caip.rutgers.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -- goodby
peskin@caip.rutgers.edu (R. L. Peskin) (08/16/89)
>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. For what it is worth, Tektronix last (& final, I think) Smalltalk release does support userPrims (wriiten in C) that share object memory. > >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. We also feel that some sort of "rapid" generator of primitives (starting with Smalltalk code) is going to be essential. It would allow users to develop prototype models and then move them to efficient instantiations. > --dick %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Richard L. Peskin CAIP Parallel Computing Lab CAIP Center CN - 1390 Rutgers University Piscataway, N. J. 08855-1390 net: peskin@caip.rutgers.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -- goodby