Deep Understanding Of The Machine

The machine is so complex these days it's hard to achieve a deep understanding of all the layers.

The bottom layer is maybe to understand how a transistor works from the basic physics. Then understand how a gate works. Then understand how an adder works. (Now you can 'forget' about the transistor). Then all the way up through to the CPU and other hardware aspects. Then start on the software stack and work your way up through these layers. OK - no one know everything about every layer, but at least an understanding of the system in terms of layers. The nice thing is that because of the abstraction you don't have to think about all the layers at a time. But it is only an abstraction and remembering this might help to get the DeepUnderstandingOfTheMachine. If your code crashes more often on hot days it could be the chip overheating.

The older machines were simpler and maybe MachineCode was the top layer then. So there were less layers to think about, people brought up on these are more likely to have the DeepUnderstandingOfTheMachine.

OK I need to reconsider.

On the other hand, why stop at resistors? I'm pretty sure that knowing the sub-atomic interactions of electricity won't help me grasp the "branch if zero" machine-code instruction. In the same way, I'm pretty sure that knowing those machine codes don't help me program in a higher level language, at least not on a daily basis.

Therefore, my vote is this: Shoot for a BroadUnderstandingOfTheMachine?. Make the computer your slave of abstraction.

A good compromise is to understand the machine at a level at least one layer down from the layer at which you are working. For example, if you are writing web applications using a high-level API, make sure you understand HTML and HTTP. If you are writing distributed apps using CORBA, then you need to understand TCP/IP and GIOP. Understanding things one level down makes it easier to reason about how the level above it works, and makes it possible to fix problems when that higher level fails.

The machine is so complex these days its hard to achieve a deep understanding of all the layers.

:s/machine/universe/

The universe is so complex these days its hard to achieve a deep understanding of all the layers.

I think learning and understanding AssemblyLanguage-level code is an essential part of being a programmer. Going lower than that really isn't necessary, as there is really no way for a programmer to make use of anything below that level. I usually write software with lots of high-level layers, but there is a lot of satisfaction and knowledge that comes with understanding and controlling the machine at a low level. If you've never used assembly language, or haven't done so in many years, give it a try. I think it helps focus one's mind on doing things as simply as possible, and gives deeper understanding of the value (and drawbacks) of higher-level abstractions and programming languages. -- KrisJohnson

Yeah, what he said! AssemblyLanguage is the great de-mystifier. A few months of it and you can actually understand the claim, "it's all done with switches," without feeling like its a cheap aphorism. I remember, before I knew C, having a C programmer tell me that C was better than ASM because it had "ParameterPassing." I felt small and stupid. Months later, I finally understood what ParameterPassing was, and that I'd been doing it all along. Same with "pointers" and other programming "devices" that have cute names but which, in AssemblyLanguage, you just do. Realizing that it all reduces to ASM helps remove a lot of the complexity baggage. -- GarryHamilton

You mean MachineCode, not AssemblyLanguage. Some AssemblyLanguages introduce entirely artificial constructs that have little to do with the machine architecture.

Disagree. Yes, some do, but that's really a NitPick. I've done vast amounts of work in machine code, and I wouldn't wish it on anyone; the only things I learned from doing lots of it (as opposed to just knowing it or automatically generating it) were stupid little things that weren't useful elsewhere. Assembly language is the only way to go in regards to the page topic, as long as one isn't relying purely on artificial constructs that simulate a virtual machine, will teach just as much. More, actually, since there's less mental clutter in the way like memorizing opcodes.

You make odd comments when you stray into systems programming subject areas.

I think that a DeepUnderstandingOfTheMachine tends to widen the perspective of someone who is debugging, generating DebuggingIdeas. These guesses are enriched by understanding the context of a problem while looking through logs, reading the code, understanding what was happening in connected systems at the time the problem happened, etc. And for people just starting out in programming this understanding tends to be hard-won through long debugging sessions in which a lot of "blaming the compiler" takes place. -- JohnSumsion

I want to throw out a StrawMan suggestion that knowing AssemblyLanguage and/or MachineCode was a useful stopping point in the descent to less abstract representations of computers in the days when single-threaded and single-cpu systems were the norm, but no longer. Today a complete DeepUnderstandingOfTheMachine requires one to understand more than just behavior of a single instruction stream. With concurrency becoming more common for both architectural as well as performance reasons, understanding things like the details of cache synchronization, memory access and inter-CPU communication is an essential adjunct to understanding how a particular single stream of instructions behaves. -- GeoffSobering