James Webb Telescope will run a proprietary JS interpreter by a bankrupt company

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.

At Lockheed in 2004, which had recently lost their bid on James Webb, some of us were trying to tell folks at Nasa about Lua. In all fairness, a lot of satellites are running bizarre, one-off scripting languages created as needed. In the cases I know of, it was usually one junior engineer who made something without any spec. In the end they are always rigorously tested.

JS is not so uncommon in science, during my PhD I did electron lithography using a scanning electron microscope that you could (well, had to) program with JS. It was built by a German company, I don’t think it’s the same one that built the software for James Webb though.

This decision was apparently made some time ago, back when the software landscape looked pretty different. I have to wonder how many decisions we make now with software will live long enough to seem as questionable.<p>If prior longevity is used to predit future longevity it’s an interesting thought exercise to think of how you’d write software. If projected longevity were my concern for a system, I’d almost certainly want things written in C or C++, maybe Ada. If I wanted high level scripting, I’d probably embed a Scheme.

Is there a better source for this? The link takes me to a reddit page that in turn leads to an apparently deleted tweet

Brings to mind this article, a history of the rise and fall of Common Lisp at JPL, which was almost selected as the control language for their robotic space missions.<p><a href="http:&#x2F;&#x2F;www.flownet.com&#x2F;gat&#x2F;jpl-lisp.html" rel="nofollow">http:&#x2F;&#x2F;www.flownet.com&#x2F;gat&#x2F;jpl-lisp.html</a><p>And of course, JavaScript having its origins as a more marketable syntactic overhaul of Lisp for in-browser scripting, it&#x27;s not hard to see how we end up with JS on the JWST for many of the same reasons.<p>Like others, I tend to idealize space tech from a distance and imagine it using technologies that are across the board better, cooler, more pure than anything that stays on the ground. While the need for extreme reliability does change things a lot, it turns out most of the same forces that guide software selection anywhere else are at play there as well.

heres a live link. And paper. Sorry I&#x27;m on mobile.<p>FWIW, they are sending observation sequences marked up as some custom JS, and an onboard interpreter will turn those into C&amp;DH sequences and spool them out.<p>That decision seems arbitrary, given most onboard executives use a ... more standardized markup lang for sequences.<p><a href="https:&#x2F;&#x2F;www.google.com&#x2F;url?q=http:&#x2F;&#x2F;www.stsci.edu&#x2F;~idash&#x2F;pub&#x2F;dashevsky0607rcsgso.pdf&amp;sa=U&amp;ved=2ahUKEwjN-L6F6-jhAhVKslQKHe-LBqkQFjAAegQIBxAB&amp;usg=AOvVaw3MOdhMNkCpks-n5XuFVDG-" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;url?q=http:&#x2F;&#x2F;www.stsci.edu&#x2F;~idash&#x2F;pub...</a><p><a href="https:&#x2F;&#x2F;mobile.twitter.com&#x2F;alteredq&#x2F;status&#x2F;800858908851982336?lang=en" rel="nofollow">https:&#x2F;&#x2F;mobile.twitter.com&#x2F;alteredq&#x2F;status&#x2F;80085890885198233...</a>

wow, I’m suprised by all the people wanting to point out the cons with JavaScript.<p>It’s unfortunate and unnessecary.

What&#x27;s a &quot;proprietary&quot; JavaScript interpreter anyway? JavaScript (ECMAScript) is a standardized language with many implementations, and ES3&#x2F;ES5 is arguably one the most portable languages of all time.

The only thing wrong here is proprietary part.

Why is it even running JavaScript? That too for mission critical application.

Why not a language that has types, perhaps C or Rust? Even if they use TypeScript then still why not go something more lower level?

I think you have to look at the reality of the situation. The last 10 years have created a legion of developers who are really only familiar with JavaScript. They have never used a proper programming language and have either never learned or have forgotten what it takes to make solid software.<p>But in reality, that&#x27;s fine. They&#x27;ll muddle through on something like this, finally getting it to work through endless tinkering, and it&#x27;ll be fine.<p>Remember, the <i>entire</i> internet now pretty much runs on this premise. And it&#x27;s fine, right?