I've been dissatisfied for some time with the offerings of the
monolithic packages. Like most hacker/astronomers, I'm further
frustrated by the amount of time I don't have to do the job right and
save humanity as we know it; doing good things like that rather than
real work is likely to lose you your job. Nevertheless, a number of
us at Goddard recently had a bull session to see what we could come up
with as our dream data-handling environment. Here are some thoughts.
We swiftly divided into two groups, those who hack and those who don't
(I'm of course using the benign form of the term hack here). The
non-hackers were plainly surprised at some of the things we were
suggesting. To them a language like IDL is a liberation from Fortran
rather than imprisonment after C (never mind something more modern).
Though uninformed about the state of the art, they were nevertheless
excited by the prospects we discussed. Their input was valuable
because they are the market that anything new must first appeal to.
Their principal concerns were that the new system be easy to learn, be
graphical (at least on the outside), and that their previous
investment in programming not be lost.
Here are the main points of what the rest of us came up with:
It must be free and available with source to everyone. There was some
fear of what would happen to our investment in software developed
under professional packages like IDL and AVS, should their
manufacturers go under -- as AVS nearly did. I don't think I need to
preach the advantages of open development to this community, so I
won't.
Rather than being a monolithic data-handling environment that defines
your limits, it should consist of pieces that each do a job well, and
interface standards that let the parts talk to one another. Thus, it
might have a scripting/interaction language and scripts that work in
it, but you might call a module from that language that you or someone
else had written in Fortran or Lisp. In principle, you shouldn't be
able to tell when reading the script whether the module is an inherent
part of the language, is written in the scripting language, or is
written in a compiled language. Someone using the GUI would likewise
be able to use that module. My guess is that the best way to handle
this kind of interaction is to reduce everything to object code and
use dynamic linking, but others may have better ideas. I understand
that TCL is good at this, though I haven't tried it yet.
People want their IRAF and IDL (etc.) programs to keep working. It
seems to me that these languages are relatively simple as such and
that some sort of conversion utility would be worthwhile. Obviously
I'm just talking about the language itself, not the modules those
packages supply (though there is no reason why not implement the same
functions for compatibility). Also useful would be a wrapper
capability that let you call these packages directly from the new
system.
AVS provides a powerful way to incorporate existing code into its
system: it provides C and Fortran libraries that have functions you
include in your code wherever you want it to talk to the rest of the
system. You start AVS and your program pops up looking just like any
other AVS module. It has widgets that you use to give input
parameters and it produces outputs in the form other modules use.
This is very powerful because you can buy their stuff and spend an
afternoon putting the calls into your code, and you're up and running
with a real visualizer rendering your model's output.
The core item in any data-handling package is the interactive mode.
The languages offered to date are frankly primitive: they stink of
Fortran and have too many limitations and unnecessary burdens built
in. They don't conform to even simple computing community standards,
like emacs-like line editing, remappable keys, etc., though some
provide poor implementations of some of these things that are perhaps
more annoying than not having the capability at all. On the other
hand, the "real" scripting languages don't let you handle real data
objects in memory, and don't have built-in operations between such
objects. IDL is very strong in this regard, and IRAF is notoriously
weak.
There is a lot more to cover that we can discuss at the BoF. Symbolic
math capability, plotting, etc. I think the key to starting it off is
to define the interfaces between the modules in an expandable way,
decide on an interactive/scripting language, expand it to handle the
kinds of objects we need it to handle (which means we need to decide
what those are), and implement the interface routines and some basic
analysis and display stuff. We release that as a development package
and solicit extensions and improvements from others. We provide good
means for communicating among the users and developers, and between
the two groups as well. We pay good attention to the community when
deciding what extensions to accept.
Properly nurtured and well managed, I think such a system would
quickly become popular in a diverse community much larger than just
astronomy. It would become extremely powerful because of the modules
contributed by a large group of users (as has happened with AVS, IRAF,
Linux, and to some extent IDL). Unlike the monolithic packages,
however, the core system would remain relatively small and simple to
learn.
Obviously one additional topic for the BoF is how to manage the
creation of such a package.
A final note. It is increasingly important to support Macs and
PC's. These are the systems found in schools, homes, etc. It will be
much easier to design such support in from the start than to stay in
the Unix world and regret it later.
--jh--
Joe Harrington
Goddard Space Flight Center
Code 693
Greenbelt, MD 20771-0001
(301) 286-9130
(301) 286-0212 fax
Building 2 Room W130
jh@tecate.gsfc.nasa.gov