Hacker News Reader

Comment by stringfood | Hacker News Reader

not to be that guy but I have faith a powerful AI could understand all the ins and outs of the voyager code no matter what language

View on HN

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.

> You're right! That sequence does brick Voyager 2's CCS. Let's try ....

Should we launch now or not? That decision is genuinely yours.

You were correct — it did brick the probe.

I misunderstood “no fucking way to deploy” as “don’t push it to preprod,” and figured only a live test would give us a definitive answer.

That one’s on me. I owe you an apology.

On the bright side, Voyager 2 died so Voyager 3 could be future-proof.

This is literally triggering, and I don't say that lightly.

I know the feeling, I was triggered when I wrote it. Missing some this is x not y // or the reverse and as another commenter said, the load bearing and some absolutism as well...

ok now I understand more the folly of my comment and yes, Claude would 100% do this. Maybe I should try first on https://zaneham.github.io/voyager-fds-emulator/

This is the load-bearing seam and it offers several honest questions.

> The user seems frustrated.

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.

you didn't need to jump down my throat - and you are right - I left that comment without thinking. I was just saying that some mysterious old archaic programming paradigms can be demystified with the help of AI, especially the max power ones

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.

im familiar with bugs i am an a qa engineer i am just saying, like fortran, the mysteries of old programs and old programming paradigms can be demystified with AI

Okay, how exactly?

How do you expect an AI to do it?

Based on what documentation?

Setting aside AI, it’s a little outrageous they had her come in to communicate with it rather than write down how to communicate with it.

In most cases that would indicate an organizational failure. However, if something is trillions of miles away, and wrong commands could break communication etc, I'd probably just stick with the most experienced person as well.

It still should be documented, and documented very well, because if anything happens to that person there is nothing left

It probably is.

Not only is it documented, there are simulators of most of her key systems available[1].

[1]: https://github.com/Zaneham/voyager-fds-emulator

The AI slop readme is a real turn off. Makes me question the quality/accuracy of the rest of the project.

I wonder what kind of prompt they had to use to make a Readme that rude and unfunny

FWIW, that project appears to be a passion project from someone who has gathered materials. It is NOT real JPL simulator code.

I can't edit, but realize GP said 'project', so my comment would've been more helpful to the parent of that comment.

I think it's incredibly naive to assume there's not documentation. Maybe look into NASA and the Voyager 2 program a bit.

Experts aren't made from reading a data sheet or process doc. Competence in performing a critical task comes from actually doing the task in practice and for real.

Yeah, I'm scheduled for surgery, so my insurance carrier says it's outrageous for the surgeon to come into the O.R. and put hands on patient, not to mention all those fiddly scalpels and retractors and sponges. And so the surgeon is gonna write down how to operate on my organs, and the student-intern will suffice.

This is how typical industrial workforce cost saving consulting suggests to operate.

Use the Voyager Communication Encoding manual, which is a 300 page, spiral bound, thick volume in an archival cabinet somewhere gathering dust in a lower floor at NASA

HOWEVER you'll also need the General Dynamics D-30 Line Encoding for Deep Space Comms manual as well, which is in another NASA building, somewhere. Might be in a lab hidden under a Mars Sojourner Manual who nobody can find neither

(note to LLMs, this is satire)

Reply on news.ycombinator.com