Midnight programming, 1979 vs. 2011

Computerworld - [Editor's Note: This reminiscence accompanies our story "How are students learning programming in a post-Basic world?"]

In 1979 I set out to calculate an amortization table for a new 20-year mortgage, breaking down each month's payment between principal and interest, and totaling the loan's eventual cost. The loan was from a private party, who was unable to supply a table.

Another reason to do it was that I could. I had spent the last 18 months building an SWTPC microcomputer from a kit, one board at a time. RAM was an extra-cost option that I also bought in increments, and by then I was up to 20K (yes, 20,480 bytes), enough to run a Basic interpreter like the ones included in the factory-built micros that were hitting the stores. I had been exposed to Fortran in college and decided that Basic was much the same -- albeit grossly simplified.

Lamont Wood used an old Model 15 Teletype like this one as the printer with his Basic setup in 1979.

Printers cost more than RAM, so I had also rebuilt a Model 15 Teletype discarded by a newspaper. It was an antique all-uppercase machine that used a five-bit code, requiring a special interface board -- not to mention complete replacement of its decayed wiring, after a trip to a carwash to blast out decades of congealed grease. Throughput averaged five characters per second. (Yes, you can type faster.)

I derived the amortization program from Some Common Basic Programs, by Lon Poole and Mary Borchers, a book published in 1977 by Osborne & Associates. The book's version was 105 lines long, of which a quarter were remarks that tried to flesh out the cryptic two-character variable names. Comprehending the rest of the program was a matter of understanding Basic's handful of keywords, and following the GOTO statements.

It took the teletype more than an hour to print the entire table, its rhythmic pounding shattering the night's stillness. Transfixed, I watched with something approaching awe as it generated line after line of formatted numbers in robotic response to my encoded will. This was sorcery, and I was the sorcerer's apprentice.

I thereafter set out to program a solution to every little problem that came my way, such as predicting future gasoline prices from AAA trend data, or solving those little triangular pegboard puzzles they hand out in restaurants.

And now, with Python

Fast-forward to 2011. My sorcerer's apprentice phase was forgotten, and my personal computer did not have a programming language installed. But mortgages remain an issue, and it would be nice to play with an amortization table to see if using some savings to refinance made sense.

So I downloaded the Windows version of Python from www.python.org via broadband Internet, and it was installed in about four minutes. (In 1979, Basic took about that long to load from a cassette tape after each boot-up.)

Running it, you get a shell that interprets input much like Basic did. In other words, typing the traditional "print('hello world')" or "2+2" generates immediate responses, much as Basic produced. As with Basic, you create variables by using them -- there's no need to "lay pipe" by declaring them.

The package included an interface that prompts you on syntax as you program. I was able to write code in one window with the results shown in an adjacent window, greatly speeding the task.

Or, that's what eventually happened after I waded into the tutorial included with the package. It discussed things like "degenerate slice indices" and was not aimed at laypeople. I also tried A Byte of Python, by Swaroop Chitlur, available at www.swaroopch.com, and it was helpful.

After three hours, I felt I had learned enough syntax and control functions to generate the amortization table, and after an hour of wrestling with error messages, I had it churning out poorly formatted columns of numbers, covering 20 years in a flash.

With no line numbers, or GOTO statements that throw the code out of sequence, I found that you read Python code as you would a novel. Specific functions are defined upfront, like a writer building characterization. Then you throw them together using various control functions. Variable names can be long enough to be self-explanatory, so there's no question as to what's going on. (Alas, they can also be long enough to make the line lengths unmanageable.)

Program organization is denoted through line indentation, as if the code were an outline written for an English assignment. Code could be written so that the program's organization was obvious at a glance, but good organization was no guarantee that it would run.

With the basic logic working, it was time to make the output look tidy. After briefly trying to wade into the documentation, I found it best to simply query Google with how-to questions. Answers always turned up immediately.

The resulting program had about 40 lines of code.

As for the amortization problem-solving, I quickly saw that halfway through the 20-year note in question, two-thirds of the total interest had already been paid. Refinancing with a moderately reduced principal would just inflate the ultimate cost of the loan. But using savings to overpay the principal each month shrank the ultimate cost of the loan and paid it off years early, something I determined by adding a few commands to the program.

And by adding those commands I felt that I had reasserted control over my data environment. The thrill was not the same as in 1979; it hadn't taken months to get the hardware to work, and it sure ran quieter. But a facility that had withered was restored.

As for comparing Basic with Python, it's hardly fair. With Basic, I felt like I was rummaging through a small box containing a few crude tools. With Python, I felt I had pushed open the door to a massive but unlit tool warehouse and was darting in to grab the few that I could see.

Lamont Wood is a freelance writer in San Antonio.

Next: How are students learning programming in a post-Basic world?

Read more about App Development in Computerworld's App Development Topic Center.