In my last post I talked about teaching Jim how to program using my favorite language, Ruby. Rather than focusing on the syntax and semantics of the Ruby language we are focusing on how to design and build software. There are several good tutorials that teach how to use Ruby.
In our previous session I gave Jim the choice of two problems on which to work between sessions. One was to design a better scheme for encrypting text. The second was to build a simulator of a one instruction set computer using the subtract-and-branch-if-negative instruction. As it turned out, he worked on the encryption program because the one instruction set computer made no sense to him. We soon solved the issue he had with building the encryption program, which was how to step through a string one character at a time. We then turned our attention to the simulator.
It turned out that I had taken too much for granted. In order to understand how to simulate a computer one needs to know a lot of background information. What is a simulation? What is the structure of a computer? What is the relationship between a computer and a software program. These are all things that those of us who write software take for granted. But I wonder, these days, how many programmers really understand what is going on underneath their software..
When I started writing software, in 1957, I had to understand the workings of a computer, if only because I was writing in assembly language. Today, unless one is building operating systems, one is very insulated from the underlying machine. Not only do we write in a high-level language like Ruby, but also we use a lot of software written by others. Programming today is more like assembling pre-programmed building blocks than interacting directly with the hardware.
In 1968 when I was at Bell Labs, Doug McIlroy and others were interested in creating a library of software routines that could be assembled into working programs. Although I don’t think they got very far with this problem back then, the advent of the internet and of public domain software has turned their vision into our reality. I think writing software was much more fun back then when I had control of every aspect of my software down to the machine level.
Jim and I spent most of our two-hour session talking about machine architecture and what really goes on at the bottom level of the software. I told him about the bootstrap program built into every general purpose computer that allows it to read in its first program and start running. I talked about sitting inside the Lincoln Labs TX-2 computer in order to run my programs. I talked about what it means to write a simulator of a computer, and then to write and run a program on the simulator. None of this is what I planned to discuss, but in retrospect I think it gave Jim a solid foundation from which to understand the programs he writes. The next time I teach someone about programming, I’ll make sure to include this discussion, perhaps by again assigning the simulation of a one-instruction computer.
– Rudd Canaday (ruddcanaday.com)
– Start of blog: My adventures in software
– Previous post: Teaching Computing
– Next post: My Home Built Computer (coming Sunday April 20)
Share this post: data-url=””
data-via=”ruddcanaday”
data-text=””
data-count=”none”>Tweet