Can't wish away the power, memory, and speed issues JavaScript has, meaning the telescope must have all three to burn.

I've written a Javascript engine back in 2000. I came away from that with a distaste for dynamic typing. It seems easier to write code with dynamic typing, but I wouldn't give it many points for robustness. JS has many odd behaviors if an unexpected type was passed to a seemingly simple function.

You've sidestepped my question though :) Why do you think NASA made the decision to use it? Is it not possible there were legitimate reasons?

The implications you're suggesting about power, memory, and speed, or even predictability in semantics, depend on the particular language spec they implemented (it was not standard ecmascript), how they implemented, and how that implementation was used within the larger system.

It seems to me like just knowing it was javascript (for some definition of javascript) is not enough.

> Why do you think NASA made the decision to use it?

Probably because they couldn't find low level programmers, it isn't easy to find people with good professional experience in C today, especially if you pay NASA wages.

This is certainly not the case. For more details do a little exploring in the link I provided above. For one, the bulk of their code is low-level, just not this particular system where it wouldn't have made sense; for two, they did this in 2002 when it was almost certainly easier to find C programmers than javascript programmers; for three, the people writing this javascript were domain experts, not professional programmers.

Some people would kill for the ability to put a 1/2-year NASA stint on the resume, if for no other reason than the idea that they contributed to the scientific research and exploration of space.

Javascript in those days was far slower and needed much more memory and power than native languages. Nothing in your link suggested otherwise.