[Matrix-SIG] a full-blown interactive data analysis environment

Paul F. Dubois dubois1@llnl.gov
Mon, 18 Jan 1999 10:57:23 -0800


My system for wrapping Fortran 77, called "Basis"
(http://xfiles.llnl.gov/Basis) has been in existance almost 15 years now.
Perhaps 200 applications have been written using it by tens of different
authors. Basis contains a system that is very much like SWIG, and a
user-interface language that is very much like an interpreted Fortran 90.
Here are some observations based on that "database" of experience:

a. The fact that the interpreted scripting language has to be used by both
authors and end users makes it crucial that said language is simple to learn
and not "computer-sciency". However, these users are smart and some of them
will push the language to its limits, so it should be powerful.

b. Contrary to the image presented in Mr. Harrington's discussion,
invariably *three* layers of code develop, not two. There is the compiled
code (in Fortran, C, and C++ as he said), then there is interpreted code
written by the authors, and finally the user's own input. Frequently, of
course, the users of a given application chip in with utility routines in
interpreted language that are put in a library.  The point I am making here
is that the authors of the compiled code don't like writing compiled code as
much as writing interpreted code and so after a while they only do that for
the time-critical parts of the code, and do everything else they can in
interpreted code. The more capable the interpreted language (such as having
array operations) the less compiled code gets written.

c. We have seen great utility in the compiled code interacting with the
interpreted code. To give one example, a tokamak modeling code may check to
see if the user has defined a certain interpreted array and if so use it as
part of a model component, otherwise sticking to some built-in analytic
model.

d. Whatever the merits or not of any given GUI interface, it is important
that the code be runnable as a batch process. Therefore, having a scripting
language base is important no matter what the superstructure may look like.

It was considerations like this that has led to interest in Python at LLNL,
and why we want to strengthen the NumPy facility.