C is a much more appropriate choice in my opinion. It expresses 99.9% of the same concepts while being orders of magnitude faster to read. Most people I know who have tried to read (some of) Knuth cited MMIX among their reasons for eventually growing tired and abandoning the effort.
> It expresses 99.9% of the same concepts while being orders of magnitude faster to read.
Knuth thinks so, or did at some point.
"I think C has a lot of features that are very important. The way C handles pointers, for example, was a brilliant innovation; it solved a lot of problems that we had before in data structuring and made the programs look good afterwards. C isn't the perfect language, no language is, but I think it has a lot of virtues, and you can avoid the parts you don't like. I do like C as a language, especially because it blends in with the operating system (if you're using UNIX, for example).
All through my life, I've always used the programming language that blended best with the debugging system and operating system that I'm using. If I had a better debugger for language X, and if X went well with the operating system, I would be using that."
Dec 7, 1993, Computer Literacy Bookshops Interview.
What he's talking about is pointer arithmetic. In assembly you have to "know" what is being pointed at such that you can access an element in an array or a component of a composite type, for example. The computer only knows about bytes. In C you can just do stuff like `(p + 6)->t` and the compiler knows how many bytes "+6" is because it knows what `p` is pointing at.
> Also, the combined dereferencing and member lookup operator (->).
That's actually a dud. The motivation was likely caused by the silly choice of the dereference operator being unary/prefix, requiring parentheses in (*ptr).memb.
Compare with Pascal's ptr^.member where no parentheses are required.
But ptr.memb can just work as well as value.memb. The operator statically knows whether the left operand is a pointer to a struct/union or a struct/union value.
