[evla-sw-discuss] Implementation languages for the observing layer

[Barry Clark]

It seems to me that we should consider the scripting-language/
implementation-language pairs listed below.  (I include with minor 
comments.)

glish/C++
This is the pair chosen for AIPS++, and would therefore have the
advantage of using a lot of stuff developed by the AIPS++ group.
On the minus side, glish is now supported by NRAO, and the 
enthusiasm for continuing to do so is not very great.  It seems
to me a poor choice for a new system.

Python/C++ via CORBA
This is the route chosen for ALMA.  It has large advantages in that
CORBA handles a lot of the differences between how things are handled
in the two languages, and pretty flexibly lets you transmit data 
from the script interpreter to the underlying code.

Python/C++ directly linked
Higher efficiency than the one above, but I suspect that one 
would be driven to passing only atomic data types between the 
two languages because anything more gets rather messy.  On this
grounds, I think I would recommend against this choice.

XML/C++
Rather tidy, in that an observation descriptor would suddenly 
appear full-blown as a structure.  But it is less than clear to me
how to handle differences between antennas (eg to designate a
reference antenna for holography, and the like), or how to handle
subarraying.  This can probably be resolved, but it would take quite
a bit of thought to be sure.

TCL/C++
This is the choice of the GBT.  Other than that, I don't know enough
about the combination to make a sensible comment.

HomeBrew/C++
Possibly starting from the script parser currently running in the 
VLBA correlator.  We would make such a thing do exactly what we want it
to do, not much more, not much less.  This would give us the future
flexibility that we could decide for new features whether to add them
to the parser or at a level above or below.  This route has the 
disadvantage of a fair amount of initial work to make it go in the first 
place, though probably only a few man-months.  Such an approach might 
become a maintenance problem, though the ones running in the VLBA 
correlator and the VLBA stations have not proved to be.  (The one 
running in the the current VLA hasn't been a maintenance problem per se, 
but getting Observe/JObserve to do what it would like them to do is a 
bit of a problem.)  The only significant advantage this offers is that 
everything else places one at double jeopardy - a significant lack of 
support for either side of the language pair would put us in a major bind.

Jython/Java
This has the major advantage that the integration seems pretty tight 
(one can just import Java Classes), without having to go through the
IDL mucking about necessary with Python/C++ via CORBA.  Seems very 
attractive on the surface, but I haven't looked very deeply.

XML/Java
Same comments as XML/C++.  Both included here in hopes of inciting a 
religous melee over the question of whether Java or C++ is more likely 
to be around in the far future.

TCL/Java
I see no possible advantage over Jython/Java.

HomeBrew/Java
I find this less attractive than HomeBrew/C++, though the difference is
small.


Is there any other pair we should be considering?