Live data from Hacker News

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

words.steveklabnik.com

171–180 of 381 posts

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

#171

Earlier quoted context omitted.

> The way a computer works is based off of transistors and some concepts built on top of that (ALUs for example). However, there is no need to know about any of that because you're presented with an abstraction (assembly). I'd argue you should know how that works. Cache-misses, pipelining and all these subtle performance intricacies that seem to have no rhyme or reason just fall out out understanding exactly how you…

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.

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

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

Well, you can just write a naive allocator that just bumps pointer and never deallocates things :). To appreciate stack vs heap, you have to learn a bit about memory management and some basic algorithms like dlmalloc, imho.

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

#173

C... IDK. Maybe. But, pointers yes definitely. Even some assembly. You really should understand how things like .size or lengh() aren’t “free” and how they work.

I think I may miss your meaning. In what sense is .size or length() not "free?"

At some point, some O(n) work was done somewhere to construct the n-element structure we're getting size on, but I don't think I've ever encountered a core library that implements .size as anything other than "Look up the cached length value that I computed the last time my length changed."

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

#174

Earlier quoted context omitted.

Just playing devil's advocate here... why is this such a "crucial" concept, for someone who is using a higher level language (like Python or Ruby)? If 99% of what that person does is gluing together APIs and software modules, and they can see their memory usages are well within range, why does it matter?

true. it's like interior decorator vs. interior designer if you're just going to move couches around and put down throw pillows, who cares about a solid foundation of design fundamentals and architectural psychology.

Yep. In truth, one can almost never win the argument of, "...but do I really need to know this?" But people should be aware that knowing fundamental things provides insight and advantages.

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

#175

As someone who felt that C was the path to knowledge for how modern computer systems "work", Forth and QEMU have become my "stretch challenge" for those with the motivation to tinker. For me, working thru the resources on the OSDev wiki by taking jonesforth and linking it with the bootstrap from the "Writing an OS in Rust" tutorial ( https://os.phil-opp.com/ ) really showed me how far C is from the hardware, and how…

I’m convinced that Forth is a valuable intellectual exercise. Can you elaborate on how you feel Forth better matches how a computer actually works? I’m not yet convinced on that point, but I have no Forth experience.

It would be my pleasure :)

I'll refer to jonesforth [1], but I think the lessons apply to the other Forth's I've seen.

The main core of a Forth is generally written in assembly to bridge the specifics of a processing unit and the canonical Forth words. For instance, most control flow words are defined in Forth, but a couple critical ones are implemented in assembly and "exported" up to the higher level words. [2]

The main task of the core is to bootstrap to a sufficiently powerful yet abstract dictionary of words that will allow a full Forth to flourish. But to get there, you'll have to make a lot of choices that will be constrained by your chip (Intel x86, x86_64, ARM, Z80, etc). The big one is type of interpreter (direct threaded, indirect threaded, etc).

In jonesforth, check out the docs and implementation of NEXT [3]. The choice was guided by a quirk of the Intel instruction set that allowed loading the memory pointed by esi into eax and incrementing esi all in one step; further, Intel x86 allows an indirect jump to the address stored in a register (eax). Not all instruction sets support this pattern, you'll have to experiment and investigate for various chips.

That choice is a critical one, but it's one of many. Where do you store the dictionary of words? How do you implement DOCOL? What registers will you preserve? Why? What instructions will you expose? Which ones will you hide? Will you allow new words to be created with machine code?

In C, much of this has been decided by others decades ago (existing operating system ABI choices, mainly). In Forth, you can try things out and only be restricted by the chips, which is what all of us are ultimately constrained by, even fancy-pants languages like Rust and Go :)

Once you get past the core into Forth, some of the computer details recede, but you usually have to be somewhat aware of how you are using the system, far more than modern programming languages. Forth is the ultimate deep-dive "language" [4], but that is as much a curse as a blessing.

Basically, use Forth for the understanding it provides, then go back to making good software in typical languages aided by the enlightenment you've attained :)

[1] https://github.com/nornagon/jonesforth/blob/master/jonesfort...

[2] https://github.com/nornagon/jonesforth/blob/master/jonesfort...

[3] https://github.com/nornagon/jonesforth/blob/master/jonesfort...

[4] I've actually stopped calling Forth a programming language; programming system captures the idea a little better, I find.

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

#176
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 "…

The explanation helps, but it should not be required.

Virtual has shifted meaning and using that word in this context confuses everyone.

Abstract is a perfectly cromulent word in this case.

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

#177

Why not assembly language? Learn a simple one in a simulator (like 6502 or 8080).

There's some charm to it, but in general, assembly languages is far too low level to solve much of any interesting problem (unless the problems one is interested in are in the domain of "How do I reduce this compiler to an assembly implementation so I can use this language on a specific piece of hardware?"). So you may run into some real challenges retaining student interest.

But I think it's a good suggestion; I certainly learned a bit from learning Apple's assembly on the ][c that I hadn't encountered elsewhere.

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

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

For your definition of 'computer', perhaps. Many microcontrollers have the stack defined by the hardware.

Leaning how microcontrollers work is not the same as 'learning how the computer works' in general, which is the subject at hand.

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

#179

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…

It varies from application to application. In my domain, we reach for the CUDA libraries to write the high-performance parts of our code. ;)

That requires special Hardware in contrast to C code.

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

#180

This is a wrong statement on so many levels: "By learning C, you can learn how computers work". I am glad you did write an article but honestly you did not have to go to this length to explain your case. Anyone who says that learning C is a prereq. for understanding Computer architecture then my friend the advice is not coming from a right place. One reason I can think of is why author got confused is because a lot o…

You don't need to learn assembly to learn how computer works(if you mean comp. arch). Assembly is already very high level language and hides most of the things that you learn by actually studying computer architecture. Reading the intel's first couple volumes of manual is a good idea, if you don't know where to start.
Post reply on HN