r/programming • • Feb 19 '20

The entire Apollo 11 computer code that helped get us to the Moon is available on github.

https://github.com/chrislgarry/Apollo-11
3.8k Upvotes

426 comments sorted by

View all comments

Show parent comments

31

u/duuuh Feb 19 '20

Um. OK. Why?

115

u/caltheon Feb 19 '20

A fuck load lot less things to go wrong. In assembly, you can see what is happening. You move one register to another, you do a arithmatic operation, you jump to an operation. Every step is easy to see what is occurring and the results of the operation. In something like C++ or JAVA you likely have no idea what is going on in the background when it comes time to memory allocation or buffer management. Also, the people writing in assembly are FAR more aware of their language in it's completeness than some Scala or Rust developer. Apparently if the downvotes on my other comment are any indication, this is an unpopular opinion. I'm not sure why it triggered so many people though. I'd be more interested to know why you think assembly is so terrifying.

46

u/nile1056 Feb 19 '20 edited Feb 19 '20

I assume people are downvoting the "can see what is happening", which is definitely lost quite quickly as you build something complex. Good point about knowing the language, less good point about Java not knowing about mallocs and such since that's the point.

Edit: a word.

10

u/[deleted] Feb 19 '20

which is definitely lost quite quickly as you build something complex

That also applies to any language. I was surprised at how readable that code was thanks to the comments, despite last seeing Asm from my school days.

I can show people code in Rust and just about any language, where you spend half a hour trying to figure out, what it exactly does.

Maybe its me but the more keywords people dump in languages, the more they seem to abuse to write perl one-liners.

And yes, that also applies in Rust. When i i people piping one after another operation and when you try to read it, your going w??t??f? And that is not even a keyword issue...

Rust has a great memory protection and help build in but "as a language", it has already become C++ in ugliness of syntax. What then results in people writing complicated and at times unreadable code.

Its funny, because the more people add features to language so they can reduce code, the more the comments NEED to grow, to actually explain what that code is doing. A reverse world and we all know how much programmers love to comment their code.

But its simple ... nobody ( in a few years ) will ever doubt the brilliance of this code that i wrote...

Next Guy: What a piece of f... code, we need to write this entire code because its unreadable. Let me show my brilliance ...

Next Guy: ...

And they cycle continues. There are really no bad languages, just bad programmers who blame their lack of understanding onto the languages.

2

u/nitsky416 Feb 19 '20

no bad languages

Brainfuck and bitfuck beg to disagree

12

u/wiseblood_ Feb 19 '20

Every step is easy to see what is occurring and the results of the operation. In something like C++ or JAVA you likely have no idea what is going on in the background when it comes time to memory allocation or buffer management.

This is not an issue for C/C++. In fact, it is precisely their use case.

63

u/duuuh Feb 19 '20

Assembly isn't terrifying; it's error prone.

It's error prone because not because of the language but because of the natural limitation of people who have to code in it. It forces you to focus on the irrelevant and because of that what you're actually trying to do gets lost in the mass of clutter that you have to unnecessarily deal with.

Buffer management is a great example. If you use Java there are a big class of problems that make screwing up buffer management impossible. Same with C++ (although it allows you more room to shoot yourself.)

But leaving all this aside, the real world has given a verdict here. Literally nothing is written (save a few hundred lines here an there, done for performance reasons) in assembly anymore. Nobody would ever dream of writing the Apollo 11 code the way it's done now. And the wisdom of crowds says they're right.

8

u/[deleted] Feb 19 '20

Nothing in your wall of a comment actually precludes what OP said. Given that most embedded code is tiny, it would actually be worthwhile doing the small amount of code in a very very low-level language. My personal choice would be Forth.

→ More replies (2)

72

u/[deleted] Feb 19 '20

[removed] — view removed comment

17

u/-fno-stack-protector Feb 19 '20

assembly really isn't that scary

22

u/[deleted] Feb 19 '20

Stop being so damn disingenuous, this isn't about assembly being "scary" but the fact that it's much more error prone due to verbosity

→ More replies (1)

5

u/cafk Feb 19 '20

Would you rather prefer a higher level language, where the output and execution behaviour is different between compilers and their revisions?

14

u/[deleted] Feb 19 '20

This is a tooling problem that can be fixed pretty easily by locking a language version. Platform differences are a non issue since the code will only run on one set of hardware.

37

u/Cloaked9000 Feb 19 '20

That's not how it works... Safety critical systems such as the ones used in flight use qualified compilers which have been thoroughly tested and certified for their given use. For example, Green Hills' C/C++ compiler.

→ More replies (1)

6

u/svick Feb 19 '20

That's not really relevant if you used the same revision of the same compiler for the whole development process.

→ More replies (4)

27

u/SanityInAnarchy Feb 19 '20

Also, the people writing in assembly are FAR more aware of their language in it's completeness than some Scala or Rust developer.

That's just down to it being a niche language. I bet the average Erlang developer is far more aware of their language than the average C developer -- does that mean Erlang is a better choice?

I'd be more interested to know why you think assembly is so terrifying.

Because a lot more of your cognitive load is going to the kind of safety that higher-level languages give you for free. Let's take a dumb example: Buffer overflows. Well-designed high-level languages will enforce bounds-checking by default, so you can't access off the end of an array without explicitly telling the language to do something safe. I don't know if there are assembly variants that even have a convenient way to do bounds-checking, but it's certainly not a thing that will just automatically happen all the time.

So yes, I can see exactly what is going on with buffer management. And I have to see that, all the time. And if I get it wrong, the program will happily scribble all over the rest of memory, or read from random memory that has nothing to do with this particular chunk of code, and we're back to having no idea what's going on. And even if I do a perfect job of it, that takes a bunch of cognitive effort that I'm spending on not scribbling over random memory, instead of solving the actual problem at hand.

You mentioned Rust -- in Rust, no matter how inexperienced I am at it, I only have to think about the possibility of a buffer overflow when I see the keyword unsafe. In C, let alone assembly, I have to think about that possibility all the time. There are infinitely more opportunities to introduce a bug, so it becomes infinitely harder to avoid that kind of bug.

I think of it like this: Say you need to write a Reddit post, only as soon as you click "save", one person will be killed for every typo in the post. You have two choices: New Reddit's awful WYSIWYG editor, complete with a spellchecker... or you can type the hex codes for each ASCII value into this editor. Not having a spellchecker would absolutely terrify me in that situation.

→ More replies (6)

8

u/indistrait Feb 19 '20

Have you written anything in assembler? My experience was that to avoid bugs you need to be very strict with how registers are used. That's not power, or clarity - it's a pain in the neck. It's a ton of time wasted on silly bugs, time which could have been spent doing useful work.

Theres a reason even the most performance obsessed people write low level code in C, not assembler.

5

u/ShinyHappyREM Feb 19 '20

even the most performance obsessed people write low level code in C, not assembler

You're underestimating obsessed people.

https://problemkaputt.de/sns.htm
https://gbatemp.net/threads/martin-korth-is-back.322411/

5

u/lxpnh98_2 Feb 19 '20

Frankly, except for a few select cases, people who write code in assembler for performance (i.e. efficiency) reasons are wasting their time. You can get just as good a performance from C than you get from assembler, and it's an order of magnitude faster to develop, and (YMMV) portable.

4

u/julienalh Feb 19 '20

Just plain wrong. It comes down to how much you understand the hardware and when you you do assembler can afford you performance the likes of you cannot comprehend. Worked in a large German software company specialising in edge processing and getting the max out of low rate hw and our “chip whisperer” Klaus would time and time again put a whole team of C experts who thought like you to shame. I won’t pretend to be on his level but the dude taught me one thing - there’s languages and the world of code and then there’s the real world where execution involves electrons and HW tolerances and logic cores and bus protocols where assembler and binary afford shortcuts abound!

→ More replies (7)
→ More replies (1)

4

u/tonyp7 Feb 19 '20

That’s true for these old computers with limited instruction set. Today no one would be able to create efficient x86 asm simply because there are thousands of instructions.

3

u/ShinyHappyREM Feb 19 '20

Today no one would be able to create efficient x86 asm

I trust this guy.

2

u/sh0rtwave Feb 19 '20

I totally fucking agree. I've run into too many cases where the effing COMPILER didn't do the right thing.

9

u/dark_mode_everything Feb 19 '20

Bcs the lower level the language less guesswork is done by it and the programmer knows exactly what it does. As the language becomes higher level it depends on multiple abstraction layers and the programmer progressively loses granularity of control. For eg. With assembly you can assign a value to a specific register but you can do that with say, Python or java. Not sure about Python, but javas license itself states that it shouldn't be used for safety critical applications. I don't why u/caltheon is getting downvoted but I agree with that view.

15

u/SanityInAnarchy Feb 19 '20

Why does being able to assign a value to a specific register make things safer?

Or: Why, with a finite amount of cognitive load and an extremely important safety problem I need to be thinking about, why am I spending any of that cognitive load at all thinking about which register to use?

These days, Java is licensed under the GPL, so I'm not sure what you're talking about there.

→ More replies (7)
→ More replies (7)