> Seibel: I’m thinking of the preface to SICP, where it says, “programs must be written for people to read and only incidentally for machines to execute.”
I’m wondering if the initial statement in SICP spoke from a time that was similar to a 1977 McGraw-Hill textbook, “Introduction to Computers”, that I picked up from a thrift store recently. A significant portion chapter on developing computer programs is dedicated to methodology; planning, the development life cycle, systems design, instructing users, processing methodology. The next chapter is about flowcharts and tables.
I mention all this to point out how intrigued I am by what looks like the emphasis that was placed back then on clarity from the human’s perspective, be it programmer, user or anyone else involved in the software’s development and use.
Another thing that’s interesting to me is how old code like Fortran looks like it’s made up of mostly just words, compared to modern languages I’ve looked at that use a lot of abbreviations and special characters.
My knowledge of programming and its history is excruciatingly minimal, but this blog post and that excerpt sort of remind me of what I just mentioned. I’m not sure why exactly, or if there’s any credence to it.
> I mention all this to point out how intrigued I am by what looks like the emphasis that was placed back then on clarity from the human’s perspective, be it programmer, user or anyone else involved in the software’s development and use.
I'm not yet born in the 1970s, but I think the fact that "code is written for people to read" is something that people in the earlier decades knew intimately, and that we have "forgotten" in recent years.
It hinges on a very simple fact - we know that machine code is for machines to execute, and they had machine code for as long as machines existed. And yet in subsequent decades, people spent so much resources in designing/inventing programming languages, so much resources in writing interpreters and compilers -- it's got to be for a good reason, right?
Once you think of it that way, the reason is obvious. Code written in programming languages are for people to read (and write), otherwise we'd just work on the binary executable.
I guess these days in the stacks of abstraction, we don't even know what's running on the bare metal any more, and for novices it might feel like "abstractions all the way down", and the point that the abstractions were originally for human consumption might have been lost or forgotten.
The approach in 1977 was that the problems we address with computer programs were static. It was up to the system developers to understand the problems well enough to learn their requirements and then implement the requirements as code. Writing the code was the last thing you did, after the problem was entirely understood, documented, flowcharted, signed off by the client, etc.
Now we understand that the problems often change as the code is developed, or in response to the code we develop. Priorities and requirements change as the work proceeds. We start writing code early, solving small parts of the problem, and building up a solution almost organically, the way a tree will grow around obstacles in its pursuit of sunlight.
The name Fortran is a contraction of "Formula Translation" it was developed to be usable by mathematicians and scientists. COBOL is another language that looks very wordy, as it was developed to be used by businesspeople.
I've spent a lot of time trying to make sure my code is commented and easily readable; and I haven't found any of that time to be wasted. I've often had to go look at code that I wrote two years, or five years, or twenty+ years previously, and I've greatly appreciated the work I put in when I wrote it.
I’m wondering if the initial statement in SICP spoke from a time that was similar to a 1977 McGraw-Hill textbook, “Introduction to Computers”, that I picked up from a thrift store recently. A significant portion chapter on developing computer programs is dedicated to methodology; planning, the development life cycle, systems design, instructing users, processing methodology. The next chapter is about flowcharts and tables.
I mention all this to point out how intrigued I am by what looks like the emphasis that was placed back then on clarity from the human’s perspective, be it programmer, user or anyone else involved in the software’s development and use.
Another thing that’s interesting to me is how old code like Fortran looks like it’s made up of mostly just words, compared to modern languages I’ve looked at that use a lot of abbreviations and special characters.
My knowledge of programming and its history is excruciatingly minimal, but this blog post and that excerpt sort of remind me of what I just mentioned. I’m not sure why exactly, or if there’s any credence to it.