Origins 3

My third relevant computer “experience:” When I enrolled at the University of Maryland in 1982, I had to sign up for a “weed-out” course as my introduction to the computer science department. The course CMSC 110P (the “P” was for Pascal, added that year to replace Fortran) introduced us to some wacky notion called A Calculus of Computer Programming. The esteemed Ben Schneiderman apparently had his hand in the “book” that backed the material, which in reality was a half-ream of paper rubberbanded together.

The course was all about how to create proofs of code, starting with individual operations and moving up to entire functions. It was a very tedious process. If I recall correctly, the course introduced its own proof language, one that bootstrapped itself. (I wish I still had the manuscript since I can’t remember what it looks like). Everyone in the class hated it. It drove me nuts initially, but it did make a big impression on me in terms of how difficult it was to code demonstrably correct functions. I remember spending half the semester on proving a few simple functions.

Wikipedia has some interesting pages about lambda calculus and functional programming languages. I never tried Haskell or ML. The notion of using functional languages to help in programming defect-free code sounds intriguing but also very tedious. Today I still recognize that creating correct code is a significant challenge. While it’s not the same thing, I view TDD as my way of demonstrating similar levels of control over what I produce.

Origins 2

(continued from Origins)

My next relevant computer experiences were in high school. We had an HP/3000 computer, a friendly, stack-based minicomputer. An anonymous donor had supplied our school with the machine and a number of terminals. The students quickly ended up its masters, knowing far more than the operator paid to do the job. I spent a lot of time outside class mucking around with the HP.

The donated HP2640 terminals had screen memory. You could page up to review prior screens, a radical notion at the time. You could even add memory cards, boosting available paging to as many as ten screens! Or, sadly, you could remove memory, which our benefactor apparently did, stripping things down to a maximum of 17 lines. Instead of the standard 25×80, we had 17 lines in which to work.

Seventeen lines isn’t much. Worse, we only had a line editor, TDP/3000 (similar to edlin, but much more functional). That meant the latest command prompt itself was one of those 17 lines, so we really only had 16 lines available to list code. It also meant you had to do quick mental math to come up with a command that listed the appropriate 16 lines, such as L 12/27.

What a nuisance! But looking back, being forced into this constrained environment taught me to construct small functions. That’s something I still find to be one of the most valuable base constructs in programming today (see Small Methods). Functions longer than 16 lines created comprehension headaches, since there was no quick way to scan the entire function at once. Longer routines required at least two list commands, and that’s only if you got the line numbers right.

As an aside, I’m sure programmers killed many more trees than necessary because of the other solution, which was to print out the code. I know people who struggled for years to move away from printouts as their primary mechanism for understanding a program.

Origins

I’m not the sort to dwell on my past, at least not most of the time. But recently I’ve thought a bit about where some of my current software development interests come from. I wrote a few of these “origins” down and thought some of them might be interesting enough to share.

My first real exposure to a computer was in the late 1970s, at the Radio Shack located in the local mall. A friend and I would hang around and bang some Basic code into a TRS-80 until we were asked to leave by the staff (usually only when they got a real customer, which was rare, and they were very good about letting us hang out otherwise).

We had bought one of those books containing complete program listings. When entered properly, the three-or-so-page programs allowed us to run cheesy little text-based games. What that meant is that I wasn’t really doing much programming–I was only typing code directly from the book into the trash80, not knowing half of what was going on. I had a small grasp of what programming was all about, but wasn’t daring enough to do much with it on my own (save for a little “guess the number from 1 through 10” application). The code in the books was so daunting–several pages of convoluted code with inscrutable variable names and lots of gotos.

Over time, I remember thinking, “why are things so convoluted?” and figuring there had to be a better way. I would take some of the programs and make small changes to them, such as renaming variables, in order to make them more comprehensible. It’s a practice I continued throughout my career, even when I knew I’d be the only one who would probably ever look at the code. To this day, I still refactor code in this manner as my first approach to better understanding unfamiliar code.

Atom