Scientific Computing

Les Tyrrell tyrrell at
Tue Sep 1 18:55:23 UTC 1998

Short answer: Smalltalk, which Squeak is based upon, is not intended
for the sorts of serious number crunching commonly found in engineering
applications.  These are typically large, monolithic, batch-style
processing applications where the emphasis is on getting numerical
results to be post-processed for later review after the computation
is over, whereas Smalltalk is well suited for highly interactive exploration
of abstract models.


Squeak is open, a bit of a new situation in the Smalltalk world.
VM's can be changed.  Provision for this is explicitly included
in the Squeak system.  One can easily imagine installing FloatArrays
like objects, much as we currently have with CharacterArrays, or for
that matter FloatMatrices.

I believe you would be able to get rather good numerical performance
for vector-style computation for many routine engineering applications.
I would not expect to be able to have good performance for high-end stuff
such as Direct Numerical Simulation of the Navier-Stokes equation over 
arbitrarily shaped complex three dimensional bodies, but then if you
are trying to do that sort of thing you have bigger worries anyway.

A bigger issue in my opinion is the extent to which the OO model fits
the way engineers typically think of numerical problems... mathematics
has a highly imperative, operational point of view, much more process
( or procedural ) oriented than object-oriented.  My impression is that
straightforward implementations of numerical algorithms are easier in
a non-OO language ( ie, a "kinder, gentler" variant of FORTRAN ) and 
that the problems we have using things such as FORTRAN are more due to
its ancient, archaic roots than the fact that it is a procedural

I know that there are folks out there doing Math in Squeak- I'd be
interested in seeing how they approach this, and hearing whether they
feel if this is an issue or not.  For myself, one of my first Smalltalk
projects was an attempt to build an unstructured Euler flow solver
so I am not at all opposed to this sort of thing.  Actually, I felt
that the interactive side of things had been neglected for far too
long in engineering computations.  Perhaps now I would be able to see
the problem more easily from an OO perspective, but then it was hard
to ignore the procedural character of the algorithms I was trying to
implement ( actaully, I did implement, but I didn't have the computational
power to run and debug them ).


More information about the Squeak-dev mailing list