Touch

 Metal

Introduction

Welcome to Touch Metal! This website is a companion to the Touch Metal board that I hope to make available soon. The board is intended to work as a stand-alone resource for exploring and learning about computers at a very low level.

In addition to the board itself, there's an instruction manual (which you can download from here for free). There are also other tools and resources available. Have a look around!

Motivation

Sometime people say they need to "unplug," as in disconnect the phone, internet link, or whatever lines are keeping them tied to a false reality, keeping them from really experiencing life. "Touch grass" is a similar sentiment: interacting with the real/physical/natural world as a break from spending so much time online, taking in virtual content, living in a digital world.

It may seem counter-intuitive to apply such a concept to computer programming, yet there are parallels to how programming is done, and to current trends in how people program computers. As a computer science teacher, I repeatedly witness the value of learning programming at a low level. Building programs in Java or Python can be quick and easy, and when we get there, it's generally a fun, even relaxing experience for student; but this is built on a foundation of lower-level understanding.

In contrast, working in C with pointers, struggling with quirky errors (like "if (flag=1) ..."), and manually managing memory can be challenging; but once one has gotten past these hurdles, the rewards are rich.

The Metal

Computers have many parts and pieces (both hardware and software), and as users or programmers, we interact with a number of these. Keyboards, mice and displays are perhaps the most familiar hardware elements. External drives (flash, CDs, floppies, etc.) are another hardware piece. On the software side, we run programs such as browsers, document viewers and media players. As programmers, we run editors, compilers and debuggers, or more likely an IDE (Integrated Development Environment) like Visual Studio, VSCode, IntelliJ or Eclipse. Those hardware pieces let us interact with these tools, which are our interface to the computer.

But there is another level...

There is the level of the CPU (Central Processing Unit), at which the actual execution of instructions takes place. This is the level where the logic elements -- registers, gates, transistors -- interact with the memory and perform the simple operations to achieve the things our programs ask for. Everything else is really just an interface to directing this lowest level. This is where things happen...

This is the metal

Why touch metal?

Because it's fun! It's not unlike playing chess: each machine code instruction is extremely simply, yet absolutely vital to the overall mission. You need to think about and understand how a set of simple instructions can work together to achieve some higher-level behavior. It's rewarding, it's satisfying, and after you've developed code at this level, you will never again doubt your ability to debug!

Is this a problem today?

I would say "problem" is a strong word; but I think there's an increasing disconnect between programmers and the things being programmed. As one moves into higher-level languages and fancier programming environments, one tends to be more removed from the low-level realities of the computer. "Vibe Computing," in which one basically describes (using human language) what they want a program to do, is an extreme example of this disconnect. It may be good for companies focused primarily on short-term savings, but it is (in my opinion) horrible for learning how to code!

Where do you program

One way to think about all of this is by looking at different languages and tools and thinking about how programming works at those different levels: how you direct the computer's behavior; how much control you have over the machine; how much you need to understand the hardware to create the software; and what you learn in the process.

While not exactly a hierarchy, the following table shows different languages and different styles of coding, roughly organized by some measure of detachment from the metal level.

Tool/Environment	Comments
Vibe Coding	Think it, say it, done. The result may be wrong, but it will likely look good! You will learn about vibe coding, but not much about programming per se.
AI-Assisted	Think it, say it, try it, describe the issues, try it again, repeat. You will get better at this process, but still learn little about coding.
Copy/Paste Trial-and-Error Coding	Often the most unsatisfying approach to coding. It requires a lot of effort, but leaves one with little sense that they understand what they've done.
IDEs (syntax-checking, auto-complete, etc.)	Generally involves developing code line-by-line. You need to know something about the language/etc. to make this work, but the lower-level details are managed for you by the IDE, and thus are in some ways effectively invisible to you.
High-Level Languages (Python for example)	This is coding! You are actually issuing instructions to the machine to govern its behavior. By design, you can do this without knowing anything about the underlying CPU, or what the hardware is actually doing. Useful for portability, but the deeper details are still hidden.
Mid/Low-Level Languages (C)	Depending on what you are doing, you may need a higher level of understanding of computing, computer hardware, memory, and so on. Even though C is generally considered a high-level language, you're really thinking (to some degree) like an assembly-language programmer.
Assembly Language	It doesn't get much more pure than this. If you are doing practical metal-level coding, you're probably working in assembly language. You may have considerable control over the system at this level (though it's possible to do assembly-language programming in an environment where you still have almost no direct access to the hardware). Still, it's generally one line of code = one operation = one machine language instruction, which is pretty cool.
Machine Code	This is the metal. Either your hardware is so archaic, exotic or new that there is no assembler; or you're just so bad that you spurn the assembler and craft the bits manually. Nice job!