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

281–290 of 381 posts

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

#281

Post by lmm »

steveklabnik wrote: post #251
lmm wrote: post #250

Earlier quoted context omitted.

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

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

I can see that any implementation of unsafe Rust would always have assembly-like unsafeness (e.g. reading an arbitrary memory address might result in an arbitrary value, or segfault). But I don't see why you would need C-style "arbitrary lines before and after the line that will not execute, reads from unrelated memory addresses will return arbitrary values" UB?

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

#282

Post by tormeh »

maceurt wrote: post #265
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.

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

Nonono. I've seen a good engineer write C code in C#. I think you should start with Scala or Rust and do the blob languages later.

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

#283

Post by lmm »

dman wrote: post #270
lmm wrote: post #239

Earlier quoted context omitted.

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…

I don't see how C passes 2 (it's notorious as a language where it takes 200 lines to make a HTTP request) or 3 (it has arbitrary textual macros, so there's all sorts of "cleverness" e.g. GObject). And I'd regard 4 and 5 as false as even C-with-IDE is less productive than e.g., to return to the same example, OCaml-without-IDE.

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

#284

Post by steveklabnik »

lmm wrote: post #281
steveklabnik wrote: post #251

Earlier quoted context omitted.

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

> 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. I can see that any implementation of unsafe Rust would always have assembly-like unsafeness (e.g. reading an arbitrary memory address might result in an arbitrary value, or segfault). But I don't see why you wou…

You are right that there's no inherent need for UB. However, we made the choice to have it.

The reason to have it is the exact same reason that the distinction between "implementation defined" and "undefined" exists in the first place: UB allows compilers to assume that it will never happen, and optimized based on it. That is a useful property, but it's a tradeoff, of course.

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

#285

Post by munificent »

tralarpa wrote: post #272
munificent wrote: post #115

I like this article a lot. There are two ways you can think of looking at the field of programming: * As a continuum from "low level" to "high level". * As a giant bag of topics: strings, heap, hash tables, machine learning, garbage collection, function, instruction set, etc. If your goal is to have a broad understanding of CS, you want to explore the whole continuum and many topics. C is great for that because it ex…

I still don't understand why you should learn C if you really want to know "how the computer works". The author says "By learning C, you can learn more about how computers work", but why taking the long path if the short path exists? Just learn assembly language. It doesn't take that much time, a few weeks are enough to get a good insight into how simple CPU work (registers, memory, no difference between numbers and…

> if you really want to know "how the computer works".

This depends on what the person is really trying to learn. If they are just interested in learning how a simple CPU does what it does, then, yes, going straight to an assembly language for some old chip from the 80s is a good idea. Writing an emulator is a fun and instructive exercise.

But my impression is that most programmers who want to learn how the computer works want to because they want to be able to write more efficient software. They want to understand how computer performance works. Learning a simple CPU is anti-helpful for that. It leads you to believe wrong things like "all memory access is equally fast".

If you want to learn how to write faster code, C is pretty good because it strips away the constant factor overhead of higher level languages where things like GC, dynamic dispatch, and "everything is a reference" mask hardware-level performance effects.

It lets you control layout in memory, so you can control data cache effects. Without a VM or interpreter overhead, most of the branches the CPU takes will be branches you explicitly write in your code, so you can control things like the branch predictor.

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

#286

Post by School-Cotton »

geofft wrote: post #191
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 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.

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

#287

Post by arcticbull »

TheOtherHobbes wrote: post #192
Sir_Cmpwn wrote: post #82

Earlier quoted context omitted.

You're joking. There's a very serious distinction between the stack and the heap - perhaps they live in the same memory but they are used very differently and if you mix them up your things will break.

There is no hardware distinction between stack memory and heap memory. In fact C teaches a model of a semi-standard virtual architecture - loosely based on the DEC PDP7 and/or PDP11 - which is long gone from real hardware. Real hardware today has multiple abstraction layers under the assembly code, and all but the top layer is inaccessible. So there's no single definitive model of "How computers work." They work at w…

There definitely is, unless there's a hardware heap pointer and hardware allocation and deallocation instructions, as there are for the stack :)

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

#288

Post by monocasa »

jreck wrote: post #276
monocasa wrote: post #209

Earlier quoted context omitted.

Stack accesses _are_ different in hardware these days, which is why AArch64 brings the stack pointer into the ISA level vs AArch32, and why on modern x86 using RSP like a normal register devolves into slow microcoded instructions. There's a huge complex stack engine backing them that does in fact give you better access times averaged vs regular fetches to cache as long as you use it like a stack, with stack-like data…

The stack pointer is just that, a pointer. It points to a region of the heap. It can point anywhere. It's a data structure the assembly knows how to navigate, but it's not some special thing. You can point it anywhere, and change that whenever you want. Just like you can with any other heap-allocated data structure. It occupies the same L1/L2 cache as any other memory. There's no decreased access times or fetches oth…

Google "stack engine". Huge portions of the chip are dedicated to this; if it makes you feel better you can think of it as fully associative store buffers optimized for stack like access. And all of this is completely separate from regular LSUs.

There's a reason why SP was promoted to a first class citizen in AArch64 when they were otherwise removing features like conditional execution.

That's also the reason why using RSP as a GPR on x86 gives you terrible perf compared to the other registers, it flips back and forth between the stack engine and the rest of the core and has to manually synchronize in ucode.

EDIT: Also, the stack is different to the OS generally too. On Linux you throw in the flags MAP_GROWSDOWN | MAP_STACK when building a new stack.

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

#289

Post by lmm »

arcticbull wrote: post #274
lmm wrote: post #235

Earlier quoted context omitted.

> On the heap, allocation might be cheap or it might be expensive, deallocation might be cheap or it might be expensive, In other words it might behave just like "the stack"; the differences between different kinds of "heaps" are as large or larger than the difference between "the stack" and "the heap". > fragmentation is a risk, the resource is 'unlimited', and the lifetime is unscoped. None of these is true in all…

I'd argue that given special purpose registers exist on most platforms to support a stack, and instructions dedicated to manipulating them (x86 %sp, push, pop) that the stack is in fact a hardware concept. The heap, however, is left as an exercise to the reader.

> I'd argue that given special purpose registers exist on most platforms to support a stack, and instructions dedicated to manipulating them (x86 %sp, push, pop) that the stack is in fact a hardware concept.

True enough; however sometimes access to "the heap" (in C terms) will use those instructions, and sometimes access to "the stack" will not. Learning one or two assembly languages is well worth doing, since they offer a coherent abstraction that is genuinely relevant to the implementation of higher-level languages. Not so C.

Post reply on HN