> 1. On Scripting Languages
>
> I was thinking about scripting languages for my ARCTIC distributed
> computing environment when it hit me: with an appropriate
> communication library and a simple convention for defining the
> capabilities of server modules, my scripting language can be C++!
I just wanted to sound a warning that we found, to our dismay, that
having a programming language such as C or C++ as a scripting language
didn't work very well in practice.
Some years back, we wrote a multi-tasking C interpreter to serve as the
front end to a system, and it was responsible for (1) high-level
telescope-control / data-acquisition, and (2) data analysis abilities.
It had a good built-in command-line editor with emacs and vi modes; it
had a small set of extensions to make it an effective interactive
system; and in general we were expecting a resounding success.
Yet it turned out that some of the very features that make for a good
compiled language make for a bad interactive and scripting language.
For example, strong typing is an obvious plus in a compiled language,
but it can be a real annoyance to someone writing a tiny script. More
recently, perl has had to deal with the same issue: typing is tricky
because of the dual use of perl for both tiny one-off scripts
and large packages.
-Will
P.S. Not directly relevant, but for those who may want to know what
happened to this package: in the end, we hid the C interpreter by
providing Yet Another Pre-Processor (YAPP) lying between the command
line editor and the C pre-processor. The YAPP preprocessor made it
easy to write things like
Point Telescope at xxx, yyy
and it simply translated these statements to C.
We (the programmers) thought this was a lovely solution: it looked like a
standard sort of command-line interface when the user wanted it, but C could
be intermixed freely to use its power wherever desired, such as for
flow control.
But the proof is in the pudding, and in the end the C interpreter was
abandoned, and some nasty commercial package used instead.