When I've written about my history, I usually mention that I wrote my first program on a knockoff Apple ][ way back in 1985. But that's not accurate. I wrote my first program long before that.
Christmas 1979
Way back in 1979, I got an awesome toy for Christmas: Big Trak. This was not a remote-control vehicle; it was a programmable one.
 |
| Merry Christmas! |
It could move forward or backward in the very precise unit of "vehicle length".
It also could turn left and right. The units for this were a little easier: "15" was a 90 degree turn. It doesn't sound very intuitive, but there were 60 units in a full circle, which meant that it was similar to a clock face (we used analog clocks back then).
Finally, there was a "Fire" button that would fire off the blue "laser" (with appropriate sounds) at the front. This was kind of cool if you could get the dog to sit still long enough.
Reality Kind of Sucks
Programming this thing was frustrating (to say the least). There was no screen, which meant that you could never see the complete "program". This also meant that there was no way to fix a wrong step in the program. You had to start from the beginning each time. For complex routes, this was tedious.
Here's a sample that was in the instruction manual:
 |
| Sample Living Room |
(The manual also had blank pages where you could draw in your own living room.) This sounds easy enough: Go forward 4, turn right 15, go forward 6, turn left 15, go forward 5, turn left 15, go forward 6, and then Fire!
The problem:
Physical reality doesn't match theoretical reality.The tires on the Big Trak were sort of a rubbery plastic. This meant that the grip was unreliable on carpeting (or on tile). The program to move forward "5" may result in really moving "4-1/2". And turning "15" may result in turning "12".
Lather - Rinse - Repeat
To program this thing, I would always start with theoretical reality. I would map things out, write out the steps on a piece of paper, and then set out entering the program.
Then I would hit "Go".
And the Big Trak would promptly not turn quite far enough and end up running into the sofa.
Then I would adjust the first turn a bit, update my steps, and then enter the program again.
Then I would hit "Go".
And watch as the Big Trak makes the first turn okay, but doesn't go forward quite far enough and ends up crashing into the coffee table.
And this would continue. And after many iterations (and with a very mellow dog), you may be able to get it to drive around the coffee table, not hit the sofa, and then fire the laser at the dog on the other side of the room.
I Must be a Programmer
I really must be a programmer because this process did not frustrate me. It was a challenge. And there was something rewarding about getting the machine to finally do what you wanted it to do. It's hard not to get a bit nostalgic thinking about the afternoons I would spend "programming". (And if any of you share that nostalgia, Big Trak was resurrected a few years ago, and you can buy one on Amazon.)
I've always put the start of my programming experience in 1985 (when I was 14), but I really need to move it to 1979 (when I was 8). But I didn't actually get paid for programming until I was 29 -- which is a bit later than most professionals.
Debugging by trial-and-error is frustrating. Especially when you have to start over each time something goes wrong. I guess this isn't really that much different from people who entered computer programs by flipping switches on the front of a console.
Better Ways of Programming
It's much less frustrating working with tools today. I still do some programming by trial and error. For an example of this, you can look at "Coding Practice: Displaying Bitmaps from Pixel Data". But this is not my preferred way of working. Since I was using pixel data and creating bitmaps (which I didn't know in advance what they were supposed to look like), I really didn't have much choice. But this doesn't make up the bulk of what I do.
The bulk of what I do is implementing business rules, manipulating data, validating requests, and so forth. This is much closer to what I was doing last night: working on an implementation of Conway's Game of Life (more info if you're not familiar with it -- and something cool: if you Google "Conway's Game of Life", it shows a live demo of it).
I didn't get very far in my implementation. I started out by implementing the rules on whether a cell lives or dies. There are only 4 rules, so it's not very difficult. I used TDD for this -- creating tests for each rule and implementing them one at a time. This turned into more than 4 tests, though. I ended up with 14 tests to cover various states. And to simplify the tests, I'll probably move from MSTest to NUnit so that I can do parameterized tests for the various scenarios. (Why does MSTest only support parameterized tests for "Metro" applications?). This would reduce things down to 4 tests: (1) live cell stays live, (2) live cell dies, (3) dead cell come to life, (4) dead cell stays dead.
I'm still working on how to store the cell data. I'd like to do it in such a way that I can run the live/die method in parallel. I'm not quite sure how I'm going to do that at this point.
Wrap Up
Programming by trial-and-error is sometimes the only option -- like when programming a Big Trak. But more often than not, there are better options which are less frustrating and more productive.
It was eye-opening to realize that my first experience with programming had nothing to do with a "computer" (although there was a TMS1000 microcontroller inside). And it's also interesting to realize that I'm still programming by trial-and-error 35 years later.
But it's also good to know that this is not my preferred method of programming, and that I'm taking advantage of other options in the majority of my work.
I think that's enough nostalgia for now (or not, I may just have to order a Big Trak for myself).
Happy Coding!
No comments:
Post a Comment