Why we “romanticize” past developers

Let’s look at this:

And quoting it directly in case it disappears later:

People like to romanticize the devs of the past. “People just don’t care about engineering now…”

JFC, there was an entire crisis(Y2K) that had to be averted because 70’s and 80’s devs couldn’t think past the year 1999 because they wanted to save a couple bytes.

Software engineering is just as lazy as it’s ever been, we just have more ways of doing it now.

Looking through his profile, he lived through Y2K, going into community college starting in 2009. And he likely also would’ve learned in his programming classes why that happened. Meaning to say the software engineers of old wanted to save 2 bytes, and so got lazy in their coding, is just outright stupidity.

And what we largely have here, what Chris is putting on display, is taking the technology of today, the standards of today, and applying them to past events. He’s taking what is possible today – the fact we can store all 4 digits of the year without issue in any system – and acting like it had to have been possible back then.

And technically it was. But there were significant trade-offs. Because there were significant limitations that Chris has never had to face. Limitations the majority of software developers alive today have never had to face.

Two of which were processing speed and storage capacity.

On the latter, you’re probably aware that your cell phone today has more processing power than all of the computers that allowed NASA to put Apollo 11 on the moon. You’ve probably also seen this famous picture of Margaret Hamilton standing next to a printout of the code that she and her team wrote to accomplish that:

And back in the 1960s, the whole field of computing and software development was in its infancy. The code that Hamilton is standing next to is dwarfed by anything today in terms of functionality and size. Because back then computers didn’t have the breathing room for everything we take for granted today, and took for granted even 20 years ago when Windows XP was still the dominant operating system with Vista on the horizon.

Meaning cutting 2 bytes out of a record size made all the difference.

This blog post wouldn’t even fit in RAM on most desktop computers from the 1970s and 1980s. The full-size version of the above picture available on Wikipedia Commons wouldn’t fit in the RAM on the IBM XT I used when I was a kid back in the 1980s.

That isn’t to say that people are spoiled today, though they certainly are. Programmers especially. Imagine writing programs for this:

That is the Texas Instruments TI-82 graphics calculator. It was considered a pocket computer back when I was in high school, sporting a Zilog Z80 processor running at 5 MHz with 32 kilobytes of RAM… oh wait, let me repeat that. It had just 32 KILObytes of RAM. Of which 28 kilobytes was user-accessible and the other 4KB reserved for the “operating system”. And that RAM was used for storage as well – if both the AA batteries and the coin cell battery died, you lost everything stored on it. (The OS was stored on a separate ROM and copied back into RAM after the batteries were replaced.)

For comparison, the computer I’m using to write this blog post has 32 GIGAbytes of RAM. A million. times. more.

The preceding TI-81 was worse still, having only 2400 bytes of user-accessible RAM. Imagine writing a program for that! Given Chris’s post above, I think that needs to be part of any modern programming curriculum.

As a calculator, the TI-81 and TI-82 were very capable, but I very much preferred the HP 48 I had in my high school AP calculus class. (Pretty sure it was the 48G.) It had a more capable programming language compared to the TI-BASIC featured on the TI-82, though it’s reverse-polish functionality took some getting used to. The 48G wasn’t much better than the TI-82 in terms of user storage, but it at least gave you the full 32 kilobytes. The GX had 128 kilobytes. It also used a separate 512KB ROM for the “operating system”.

Back when I was first learning to program, the early 1990s, my father gave me a torn up book of text-based games written in BASIC – the Beginner’s All-purpose Symbolic Instruction Code. And it was fun and one hell of a learning experience taking those programs and adapting them into TI-BASIC for my TI-82 and, later, the TI-85.

The largest in that book was a Star Trek game. It wasn’t possible to convert that for the TI-82 due to limits in how many lists and matrixes it could store, but I could just barely convert it for the TI-85. It took forever to type into the calculator and barely fit due to the storage limits. But when I showed it off to my friends at school, it immediately made them envious.

Anyway…

When the total memory space for your code and any variables it uses is measured in only kilobytes, imagine the compromises you have to make, the ingenuity you needed to exercise to write a program that met your requirements – after convincing the bean counters that half what they wanted isn’t even physically possible.

Then scale things down smaller still.

We’re talking about a time when single-character and two-character variable names were the norm out of necessity. Because having longer variable names peppered through your code meant risking running out of storage space for the code, provided your compiler or interpreter didn’t run out of memory trying to process it. Comments weren’t really a think either, again due to storage and memory limitations – they were almost non-existent in that BASIC programs book I mentioned earlier.

As memory and storage capacities grew, and processors became far more capable, better practices were adopted. More comments for your code started becoming a thing, followed by self-documenting code. Frameworks and APIs became more capable as well because the systems that would be compiling or running the code could handle all of that without running out of memory – mostly.

We romanticize the developers of the past – including those like Margaret Hamilton and her team, Adm. Grace Hopper, Dennis Ritchie, John Kemeny and Thomas Kurtz – because of the limitations they had to work with, because of what they were able to accomplish despite those limitations.

Again, Hamilton and her team wrote the code that helped put Apollo 11 on the moon. And programmed that for systems dwarfed by even my TI-82.

And, again, those are limitations software engineers today will likely never have to face.