I would like to share some thoughts regarding any new trends in the design of
astronomical application packages.
I am a scientific applications and systems programmer with some 20 years
experience, about 7 of which have been in or near the astronomical community.
For the record, the other 13 years have been on medical imaging and avionics
display systems.
In that time I have seen much change in scientific computing environments. The
changes have been very exciting, with capabilities increasing seemingly without
bound. But from a users perspective, I will say it has been disappointing.
End-user functionality has improved drastically, certainly, but the users are
still encumbered with a bewildering array of interfaces, options, and
conventions. And programmers are forced to learn myriad details to package
useful algorithms in a friendly fashion. In short, the user has been the loser
while the technologists have been having all the fun.
This disparity is finally being taken seriously by the computing marketplace.
The reason is that now solutions sell, not computers. I think the trend towards
inventing new operating systems, network standards (including RPC and
client-server), and user interfaces is winding down in favor of *using* what we
have to build more and better applications. As evidence, consider the broad COSE
acceptance of CDE by the major workstation vendors and the consistency of the
various Windows GUI and IPC APIs in the desktop environments (Windows, 95, NT
and OS/2).
For me personally, in the good old days I loved working in the kernel as much
as anyone. In the 70s and 80s there were no dominant computing environments and
much explicit thought was required to insure any hope of portability. But I too
now want the users to benefit and am willing to let the underlying technology
be what it may.
So, a suggestion: in any plan for a next generation astronomical package
consider using only a very thin veneer, if any at all, between it and an
underlying operating environment. In particular, go ahead and use UNIX, CDE (X
Windows and Motif), POSIX threads, RPC and sockets APIs directly and existing
scripting languages such as perl.
The longevity and stability of these technologies are likely because they are
maturing and are powerful in their own right, but mainly because current
marketing emphasis on applications will tend to resist devoting resources
towards changing them. I do not think the fears of "locking into" one operating
system any longer apply. UNIX is my choice because it seems porting it to
brand-X is a challenge which is solved easily, often for free, as witnessed by
its available on the *86, PowerPC and Mac desktop architectures as well as all
major workstations.
I believe it best to concentrate precious software engineering efforts on
adding the real value: defining the file, message and object formats needed for
data interchange and the algorithms, not redefining new scripting, tasking,
GUI, and IPC mechanisms.
My experience has shown me that the "thin or no veneer" approach has direct
advantages of simplicity and performance. It also takes maximum advantage of
existing knowledge, both for programmers and the users, which any new
interfaces can not, by definition. At the risk of heresy, it is also my
experience, in spite of the grand promises of the Structured and now Object
Oriented methodologies, that no amount of preparation can fully prepare a
design for future change so I would caution against using that as a major
reason for any proprietary layers.
In summary, I am suggesting a minimalistic approach to any new designs. May I
observe that astronomical computing seems not so different from other
scientific or even business arenas, from which it follows that solutions which
are proving to be successful at large are also likely to serve this community
well. I realize the pivotal importance of laying a firm, well-designed
foundation. What I am emphasizing is that any new design process include
careful attention to keeping the foundation and basic infrastructure as small
as possible, and a big step in doing so is reducing the need for an artificial
portability layer.
Thank you all very much. I look forward to continued discussions of the
astronomical computing environment.
Elwood Downey
ecdowney@noao.edu
http://iraf.noao.edu/~ecdowney/resume.html
PS. In spite of my email address, I have no affiliation whatsoever with NOAO.
All opinions expressed here are entirely my own.