Certainly we should devote some effort to defining the underlying
stuff, but that's something the proposed committee will be able to
handle well enough (possibly with more input from this list after the
conference). We should spend some time here, and reserve most of the
time at the BoF, for a discussion of what the customer wants. Most of
us are not good at that sort of sociological/psychological question --
we're trained as programmers and astronomers, not in the social
sciences, and languages like Perl show us that such training is
important to the success of a system (Wall is a linguist). Knowing
where we're going is as necessary as the details of implementation.
Since we're not going to be as coherent about it, we should spend more
time on it.
I'm talking mostly about command language and display interface, and
the general concept of how to package what is essentially programming
to people who consider IDL or CL to be "another programming language
to learn," on the same level as FORTRAN or C (as I heard expressed at
last week's DPS meeting). Of one thing I am certain: using C++ or any
other nuts-and-bolts real language interactively is doomed to fail
because it's too complicated. We ourselves might like a full-featured
programming language, but it will never fly in the community, and as
someone pointed out it didn't even fly where it was implemented.
Whatever we produce must be possible to use in a very naiive mode
without reference to types, pointers, addresses, classes of objects,
and so on. A language like Lisp might be the exception here, but Lisp
has problems with algebraic expression syntax.
Count how many astronomers have Macs or PC's on their desks and prefer
those environments to the Sun they grudgingly do their image
processing on. Realize that we need to teach classes of high school
and college students to use this new thing we're designing, because
the computational habits of non-computer people are set in the early
years when they have time to learn such things (witness FORTRAN's
continuing popularity, again). But many colleges, and almost all high
schools, only have Macs and PCs for their students. Most machines
that students (and even professionals) own at home are Macs or PCs.
Compared to these numbers, the Unix machines pale to a small fraction.
A Unix-only implementation will be DOA. Saying "let them run Linux"
is pretty Unicentric and will doom any system to failure. Yet, of
course the system must run under Unix or we won't use it ourselves!
So, if we want similar look-and-feel, and portable code, we need the
equivalent of a generic window system that can be implemented in terms
of all the popular real window systems. We'd like not to take too
much of a performance hit here, but portability comes first. What
window system operations do we want? I think we'll be surprised at
how many. Leaving this level of input to a small committee is a
mistake.
Someone mentionned Motif. Motif is a commercial product, so we
shouldn't use it at all. As a user, I see little that it offers other
than ugly windows and more complicated interaction. I understand that
it makes life much simpler for the programmer, but this isn't about
programmer convenience; if it were we'd just tell everyone to buy
off-the-shelf products like IDL, write our own stuff in our favorite
languages, communicate over pipes, and be done with it. For me, the
main benefit of changing everything about the way I do science is that
I will be able to do it at home, will be able to teach it to my
students, and will be able to hack on parts of the system I don't like
to make them better.
The standard idea for a palatable command language is to have one that
can do the basic by-hand operations easily but has more serious
programming capability waiting in the wings. History shows us that
this is hard. However, another idea, pioneered by IRAF, is to have a
command language for messing around and a real language for doing real
things. Unfortunately, IRAF made some poor design and implementation
decisions with CL, and few people want to waste time implementing
stuff in SPP because that restricts the application to being run only
under IRAF. Would a new command language for IRAF, complete
interfaces to compiled languages, and a modern graphics system solve
enough of our problem that we can wait for the larger computing
community to catch up, as it inevitably will? For all its utility to
us, I don't see FITS being adopted by anyone else in a hurry. It
doesn't even often get implemented as a standard format conversion in
most commercial software packages. Why do we think a new data
analysis system for astronomy will be any more successful? More to
the point, I think we should be reaching into the established
computing community more for solutions. Perhaps FSF would be
interested in adding the features we want in a command language to TCL
or Guile?
--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