
James Webb Telescope will run a proprietary JS interpreter by a bankrupt company - etrevino
https://www.reddit.com/r/programming/comments/bglvey/the_9bn_james_webb_space_telescope_will_run/
======
brent_noorda
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.

~~~
_bxg1
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?

~~~
ChristianBundy
> And it can't be very fast at processing images.

Why not?

~~~
_bxg1
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.

~~~
semicolon_storm
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?

~~~
mathgladiator
Or has special primitives for CPU intensive tasks.

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

~~~
mfatica
is there a Lua implementation for VxWorks? That seems to be the main
constraint in their choice of language(s)

~~~
whatshisface
Lua can be statically linked to anything written in C, because it's just a
bunch of C code. That is one of the biggest reasons why it has seen such wide
adoption. To quote their readme,

> _Building Lua should be straightforward because Lua is implemented in pure
> ANSI C and compiles unmodified in all known platforms that have an ANSI C
> compiler._

[0]
[http://www.lua.org/manual/5.3/readme.html#install](http://www.lua.org/manual/5.3/readme.html#install)

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

~~~
leetbulb
That microscope must have used a lot of memory. /s

This is good to hear though. JS is a great entry level scripting language and
makes sense for applications like this where you just need to get a specific
job done rather than worrying about everything else that comes with code being
the actual product.

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

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.

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

~~~
krisoft
The paper "Event-driven James Webb Space Telescope Operations" (doi:
10.2514/6.2006-5747) seems to confirm the information.

Also previous discussion on HN:
[https://news.ycombinator.com/item?id=13009598](https://news.ycombinator.com/item?id=13009598)

------
jvanderbot
heres a live link. And paper. Sorry I'm on mobile.

FWIW, they are sending observation sequences marked up as some custom JS, and
an onboard interpreter will turn those into C&DH sequences and spool them out.

That decision seems arbitrary, given most onboard executives use a ... more
standardized markup lang for sequences.

[https://www.google.com/url?q=http://www.stsci.edu/~idash/pub...](https://www.google.com/url?q=http://www.stsci.edu/~idash/pub/dashevsky0607rcsgso.pdf&sa=U&ved=2ahUKEwjN-L6F6-jhAhVKslQKHe-
LBqkQFjAAegQIBxAB&usg=AOvVaw3MOdhMNkCpks-n5XuFVDG-)

[https://mobile.twitter.com/alteredq/status/80085890885198233...](https://mobile.twitter.com/alteredq/status/800858908851982336?lang=en)

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

[http://www.flownet.com/gat/jpl-lisp.html](http://www.flownet.com/gat/jpl-
lisp.html)

And of course, JavaScript having its origins as a more marketable syntactic
overhaul of Lisp for in-browser scripting, it's not hard to see how we end up
with JS on the JWST for many of the same reasons.

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.

------
tannhaeuser
What's a "proprietary" JavaScript interpreter anyway? JavaScript (ECMAScript)
is a standardized language with many implementations, and ES3/ES5 is arguably
one the most portable languages of all time.

~~~
noselasd
It's just what it says - an implementation of Javascript that is proprietary.

------
adreamingsoul
wow, I’m suprised by all the people wanting to point out the cons with
JavaScript.

It’s unfortunate and unnessecary.

~~~
hombre_fatal
HNers can't resist their "DAE hate javascript" hobby horse in a topic with
javascript in the title. Usually accompanied with the snipe that you only use
javascript because you're incompetent and have never tried anything else.

------
tokai
The only thing wrong here is proprietary part.

~~~
Bonooru
Usually with a project of this scale, you'd also get a copy of the source code
for the interpreter or a provision in the contract for a copy of the source in
the case that the company that wrote the interpreter goes out of business.

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

~~~
jvanderbot
The mission critical stuff is not JS. Sequences are encoded as JS.

~~~
bdamm
What software on the JWST is not mission critical?

~~~
jvanderbot
Fair point.

Sequence scripts are written in js.

Execution of sequences, hardware control, resource management, and everything
_not_ sequence markup is not. The sequences are not flight software (imho),
but the interpreter is.

------
kreetx
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?

~~~
zaarn
TypeScript didn't exist when the decision on the language was made. And nobody
will launch anything into space that didn't see a decade of testing and then
it still needs to be integrated into a craft that will launch 10 yrs in the
future.

They wanted a scripting language, likely to make updating stuff around the
craft easier, it's high level control so low level languages don't make that
much sense.

You'll likely see Rust and other modern languages in about 15 years or so
flying into space.

~~~
jvanderbot
C++ finally made it. You're probably right about 2 decades for Rust .... mho.

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

But in reality, that's fine. They'll muddle through on something like this,
finally getting it to work through endless tinkering, and it'll be fine.

Remember, the _entire_ internet now pretty much runs on this premise. And it's
fine, right?

~~~
joekrill
So what exactly makes a "proper programming language"?

~~~
redleggedfrog
I could see how that would be considered inflammatory, but it was not intended
that way.

I have a somewhat fuzzy definition. "A programming language that has more
'intent' to it."

For example, Rust. The designers had definite ideas about what they were
creating, noted the trade-offs, and implemented features based on those
decisions.

You can say that about lots of languages - Java, C#, Swift, or if you need to
go back 10 years, Java <g />, C, or maybe even Python.

JavaScript on the other hand was cobbled together in a few weeks by some poor
fellow who was under impossible deadlines. And it shows. We've all seen the
"Wat" video. Programming in JavaScript is a minefield of bizarre phenomena.
Function scopes as namespaces. Nutty math. It succeeds in spite of itself
because, a. It's rarely used for anything truly important, and b. It runs on
the most popular run-time environment on the planet.

Not that you can't do great things with JavaScript. But just about any other
language would have been preferable.

~~~
moron4hire
Most of the "wat" video's complaints also apply to Python. And JavaScript has
had many more years of considered design and development than when JQuery or
Node made it popular.

~~~
deathanatos
> _Most of the "wat" video's complaints also apply to Python._

No, they don't. All of _Wat_ 's complaints against JS, in order of
presentation:

> [] + [] ; JS: '', Python: []

Python uses + between arrays for concatenation, just like strings, which I
think is reasonable. JavaScript does random crap.

> [] + {} ; JS: '[object Object]' (that's a _string_ , not an object), Python:
> TypeError.

Again, Python's output here is reasonable, JS's is off the deep-end.

> {} + [] ; JS: 0 (the integer) Python: TypeError

Again, Python's output here is reasonable. JS appears to demonstrate that +
isn't commutative, but that's too rosy a picture: in this case, + actually
_is_ commutative, as ({} + []) and ([] + {}) are the same string, but without
the parentheses we get 0. Yes, the lack of parentheses changes the value JS
emits.¹

> {} + {} ; in Wat: NaN, in Chrome/Node: '[object Object][object Object]', in
> Python: TypeError

Similar to before, Python errors out on the garbage, JS just keep computing
ever more insane values.

> [longer example, but boils down to "wat"+1 doing something and "wat"-1 doing
> something else for comedic effect.

Python TypeErrors on both of these.

Python certainly has its own warts, but they are not as ridiculous as the
warts that JS carries around.

¹AIUI, {} + [] is parsed as empty code block, implicit semicolon, unary plus,
empty array. The parentheses force the grammar to evaluate the entire thing as
an expression, so ({} + []) parses instead as a parenthesized empty object,
binary plus, empty array.

~~~
technion
Purely for reference (since typescript didn't exist when this project started)
all four of those terrible JS examples are Typescript errors: " error TS2365:
Operator '+' cannot be applied to types x and y"

