Live data from Hacker News

Should you learn C to “learn how the computer works”?

words.steveklabnik.com

331–340 of 381 posts

Re: Should you learn C to “learn how the computer works”?

#331
post #191

Earlier quoted context omitted.

> Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design. This I agree with and also I'd call the most important reason for Rust programmers to learn C. The C ABI is a lingua franca, not because it's good or pure but (as with spoken linguas franca) happened to be in the right place at the right time. It defines certain conventions and assumptions…

For those who don't know what ABI means (as I did not) and thought it might be a typo. ABI = Application Binary Interface https://en.wikipedia.org/wiki/Application_binary_interface https://upload.wikimedia.org/wikipedia/commons/b/bb/Linux_AP...

To save you the read: in web terms, the API is e.g. Stripe and the ABI is HTTP.

Re: Should you learn C to “learn how the computer works”?

#332
post #124

Earlier quoted context omitted.

The exact reason why C shouldn't be used to write high level software. Also, the set of things you can do in standard C is a subset of the things you can do in assembler.

heated debate over where to draw the line between low and high level software ensues

Grumble grumble...

Procrastination ensues

Re: Should you learn C to “learn how the computer works”?

#333

Earlier quoted context omitted.

In what sense is stack-relative addressing, PUSH, POP, and addition/subtraction on the stack pointer not ISA-level support for stack allocation of local variables?

Addition, subtraction, and stack-relative addressing are, in most architectures I'm familiar with, generic- stack-relative addressing ends up just being a special case of register-relative addressing, and addition and subtraction are rather important instructions in their own right. PUSH/POP are more obviously "hey store your locals on the stack, kids", but on, say, x64, how often do you actually see a push instead o…

On x86, push/pop have dedicated hardware optimizations known as the stack engine which perform most of the rsp increments/decrements and passes those offsets into the decoder, instead of using executions slots on them. push/pop are also much smaller than the corresponding mov/add instructions.

It's much more optimal to use a series of push/pops for smaller operations like saving registers before a call than to manually adjust and store onto the stack.

While technically this is still incrementing/decrementing a register and storing, the amount of isa/hardware support for such things clearly demonstrates that the x86 isa and modern x86 hardware gives special treatment to the stack.

Re: Should you learn C to “learn how the computer works”?

#334

Earlier quoted context omitted.

The language doesn't break as much today, but what constitutes "idiomatic" Rust is constantly changing. I don't use Rust but I spend a lot of time with people who do and am echoing what I've heard from them, and seen for myself as a casual user of Rust software and occasional drive-by contributor. It doesn't have to be a monumental task. Rust is simply too big, and getting bigger.

Thanks. That’s much more reasonable, IMHO. Specs are always a monumental task. The first C spec took six years to make in the first place!

But C never set out to be what it is today. It was a long time before anyone thought a spec was worth writing. For a language with the stated design goals of Rust, a specification and alternative implementations should be priority #1. You can't eliminate undefined behavior if you don't define any!

Re: Should you learn C to “learn how the computer works”?

#335
post #191

Earlier quoted context omitted.

> Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design. This I agree with and also I'd call the most important reason for Rust programmers to learn C. The C ABI is a lingua franca, not because it's good or pure but (as with spoken linguas franca) happened to be in the right place at the right time. It defines certain conventions and assumptions…

There is not really any such thing as "the" C ABI -- different platforms have totally different conventions, even on the same instruction set.

It's shorthand for "the ABI relevant to the current context", which is entirely reasonable.

Re: Should you learn C to “learn how the computer works”?

#336

C doesn't necessarily teach you how computers work. But it does teach you how software works. Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design. >You may have heard another slogan when talking about C: “C is portable assembler.” If you think about this slogan for a minute, you’ll also find that if it’s true, C cannot be how the computer work…

C is a useful and universal model of computation not just because most native software is ultimately built on C, but because any hardware that people end up widely using also has to have a sensible C compiler.

The C model is relatively close, I’ve heard, to the hardware of a PDP-11. But there have been tons of abstractions and adaptations on both sides of that coin ever since; not only can a C program provide a language runtime that behaves quite differently from a PDP-11, but the C program itself is compiled to machine code that is sometimes quite different than the code for a PDP-11, and even the low level behavior of the CPU often differs from what’s implied by the ISA. And while all of these models of computation are Turing equivalent, the transformations to and from C are very well known.

Re: Should you learn C to “learn how the computer works”?

#337

Earlier quoted context omitted.

To be exceedingly clear about it: yes, that is my fundamental point.

But, I mean, how useful is that point? Virtually everything, including the X86 ISA, is an "abstract machine".

The C abstract machine isn't implemented in hardware. It needs a compiler to translate from the C abstract machine semantics to hardware ISA semantics. Those compilers have grown to exploit the peculiarities of the C abstract machine in ways that no hardware implementation would do.

Re: Should you learn C to “learn how the computer works”?

#338

Earlier quoted context omitted.

Python has scalability issues which are solved by calling into C libraries. What does that tell you about whom should be listening to who? There are many reasons C programmers are experts in their craft while python programmers are 10 a penny.

My point was that C programmers aren't experts at their craft, just experts at C, and all the habits that were possibly good in C carry over, making them less than good at Python. Also, I think your comment is a great example of the mentality that C programmers I've worked with brought to the table (partially because it's true for C but untrue for other language, particularly python); that if you can write code that…

C is their craft and they're experts so what's not to like?

I'm not sure what this 'good enough' angle is and why you think it's specific to C. It's an issue to other language more than C as those other languages are often used by shops without proper software engineering practices in place. All the places I've worked which use C enforce those SW practices but it's not clear to me that the same could be said for other languages.

If anything, one of python's downfalls is its desire to do too much complexity in lambda or list comprehension statements. Those areas that cause you to stop and have to think about the code are weaknesses of python but every novice tries to do it by copying and pasting from stackoverflow.

So I think you've got the position flipped, IMO.

Re: Should you learn C to “learn how the computer works”?

#340
post #90

C conceptually is the nearest layer to the hardware that you'll get outside assembler. What that means is that most C operations can be easily translated into the machine code equivalents and that makes debugging of compiled code so much easier. A disassembly of many binaries will reveal their C roots by function calls being equivalent to jump statements, as an example. If you have the C source then you can usually f…

You can get that as well with NEWP, PL/I, Extended Pascal, BLISS, Modula-2 and tons of other system languages.

Maybe but there's a reason C emerged as the winner because none of those systems really has an established reference model to look at. C has several - e.g. UNIX being written in C.
Post reply on HN