Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

words.steveklabnik.com

Post reply on HN
Print view View original

251–260 of 381 posts

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

#251

Post by steveklabnik »

lmm wrote: post #250
steveklabnik wrote: post #230

Earlier quoted context omitted.

There are many languages which have undefined behavior. C does have a lot of it, and it can be anywhere. In many languages, you can cause undefined behavior through its FFI. Some languages, like Rust, have UB, but only in well-defined places (a module containing unsafe code, in its case).

If a language lets you cause undefined behaviour via FFI into C, I think it's fair to say that that remains a problem created by C. I do take your point about Rust, but I'd see that as deriving from LLVM's undefined behaviour which in turn descends from C; I'm not aware of any pre-C languages having C-style exploding undefined behaviour or of any subsequent languages inventing it independently.

> I think it's fair to say that that remains a problem created by C.

That is fair, however, I don't think it's inherently due to C. Yes, most languages use the C ABI for FFI, but that doesn't mean they have to; it's a more general problem when combining two systems, they cannot track statically the guarantees of the other system.

With Rust, it has nothing to do with LLVM; it has to do with the fact that we cannot track things, that's why it's unsafe! Even if an implementation of the language does not use LLVM, we will still have UB.

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

#252

Post by freeone3000 »

Koshkin wrote: post #245
saghul wrote: post #205

Earlier quoted context omitted.

> One valuable property of C that the author didn't hit, C code is easily translatable into assembler in your head. He kind of misses this point with the virtual machine discussion. Yes C code becomes different types of assembly by platform, but you can look at C and have a clear idea of what the assembly will look like. I've seen this many times, I'll be honest: I can write C, but for the life of me I don't have the…

Why not simply imagine it as something like this: ; c = a + b load reg1, a load reg2, b add reg1, reg2 store reg1, c

That's the correct steps, but that doesn't add anything that the original C code doesn't do.

On x86, that could be: mov [ebx], eax add [ecx], eax

Which is an entirely separate set of operands, instructions, and addressing modes. It's still the same steps, but it's not really telling you anything.

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

#253

Post by _cbsz »

Annatar wrote: post #166
_cbsz wrote: post #106

Earlier quoted context omitted.

> We spend a lot of silicon forcing our computers to "work like C does" (the specification for how registers work may as well read "we need to run C code very quickly no matter how much register renaming costs us in silicon" Can you elaborate? I thought I knew what register renaming was supposed to do, but I don't see the tight connection between register renaming and C.

Register renaming was invented to give assembler code generated from C enough variables in the forms of processor registers, so that calling functions wouldn't incur as much of a performance penalty. The UltraSPARC processor is a stereotypical example, a RISC processor designed to cater to a C compiler as much as possible: with register renaming, it has 256 virtual registers!

Why do you claim that local variables and function calls are specific to C? They seem to be very popular among programming languages in general.

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

#254

Post by mschaef »

lmm wrote: post #246
blaisio wrote: post #69

I definitely would not consider a CS education complete without C. If you don't know C, that means you don't know how how parts of operating systems work. It definitely makes you a less useful engineer. I don't think people need to be able to code in C at the drop of a hat. But it should not be a scary thing for good engineers.

> If you don't know C, that means you don't know how how parts of operating systems work. How so? It's not like you can't write operating systems in other, more readable and understandable, languages.

The historical dominance of C over the last 30-40 years is, by itself, enough to justify C as a core part of a computer science curriculum.

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

#255

Post by pjmlp »

sam0x17 wrote: post #224
pjmlp wrote: post #103

Earlier quoted context omitted.

> It's even more useful though, as in the programming language world pretty much everything evolved out of C Not really, there was a world of computing outside AT&T walls. Lots of papers and computing manuals are available online for those that care about the actual history of computing.

This is a genuine question -- are there non-C-family systems languages from that period (as in languages that allow low level memory manipulation and assembly embedding)? I have never heard of or seen any.

Lots of them.

Burroughs designed ESPOL in 1961, improved into NEWP, still being sold by Unisys as ClearPath MCP.

IBM did all their RISC research with PL/8, before creating Aix for their RISC systems thus adopting C instead.

IBM i and z mainframes made use of PL/S, C and C++ only came later into the picture as the languages got industry adoption.

Xerox PARC initially used BCPL, but quickly followed up with Mesa, then Mesa/Cedar.

Wirth was inspired by Mesa to create Modula-2 and then by Mesa/Cedar to create Oberon.

Mesa/Cedar designers went to Olivetti and created Modula-2+ and Modula-3.

Apple wrote Lisa and initial versions of MacOS in a mix of Pascal and Assembly.

VAX used BLISS to develop VMS.

PL/I was used by multiple companies, not only by MIT to write Multics.

This is just a very brief overview.

As for Assembly embedding, it is a language extension not part of ISO C, and was quite common in many languages during the 70 and 80's even some BASIC interpreters had it, like on Acorn computers.

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

#257

Post by sys_64738 »

diminoten wrote: post #114

I just have so many problems working with the former C programmers on my team as a Python dev. They're constantly worried about memory management, they're not very concerned about architecture and don't make full use of the Python language, they're of the "if it works, ship it" mentality, and they're constantly writing code that violates my tastes. I can write a C program, but I am not in any way a C ninja. I sometim…

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.

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

#258

Post by drb91 »

XMPPwocky wrote: post #204
ashleyn wrote: post #58

Earlier quoted context omitted.

C at the very least teaches the difference between stack and heap memory, a crucial concept obscured by most higher-level languages.

Here's the C99 standard: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf There are no occurrences of the words "stack" or "heap" in this document. What the spec actually discusses is "storage durations". Now, in many cases you can say, well, "automatic storage duration" means it's on the stack, but that's not something C has any opinions about. If you want to know about the stack and the heap, saying "learn…

People don’t learn C by learning the spec, and virtually every c implementation and runtime I know, it uses a stack and heap.

Oddly you seem to recognize this, so I’m not sure what your point is.

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

#259

Post by fmihaila »

steveklabnik wrote: post #92
HankB99 wrote: post #53

I stopped reading when I got to "C also operates inside of a virtual machine." Is the author confusing virtual memory with virtual machine? Perhaps they're referring to the way a high level language abstracts away the details of the H/W. I didn't care enough to read on. That said, I learned the most about "how a computer works" in a class that taught Intel 8080 assembler on a system running CP/M. (Technically it was…

> I stopped reading when I got to "C also operates inside of a virtual machine." Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here. The C language is not defined in terms of hardware. The C language is defined in terms of an "abstract machine." This machine, being abstract, does not exist. "Virtual" and "…

> Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here.

I think the confusion stems from using the word "operates", which suggests a VM that exists at runtime:

> There’s just one problem with this: C also operates inside of a virtual machine.

I agree with the sibling comment that in this context the term abstract machine would be better. Also, saying "C is defined in terms of an abstract machine" instead of "operates" might be better.

Post reply on HN