Re: ALMA Science Software Requirements - an alternate spin

[Barry Clark <bclark@aoc.nrao.edu>]

With respect to Steve Scott's viewpoint, I'm entirely in agreement that
one doesn't really want to let astronomers look at a script, or cut and
paste old ones forever to run the telescope for all his observing.  A 
script is primarily a programmer's diagnostic tool, and a very powerful one.
Astronomers will use a scheduling tool with whatever bells and whistles
suit their fancy, which writes a script for the real-time system, 
preferably so seamlessly that the astronomer doesn't know it exists.

I am enthusiastic about using macros (maybe even with one parameter,
though I'm not entirely convinced that one is necessary).  Whether these
correspond to Steve's "blocks" I'm not sure.  They can make the script
a lot more readable, even for programmers.  I'm against a great more 
complexity.

It is not at all clear to me whether information needs to be passed from
the observing tool to AIPS++ (or whatever).  And it is especially unclear
to me that the real-time system needs to know about it if it does.  I don't
think so.

I am unenthusiastic about
> o One set of tools can be used from preparation to running the 
>   instrument. This should include viewing the log or history of
>   what has been done with the instrument. Note the utility of the
>   hierarchical approach for this particular task.
I think we will have people wanting to use too great a range of observing
styles to be happy with a single tool.

In my own stuff, I'm guessing that it takes about twice as many man-hours
to do something on the real-time system as to do the equivalent in the 
non-real-time world.  This is a powerful impetus to keep the real-time
world as simple as possible.  An ascii script is about as complex as I'd
like to go.  Looping is probably worth having.  (I did the VLBA control
system without macros and with looping - both mistakes.)

The design of the scripting language is strongly affected by the question
of whether we want to allow observers to divide their antennas into 
subarrays and to swap antennas freely between them.  It adds complexity,
but I can see it might be desirable.