An excerpt from Richard Hamming’s The Art of Doing Science and Engineering with some relevance to AI coding:
In the beginning we programmed in absolute binary, meaning we wrote the actual address where things were in binary, and wrote the instruction part also in binary!
[...]
If, in fixing up an error, you wanted to insert some omitted instructions, then you took the immediately preceding instruction and replaced it by a transfer to some empty space. There you put in the instruction you just wrote over, added the instructions you wanted to insert, followed by a transfer back to the main program. Thus the program soon became a sequence of jumps of the control to strange places. When, as almost always happens, there were errors in the corrections, then you used the same trick again, using some other available space. As a result the control path of the program though storage soon took on the appearance of a can of spaghetti. Why not simply insert them in the run of instructions? Because then you would have to go over the entire program and change all the addresses which referred to any of the moved instructions! Anything but that!
We very soon got the idea of reusable software, as it is now called. Indeed, Babbage had the idea. We wrote mathematical libraries to reuse blocks of code. But an absolute address library meant each time the library routine was used it had to occupy the same locations in storage. When the complete library became too large we had to go to relocatable programs.
[...]
The first published book devoted to programming was by Wilkes, Wheeler, and Gill, and applied to the Cambridge, England EDSAC (1951). I, among others, learned a lot from it, as you will see in a few minutes.
Someone got the idea a short piece of program could be written which would read in the symbolic names of the operations (like ADD) and translate them at input time to the binary representations used inside the machine (say 01100101). This was soon followed by the idea of using symbolic addresses—a real heresy for the old time programmers. You do not now see much of the old heroic absolute programming (unless you fool with a handheld programmable computer and try to get it to do more than the designer and builder ever intended).
I once spent a full year, with the help of a lady programmer from Bell Telephone Laboratories, on one big problem coding in absolute binary for the IBM 701, which used all the 32K registers then available. After that experience I vowed never again would I ask anyone to do such labor. Having heard about a symbolic system from Poughkeepsie, IBM, I asked her to send for it and to use it on the next problem, which she did. As I expected, she reported it was much easier. So we told everyone about the new method, meaning about 100 people, who were also eating at the IBM cafeteria near where the machine was. About half were IBM people and half were, like us, outsiders renting time. To my knowledge only one person—yes, only one—of all the 100 showed any interest!
Finally, a more complete, and more useful, Symbolic Assembly Program (SAP) was devised—after more years than you are apt to believe, during which time most programmers continued their heroic absolute binary programming. At the time SAP first appeared I would guess about 1% of the older programmers were interested in it—using SAP was “sissy stuff,” and a real programmer would not stoop to wasting machine capacity to do the assembly. Yes! Programmers wanted no part of it, though when pressed they had to admit their old methods used more machine time in locating and fixing up errors than the SAP program ever used. One of the main complaints was when using a symbolic system you didn’t know where anything was in storage—though in the early days we supplied a mapping of symbolic to actual storage, and believe it or not they later lovingly pored over such sheets rather than realize they did not need to know that information if they stuck to operating within the system—no! When correcting errors they preferred to do it in absolute binary addresses.
FORTRAN, meaning FORmula TRANslation, was proposed by Backus and friends, and again was opposed by almost all programmers. First it was said it could not be done. Second, if it could be done, it would be too wasteful of machine time and capacity. Third, even if it did work, no respectable programmer would use it—it was only for sissies!
[...]
With FORTRAN available and running, I told my programmer to do the next problem in FORTRAN, get her errors out of it, let me test it to see it was doing the right problem, and then she could, if she wished, rewrite the inner loop in machine language to speed things up and save machine time. As a result we were able, with about the same amount of effort on our part, to produce almost ten times as much as the others were doing. But to them programming in FORTRAN was not for real programmers!
One moral of this story is, there is no such thing as “too easy” for getting things done.
It’s interesting to think about why you wouldn’t automate a production process. I see six overlapping goals that you can pursue when you choose to do something by hand:
Getting things done. Your goal is to achieve the result by any means, and manual work is the only or the best means available.
Optimization. You can sometimes perform a task better with bespoke materials, tools, and methods. This normally doesn’t imply the whole product must be made the same way.
Assigning rank. Your goal is to establish who is the best. Automation is as appropriate as driving a car in a marathon. (You may still try to drive a car in a marathon if formal rather than actual rank is what you care about. Automation can be used for cheating.)
Making art. The execution is in service of an aesthetic goal.
Maintaining skill. You want to learn and then remember how to achieve the result or to be able to replicate it under conditions where automation isn’t available.
Working more pleasantly. Doing things manually can mean less pressure and stress.
There is also a seventh motivation that isn’t really a goal:
Being satisfied with the status quo or stuck in your ways. You don’t want to automate because doing things manually works well for you. Or maybe it doesn’t work well, but as a human you are a creature of habit. Rightly or wrongly, you also aren’t concerned about the competition.
It sounds like the “real programmers” in the Hamming quote who didn’t want to move on from binary to assembly and then to a high-level language wanted to optimize (“it would be too wasteful of machine time and capacity”, so goal 2), were creatures of habit who didn’t worry about the competition (7), and cared about rank (“no respectable programmer would use it—it was only for sissies!”, 3).
What I wonder is, how did it feel for them from the inside? Besides 2, 3, and 7, did they think they were maintaining skill? This is a reason I have heard repeatedly from programmers who moderate their use of LLMs. From a comment by user lesser23 on a recent Hacker News story:
I have found that after around a month of being forced to use them I felt my skill atrophy at an accelerated rate. It became like a drug where instead of thinking through the solution and coming up with something parsimonious I would just go to the LLM and offload all my thinking. For simple things it worked okay but it’s very easy to get stuck in a loop.
I’ve heard similar comments from friends. The concern seems real enough, and I have responded to it by writing some of the code I know an LLM could write for me and by looking for better solutions to my problems than an LLM would come up with.
An excerpt from Richard Hamming’s The Art of Doing Science and Engineering with some relevance to AI coding:
—Hamming (1996), pp. 45–8
One moral of this story is, there is no such thing as “too easy” for getting things done.
It’s interesting to think about why you wouldn’t automate a production process. I see six overlapping goals that you can pursue when you choose to do something by hand:
Getting things done. Your goal is to achieve the result by any means, and manual work is the only or the best means available.
Optimization. You can sometimes perform a task better with bespoke materials, tools, and methods. This normally doesn’t imply the whole product must be made the same way.
Assigning rank. Your goal is to establish who is the best. Automation is as appropriate as driving a car in a marathon. (You may still try to drive a car in a marathon if formal rather than actual rank is what you care about. Automation can be used for cheating.)
Making art. The execution is in service of an aesthetic goal.
Maintaining skill. You want to learn and then remember how to achieve the result or to be able to replicate it under conditions where automation isn’t available.
Working more pleasantly. Doing things manually can mean less pressure and stress.
There is also a seventh motivation that isn’t really a goal:
Being satisfied with the status quo or stuck in your ways. You don’t want to automate because doing things manually works well for you. Or maybe it doesn’t work well, but as a human you are a creature of habit. Rightly or wrongly, you also aren’t concerned about the competition.
It sounds like the “real programmers” in the Hamming quote who didn’t want to move on from binary to assembly and then to a high-level language wanted to optimize (“it would be too wasteful of machine time and capacity”, so goal 2), were creatures of habit who didn’t worry about the competition (7), and cared about rank (“no respectable programmer would use it—it was only for sissies!”, 3).
What I wonder is, how did it feel for them from the inside? Besides 2, 3, and 7, did they think they were maintaining skill? This is a reason I have heard repeatedly from programmers who moderate their use of LLMs. From a comment by user lesser23 on a recent Hacker News story:
I’ve heard similar comments from friends. The concern seems real enough, and I have responded to it by writing some of the code I know an LLM could write for me and by looking for better solutions to my problems than an LLM would come up with.
I would never program in the assembly language, but recently I have reverse-engineered an old DOS game, and it was a work of art.
(Off-topic: I didn’t realize that there were so many popular Czech-made computer games: 1, 2, 3, 4, 5.)