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.
not defending it, but I think it boils down to the requirement to be able to quickly issue specific commands to various subsystems. So one choice would be a Domain-Specific Language, the other would be an "everyone-already-knows-it" language like JS.
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.
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.
I think comparing js to a highly specialized, well constructed, ruggedized, and well loved machine is a bit off. It's more like mowing your lawn with whatever you can grab from the gas station on the way home. Something surely ubiquitous, familiar, convenient (for you), and completely unsuited given we have tools for it.
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.
Rust and Typescript didn't exist when this decision was made. The 2MB size limit would also take some engineering effort to workaround for both of those languages.
JavaScript is very safe. You probably have it enabled in your web browser. Meaning a overflow/out of bounds could give any website control of your PC. In this regard JavaScript is very strongly typed. It's also relative fast, fast to write, and easy to understand. It has a relative small memory footprint, and the payload (JS text file) is small compared to for example a statically linked binary. So if you are willing to give up some performance in order to write safe and easily maintainable code fast, then JavaScript is good, if performance is priority you are better off with a systems language. If you are targeting tiny 1$ CPU's you still need to write in assembly (or maybe C). which however doesn't make sense for a satellite that you only make 1-2 copies of, besides reducing weight.
There are languages (sometimes a subset of an existing language, like C) where you can prove for a program that it has no bugs, or that it can function in a real-time context (i.e stays reactive to some frame rate at all situations). This is useful for very expensive hardware that you can't go and service later on. JavaScript can easily explode at run time, while these other languages won't even compile.
JavaScript is small, but then again - you need to ship the interpreter.
Not sure about maintainability either - static typing really helps with that.
The safety you mention is that js runs in a sandbox (and e.g can't wipe your hard drive), but this is a feature of browsers, not the language itself.
All in all I find it hard to believe they wrote any critical parts in js, and I'd also guess it's possible to replace the currently deployed scripts should they fail.
JavaScript types are very strict, and are checked at runtime, compared to at compile time. So you are less likely to get some random off by one bug in JavaScript then say C, which causes a bit flip somewhere and makes the rocket engines turn on, or what not. JavaScript "exploding" at runtime is great, it's much better then to continuing poisoning the state making weird stuff happen. JavaScript is however paying the price in performance, where a statically typed language can have 10x better performance.
The point is to write bug-free code. Dynamic typing makes that harder (makes proving that harder). If you just focus on off-by-one array reads then you're focusing on something that is already solved either by languages themselves, or tools around it that prove that the access is always ok. And there are also libraries that do bounds checking for you. But you still maintain memory access should you need it. (And, depending on the operating system, you can't actually read and write any memory - you get a segfault instead, which is perhaps the js explosion equivalent, no?)
On the point about inconsistent state: if your JavaScript program is doing something important but then dies because of a bug then maybe the interpreter was left in a consistent state, yes, but what it was doing was not. This is safe how?
About inconsistent state, take an altitude meter for example, in an airplane setting, it's better if the altimeter restarts, then having it show the wrong value.
For bug prevention I like defensive programming, checking for "impossible" conditions that should never happen. And always exit if the unforeseeable occurs.
The most effective way to prevent bugs though is probably to keep that program small and comprehensible, and that's easier with a high level language.
The static type checking is just one of many ways to prevent bugs. Personally I rather want the dynamic features. And I add checks at critical intersections, with human friendly errors. And do other automatic tests.
I think I see what you mean. I think it's the Erlang way of software developments: acknowledge that bugs are bound to happen, and if so then recover by restarting quickly, and have the other party (in a network setting) retry. If the restarter thing has no bugs, then I guess it's ok that way.
What I was pointing at more is that there are ways to prove for a program (even for C I've heard) that your program has no bugs, and also that whatever loop it has it always runs at some "Hz" level at most - which makes this a good fit for controlling something efficient in real-time. As far as JavaScript goes it seems it's mostly meant to run at the edge where it's fine to fail mid-way and where you have time to wait for a restart. How much time is enough time is, I guess, very dependent on what is being controlled, and perhaps for a telescope restarting is tolerable.
I write haskell these days and I can say that for the most part of the code I don't check anything since the type checker does it for me (once, at compile time). And if it compiles I can be fairly sure that there are no bugs. It's only at the edges where I talk to external APIs and/or parse json where I get errors and need to handle them in some way. There are of course bug sources left after types, but a huge part of it simply doesn't exist.
But I do understand how JavaScript can be a good choice if errors are tolerable, since it's fast to prototype in, and also, as a language it's easy to pick up, tons of resources online, plenty of developers who already know it etc. But I'd still maintain that safety isn't a property of the language itself, but more of the infrastructure it runs on.
So, i don't think, that Haskell really helps not to introduce logical bugs. And, as to my experience with Haskell, such bugs really hard to detect (somebody else's code is hard to read; especially, if the code is based on categorical abstractions, not widely known, or on well known abstractions, but in pervasive ways), and harder to fix, because of the amount of code that should be rewritten.
And of course, with Haskell there are always undetectable system errors, like consuming all of the system RAM by quite simple loops. There are no internal tools in the Haskell's semantics, to detect such situations, catch them and treat sanely.
And usually strict type systems are bad in providing such a system reflection semantics to the languages. You always should fallback to some kind of external interpreter, like IO, which may be integrated in the language with extremely hard to detect errors. See, for instance, the bugs in FSCQ http://css.csail.mit.edu/fscq/
So, Haskell, i think, is not the best choice for spacecraft programming.
And one should not rely only on the type systems and verification (remember Arian 4 or Deep Space One stories). You always need to test exhaustively. But if so, why not to use simpler language? At least it might have less bugs in its interpreter/compiler.
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.
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?
In the context of a critical, long-running, resource-constrained system, a language + runtime that can have deterministic memory usage. So: not JavaScript and probably not J2SE either.
Having written in it for a while, JavaScript just kind of is "meh".
TypeScript, for instance, is a much better development experience in terms of language constructs, but that only makes the package management situation stand out more.
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.
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.
> 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.
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"
No, but that's it's Achilles heel. You can't really just the fundamental part of the language because a gajillion websites are already in existence using it. We're stuck with the janky.
Prototypical inheritance is actually not a bad choice.
The event loop also stood the stand the test of time, it's a great choice for IO heavy environments like the web is.
The weak type system made it possible to bang out code really quickly without much thought thus making it very beginner friendly. Most of its issues can be traced back to this.
> The last 10 years have created a legion of developers who are really only familiar with JavaScript
That probably played 0 role into this. When the project was created, about 20 to 15 years ago, people put in the design specs. The language selection was JS, Python 1.5 (1.5, not 2, not 3, 1.5, released in 1999) and a custom script language.
NASA decided for JS because Python used more memory.
The JS that is being run is essentially IE6 or IE5-level, so none of the modern features introduced in IE8 and forwards that make it all so easy.
I'd expect more modern variants of JS (TypeScript) or even something like Rust to make an appearence in 15 years or so. Atleast for these kinds of missions.
The reason they didn't choose tcl had nothing to do with the language.
> 2. An attempt was made to port each scripting engine to the VxWorks real-time operating system on a flight-like Power PC 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.
The Python community was growing so fast, within a couple of years most Python developers had never used 1.x. Also 2.0 introduced an awful lot of very valuable improvements. In any case, 1.6 had some source incompatibilities with 1.5.2 anyway, so eh.
This language choice was made 10 years ago by developers working for NASA. While I think it was a questionable choice, I don't think it was a hype driven choice and I don't think its accurate to say these developers only know JavaScript.
Come to think of it, STScI, which is where those developers worked (and maybe still do), was always a favorable environment for Python.
Back in the early 2000s, before Numpy was a thing, STScI developed an image-file-reader for Python called PyFITS, and an underlying array extension to Python that allowed multiple base types, slicing, etc., called numarray (e.g., see https://scipy.github.io/old-wiki/pages/History_of_SciPy.html). In some sense, STScI might have been expected to prefer Python to JS.
> They have never used a proper programming language and have either never learned or have forgotten what it takes to make solid software.
I've done C, C++, C#, Java, Basic and Python for a living in the past and I always make rock solid software. JavaScript is by far the most productive programming language that I've used to do this.
People who think there's such a thing as an objectively "proper" programming language that they haven't even named are actually the problem with this industry, not JavaScript developers.
There's really nothing but an opinion in my response (and in the item I'm responding to) and a bit of bragging certainly doesn't invalidate that in the slightest.
Besides that, if you think that there are no people out there who can consistently write solid software, well...you're just flat out wrong. (And if you think you can't find them on HN, well wrong again...)
I think the apparent hubris is what they're referring to, and that it is a negative indicator of developer self-awareness, while humility and willingness to acknowledge past mistakes are positive signs.
Honestly, if you've always delivered rock solid software, you're some sort of mythical creature.
There’s a comic, I forget where, that says the difference between good and bad developers is that while both cause the code reviewer to exclaim “WTF?”, the bad developers causes far more of them. :)
> I think the apparent hubris is what they're referring to, and that it is a negative indicator of developer self-awareness, while humility and willingness to acknowledge past mistakes are positive signs.
Yes, anyone who's ever done a slight bit of bragging, even if it's actually true, is automatically and forever, completely lacking developer self-awareness.
> Honestly, if you've always delivered rock solid software, you're some sort of mythical creature.
There are whole agencies full of people that do it. But I get it, the thought that it's somehow impossible probably makes most software devs feel better about accepting their own mediocrity.
I love how everything is so black and white to HNers. "If you've ever bragged, you can't be telling the truth." or "If you use JavaScript, you're not a real programmer."
Indeed, it takes a quite bit of experience to realize how fragile our products are, especially given enough time. If some dev claim they never deliver bugs, have 100% coverage with tests etc. thats a huge warning sign.
I've seen great cathedrals of frameworks and patterns being built by smart experienced guys over few years, which ended up in quite a bit of mess at the end. Add a junior or two and see what added value they bring
> Remember, the entire internet now pretty much runs on this premise. And it's fine, right?
Oh, great, a space telescope run like the internet. Now every 2-bit remote galaxy out there is going to be making toxic comments about the Earth and human civilization as we know it. Be careful not to mention things like white dwarfs, or you'll be in for it from all sides.
Thanks JavaScript. Way to ruin the night sky for all of us.
> They have never used a proper programming language and have either never learned or have forgotten what it takes to make solid software.
I've been coding since I was kid, and professionally for over 20 years. I've used a few different languages, in a few different contexts, but Iv'e done JS in front/backend for the last 7 years or so and I find statements like these utterly tiresome. Sure, there are lots of naive JS devs...but I can say the same for Java, or any other language that is "a proper programming language". A lot of JS code is written to optimize for things that may it not seem like "solid software" - but I've seen a lot of terrible "solid software".
When we collectively realize that our industry is so young, that the best practices of yesteryear are often now viewed as mistakes (and that the practices from before that were maybe the right idea...), and that we really DON'T KNOW the correct answer, maybe then we'll stop loving to hate on people who are doing work that we might not do so well at if we tried it.
I don't know your intentions in saying what you said, but in general there is a LOT of smug looking-down on web development in general and JS development in particular. Arrogance is not a good look, and derision is worse. The industry has improvements it can make, certainly, but this is something true of us all, not something restricted to one sub-group while everyone else is doing thing The Right Way.
Good coders can be productive and write good code in any mainstream language, contrary to what is said in the famous "PHP: a fractal of bad design"[0].
That said JavaScript has a number of the same problems as PHP and pointing this out should be equally acceptable as pointing out issues with PHP[1], and while I'm impressed that it was created in three weeks and impressed with the JS community we shouldn't pretend it is a very well designed language. People being productive in JS is pretty much a result of an amazing ecosystem, not because of the language.
For a very simple example of what JavaScript could have been, look at Typescript: anything you can do in JS you can also do in TS. In fact, "porting" from JS to TS is as simple as changing the file extension.
Yet except for the need for transpiling TS is massively easier to work with and can eliminate whole classes of problems when used correctly.
Source: Have programmed and maintained others creations in JS and later TS.
[1]: I also have programmed my fair share of PHP code. It doesn't have to be bad. But I'll happily admit that it isn't the prettiest or most well designed language I know.
I completely disagree. It is physically impossible to be more productive in a C++ project that takes 5 minutes to compile compared to almost any interpreted language with a debug cycle spanning seconds. It's that simple. The next issue is the ecosystem. Often the language itself is completely irrelevant if the ecosystem is good enough but here is the thing: ecosystems are tied to languages. Yes I can be productive in "crappy language X" if I recreate the superior ecosystem of "super language S". I am not a superhuman lifeform that has the power of hundreds of bright human brains (millions of bad ones aren't enough) and the corresponding two hundred hands required to interface with the computer.
No. I will just pick a good ecosystem and the language it was built around and be happy instead of proving that you can build a skyscraper out of feces by producing steel via nuclear fusion.
It's very possible, but instead of debugging you spend more time thinking so you're making fewer iterations.
That said, I really enjoy Common Lisp for being compiled (good performance versus interpreted) and the speed of compiling (compiling single functions at a time) so you get the same time-to-execution as your interpreted languages. Better, actually, if you change the function definition in place when you hit a condition.
EDIT: I hit submit before finishing my thoughts.
C++ isn't that bad. 5+ minute compile times can be tightened down if you have a good structure for your codebase. And if it remains at 5+ minutes, that's what unit testing is for (shouldn't need the whole build to execute) along with a build pipeline. Submit the change and get results after a few minutes. Distcc and other systems can also aid for the really large projects. Another factor to consider, to test that interpreted (presumably dynamically typed) program you have to have more tests than the C++ program needs. Static typing (even though I have issues with C++'s type system, it's still ok) covers a lot of the areas that you have to manually create tests for in dynamically typed languages
We do Erlang and C++ for CUDA programming where I am. It would be nearly impossible for us to write good code for what we do in, say PHP, or even Java.
> pointing this out should be equally acceptable as pointing out issues with PHP
Not the best example, considering that PHP has done its time as whipping boy. I've never been a PHP dev and I did my share of trash-talk against PHP instead of learning about the aspects that I could learn from.
My problem isn't that it's "unacceptable" to point out issues - it's that people aren't doing so CONSTRUCTIVELY. Instead, it's about finding the lesser social class to dump on freely.
For example - I have serious concerns/doubts about typescript and how it props up a tool-enhanced crutch for programming-as-communication that ultimately leads to lower-quality code. You would likely disagree and would raise your concerns about JS without TS. We can have a lovely conversation comparing points and, while it's probable neither of us is convinced by the other, we both walk away with a better understanding of the perspectives of others and impacts of code choices.
OR we could imply that JS isn't a "proper" programming language, and thereby JS devs aren't "proper" programmers and we can pat them on the head and tell them to run along and play.
Back when I was doing a lot of Perl dev (before my Java days) I noticed that the weaker Perl devs would hate-on Python (and the reverse), while the stronger Perl/Python devs would hang out with the stronger Python/Perl and compare notes. It took me a while to figure out why that made sense. The two communities had a lot of explicitly different philosophies, yet were really able to learn from one another and occasionally both languages improved as a result.
If JS isn't someone's preferred approach, that's fine...but that doesn't mean they are "lesser". They're _different_, just like different problem domains are _different_. That doesn't make them immune from criticism either, but I'm far more interested in those looking to broaden their views rather than broaden the reach of their current viewpoint.
Thanks for being so calm. In hindsight I regret my comment.
Reading your comment now and rereading your comment I realize you were defending Javascript programmers, not the language. (I guess we'll have to disagree about JavaScript the language :-)
I agree we shouldn't attack programmers because of language choice. And I am happy that I pointed out that I am amazed by the JS community as it hopefully shows that I wasn't trying to attack anyone.
Thanks for clarifying - I hope I didn't come across too defensive. It's definitely become a sensitive spot when so many are dismissive, so I might lash out at those undeserving of it.
As for the language - JS definitely has its warts and its holes. It's not a language I love, but it IS a language I greatly enjoy developing for. Then again, I thought Perl was a great language (albeit with its own warts) so my views are fairly unconventional. Definitely though, I tend to think that languages fall into a more complex graph than just "better" and "worse", or even "better at X" and "worse at X".
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.
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.
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.
Related: In Specialty Engineering, we had to irradiate the hell out of the CPUs and see what happened. This was done by running cables into the rad chambers and then running a program on the CPU to test all of the chips and other stuff on the motherboards as they were blasted. Most of the time, we just went up in dosage until the system failed, which wasn't long.
One thing that always stuck out to me though, were the counters in the room. We'd leave one in the test chamber as close to the parts as possible, to get more accurate readings. Those little counters always borked out. The 7-part digital counters would just flicker and dance about in the rads. These 'hardened' counters would always fail first, and a lot sooner, than the CPUs.
I was just doing the dosing, not the code in the CPU. But if those very simple counters were fried well before the more complicated CPUs, and they were not in the full thrust of the radiation, then I can't imagine what those guys were doing to mitigate their code in that rad-soup. It was very impressive.
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.
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?
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.
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?
I very much doubt they JIT anything, because of the associated fault risk. So it's going to be an interpreter implementation. That means inner loops will run rather slowly. It could still use image processing library, sure.
I doubt NASA wants to do much image processing on-board in the first place. Mostly just lossless compression and maybe some thumbnailing, if they can't download everything.
It's used for sequencing. Think game scripting, except for a machine. The instruments / data handling is not in JS. None of the key functionality runs on a virtual machine or interpreter (I'd stake a lot on that). But, for instructions that must be human readable and machine readable, which are uploaded from ground stations, you sometimes want a scripting language like LUA or JS.
From what I understand of satellites and rovers, the only parts which are totally critical to get right are the modem, power to the modem, and bootloader. Almost everything else can be adjusted if a fault occurs (and they often are).
That works if you have a low data rate, last ditch omnidirectional antenna fall back. Otherwise for deep space satellites you've got to run quite a bit of stuff to get and perhaps keep the antenna pointed at a transmitter, which for a satellite includes station keeping functionality.
Imagine FTP-ing into the telescope to change some JS-files live, then just "refresh" and see what happens. They are probably using a simulator, and run tests before deploying the JS code. The tooling around JavaScript has come a long way, with type checkers, static analysis, code coverage, debugging, etc. The language itself is also very safe (hey, we are executing trustless JS in the browser). What do you mean by weird quirks ? The only thing that still annoys me are float's.
Ohh yeh, I think the equality table is just something you have to learn, like a chemist learn the periodic table. I make use of null==undefined a lot and prefer it over thruthy/falsy. I try to avoid NaN but sometimes use isNaN(nr)
So it seems that though the scripting language is nominally, and maybe even syntactically "JavaScript", the engine interpreting the code has been honed to ensure consistency and reliability. Since JS 3.0 is being used, I assume it's a lot simpler interpreter, no JIT involved, etc.? I'm curious as to what they might have removed/changed/fixed in the language?
It'd be nice if they differentiated sequencing from hardware control a little clearer in this conversation. Is anyone controlling adaptive optics or running signal processing in js? I think very much not.
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.
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.
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.
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.
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.
114 comments
[ 3.8 ms ] story [ 160 ms ] threadSequence 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.
Also previous discussion on HN: https://news.ycombinator.com/item?id=13009598
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.
As much as we're spending on this thing, I feel like it could be written in Rust and verified with TLA+.
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.
JavaScript is small, but then again - you need to ship the interpreter.
Not sure about maintainability either - static typing really helps with that.
The safety you mention is that js runs in a sandbox (and e.g can't wipe your hard drive), but this is a feature of browsers, not the language itself.
All in all I find it hard to believe they wrote any critical parts in js, and I'd also guess it's possible to replace the currently deployed scripts should they fail.
On the point about inconsistent state: if your JavaScript program is doing something important but then dies because of a bug then maybe the interpreter was left in a consistent state, yes, but what it was doing was not. This is safe how?
For bug prevention I like defensive programming, checking for "impossible" conditions that should never happen. And always exit if the unforeseeable occurs.
The most effective way to prevent bugs though is probably to keep that program small and comprehensible, and that's easier with a high level language.
The static type checking is just one of many ways to prevent bugs. Personally I rather want the dynamic features. And I add checks at critical intersections, with human friendly errors. And do other automatic tests.
What I was pointing at more is that there are ways to prove for a program (even for C I've heard) that your program has no bugs, and also that whatever loop it has it always runs at some "Hz" level at most - which makes this a good fit for controlling something efficient in real-time. As far as JavaScript goes it seems it's mostly meant to run at the edge where it's fine to fail mid-way and where you have time to wait for a restart. How much time is enough time is, I guess, very dependent on what is being controlled, and perhaps for a telescope restarting is tolerable.
I write haskell these days and I can say that for the most part of the code I don't check anything since the type checker does it for me (once, at compile time). And if it compiles I can be fairly sure that there are no bugs. It's only at the edges where I talk to external APIs and/or parse json where I get errors and need to handle them in some way. There are of course bug sources left after types, but a huge part of it simply doesn't exist.
But I do understand how JavaScript can be a good choice if errors are tolerable, since it's fast to prototype in, and also, as a language it's easy to pick up, tons of resources online, plenty of developers who already know it etc. But I'd still maintain that safety isn't a property of the language itself, but more of the infrastructure it runs on.
http://ttendency.cs.ucl.ac.uk/projects/type_study/
So, i don't think, that Haskell really helps not to introduce logical bugs. And, as to my experience with Haskell, such bugs really hard to detect (somebody else's code is hard to read; especially, if the code is based on categorical abstractions, not widely known, or on well known abstractions, but in pervasive ways), and harder to fix, because of the amount of code that should be rewritten.
And of course, with Haskell there are always undetectable system errors, like consuming all of the system RAM by quite simple loops. There are no internal tools in the Haskell's semantics, to detect such situations, catch them and treat sanely.
And usually strict type systems are bad in providing such a system reflection semantics to the languages. You always should fallback to some kind of external interpreter, like IO, which may be integrated in the language with extremely hard to detect errors. See, for instance, the bugs in FSCQ http://css.csail.mit.edu/fscq/
So, Haskell, i think, is not the best choice for spacecraft programming.
And one should not rely only on the type systems and verification (remember Arian 4 or Deep Space One stories). You always need to test exhaustively. But if so, why not to use simpler language? At least it might have less bugs in its interpreter/compiler.
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://mobile.twitter.com/alteredq/status/80085890885198233...
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?
TypeScript, for instance, is a much better development experience in terms of language constructs, but that only makes the package management situation stand out more.
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.
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.
> cobbled together in a few weeks by some poor fellow
It was. And then all work has stopped on it, right?
Prototypical inheritance is actually not a bad choice.
The event loop also stood the stand the test of time, it's a great choice for IO heavy environments like the web is.
The weak type system made it possible to bang out code really quickly without much thought thus making it very beginner friendly. Most of its issues can be traced back to this.
every time like clockwork
I think you mean the Web.
That probably played 0 role into this. When the project was created, about 20 to 15 years ago, people put in the design specs. The language selection was JS, Python 1.5 (1.5, not 2, not 3, 1.5, released in 1999) and a custom script language.
NASA decided for JS because Python used more memory.
The JS that is being run is essentially IE6 or IE5-level, so none of the modern features introduced in IE8 and forwards that make it all so easy.
I'd expect more modern variants of JS (TypeScript) or even something like Rust to make an appearence in 15 years or so. Atleast for these kinds of missions.
> 2. An attempt was made to port each scripting engine to the VxWorks real-time operating system on a flight-like Power PC 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.
https://www.scribd.com/document/407354589/Event-driven-James...
(My guess: no, but that happened well before my Python initialization.)
Back in the early 2000s, before Numpy was a thing, STScI developed an image-file-reader for Python called PyFITS, and an underlying array extension to Python that allowed multiple base types, slicing, etc., called numarray (e.g., see https://scipy.github.io/old-wiki/pages/History_of_SciPy.html). In some sense, STScI might have been expected to prefer Python to JS.
I've done C, C++, C#, Java, Basic and Python for a living in the past and I always make rock solid software. JavaScript is by far the most productive programming language that I've used to do this.
People who think there's such a thing as an objectively "proper" programming language that they haven't even named are actually the problem with this industry, not JavaScript developers.
Everything else you claim is suspect because you said this.
Besides that, if you think that there are no people out there who can consistently write solid software, well...you're just flat out wrong. (And if you think you can't find them on HN, well wrong again...)
Honestly, if you've always delivered rock solid software, you're some sort of mythical creature.
Yes, anyone who's ever done a slight bit of bragging, even if it's actually true, is automatically and forever, completely lacking developer self-awareness.
> Honestly, if you've always delivered rock solid software, you're some sort of mythical creature.
There are whole agencies full of people that do it. But I get it, the thought that it's somehow impossible probably makes most software devs feel better about accepting their own mediocrity.
I love how everything is so black and white to HNers. "If you've ever bragged, you can't be telling the truth." or "If you use JavaScript, you're not a real programmer."
It's very comical.
I've seen great cathedrals of frameworks and patterns being built by smart experienced guys over few years, which ended up in quite a bit of mess at the end. Add a junior or two and see what added value they bring
Oh, great, a space telescope run like the internet. Now every 2-bit remote galaxy out there is going to be making toxic comments about the Earth and human civilization as we know it. Be careful not to mention things like white dwarfs, or you'll be in for it from all sides.
Thanks JavaScript. Way to ruin the night sky for all of us.
I've been coding since I was kid, and professionally for over 20 years. I've used a few different languages, in a few different contexts, but Iv'e done JS in front/backend for the last 7 years or so and I find statements like these utterly tiresome. Sure, there are lots of naive JS devs...but I can say the same for Java, or any other language that is "a proper programming language". A lot of JS code is written to optimize for things that may it not seem like "solid software" - but I've seen a lot of terrible "solid software".
When we collectively realize that our industry is so young, that the best practices of yesteryear are often now viewed as mistakes (and that the practices from before that were maybe the right idea...), and that we really DON'T KNOW the correct answer, maybe then we'll stop loving to hate on people who are doing work that we might not do so well at if we tried it.
I don't know your intentions in saying what you said, but in general there is a LOT of smug looking-down on web development in general and JS development in particular. Arrogance is not a good look, and derision is worse. The industry has improvements it can make, certainly, but this is something true of us all, not something restricted to one sub-group while everyone else is doing thing The Right Way.
That said JavaScript has a number of the same problems as PHP and pointing this out should be equally acceptable as pointing out issues with PHP[1], and while I'm impressed that it was created in three weeks and impressed with the JS community we shouldn't pretend it is a very well designed language. People being productive in JS is pretty much a result of an amazing ecosystem, not because of the language.
For a very simple example of what JavaScript could have been, look at Typescript: anything you can do in JS you can also do in TS. In fact, "porting" from JS to TS is as simple as changing the file extension.
Yet except for the need for transpiling TS is massively easier to work with and can eliminate whole classes of problems when used correctly.
Source: Have programmed and maintained others creations in JS and later TS.
[0]: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
[1]: I also have programmed my fair share of PHP code. It doesn't have to be bad. But I'll happily admit that it isn't the prettiest or most well designed language I know.
No. I will just pick a good ecosystem and the language it was built around and be happy instead of proving that you can build a skyscraper out of feces by producing steel via nuclear fusion.
That said, I really enjoy Common Lisp for being compiled (good performance versus interpreted) and the speed of compiling (compiling single functions at a time) so you get the same time-to-execution as your interpreted languages. Better, actually, if you change the function definition in place when you hit a condition.
EDIT: I hit submit before finishing my thoughts.
C++ isn't that bad. 5+ minute compile times can be tightened down if you have a good structure for your codebase. And if it remains at 5+ minutes, that's what unit testing is for (shouldn't need the whole build to execute) along with a build pipeline. Submit the change and get results after a few minutes. Distcc and other systems can also aid for the really large projects. Another factor to consider, to test that interpreted (presumably dynamically typed) program you have to have more tests than the C++ program needs. Static typing (even though I have issues with C++'s type system, it's still ok) covers a lot of the areas that you have to manually create tests for in dynamically typed languages
Not the best example, considering that PHP has done its time as whipping boy. I've never been a PHP dev and I did my share of trash-talk against PHP instead of learning about the aspects that I could learn from.
My problem isn't that it's "unacceptable" to point out issues - it's that people aren't doing so CONSTRUCTIVELY. Instead, it's about finding the lesser social class to dump on freely.
For example - I have serious concerns/doubts about typescript and how it props up a tool-enhanced crutch for programming-as-communication that ultimately leads to lower-quality code. You would likely disagree and would raise your concerns about JS without TS. We can have a lovely conversation comparing points and, while it's probable neither of us is convinced by the other, we both walk away with a better understanding of the perspectives of others and impacts of code choices.
OR we could imply that JS isn't a "proper" programming language, and thereby JS devs aren't "proper" programmers and we can pat them on the head and tell them to run along and play.
Back when I was doing a lot of Perl dev (before my Java days) I noticed that the weaker Perl devs would hate-on Python (and the reverse), while the stronger Perl/Python devs would hang out with the stronger Python/Perl and compare notes. It took me a while to figure out why that made sense. The two communities had a lot of explicitly different philosophies, yet were really able to learn from one another and occasionally both languages improved as a result.
If JS isn't someone's preferred approach, that's fine...but that doesn't mean they are "lesser". They're _different_, just like different problem domains are _different_. That doesn't make them immune from criticism either, but I'm far more interested in those looking to broaden their views rather than broaden the reach of their current viewpoint.
Reading your comment now and rereading your comment I realize you were defending Javascript programmers, not the language. (I guess we'll have to disagree about JavaScript the language :-)
I agree we shouldn't attack programmers because of language choice. And I am happy that I pointed out that I am amazed by the JS community as it hopefully shows that I wasn't trying to attack anyone.
As for the language - JS definitely has its warts and its holes. It's not a language I love, but it IS a language I greatly enjoy developing for. Then again, I thought Perl was a great language (albeit with its own warts) so my views are fairly unconventional. Definitely though, I tend to think that languages fall into a more complex graph than just "better" and "worse", or even "better at X" and "worse at X".
This is NASA we're talking about. For a satellite. There will be no muddling, or tinkering.
Nasa isn't in the market to hire any old web dev you know. This is rocket science.
Edit: On second reading you may not be a serious as I first thought :)
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.
>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
One thing that always stuck out to me though, were the counters in the room. We'd leave one in the test chamber as close to the parts as possible, to get more accurate readings. Those little counters always borked out. The 7-part digital counters would just flicker and dance about in the rads. These 'hardened' counters would always fail first, and a lot sooner, than the CPUs.
I was just doing the dosing, not the code in the CPU. But if those very simple counters were fried well before the more complicated CPUs, and they were not in the full thrust of the radiation, then I can't imagine what those guys were doing to mitigate their code in that rad-soup. It was very impressive.
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?
Why not?
I doubt NASA wants to do much image processing on-board in the first place. Mostly just lossless compression and maybe some thumbnailing, if they can't download everything.
- undefined vs null vs empty
- the pile of weirdness that is ==
- the other pile of weirdness that is implicit truthiness/falsyness
- NaN's many fun qualities
https://www.destroyallsoftware.com/talks/wat
It’s unfortunate and unnessecary.
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.