12 votes

NASA's flagship James Webb Space Telescope, will run Javascript for instrumentation control using a defunct & proprietary interpreter with a list of errata last updated in 2003

10 comments

  1. [10]
    unknown user
    Link
    Proprietary JS interpretation engine. Check. Defunct company associated with it. Check. Gigantic list of bugs over 15 years old. Check. This will be fun.

    This will be fun.

    9 votes
    1. [7]
      meghan
      Link Parent
      Do they go over in the paper why they aren't using an engine such as V8 or SpiderMonkey?

      Proprietary JS interpretation engine

      Do they go over in the paper why they aren't using an engine such as V8 or SpiderMonkey?

      4 votes
      1. [6]
        unknown user
        Link Parent
        They made this decision before such things even existed.

        They made this decision before such things even existed.

        7 votes
        1. [5]
          meghan
          Link Parent
          But now they do...

          But now they do...

          3 votes
          1. [2]
            Ordinator
            Link Parent
            That's not really how NASA works. Requirements are set and they are implemented. It's mostly an okay system, but it seems to have failed this time. I really struggle to understand what JavaScript...

            That's not really how NASA works. Requirements are set and they are implemented. It's mostly an okay system, but it seems to have failed this time. I really struggle to understand what JavaScript is doing in their tech stack at all. I would have serious reservations about putting JS in a mission critical application today, much less back when JWST was being spec'd out.

            5 votes
            1. [2]
              Comment deleted by author
              Link Parent
              1. meghan
                Link Parent
                but yeah, on the point or @Ordinator and @teaearlgraycold, especially in the 90's, why did they think Javascript was a good choice for a system meant to entirely /bug free/ and sustainable for...

                Since the establishment of the James Webb Space Telescope’s (JWST) mission definition in the late 1990’s,

                but yeah, on the point or @Ordinator and @teaearlgraycold, especially in the 90's, why did they think Javascript was a good choice for a system meant to entirely /bug free/ and sustainable for decades?

                2 votes
          2. [2]
            zaarn
            Link Parent
            It's not that easy to simply put V8 on something like a spacecraft. Most of the hardware is like around 15 years old, likely some radiation hardened variant of PowerPC with a few megabytes of RAM....

            It's not that easy to simply put V8 on something like a spacecraft. Most of the hardware is like around 15 years old, likely some radiation hardened variant of PowerPC with a few megabytes of RAM. The hardware and software that gets sent up needs to be thoroughly tested.

            When you chase the goal of making software that cannot be allowed to fail into unsafe states, it is better to have a implementation which is well tested and where almost all bugs are known than an implementation which is new and untested. In 15 years, they probably discovered every single bug that this engine has to offer.

            5 votes
            1. unknown user
              Link Parent
              Yeah exactly this. Hopefully my title isn't construed as overly negative, I just found this humorous and worth mentioning here.

              Yeah exactly this. Hopefully my title isn't construed as overly negative, I just found this humorous and worth mentioning here.

              1 vote
    2. [2]
      teaearlgraycold
      Link Parent
      Well this seems like a horribly indefensible decision. Why even choose JS in the first place?

      Well this seems like a horribly indefensible decision. Why even choose JS in the first place?

      3 votes
      1. edenist
        Link Parent
        The document linked to is basically answering this question. And to be fair, they do a good job of justifying it's usage. I recommend reading section 4.1 in particular. You also have to keep in...

        The document linked to is basically answering this question.
        And to be fair, they do a good job of justifying it's usage. I recommend reading section 4.1 in particular. You also have to keep in mind that the selection process was performed in 2003. In particular:

        An attempt was made to port each scripting engine to the VxWorks real-time operating system on a flight-like PowerPC by embedding it into a payload flight software application. TCL was dropped from the study when it could not be successfully ported to VxWorks. JavaScript, Python and G-script were successfully ported and a series of tests with prototype flight software applications were run in order to rank them against the success criteria. G-script received the lowest score due to its limited functionality, its awkward syntax, and the increased cost that would be needed for development and maintenance of a custom scripting language.

        JavaScript and Python both demonstrated full functionality: they were quite flexible and supported a very user-friendly interface. JavaScript, however, showed a superior ability to meet the operational requirements. It was fully compatible with VxWorks with extremely little modification and JavaScript could be embedded within the payload flight software using a much simpler interface than Python required. The Python port also exhibited memory leaks, and already was quite old. Whereas the ScriptEase JavaScript port to VxWorks is maintained, the Python Open Source community does not provide this support. A labor-intensive custom port of the current Python version would have been required with no guarantee of success. For these reasons, JavaScript was recommended by the evaluation team and was subsequently accepted by the JWST Project for implementing the event-driven operations system.

        10 votes