(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.
