Live data from Hacker News

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

words.steveklabnik.com

261–270 of 381 posts

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

#261
post #161
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.

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…

They may not be distinguished at the instruction level, but if you’re trying to argue it’s not a useful thing to teach you’ve lost me. Dynamic vs static vs scoped (stack) allocation is incredibly important to reasoning about basic programs.

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

#262

Earlier quoted context omitted.

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.

Depends on what you mean by "general purpose computing". Is machine learning general purpose? Are graphics general purpose? Is playing video and audio general purpose? If those aren't general purpose, I'm not sure what "general purpose" means.

GPUs and other specialized hardware aren't good at everything, and I acknowledged as much upthread, but the set of problems they're good at is large and growing.

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

#263
post #242

Earlier quoted context omitted.

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 th…

> 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.

I strongly disagree. Yes some execution units are more let's say "dedicated" to pointers than other, and obviously ultimately you will dereference your pointers, so you will load/store, but compilers happily emit lea to do e.g. Ax9+B and in the other direction, add or sub on pointers. Some ISA even have almost no pointer "oriented" register (and even x64 has very few)

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

#264

Earlier quoted context omitted.

> 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 abs…

In the language of the spec, it does “operate” inside the machine. Well, the spec says “execute” but that’s even more likely to be confused with a runtime thing.

Additionally, and this is something I really didn’t get into, languages aren’t inherently compiled or interpreted. You could have a C interpreter.

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

#265
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.

Related article by Joel Spolsky. "The Perils of Javaschool" [1]

C really will test you and make you a better programmer than any high level language ever could. Someone who is a good C programmer will right better code in any language than someone who is just focused on high level languages. The same could not be said for python, java, or js.

1. https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...

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

#266

I teach C. It's an increasingly terrible way of learning "how a computer works". You would be much better off learning a little assembler. The problem is most of the pain of learning C comes from undefined behaviour, which isn't how "computers work". The fact that depending on optimisation level writing past the end of an array might write to memory, or might not, is (mostly) a unique feature of C. Similarly sometime…

When I was learning assembly, one of my favorite things to see was what assembly got generated (more or less) from really, really simple higher level application code (C, C++, etc). Code consisting of really simple arithmetic, loops, function calls, object creation, etc.

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

#267

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…

I don't disagree with anything you said, but I wanted to point out you also don't disagree with the author. Your point ("this phrase is an approximation") is also the author's point. I felt he walked through the why fairly and with nuance.

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

#268
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…

Debates about the "stack" rage every couple of years on comp.lang.c. Invariably people conflate two different meanings: (1) an abstract data structure with LIFO ordering semantics, and (2) #1 implemented using a contiguous block of [virtual] memory.

The semantics of automatic storage necessarily imply #1, but they do not require #2. Indeed, there are widely used implementations which implement #1 using linked lists (e.g. IBM mainframes, and GCC's split stacks or clang's segmented stacks).

Similarly, function recursion semantics necessarily imply #1 for restoring execution flow, but not #2. In addition to the examples above, so-called shadow stacks are on the horizon which maintain two separate stacks, one for function return addresses and another for data.[1] In the near future a single contiguous stack may be atypical.

[1] Some variations might mix data and return addresses if the compiler can prove safe object access. Or the shadow stack may simply contain checksums or other auxiliary information that can be optionally used, preserving ABI compatibility.

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

#269

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 ?

If only things were so simple... https://en.m.wikipedia.org/wiki/Modified_Harvard_architectur...

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

#270
post #239
post #234

One thing I like about C is that it is a small language hence making it very approachable to newcomers. Other systems languages (C++ / Rust) have much longer roads to being productive.

What does "small language" even mean here? C has far more keywords, built in control flow constructs, and other special case builtins than, say, OCaml, so I'd argue it's actually a very large language. C's standard library is small but only because it's missing huge amounts of functionality (which might be acceptable in a language with a good dependency manager, but C doesn't have that).

Here is my (arbitrary) definition of small 1. Have a concise crisp book capturing the language

2. Give you a (false) sense of being productive in a couple of days (maybe a week)

3. Limited syntactic extensibility / metaprogrammability so that you dont run into extremely "clever" online discussions.

4. Ability to be productive without learning a new build tool / ide.

5. Ability to be productive without requiring auto completion.

Post reply on HN