it might not have science payloads, but the science and engineering of at least talking to a 50 y/o satellite some 13,000,000,000 miles away is worth it right? right?

I guess it's not the kind of instrument that one can turn on and off?

TFA says "keep the [probe] warm"; I'm not sure if it's poetry or a necessity; on Earth electronic components guaranteed to operate for maybe -100 °C ~ 100 °C at best but here one must be close to 0 °K.

Not to be that other guy, but AI might take a few tries, and you really might not get a 2nd try with these probes.

Part of NASA's remit is public communications. They have inspired generations and generations of engineers, scientists, technicians, and explorers. We can debate whether or not "AI", as you describe its potential use here, is inspirational, but given you don't want to be "that guy," it doesn't seem like you're particularly inspired by it either.

Based on what documentation?

I dislike AI but I think it's unfair that you're being downvoted for this.

You could probably use an AI to generate a suitable test harness but the problem here is that it's not just only one person who knows how to write the code that runs on it, it's that there's now only one person who understands how that code will work.

You're familiar with what bugs are, right?

I'm going to send you down a bit of a rabbit hole here - https://www.bigmessowires.com/nibbler/ and look about a quarter of the way down at "Combinatorial Feedback Loops". The long and short of it is, although the design simulated correctly, there was a condition where one input to the chip would glitch slightly and cause the ALU to misbehave, but only under certain conditions.

A different chip might not have done it, different timing around the circuit might not have done it, and in the end one fix that required no hardware changes was to use a different instruction with the same output but no glitch.

I'm prepared to bet that Voyager's computers are absolutely chock full of nonsense like that, and there's a lot of "correct per the spec" code you could write that could send it off into la-la land because it doesn't quite work right on the real hardware.

And that specifically is where you need a human to say "yeah but it needs to be written with *these* specific opcodes because *those* specific opcodes will...", and I'm not sure that AI is ready to do that yet.

The root of the problem is the one I run into if I wanted to use AI to write code - AI is a big copy-and-paste machine and does not really understand all the tiny details that we hold in our brains.

Without the implicit knowledge that goes around things like "well you can't do that because..." you're going to get into a mess.

There’s money to go around!

I've always thought asteroids could be used as automated "weather stations" with probes not just as mission targets in themselves. These could be updated or maintained occasionally.

Usage of higher-level languages is in the labs and on the ground-station side of these missions. No FORTRAN interpreter runs on a space probe.

In the 1970s, there was a distinction between "machine language" and assembly language. Assembly (or assembler) language is the symbolic source code that a programmer would use. Machine language is the binary dump of the actual text segments that the CPU directly interprets to run.

But cars do have that level of reliability, in ECU (sans hardware I guess, still flash memory). It's just everything else around is ass

"Oops, you are right. I shut down the spacecraft, and now it will never boot again. Here's how it happened:"