Python and spacecraft onboard or ground control scripting

[Donn Cave]

Quoth Jeff Shannon <jeff at ccvcorp.com>:
| In article <3cb8a237 at news.mhogaming.com>, 
| Ken.Peek at SpiritSongDesigns.comNOSPAM says...
|
| > ...  If you do not intend to operate the
| > spacecraft in 'interactive mode', then why use a scripting
| > language at all?
|
| For the same reasons that one uses a "scripting" language in any 
| other project -- speed of development, plus clearer, easier-to-
| read code (thanks to less boilerplate).  Which leads directly to 
| easily maintainable code and simpler software upgrades.
|
| Note that the term "scripting language" is a very imprecise term, 
| and it's arguable that it doesn't strictly apply to Python.  
| Python is an interpreted general-purpose language, which is 
| useful for scripting (among other things).  Then again, there are 
| some people who use C as a scripting language...

Sure - especially if you take it in the most useful sense,
application scripting, in which case the nature of the language
is more or less irrelevant once you have access to the host
platform's scripting API.

If I were promoted to spacecraft programmer, Python's attraction
for me would be mainly its storage (reference counted "garbage
collection") and exceptions.  The storage policy (which by the
way would favor C Python over Java Python, since the latter's
implementation is as I understand it less predictable) solves a
lot of problems that make library interfaces gnarly (and subject
to bugs like buffer over-runs.)  The exceptions also simplify
library interfaces, though here I would be more worried about
surprises - it's an attraction, but it does carry its own problems.

None of these requires an interpreter, which I think might have
been the point of the question.  I can't imagine anyone would
have a reason to specifically want an interpreter for an application
like this, given the choice, but we usually aren't given the choice.

	Donn Cave, donn at u.washington.edu