I led the team that created the JavaScript interpreter JWST is using, and I still occasionally work with them on it. 16 (or so) years ago I was blown away at the amount of research NASA did covering all of the control language options, and of course glad that they selected ours. The language itself wasn’t so important as having adequate performance, robustness, memory use, reproducibility and extreme QC.. the way I remember thinking about it was that when your system is running a million miles away, you can’t send an IT tech to press ctl-alt-del when something goes wrong. IMHO they made a well-researched choice that continues to hold up.
I write JS professionally, and I can't fathom why they would use it on something so important and correctness-critical. Can you shed some light on that?
Edit: Thinking about it, I have read that Lisp was used for early NASA missions because of its ability to be rewritten in-place, which JS mostly shares. Still, JS has so many weird quirks and so easily throws exceptions. And it can't be very fast at processing images. Maybe it's only used for high-level control logic?
> And it can't be very fast at processing images.
Why not?
Because it's a very a CPU-intensive task? It's all relative, but in 2003 JS was one of the worst languages you could possibly use for that. Of course it's moot if they aren't actually planning to use it for that side of things.
Speed can vary from interpreter to interpreter. I haven't seen any benchmarks of this interpreter, so we don't know how fast it may be. Maybe their JS interpreter applies some restrictions to the language that greatly speeds it up?
Or has special primitives for CPU intensive tasks.
I very much doubt they JIT anything, because of the associated fault risk. So it's going to be an interpreter implementation. That means inner loops will run rather slowly. It could still use image processing library, sure.
I doubt NASA wants to do much image processing on-board in the first place. Mostly just lossless compression and maybe some thumbnailing, if they can't download everything.
It's used for sequencing. Think game scripting, except for a machine. The instruments / data handling is not in JS. None of the key functionality runs on a virtual machine or interpreter (I'd stake a lot on that). But, for instructions that must be human readable and machine readable, which are uploaded from ground stations, you sometimes want a scripting language like LUA or JS.
From what I understand of satellites and rovers, the only parts which are totally critical to get right are the modem, power to the modem, and bootloader. Almost everything else can be adjusted if a fault occurs (and they often are).
That works if you have a low data rate, last ditch omnidirectional antenna fall back. Otherwise for deep space satellites you've got to run quite a bit of stuff to get and perhaps keep the antenna pointed at a transmitter, which for a satellite includes station keeping functionality.
Imagine FTP-ing into the telescope to change some JS-files live, then just "refresh" and see what happens. They are probably using a simulator, and run tests before deploying the JS code. The tooling around JavaScript has come a long way, with type checkers, static analysis, code coverage, debugging, etc. The language itself is also very safe (hey, we are executing trustless JS in the browser). What do you mean by weird quirks ? The only thing that still annoys me are float's.
> What do you mean by weird quirks ?
- undefined vs null vs empty
- the pile of weirdness that is ==
- the other pile of weirdness that is implicit truthiness/falsyness
- NaN's many fun qualities
https://www.destroyallsoftware.com/talks/wat
Ohh yeh, I think the equality table is just something you have to learn, like a chemist learn the periodic table. I make use of null==undefined a lot and prefer it over thruthy/falsy. I try to avoid NaN but sometimes use isNaN(nr)
So it seems that though the scripting language is nominally, and maybe even syntactically "JavaScript", the engine interpreting the code has been honed to ensure consistency and reliability. Since JS 3.0 is being used, I assume it's a lot simpler interpreter, no JIT involved, etc.? I'm curious as to what they might have removed/changed/fixed in the language?
It'd be nice if they differentiated sequencing from hardware control a little clearer in this conversation. Is anyone controlling adaptive optics or running signal processing in js? I think very much not.
Were the results of this research made public? If so, could you, please, share them?