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

241–250 of 381 posts

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

#241

Post by droithomme »

I agree with his own summary of his own article: "[T]his idea is not inherently wrong, but does come with some caveats. As long as you keep those caveats in mind, I think this can be a viable strategy for learning new and important things."

If one really wants to know how the computer works, the course "Build a Modern Computer from First Principles: From Nand to Tetris" is excellent. You start with basic gates, build logic devices, build a CPU, build a computer, write an assembler, write a virtual machine, and finally write a compiler and then implement whatever game you like in it.

The class, astonishingly, has no prerequisites, and has been completed by people from 10 to 80.

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

#242

Post by jreck »

arcticbull wrote: post #143
jreck wrote: post #75

Earlier quoted context omitted.

You can also learn that difference in something like C#. You don't need C for that. And C pretends there's a distinction between the stack & heap that doesn't actually exist. There is no significant difference there.

I suggest maybe you learn C :) or Rust. There are significant performance and strategy differences between the stack and the heap. On the stack, allocation is cheap, deallocation is free and automatic, fragmentation is impossible, the resource is limited, and the lifetime is lexically scoped. On the heap, allocation might be cheap or it might be expensive, deallocation might be cheap or it might be expensive, fragmen…

> Your statement is equivalent to saying "there's no difference between pointers and integers" - technically, they are both just numbers that live in registers or somewhere in memory. In reality, that approach will not get you far in computer science.

No, because in reality those are handled by different computational units. Integers are handled by the ALU, and pointers are handled by the loader. They are distinct things to the CPU.

Stack & heap have no such distinction. There isn't even a heap in the first place. There's as many heaps of as many sizes as you want, as the "heap" concept is an abstraction over memory (strictly speaking over virtual address space - another concept C won't teach you, yet is very important for things like mmap). It's not a tangible thing to the computer.

Same with the stack. It's why green-threads work, because the stack is simply an abstraction over memory.

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

#243

Post by lmm »

Annatar wrote: post #171
hfdgiutdryg wrote: post #74

Earlier quoted context omitted.

I'd argue that you shouldn't be driving a car unless you've rebuilt a transmission yourself, but that argument wouldn't go far.

It would be valid, though. A computer programmer must understand how a computer works lest she or he write slow, bloated, inefficient software.

Given how many person-years have been saved and how much value has been produced by "slow, bloated, inefficient software", I must disagree in the strongest possible terms. Producing "slow, bloated, inefficient software" is far, far preferable to not producing software at all.

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

#244

Post by btmorex »

pcwalton wrote: post #185
ddevault wrote: post #34

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…

Our popular software stacks are written in C and C++, but that's more because of history than anything else. I rarely reach for just "classic" C for performance anymore. These days I'm more likely to reach for GPUs, SIMD intrinsics (available in Rust), or at least Rust/Rayon for code that needs maximum performance. C is fundamentally a scalar language. In 2018, the only code for which "classic" C is the fastest is co…

Except even when you think vectorized processing should be a performance win, it often isn't: http://www.vldb.org/pvldb/vol11/p2209-kersten.pdf

I'd argue that GPUs and SIMD instructions have so many restrictions that they're useless for general purpose computing. Yeah, they have niche spaces, but in terms of all the different kinds of programs we write, I think those spaces are going to remain niche.

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

#245

Post by Koshkin »

saghul wrote: post #205
joshe wrote: post #186

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. This is at a really good level for driving intuitions about what the computer is actually doing. Yo…

> 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

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

#246

Post by lmm »

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.

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

#247

Post by freeone3000 »

tptacek wrote: post #202
geofft wrote: post #161

Earlier quoted context omitted.

There is no difference inside the computer between those concepts. For convenience, many architectures have a single assembly instruction for taking one register (called the "stack pointer"), adjusting it by a word, and moving a register to the address at that word, and a corresponding instruction to move data back to a register and adjust it in the other direction. That's the extent of the abstraction. You can imple…

I think this is lawyering a bit. There might not be a "heap", per se, but there is stack allocation (which is embedded all the way into the ISA) and "everything else". You can, after all, build a simple "heap" on top of an adequately large static buffer. Since this is a distinction that is very important both for performance in high-level languages and for correctness in C, and one C forces you to think about and mak…

The distinction is important for apartmented thread models, such as those found on Windows, where you do have multiple heaps, and pointers allocated on one are not valid in another.

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

#248

Post by hsivonen »

jcelerier wrote: post #125
ddevault wrote: post #34

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…

> there are many kinds of different computers, with different architectures are there ? how many laptops, desktops, smartphones, tablets, use anything else than the von neumann architecture ?

On hardware level, all those use von Neumann architecture. Wasm, however, exposes Harvard architecture (implemented on top on von Neumann machines). Yet, you can compile C to Wasm, which is a data point about how abstract C is: so abstract that it can target Harvard architecture despite targeting just von Neumann architecture being sufficient for targeting modern hardware.

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

#249

Post by gdwatson »

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…

"C" doesn't just include the spec but also the customary semantics [1] of the language. The customary semantics certainly include the stack and the heap.

[1] https://arcanesentiment.blogspot.com/2014/12/customary-seman...

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

#250

Post by lmm »

steveklabnik wrote: post #230
lmm wrote: post #225

Earlier quoted context omitted.

"Exploding" undefined behaviour is a problem created by C. Other languages don't have it, not even assembly languages.

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.

Post reply on HN