from the proprietary-js-from-a-bankrupt-company dept.
The James Webb Space Telescope runs JavaScript, apparently
It turns out that JavaScript, the programming language that web developers and users alike love to complain about, had a hand in delivering the stunning images that the James Webb Space Telescope has been beaming back to Earth. And no, I don't mean that in some snarky way, like that the website NASA hosts them on uses JavaScript (it does). 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.
[....] This knowledge has been bubbling up on the internet in Hacker News and Twitter threads for years, but it still surprised quite a few of us here at The Verge once it actually clicked. At first blush, it just seems odd that such a vital (not to mention expensive) piece of scientific equipment would be controlled by a very old version of a technology that's not particularly known for being robust.
After thinking about it for a second, though, the software's age makes a bit more sense — while the JWST was launched in late 2021, the project has been in the works since 1989.
[....] NASA's document says that this way of doing things gives "operations personnel greater visibility, control and flexibility over the telescope operations," letting them easily change the scripts "as they learn the ramifications and subtleties of operating the instruments." Basically, NASA's working with a bunch of files that are written in a somewhat human-readable format — if they need to make changes, they can just open up a text editor, do a bunch of testing on the ground, then send the updated file to the JWST
I would remind everyone that SpaceX Dragon 2 crewed capsule's touch screen control panels are run by the Chrome browser and Javascript.
(Score: 5, Informative) by turgid on Sunday August 21 2022, @10:24AM (10 children)
And people are crazy enough to fly in it?
Touchscreens are bad for vehicle control in the first place. Secondly, all that complex software has no place on a safety-critical system.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 5, Insightful) by Rosco P. Coltrane on Sunday August 21 2022, @11:23AM (8 children)
These worrying use cases of browsers and shitty web-two-oh tech is a perfect example of the old adage "When your only tool is a hammer, all problems look like nails". Using a browser to control a rocket ship, or Javascript to control a multi billion dollar spacecraft is utterly bonkers to those who can code in proper languages and design proper GUIs. But what do you think universities have been teaching the current crop of computer engineers? Web garbage of course. There's a lot more money to be made for those who style themselves as "full stack developers" (i.e end-to-end web garbage specialists who can deploy server-side as well as client side garbage) than for those who spend time studying actual computer science.
(Score: 4, Interesting) by RamiK on Sunday August 21 2022, @02:47PM (6 children)
The decision was made 15 years ago so the current crop of programmers wasn't a consideration.
Regardless, going by Event-driven James Webb Space Telescope operations using on-board JavaScripts (V. Balzano, D. Zak) [doi.org] ( google for a pdf ), they pitted a 3yr/old unmaintained python version against an unspecified TCL port, an in-house g-script thingy and a commercially available contemporary and an up-to-date javascript engine:
Oh-so-surprisingly, TCL and gscript didn't meet the functionality needs while python had a memory leak:
Honestly it feels like they chose the first proprietary solution that was ready-made available since they didn't want to bother so they ass-pulled that decision making tree by rigging the specs in its favor. I mean, they don't even make mention of "reliability" anywhere...
Sad times.
compiling...
(Score: 2) by turgid on Sunday August 21 2022, @03:49PM (3 children)
VxWorks, eh?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Interesting) by RamiK on Sunday August 21 2022, @04:27PM (2 children)
That's normal in aerospace along with the PowerPC CPU. The oddities were TCL as it was mostly a *unix thing and the lack of Lua which was and is quite common in that space for that particular use case... Go figure.
compiling...
(Score: 3, Interesting) by bzipitidoo on Monday August 22 2022, @02:43AM (1 child)
My experience with VxWorks was thoroughly negative. Years ago, I decided to upgrade to the famous WRT54G wireless router. Little did I know that the good WRT54G was revision 4, and Linksys had just released revision 5, in which they completely gutted the internals, tossing Linux for VxWorks, and cutting the memory by half. Worst router I ever owned. To call that thing a WRT54G was highly deceptive. Long delays. Couldn't even ping reliably. After 2 days of struggling with it, I took it back for a full refund. Real time OS, pshaw, right.
That VxWorks is still around today suggests it can't be utter crap. Still, it's proprietary and closed source. So I'm not interested.
(Score: 3, Insightful) by RamiK on Monday August 22 2022, @07:18AM
The problem is VxWorks is just not designed for reliable multitasking. That is, it's use case is for systems where you have multiple physical CPUs each running their own task and if one of them stalls, a physical CPU or even human operator can issue a reboot to a privileged CPU or just cycle on/off the whole machine.
So using it in a router where you need multitaksing and the ability to resurrect a faulty service without stalling the kernel is just wrong.
The correct choice for a router RTOS is obviously QNX where the microkernel keeps everything running which is why it's being used on all the smartphone basebands.
compiling...
(Score: 2) by Freeman on Monday August 22 2022, @02:01PM (1 child)
I love Python. I wouldn't want to trust Python to get me to the moon and back safely. I would say C++ and some very, very good programmers.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 2) by RamiK on Monday August 22 2022, @08:45PM
Moving from Ada to C++ was a very costly mistake for the F35... Regardless, they specified needing an interpreted language for sequencing and that it came down to python vs. javascript so, given that, I think python would have made for a better choice. Though I agree neither was a good option and they should have just sandboxed Lua or some other similar embedded solution.
compiling...
(Score: 1) by aafcac on Sunday August 21 2022, @05:15PM
I'd personally be more concerned about whether there's enough protection against cosmic rays and other space stuff that can interfere with electronics than whether or not it's got a touch screen. Personally, I hate touchscreens for most things, but especially in cases where it's crucial to not hit the wrong thing at the wrong time. One of the nice things about physical buttons and switches is that you can integrate a flip up shield to prevent somebody from touching by accident in a way that's not practical with touch screens.
(Score: 4, Interesting) by istartedi on Sunday August 21 2022, @09:30PM
Dragon has physical controls in a bank below the screens. They're not stupid. In the unlikely event that all the screens fail, they can fall back on a more traditional control system as well as the automated systems. Wherever practical, redundancy tends to be a design characteristic of crewed space systems.
Appended to the end of comments you post. Max: 120 chars.
(Score: 4, Insightful) by Anonymous Coward on Sunday August 21 2022, @02:10PM (1 child)
If you go to the PDF paper, they use this for on board scheduling and instrument setup. They wanted to move the burden from the ground for that to the spacecraft (where they can override it anyway) and load up the next week or two of events and let the telescope schedule it (skip targets, add them, react to some event, etc.). For Hubble they have to come up with their weekly observing plan and do a bunch of ground crunching to optimize it resulting in a time based schedule ("at this time look here"). Then they need to binary pack it and upload it. If something changes off of the plan, like a potential supernova going off, they need to scramble on the ground and do the whole thing over and get it uploaded. Here it seems they want JWST to be a lot more flexible; if that supernova goes off they can add that event itself and the telescope will rejigger itself to accommodate it. They also wanted the scripts to be human-readable so that you can skip the parse it into binary then validate the binary step, so they used ASCII scripts. So going in with those design constraints, is Javascript a bad choice over other script parsers? It isn't like you're going to be updating the script parser every time a new version comes out anyway.
(Score: 3, Informative) by Mr Big in the Pants on Sunday August 21 2022, @08:29PM
Exactly my thoughts.
JS is a garbage language to use in any number of contexts. Some argue it is just garbage in general.
BUT, scripting languages have their place. And this sounds like a place they would do well.
Could they have chosen a 'better' language. Maybe. But that sounds more like opinion.
At least JS has a lot of use under its belt and I assume the entire team had a lot of XP with it.
(Score: 1, Interesting) by Anonymous Coward on Sunday August 21 2022, @06:40PM
Yeah but, whaddya gonna do now that Webb discovered that the Big Bang is a hoax [mindmatters.ai]?
(Score: 3, Funny) by shrewdsheep on Sunday August 21 2022, @08:50PM
It is called the "Webb" telescope, long form for Web. Well, the rest is history.