The Maryland high school I attended helped me get my early career off the ground. In 1980, I took my first computer class. A friend and his geek cohorts had already learned enough to swarm all over the HP/3000 machine we used. They quickly knew more about it than the operator hired by the school.
I learned that our machine and the terminals (HP-2640A’s, I believe) had been donated to the school. But before giving up the terminals, the donor cracked them open and removed some of the terminal memory, no doubt to help beef up the terminals for their newer system. The terminal memory allowed you to scroll back: by default, you got one page at a time (25×80, or maybe 24×80 to accommodate the f-keys line at the bottom). Later, when I started working at the University of Maryland–a job I got mostly because of my high school experience with the HP/3000–I had a wondrously souped-up terminal that allowed me to scroll back a whopping ten or so pages!
For whatever dumb reason, however, it was possible to remove even some of the first screen’s worth of memory. So instead of a 25×80 display, we effectively had a 17×80 display. You’d see 17 lines of output, followed out by a functionally-dead and black bottom third of the screen.
The effect this constraint had on editing programs was overwhelming. We used a line editor (TDP/3000 was the nicer one that HP offered), which meant you had to explicitly tell the editor to display certain lines when you wanted to view them. It went something like:
> list 34-49
… 16 lines of code displayed here …
>
The list command itself could scroll off the screen, but you still had a new command prompt taking up one more line, effectively leaving us with 16 lines maximum of code that I could see on-screen at any given time. I got very good at figuring out n:n+15.
The result: I learned very early on to compose my programs so that many, if not most, of my functions were short–no more than 16 lines! Otherwise, I’d spend far too much time listing lines appearing earlier or later in a function (to emulate scrolling up and down).
This habit became a key part of the successful parts of my programming career. My programs were usually structured to be very easy to maintain, and I never had lots of problems with pinpointing and fixing defects. Creating short methods is a great practice that I still find value in today.
Comments
Sadly (and I say that with some irony) I learned programming on dear old Dad’s employer’s mainframes (circa 1977). Timesharing Basic, large swaths of heat-sensitive terminal paper, acoustic couplers (they just don’t make those like they used to!)…
Though I do recall being delighted by GOSUB, the constraint you explore here wasn’t fully instilled (‘installed’) in me much later while using VisualAge for Java. This IDE encouraged (forced?) you to enter the body of a method into one of numerous small windows.
Later (during my non-Agile dot-COM Dark Ages) a colleague had this to say upon seeing my clear, concise, cohesive code: “Wow! You must really like long stack traces!”
My reply was likely an introvert’s shrug, but I seem to recall my mind battling between “Why, yes, I really love it when a stack trace describes the precise scenario leading me directly to the defect” and “Stack traces? What stack traces? I wrote unit tests!” 😉
