continue discussion?

Joe Harrington (
Wed, 9 Oct 1996 19:06:52 -0400 (EDT)

It was good to continue the discussion of data analysis systems at
ADASS this year, though I was somewhat disappointed that discussion at
the BoF was not as spirited as in Tucson. I have hope that we will
see a base system that does the gaming table job in the next year or
so. I had a brief email exchange with Richard Stallman following the
conference. He says there are free versions of both Java and Corba in
development, but thought that GNU's Guile language might be the answer
we seek. Although its native language is Scheme, it allows
transparent use of interpreters for other languages. One already
exists for a simple, C-like language, and others are under
development. Take a look at I will be in
contact with the author soon to determine the level of numerical

I think part of the reason for the lower level of participation this
year is that people are coming around to similar points of view and it
is time for someone to go and do a trial implementation of a system
taking advantage of "gaming table" concepts. However, I am concerned
because too many innovative system projects take the ball and run so
far with it that people don't recognize it when it comes back.
Examples are languages that don't do what we need, or that do it but
have a perverse syntax that nobody likes. While design reviews are
very common in most engineering disciplines, they are rare in software
projects, with results about as expected. If there is an active
discussion where the people doing the work can float ideas and get
feedback, perhaps we'll have better luck. To this end, I hope we can
continue our discussion over this list.

Let's start with two simple questions about existing packages. I
asked these at the IDAE BoF but seek more detailed answers here.
These are important because without good application routines, no
amount of glue is any use.

1. Let's say I am writing some routines to do image manipulation.
They are generally useful, so I would like them to be accessible to
people who use a wide variety of environments. However, they take a
lot of data, so the closer they are to the environment the better it
will be for the user (writing the data on the disk and having the
environment fork a shell that runs a stand-alone program will be
slow). At the moment, IDL can dynamically link to it as long as data
forms are C-like. How do IRAF, MIDAS, AIPS++ best get connected to
the routine? Others? What implementation strategy makes best sense,
so the wrappers I write for the environments are small and simple?

2. What would you need to do to make the routines in existing
environments (IRAF, MIDAS, etc.) available to be linked against? Are
some kinds of routines much harder than others? How hard would it be
to create an IPC interface to these languages? The reason is that
once you can link to a routine (or talk to it via IPC, or whatever),
you can access it from a variety of languages, and people can combine
the language of their choice with the routines from different