Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
NASA

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.

This discussion has been archived. No new comments can be posted.

The James Webb Space Telescope Runs JavaScript, Apparently

Comments Filter:
  • by xevioso ( 598654 ) on Thursday August 18, 2022 @03:47PM (#62801489)

    I thought the plural of JavaScript was JavaScripts.

    Good thing they have no sheeps in space.

  • by MightyMartian ( 840721 ) on Thursday August 18, 2022 @04:05PM (#62801561) Journal

    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)

      by narcc ( 412956 ) on Thursday August 18, 2022 @05:21PM (#62801779) Journal

      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)

        by Nartie ( 1128613 ) on Thursday August 18, 2022 @05:28PM (#62801797)
        I would have written it in Rust. In 2002 Rust was entirely bug free.
      • 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.

        • by narcc ( 412956 )

          Ada is not an appropriate language for this particular application.

          • Of course it is. It is a general purpose, human readable, very safe, language.
            • by narcc ( 412956 )

              I like ADA as much as the next guy, but you really want an interpreted language here.

              • by sfcat ( 872532 )

                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

    • by GuB-42 ( 2483988 )

      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.

    • by clovis ( 4684 )

      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)

    by GotNoRice ( 7207988 ) on Thursday August 18, 2022 @04:06PM (#62801563)
    It's extremely common for spacecraft to use very mature systems that seem "old" by common standards. The perseverance rover on Mars, which has been there for less than 2 years, uses a CPU that is based on the same CPU that the first generation iMac used back in the late 90's.
    • by XXongo ( 3986865 ) on Thursday August 18, 2022 @04:17PM (#62801591) Homepage
      Yeah-- more modern CPUs get zapped badly by cosmic rays. Not very useful to be a hundred times faster if you die in a few days, or even if you have to reboot every few days.
    • 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.

      • by tlhIngan ( 30335 )

        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.

        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.

      • 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.

    • by fermion ( 181285 )
      Hard to fix things in space. So even simple things that we take for granted, like batteries, have to be stressed tested and yes, hope for the best. Luck always plays a part

      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

  • by bjdevil66 ( 583941 ) on Thursday August 18, 2022 @04:06PM (#62801569)
    Hopefully they use more "onFocus" than "onBlur" in the code.
    • var str = new String("JWT Is Awesome!");
      document.write(str.blink());

      You know something like that is in there somewhere...

    • by narcc ( 412956 )

      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.

      • To be fair, Javascript is kind of sucky, too.

        • by narcc ( 412956 )

          I'll disagree. I think it's very much misunderstood. I'd go so far as to call it 'almost elegant'.

          • Even Crockford has sworn it off at this point. Almost elegant, basically sucky.

            • by narcc ( 412956 )

              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

              • 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.

                • by narcc ( 412956 )

                  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.

  • by Walt Dismal ( 534799 ) on Thursday August 18, 2022 @04:24PM (#62801617)
    In other news tonight, the Webb Telescope has been hacked by 13 year old snarky little brats and turned into a giant space laser that destroyed the Samuel L. Ballsnacker Elementary School in Butyric Acid, New Jersey. The giggling demons proclaimed that a semicolon error allowed them to inject code and seize root. They also thanked the creator of JavaScript for botching what could have been a useful tool.
    • 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.

      • by gtall ( 79522 )

        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.

    • by Cito ( 1725214 )

      I'd install a minecraft server. ;-)

      • by bn-7bc ( 909819 )
        Why? The latency would be terrible an long term connectivity would , I suspect, allso be an issue
  • by gbooch ( 323588 )

    Developed using the Unified Modeling Language :-)

  • Imagine how many many more years they could have gotten out of JWST had they chosen a proper language.
    • Zero. JWST's lifespan is based on propellant, not energy use.

      • Incorrect.

        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
        • 99% sure with out even googling it JWST spends most of it time collecting photons not processing them. If faster processing would allow it to take pictures faster you can be sure they would have figured out a way to cram more in or shield a modern processor.
          • 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.

            • The limiting factor on collecting data is the local storage, and the available windows to transmit the data back to earth.
    • 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.

  • I think the real tragedy is the missed opportunity to insert a dad joke about JS and the Webb.

  • The only misdeed here is calling a JavaScript script a JavaScript.

  • "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. "

  • JavaScript running on the James Webb to explore Space ... is this sabotage to prevent us from finding out more than we should
  • Shake both of their heads. Decide first contact can wait another century or two.

A bug in the hand is better than one as yet undetected.

Working...