The James Webb Space Telescope Runs JavaScript, Apparently (theverge.com) 60
It turns out that JavaScript had a hand in delivering the stunning images that the James Webb Space Telescope has been beaming back to Earth. From a report: I mean that the actual telescope, arguably one of humanity's finest scientific achievements, is largely controlled by JavaScript files. Oh, and it's based on a software development kit from 2002. According to a manuscript (PDF) for the JWST's Integrated Science Instrument Module (or ISIM), the software for the ISIM is controlled by "the Script Processor Task (SP), which runs scripts written in JavaScript upon receiving a command to do so." The actual code in charge of turning those JavaScripts (NASA's phrasing, not mine) into actions can run 10 of them at once.
The manuscript and the paper (PDF) "JWST: Maximizing efficiency and minimizing ground systems," written by the Space Telescope Science Institute's Ilana Dashevsky and Vicki Balzano, describe this process in great detail, but I'll oversimplify a bit to save you the pages of reading. The JWST has a bunch of these pre-written scripts for doing specific tasks, and scientists on the ground can tell it to run those tasks. When they do, those JavaScripts will be interpreted by a program called the script processor, which will then reach out to the other applications and systems that it needs to based on what the script calls for. The JWST isn't running a web browser where JavaScript directly controls the Mid-Infrared Instrument -- it's more like when a manager is given a list of tasks (in this example, the JavaScripts) to do and delegates them out to their team.
The manuscript and the paper (PDF) "JWST: Maximizing efficiency and minimizing ground systems," written by the Space Telescope Science Institute's Ilana Dashevsky and Vicki Balzano, describe this process in great detail, but I'll oversimplify a bit to save you the pages of reading. The JWST has a bunch of these pre-written scripts for doing specific tasks, and scientists on the ground can tell it to run those tasks. When they do, those JavaScripts will be interpreted by a program called the script processor, which will then reach out to the other applications and systems that it needs to based on what the script calls for. The JWST isn't running a web browser where JavaScript directly controls the Mid-Infrared Instrument -- it's more like when a manager is given a list of tasks (in this example, the JavaScripts) to do and delegates them out to their team.
JavaScripts? With an S? (Score:3)
I thought the plural of JavaScript was JavaScripts.
Good thing they have no sheeps in space.
Re: (Score:1)
Re: (Score:2)
Re: (Score:3)
And you are basing that on the use of Javascripts? I suppose the optics are mere child's play, the telescope's structure is something that could be whipped together in, what, a weekend for a sparkling engineer like yourself. And that propulsion that got it to the La Grange point, nothing but high school shop class needed. The mechanics that got it to fold up on Earth and unfold correctly in space is just basic mechanics, right? I hope that NASA never employs you.
Re: (Score:2)
Re: (Score:2)
Nope. And I wrote that. Are you dyslexic?
So... (Score:3)
So, automation scripts in other words. I don't know if I would have chosen Javascript, but there are pretty lightweight interpreters out there, and if they have a rock solid toolkit, why not?
Re:So... (Score:4, Informative)
It's not a bad choice, but it does seem like an odd choice. I don't know what I would have picked back in 2002, but I don't know if I would have even considered it. If they were looking for something fault tolerant and easy to use, I guess they could have done worse.
JavaScript is a pretty simple language, so a lightweight interpreter is certainly possible.
It just occurred to me that we're second-guessing a technical decision a team at NASA made 20 years ago even though we know nothing except the name of the language they selected. Pure hubris.
Re:So... (Score:4, Funny)
Re: (Score:2)
Rust would not have been a good choice for this particular application. It also didn't exist in 2002.
Re: (Score:2)
Re: (Score:1)
Yes, I know. This just seemed to be the best response to the weird anti-Rust trolls.
Re: (Score:2)
Re: (Score:2)
It just occurred to me that we're second-guessing a technical decision a team at NASA
Yes, because there was already a perfectly good industrial-hardened, proven (not formally, but as in experience) language that has been in use for those kinds of systems - Ada.
Re: (Score:2)
Ada is not an appropriate language for this particular application.
Re: (Score:2)
Re: (Score:2)
I like ADA as much as the next guy, but you really want an interpreted language here.
Re: (Score:2)
I like ADA as much as the next guy, but you really want an interpreted language here.
On a space telescope? Uh, no. If you are debugging your code on the billion dollar space telescope you are doing something wrong. And that is the only reason I can think of to use an interpreter here. You want something that is stable and you know will be around and supported for decades to come. You want something that can get security updates without breaking. You want something with a clear syntax with few surprises. You want something efficient that runs on the weird hardware that is hardened to
Re: (Score:2)
I would have thought about LUA, which is lightweight, written in strict ANSI C and easy to embed. It is very popular in the video game industry and is also used in embedded software. JavaScript feels a bit quirky to me but why not, it is not the first time it has be used in that fashion. Another alternative is Python, which scientists tend to like, but I find it a bit heavy and a bit messy at low level.
Re: (Score:2)
So, automation scripts in other words. I don't know if I would have chosen Javascript, but there are pretty lightweight interpreters out there, and if they have a rock solid toolkit, why not?
a-yup
From the manual, https://www.jwst.nasa.gov/reso... [nasa.gov] section 3.7:
"The Operations Scripts System (OSS) is a collection of JavaScripts (Figure 23) that execute planned science observations
and supporting activities, which are specified as a set of text files that are uploaded to the ISIM file store after ISIM
initialization:
And,
The fact that the OSS is written in JavaScript and stored on-board as text files is significant because this gives the
operations personnel greater visibility, control and flexibility over the telescope operations. As they learn the
ramifications and subtleties of operating the instruments, they can modify the JavaScripts and, after thorough testing in a
ground facility, they can simply replace an onboard file to make the change. The JavaScripts are written using the
terminology of the user’s domain of commands and telemetry. This is in contrast to the ISIM FSW tasks, which involve
real-time state machine logic, intricate hardware interaction, intertask message routing, a hierarchy of task priorities, and
complex operating system interfaces. The OSS is in the user domain and is consistent with the users’ perspective, needs
and objectives. The ISIM FSW is in the system domain and provides the user with access to the functions and features
of the system without the need for detailed knowledge of the underlying implementation.
So it appears the idea is to have scripts that the user-level people can read and maintain while isolating them from the nuts and bolts level.
Tha sounds to me like a job for JavaScript, especially considering that the decision was probably made around 2005.
This is very common. (Score:5, Informative)
Re:This is very common. (Score:5, Informative)
Re: (Score:2)
I know NASA was using hardened 486s well into the 2000s, in part because its a very mature processor that's both well documented and fully field tested, so the bugs and gotchas are pretty much completely known. You definitely do not use bleeding edge tech on something that's going to end up millions of miles away with no chance for servicing.
Re: (Score:2)
I believe it was 486s on the Shuttle, but everything since then is a RAD6000 processor I believe. PowerPC based processor running at 266MHz or so.
Re: (Score:2)
When I was at JPL, I called it "trailing edge" technology. We had 1802 processors with failure modes that were pretty well understood. Add to that the physical size of a register cell with the amount of charge holding the state, and processors and memory had a good chance of managing hits.
It is amazing what they can do with the more recent technology. Javascript? Strange, maybe, but there's only so many things that you can do in Javascript, and sandboxing is easier, perhaps.
Re: (Score:3)
The limiting factor in any computer system is excess processing power. The excess the more can be used to make the computer more accessible. The first computer that was sent to space that I worked on had to be coded in assembly. Later it was C.
There are other advantages. Bandwidth is limited and having a concise language to communic
Kinda shuddered when I read the headline (Score:5, Funny)
Re: (Score:2)
var str = new String("JWT Is Awesome!");
document.write(str.blink());
You know something like that is in there somewhere...
Re: (Score:3)
I seriously doubt that the environment they used included an implementation of the DOM API.
I've been saying for ages that what people hate isn't JavaScript, but the DOM API. Why developers of all people conflate the two, I'll never know.
Re: (Score:2)
To be fair, Javascript is kind of sucky, too.
Re: (Score:2)
I'll disagree. I think it's very much misunderstood. I'd go so far as to call it 'almost elegant'.
Re: (Score:2)
Even Crockford has sworn it off at this point. Almost elegant, basically sucky.
Re: (Score:2)
That's misleading. What Crockford is objecting to are new additions to the language. I generally agree with him. Arrow functions were a mistake. So were pretend classes.
Almost elegant, basically sucky.
I can tell you why ES6 was a mistake. Can you tell me why you think the language is "sucky"? Because most people who repeat that meme, which was born out of complete ignorance, can't. They can't because they don't actually know anything about the language. Here's a hint: If you find 'this' confusing, you don't understand the basics
Re: (Score:2)
I can tell you why ES6 was a mistake. Can you tell me why you think the language is "sucky"?
Weird scoping rules. Types. Ability to to misspell a variable and it doesn't even throw an error at runtime.
Re: (Score:2)
What weird scoping rules? They're as standard as they come. Or is it that you don't understand closures?
Types are simple and perfectly consistent. Or do you mean dynamic typing in general? That's a pretty weak criticism.
Ability to to misspell a variable and it doesn't even throw an error at runtime.
"use strict"; Problem solved. The same can't be said for other languages with dynamic typing.
in other news... (Score:5, Funny)
Re: (Score:3)
That was my first thought too.
But really, for a device that (presumably) already has a security layer preventing unauthorized users from connecting to it *at all*, any hypothetical security issues should remain hypothetical - the only people with access to exploit them already have enough access to not need to.
Re: (Score:3)
The Javascript isn't providing access to the telescope, it is merely handing off commands once received by the front end. Do you really think NASA is going put up a billion dollar baby with no security involved in vetting communications? Ya, those engineers would never think to do that.
Re: in other news... (Score:2)
Remind meâ¦was that calculation supposed to be in units of Kilometers or miles?
Re: (Score:2)
Re: (Score:2)
I'd install a minecraft server. ;-)
Re: (Score:2)
UML (Score:2)
Developed using the Unified Modeling Language :-)
Wasted energy (Score:2)
Re: (Score:2)
Zero. JWST's lifespan is based on propellant, not energy use.
Re: (Score:2)
JWST has limited propellant. There is a certain amount of processing that can be done in that time frame.
If you use an interpreted language, it must do a lot less processing dedicated to actual data, and much of the processing is dedicated just to run the language.
If you used a compiled language, you can do more processing dedicated to actual data than the bookkeeping of the language (because there is none).
There is an equivalent in years (as a proxy measure) for how much actual data c
Re: (Score:2)
Re: (Score:1)
Given that it's going to be collecting image data for a couple decades, a few milliseconds every now and then could add up to a few minutes of wasted opportunity to take photos, but only if they're in a critical path.
Re: (Score:2)
Re: (Score:2)
Language is really important!
If they had spoken nicely to the telescope, its stress level would have been lower and it wouldn't have fidgeted around so much, wasting precious propellant.
JavaScript used on the Webb (Score:1)
I think the real tragedy is the missed opportunity to insert a dad joke about JS and the Webb.
JavaScript script != JavaScript (Score:2)
The only misdeed here is calling a JavaScript script a JavaScript.
Corrected Title (Score:2)
"The James Webb Space Telescope Runs JavaScript, [Appropriately]"
FTFS:
"...those JavaScripts will be interpreted by a program called the script processor, which will then reach out to the other applications and systems that it needs to based on what the script calls for. "
Sophisticated Act of Sabotage? (Score:1)
Aliens review our technology... (Score:2)
Shake both of their heads. Decide first contact can wait another century or two.