> For better or worse, parenthesis aren't that bad with the proper IDE tooling.
Hell, even without [0], you can at least count the parenthesis by hand in a pinch. I remember seeing lots of crazy-awesome stuff done in AutoLisp by 'non-programmers', versus 'structure as spacing' in Python which really sucks if the Editor was designed to use the system default (probably non-monospaced, cause other products in the industry had dialogs that broke if you switched to a monospaced) font. [1]
[0] - but real talk parenthesis matching in an editor is a lifesaver
[1] - oooooold version of a very popular GIS product.
It is still a bit amazing to me that it was significantly easier to do coroutines in Sigma 5 assembly and likely most any assembly than in C or C++. Two languages supposedly close to the machine.
I have seen a pure C/C++ implementation of coroutines (it used setjmp/longjmp, and memcpy to copy stacks in and out of the native arena). Not the most portable of constructions, but it worked absurdly well.
Being able to write "async" code essentially in-line is a superpower.
Regarding "that almost nobody on Earth fully understands anymore", I claim this is nonsense, and definitely not an obstacle.
I've audited codebases in languages that I haven't programmed in. It is a matter of grasping a few basic concepts, like branch execution, branch destination, where data is stored, how it is communicated. Don Lancaster told us how to do this: https://www.tinaja.com/ebooks/enhance_vI.pdf.
I was puzzled by this claim, too. I think that the article is wrong, and that the code is written in HAL/S, a NASA-only language that sort of started off as a preprocessor to Fortran, though it has some PL/I-like features. If it really was written in Fortran, it probably was in a vendor-extended Fortran IV, which a lot of old guys like us know. But NASA used HAL/S for a number of projects, including the Shuttle. (And, by the way, thanks to perplexity.ai, here's a link to the HAL/S language manual: https://archive.org/details/nasa_techdoc_19750002029.)
The parent comment is apt. Of course, languages have their own quirks. But, as Christopher Strachey is once claimed to have said, “I use the same language no matter what compiler I run.”
Now what is more likely to be true is that the code is strangely structured (both because structured programming was new then, and because of memory and processor limitations), and also that much of the internal documentation has been lost. I wish the article had been clearer on that.
I think that the Voyager software is in assembly languages (there are several distinct computers on board), and that it is the program preparation software is written in a “Fortran V” extension.
> Regarding "that almost nobody on Earth fully understands anymore", I claim this is nonsense, and definitely not an obstacle.
It seems like you aren't very familiar with the history of the Voyager or the computer systems it uses. The Voyager has three onboard computers, each of which has a custom ISA. Two of the three computers were only used on Voyagers. After the main Voyager mission ended in the late 1980s and they were repurposed to collect data on interstellar space, the probes were reprogrammed to only require limited commands on one of the computers, and no intervention whatsoever on the other two. They also got rid of the testbench for testing code on the ground, so the only working Voyager systems are billions of miles away from Earth. Since then, Voyager has been operated by a skeleton crew that has been shrinking over time as people retire. The result of all of this is that they legitimately do not have a full understanding of how the hardware and software operates. Here's one example from a talk about how the crew fixed an issue with the Flight Data Subsystem, one of the computers that hadn't needed any significant software changes since the interstellar mission began (https://www.youtube.com/watch?v=dF_9YcehCZo):
> So our top priority was to figure out what the FDS was and how it worked. Because unfortunately the person who was the real expert had retired decades ago and the person who was their fill-in, their backup, had retired two years ago. So it was the worst place it could have hit us. These are some examples of some of the documentation we dug up on the FDS. So they're all hand written. These are some very dim circuit diagrams and these are hand written timelines for how to change FDS processors. We were lucky to find these. Some things we couldn't find. A lot of it was like this, that had been scanned. And frequently, these sources were contradictory, ambiguous. Why? Because we changed the way the spacecraft worked with every planetary encounter and entering the VIM and when things broke. So there was a lot of opportunity for ambiguity to arise in the documents over the course of 50 years. This is my favorite example. So this is a page out of an important FDS document. The change bar on the far side indicates it's a change, but somebody went in and made a very cryptic circle of the sentence and crossed it out. I have no idea to this day what it means. I have no idea. Maybe it was important. Maybe they crossed it out, because they thought crossing out was important. I'm not sure. So there were other cases like this. So we were even so confused in some cases, we weren't sure if we were sending data to the FDS - should it be least significant bit first or most significant bit first? We had that level of uncertainty.
> We didn't know we had the right instruction set. I showed you the instruction set there. We didn't know that was the one used to build the software, back when there was an assembler. We didn't know the source code version was the same as what was running onboard the spacecraft. We had a listing of the code, but it was a Microsoft Word document, with optical character recognition scans. We didn't know if there were errors in it. We had no assembler. So they're just playing with bits. There's no simulator and there's no test bed. So there were a few challenges. So basically this was bare knuckle binary manipulation. And they had to think of all the problems. I'm sure you guys are far better than I am of thinking of the problems associated with playing with memory like this. You could overwrite something. You can fail to recognize jumps. How do you debug it in flight on a flying spacecraft? And how do you know you're not missing something in those instruction sets and codes? And the list goes on and on.
>NASA still maintains some of the Voyager spacecraft code in a 1970s-era programming language that almost nobody on Earth fully understands anymore
I did not address the issue of the hardware documentation, just the issue raised by the headline. I fully understand the issues that the hardware and the problems of not having a full map of the hardware or a test bed to check out the code.
Well the 1970s era programming language would be the assembly language for the bespoke Voyager processors, and the spotty institutional knowledge and lack of a Voyager on the ground means that there's no full understanding. I'm not sure what's inaccurate here.
> Microsoft Word document, with optical character recognition scans
It's incredible that there is someone out there in this world who thought that OCRing documentation into a Word document is a good idea. And implemented it.
reply