From a technical standpoint, how practical is it to divorce the
interactive/scripting language from the guts of the system? Let's say
I really like C, my friend likes Lisp, and my advisor is a
dyed-in-the-wool FORTRAN addict. For maximum intuitiveness, fastest
learning curve, and also for rapid prototyping, each one of us will
prefer an interactive language whose basic constructs and behavior are
like the compiled language we prefer (flow control, blocking, argument
passing rules, data structures, etc.), but that has the "hair" removed
(declaring variables, allocating memory, dealing with types).
Ideally, we should all be able to make use of the same analysis,
display, and plotting routines. I'll take it a step further and say
we should even be able to call routines written by each other in
different scripting languages. The idea would be that the system core
(Jan's Gaming Table) would take care of managing the objects and
connecting to dynamically linked modules, including those that handle
interpreting the different languages, plotting, etc.
The question of course is what objects to use. Jan has suggested
standardizing on the AIPS++ objects, but I suspect that everyone will
have a different idea about exactly what should be part of a given
object, so there must be some way of extending or modifying an
existing object, right from the scripting languages, with instructions
for converting it to the vanilla object when the time comes to call
someone else's routine. And of course, once we have scripting
language modules that we like, we will want to have them compiled and
fully optimized.
In reply to Doug's posting, I just spent the greater part of a day
slaved to a graphic artist and his Mac, because there's nothing like
Adobe Illustrator on Unix. I'd sure like to have something like
Illustrator as part of my interactive environment, without needing to
buy 2 computers. Supposedly they will be releasing Illustrator v6 on
the PC some time this year, in which case Linux is a partial savior.
However, I'd still be rebooting a different OS each time I used it.
The slides look great, but I learned one hard lesson: Even if you
designed your paper's figures to look good when projected as a slide,
you can't close the gap. You want to add color, you can't fit as much
text, and the font and line weights need to be much heavier on a
slide. Has anyone considered making a WYSIWYG graphics system that
lets you set options, so when you go to dump your PostScript file you
can ask for weights and colormaps appropriate for print, viewgraphs,
projector slides, etc.? Going into a complicated graphic and changing
all the line weights is a real pain! Because we often make changes in
figures as a result of automatic processing of data, such a system
would need to be able to read automatically-generated data and replace
the existing representation of those data in the graphic. An example
here is a graph with titles, colored background, axes and labels, and
snazzy annotation, etc., for which you need to generate 100 versions,
each with different actual data. After the interactive layout, you
would want the rest to be noninteractive.
It's embarrassing how much better the individual workhorse
applications are on Macs and PC's. And it's embarrassing how little
else you can actually do on those computers. I would suggest that
most of what we want already exists in pieces, and that it's a matter
of creating the core and interaction standards that let them work
together. I wonder if that's called an operating system? I hope the
problem isn't that large.
--jh--