It seems this list fell rather silent after the ADASS '95 meeting. Let
me see if it is still alive...
Not being a software developer myself, there are two things on my mind,
one in response to what has been said in Tucson, and one that I would have
liked to bring up, but didn't consider appropriate at the time.
1. It was discussed that the time of large monolithic packages has maybe
passed, and that perhaps now we should look at creating libraries, with
contributions from everywhere, from which packages for specific purposes
may be assembled. It seems to me that people did agree with the concept,
but didn't know how to go about it. Being a relative outsider (I have to
make available to astronomers and then support what you folks are coming
up with) I believe the software developers in astronomy have a communication
problem. Your are sitting there, sometimes for years, developing your
packages, and only coming out with them when they are completed. I understand
that, in the better organised groups, developers present regular updates
on their progress, but these are kept within the groups. If there is a
serious interest in libraries of routines and algorithms, then you
should come out with each chunk of software immediately, and present it to
the entire community (we could arrange for proper credits being kept with
each such bite of software). Such practise does, of course, require a
proper platform, like a(n electronic) journal. Could anyone suggest one,
or would we have to set up one (which then might cover `Information Handling'
in astronomy in its widest sense, including developments concerning
electronic publishing, and on-line databases and information systems).
1a. A concern: when senior staff understand that there is a library of
routines from which e.g. reduction packages for specific purposes may
be assembled, what incentive would they have to keep supporting a
whole software group? Let the astronomers or their software engineers
(each astronomical institute has one or two) do it themselves!
2. Supporting astronomers in their use of software packages, I find that
many packages are pretty hard to install. Has anyone out there ever heard
of GNU, and the GNU standards for porting and installing software? There are
three aspects in software installation:
1. configuration
2. compilation and installation
3. verification
ad 1. Today most packages come with lengthy README and INSTALL files (or
chapters in their manuals), which require carefull reading, and answering
of many questions (mostly by setting environment variables). These things
can (and hence should!) be automated: see the `configure' scripts
accompanying most of todays GNU software. Please realize that when your
package is used at 100 sites, 100 system administrators have to go
through your arduous procedures. Think of what the astronomical community
might save (in terms of labour, which may be directed to other purposes),
when a single or a few persons take their effort just a little further.
And I believe this may be asked from you, since most astronomical
software developers work at international organisations which are being
kept alive on contributions from many nations and national institutes.
ad 2. The `monolithic' packages of today often come with hundreds of
executables. In Unix environments, all of these packages are competing
for space in the /usr/local/bin and /usr/local/lib directories.
When you have say 10 of such packages on your system (not uncommon at
university affiliated astronomical institutes: astronomers use whatever
they need, which in most cases is not just one single package), that amounts
to thousands of files. What I would like to see is a scheme like this:
/usr/local/lib/<package>/bin
/lib
/etc
/...
and a single environment variable pointing at the top of the package, plus
a script that sets everything right for proper use of the package.
Such a scheme would allow for much cleaner system administration.
ad 3. Note that most packages are `ordered' by astronomers, but installed
by systems people. Most packages have never heard of a verification
procedure, but when they have, reference is made to the user's (astronomer's!)
manual (IRAF). Such a procedure is hard to understand for a system manager,
who will leave it to the astronomer, who will then have to come back to
the system manager to have adjustments made, who will then have to turn
to the astronomer to do the verification, who will then... The best
verification procedure that I have come across so far is the TRIP test
that comes with TeX. After installation of the package, you run the trip
test, and compare the log file of the test to the log file produced from
the original implementation at the developer's site. When they are the
same, you can rest assured that the local implementation contains no
bugs, other than the ones in the developer's original... I would claim that
the lack of a verification procedure for local implementations of
software packages is improper, from the point of view of computer
engineering, as well as from the scientific point of view.
-- Sake J. Hogeveen, Astronomical Institute, Utrecht University, Princetonplein 5, P.O. Box 80000, NL-3508 TA Utrecht, The Netherlands. Telephone: +31 (0)30 2535227/5200, Fax: +31 (0)30 2535201, E-mail: hogeveen@fys.ruu.nl.