Last week, I was reading some old code. I wrote it in 1975. It was in FORTRAN IV and it was on punch cards. Really bad code. One character, meaningless variable names. Lots of goto statements. FORTRAN IV didn't have while loops but you could get the same thing with goto if done right.
Someone is probably going to argue that if there are goto statements its not right but it was the only way back in the day. The famous “GOTO considered harmful” paper had been written but not universally accepted yet. FORTRAN IV had not adopted language features to make it easy yet.
While I was in university the big new thing was called structured programming. It required some new ways of design and eventually some new programming language features. It took the tools in the languages changed before we could get by without that nasty goto statement.
FWIW I’ve written new version of this program in other languages since and it is much easier, cleaner, self-documenting, and just better across the board with new languages, libraries, and programming paradigms. The basic algorithm is the same though.
The big surprise in my old program was that is was extremely well commented. The first time I tried to replicate that program in a new language revisiting those comments saved me a lot of time In fact, one could easily rewrite it in a new language from the comments alone. I could at least feel good about that.
Latter in my career, object oriented programming was the thing. That also required new design considerations and programming language features. FORTRAN IV could not have supported OOP. Today there are versions of FORTRAN (and COBOL too) that have language support for object oriented programming. I’m not sure I want to see them though. Just saying.
I’ve been thinking about what this means for how I teach students today. The rate of change in computing and programming is growing not slowing down. As much as things have changed in the last 45 years they are likely to change even more in the next 45 years.
Some concepts are likely to be around forever. Decisions are likely to rely on Boolean expressions. Repetition is likely to stick around and require proper set up, values to change, and code to check for completion. We’re going to be thinking about memory and data types even if we don’t think about them in exactly the same way.
John Ruskin said, "For all books are divisible into two classes, the books of the hour, and the books of all time." I first saw that on the library wall when I was in university. The same is likely true if we substitute some software design concepts. Just as monolithic programs gave way to structured programming and structured programming gave way to object oriented programming, programming paradigms change based on changes to language, hardware, and the needs of the day. I don’t really know what changes we will see with quantum programming for example.
What ever programming language we teach with though we need to think about the concepts, especially foundational concepts, that are likely to be around for the long term. I haven’t programmed in FORTRAN IV in decades but understanding how those horrible goto statements mixed with line numbers and if statements worked sure made understanding a modern while loop easy.