compare books like CODE, SICP, and related books discussed below, to books like Beautiful Code, Higher Order Perl, Mythical Man Month, Seven Languages in Seven Weeks, tons of whitepapers.
do I really need to read CODE? Seems like a bottom-of-stack book that will never quite make it to the top.
But the truth is that the benefit/effort ratio in that book is pleasantly high. It is very easy to read and it did gave me quite some "Oh! So that is how it works!"
The reality, of course, is that the book was so spot-on and insightful that many of its ideas have simply been absorbed into the way we approach software development. It seems so common sense today that people don't even cite an idea stolen from TMMM.
Unfortunately, this meant that nothing in the book was new to me, and reading it was rather dull. Because of that, if you've spent much time following the tech community, my recommendation is to prioritize reading TMMM below many of your other suggestions.
This book (probably) won't do that, but it will give you a more intuitive sense of how the machine actually _works_ at its core. This is not meant to be hands on stuff for someone who's programming at your level of abstraction.
Compared to those books you could clear this one out in a few days, and the benefit/effort ratio is probably actually better, although much less directly applicable.
I'm still trying to teach some of them that a memory copy isn't instant.
Having the benefit of an EE based undergrad degree was awesome for this reason, esp. since my first job was firmware design. The downside is that I never took a compiler course and have had very little exposure to stuff like discrete mathematics and turing machines. I didn't learn anything about OO design 'til after school, and I still haven't gotten into functional programming.
Sometimes I worry that I actually missed out on the good stuff. :/
In my experience, of the hard sciences, CS is by far the most amenable to self-study. CS isn't easier, whatever that might mean, but CS is amazingly inviting: if you've got a computer and a textbook budget, you can learn some really neat stuff. So don't despair; get studying!
I often recommend K&R, even to those who aren't primarily learning C.
K&R is a book that influenced me a lot, but its most important lesson is not laid down very explicitly. IMHO, this lesson is its notion of programming style: terse, small, efficient. It permeates the whole book and C/Unix design but the book is not explicitly about it.
Unfortunately it is a lost lesson. Today, programming became just the act of gluing bloated frameworks, libraries and doing severs configuration. The small, simple and powerful K&R approach is totally lost in a world dominated by bloatware (e.g: Java/.Net/Boost).
What does learning C provide that other programming languages (majority of which have some basis in C) don't teach you?
Memory management (allocation, pointers, etc)? Pipes and buffers?
They are present in other languages, and one could argue with memory management why 'every' programmer must learn those techniques even if they are never really applicable to them.
I'm really trying to think back to my C days (I haven't done it in a long time) as to why it is so important to know? What is unique about it?
ACTUAL REVIEW/SPOILER CONTENT:
So, the book does start pretty slowly. It considers the case of signaling with flashlights. This motivates semaphores (not the concurrency type!), which in turn motivates telegraphs. The telegraph repeater and its automation is used to motivate logic gates. Around here (forget exactly whether it's before or after) the author diverges for a chapter or two into boolean logic and counting mechanisms. Then the idea of storage is brought in, then the idea of state machines. Calculation is brought in, and soon the author has a simple little ALU. The author talks about wiring up an interface for this, and then there is talk about interrupts, operating systems, and also real embodiments of this sort of hardware--6502 or 8086 assembler is introduced and discussed.
The writing is geared such that someone in highschool shouldn't have trouble understanding anything, and there is enough history thrown in with the light style that it isn't a chore to slog through.
WHY THIS BOOK IS NOT A WASTE OF TIME:
So, I've already taken the introductory computer engineering/CS classes during my time at university. I've already read a lot in high school and a lot after college on computers and their architecture. This is not a new subject to me. Why is this still a good read?
Folks, our professions (whether you are a mechanical engineer black-boxing gear trains, a software engineer black-boxing Java/Scala/JVM bytecode, or a Perl hacker black-boxing the very mouth of madness) are all rooted in abstraction. Everything we do, everything we touch, is a slice of a pyramid of (sometimes shaky/leaky/smelly) abstractions.
The great thing about Code isn't what it teaches you about programming (it doesn't cover much other than assembly, if that) or computer engineering (no help soldering or designing ring buses or whatnot) or even mathematics (boolean algebra is pretty straightforward in its presentation); instead, Code focuses on bringing us to a functioning microcomputer from a flashlight in our bedroom, without ever skipping a layer of abstraction.
Even if you already know each slice (in broader detail than presented), seeing the entire journey is at worst enjoyable and at best extremely educational.
I just thought I'd mention this as well.
As my ME friend (at that time, roommate) was chugging through the book, he'd randomly come up and ask me questions or points of clarification. This culminated one evening during dinner.
He, my other roommate (a Linux sysadmin/applied mathematician), and I (software developer and former ME) were enjoying some Indian food, and the ME began bugging us about interrupts. He couldn't understand quite what they were useful for.
So, over the course of four or so hours, we probed him with questions geared towards increasing his understanding. Something along these lines transpired:
ME:"So, what are interrupts good for?"
SD: "Well, they're good for getting the processor's attention. How would you handle checking if a button is down?"
ME: "I could have processor check a line in."
SA: "And if that check happens to miss the button press?"
ME: "...erm, I could have something else check it, faster."
SD: "And how would you check it?"
ME: <thinking hard> "You...could have the switch be controlling a bit of the memory, I guess."
SD: "Congratulations! You've invented memory-mapped I/O!"
SD/SA: <give brief spiel on MMI>
SD: "But you still haven't told us about how to solve interrupts."
ME: <several more suggestions that are basically around polling>
SD: "Let's think about the problem. What you want to do is have the processor poll the button, right?"
ME: "Yes."
SD: "And only do this when it's needed, right?"
ME: "Yep."
SD: "So, what if there was some kind of way of signaling the processor that data was ready?"
ME: "...oh. I guess you could use a pin for that."
SD: "What would that pin do?"
ME: "I think it would have to tell the processor to go handle input."
SD: "And how would that work?"
ME: <several suggestions about dedicated copying logic>
ME: <converges to idea of setting program counter to interrupt code in memory>
SA: "What happens if I want to go somewhere else to handle my interrupt code?"
ME: <suggests looking up equivalent of jump instruction to trampoline into handler>
SA: "You've just invented the interrupt trap vector!"
...etc...
So, by the end of the night, with proper questioning we'd gotten him to come up with MMIO, with virtual memory, with paging, and eventually gotten him to consider how to implement concurrency via scheduling and his newly discovered virtual memory mechanism.
It was delightful, and wouldn't have been possible unless he'd been getting the lay of the land from reading Code.
edit: oh god the spacing edit2: processor's, not processors
http://www.amazon.com/Annotated-Turing-Through-Historic-Comp...
Seeing every step from the ground-up really helps demystify the machines you see around yourself every day.
I can only imagine how much easier it will be today than in 1994. Oh the gadgets I will build... Good thing my birthday is here and Christmas is coming soon!
Ever since I read it, I recommend it to every person who wants to learn about computers. I think this should be the first book to read for any person who wants to learn about computers on any level.
This book brings the knowledge (that some are only able to gather through experience) in a compact and systematic form.
(I'm guessing some recent Unix-programming-environment books cover a lot of the stuff in _ST_, but I haven't read 'em).
One was __The Mythical Man-Month__ (the old one, not any of the reissues). That put into words so many things that I felt about computer programming, if nothing else the humanness of programming as a pursuit.
The second was __Software Tools__. Even then, whichever version I encountered was ancient (I was learning C in school). It didn't impact me quite as much as TMMM (which I think i read most of in the library), but it was enough for me to remember and pick up a used copy a few years back.
I still haven't read it, so I'm glad you reminded me about it.
As far as a modern book, the one that seems closest to me is __The Practice of Programming__.
I could not find a link to the book, but found this blog post which has also some pictures:
http://www.currybet.net/cbet_blog/2004/06/the-beginners-comp...
My vote for must read is: "Zen and the art of Motorcycle Maintenance" - Pirsig
Also, I had fun building my own simple computers in logic gate software.
I still had no idea how 10010011000110101001010 etc etc allowed me to play World of Warcraft. There was a small part of me that hoped beyond hope that computers were magic and there was some grand conspiracy going on to cover that fact.
Then I read CODE.
My hopes were shattered, but they were replaced by something much more treasured: Understanding.
"Microcomputer Structures" is out-of-print, but I recall the small text starting with atomic physics and building up to an introduction of the Von Neumann architecture.
As a freshman at Boston University in the 1980's, I took this mind-expanding course (probably because it was way above my level) with Professor D'Angelo. The final project was building an interface to a single-board computer.
I have given this book to 2 people who told me they wanted to know more about computers. It's very easy to read and does an excellent job of explaining basic computer concepts. Probably not too interesting for this crowd. But it's an excellent introduction to computing.
edit: It may actually be more of an electrical engineering class, but the CS program here is ABET certified, so it's essentially an engineering degree itself, but this is the kind of thing that any CS graduate should be intimately familiar with.
Here's a link to an interview of him that briefly covers some of the topics in his keynote. http://technologyandfriends.com/archive/2011/06/13/tf160.asp...
While I agree that programmers should understand the fundementals of how a cpu et al works, is this book the best one?
