🚀 go-pugleaf

mccalpin@perelandra.cms.udel.edu (John D. McCalpin) ("jdm>") writes:
in response to cammerdl@camme.UUCP (rdl De Langhe CAMME project) ("rdl>")

rdl> Would it not be much more easy and efficient if these scientists could
rdl> use an algebra-like programming language, in which they can easily 
rdl> recognize errors, or proof correctness of an algorithm, etc. and let some 
rdl> kind of a source-code generator parse their expressions into C 
rdl> (or FORTRAN) ?

jdm> This is certainly one of the weakest areas in the field of "scientific
jdm> programming".   
jdm> 
jdm> I found a very interesting article in the Journal of Computational
jdm> Physics in 1966 describing a package written in Algol which wrote 3D
jdm> plasma dynamics programs in Algol.  Since this work was done in
jdm> 1964-1965, it is a bit shocking that in 25 years such techniques have
jdm> made such negligible intrusion into the day-to-day activities of
jdm> scientific programmers.

Generation of standard Fortran or C code to evaluate an algebraic expression
has been a standard feature of symbolic algebra programs such as MACSYMA 
for at least 15 years.  Mathmatica supports similar functionality.
I have never seen it used much.  Anyone care to speculate on why this is?
 
jdm> The introduction of higher-level/object-oriented languages will
jdm> presumably make the construction of many programs easier, since a
jdm> collection of "building blocks" can be constructed to take care of a
jdm> lot of the coding detail.   Ken Wilson's group (then) at Cornell was
jdm> using C++ for such a project.  I heard that Wilson left Cornell, but I
jdm> don't know where he went, or if the "Gibb's Project" followed him.

I have heard alot of enthusiasm for object oriented programming, but
it seems like you can create incompatible objects almost as easily as
non-shareable libraries.  I hope I am wrong.

jdm> John D. McCalpin			mccalpin@perelandra.cms.udel.edu

David States