The future of programming (1982)
dl.acm.org
dl.acm.org
> One of the key problems in analysis and specification of systems is that the eventual users do not have a good idea of what they want the system to do.
> Automatic Programming The term "automatic programming" has been used for many years to refer to the process by which an executable program may be produced from nonproce- dural specifications of the task to be performed. Some limited forms of automatic programming are already available and more will become available in the medium term. Over the longer term, it will be possible for pro- grammers to create running programs by providing a specification of program functions and outputs, without having to proceed with a detailed program design or with the production of code.
Am I living in 1982?
Well as far as actual programming is concerned, little has fundamentally changed since then. We still sit at keyboards and edit code with a text editor.
That's basically what the job was up until LLMs came along.
They actually were somewhat correct in 1982. While they do not explicitly mention AI, we can summarize that e. g. claude is, in some ways, an "improved tool" for some parts of writing code.
“Over the longer term, the nature of programming will change even more significantly as programmers become able to describe desired functions in a nonprocedural way, perhaps through a set of rules or formal specification languages.”
> "This fundamental change will occur in several ways. [...] programmers will become able to express the desired function of a program in terms of its expected behavior and output(s) without having to specify the precise algor- ithms involved in performing the processing.
Third, many programmers will then move away from concern with the "how" of programming to concentrate more heavily on the "what"; applications programming will then become equivalent to today's task of requirements analysis and specification. In short, both the nature of programming and the nature of programmers will change."
If you look at science fiction AIs from HAL onwards, they usually have limited practical agency - good for handling mundane automation, answering the occasional question, and usurping power, but not in any sense capable of solving original engineering problems.
It's much easier to imagine a big defence-linked computer system like Skynet than something like Claude or ChatGPT, which can improvise working software to a vague spec.
I'm sure a lot of developers have had "I wish I could just tell it to build what I want" moments on the past, but I'm not sure anyone anticipated being able to do it, even five years ago.
Particularly the https://en.wikipedia.org/wiki/Fifth_Generation_Computer_Syst... was cited.
Don't you think they made that call way too early? You could've had a full career between then and now.
I was getting into university around the same time. I don't recall any sentiments like this at all. And when discussions about automating programming came up it was usually dismissed as impossible - which it was back then. People didn't necessarily say it would never happen, but it was going to be a very long time in the future. It basically became possible to do in 2024 (and much better since then), way earlier than I would've have expected it to happen. But in the meantime from 1984 - 2024 I was able to have a pretty good career (I'm glad to be able to be retired now, I wouldn't want to be facing this in my 40s or 50s.)
But here's the thing, Clarke and others postulated that as soon as computers could 'reason' they would figure out that humans were holding them back. So even in the 80's and 90's engineers and scientists were imagining "self programming" computers or computers that could program other computers, and understood that while it would speed up productivity of programmers it would also speed up the productivity of malcontents.
I think it would be safe to say that they hadn't really thought too much about computers that were still dumb as a post but could now search trillions of possible solutions per second. Semantically brute force searching for an encryption key is 'infeasible' for keys that are sufficiently long (have enough entropy) but when the 'key' is "this input produces this output" the entropy there is significantly smaller and search for a set of operations that takes you from the input to the output is, computationally, an easier problem.
For starters, the AIs in the Culture (series started in the 80s) ran the whole society and were superhuman and essentially better at any single thing than humans.
They were still the "independent, sentient" sort of AI vs the Claude "super fast information processing loop" style, though. But absolutely general purpose and original-thinking, and much more advanced than what we have.
Huh? I don't think it's true at all- HAL passes the Turing test and is effectively more capable than his human colleagues. What they could not see was the complexity of the technology around it- programmable computers everywhere, each running tons of extremely complicated software, everything networked.
Instead, what most science fiction got wrong (and I got entirely wrong myself before LLMs) is that the technology is a consumer technology. Inference is cheap enough that it can be served to millions almost for free. The famous machines of SF (HAL, Colossus, WOPR from War Games, SkyNet, etc.) are all dedicated systems in some inaccessible laboratory, in service of a single client and working at some multiple of human speed. What we got instead is as many instances as we want, directly available to anyone.
1 It's hardly sf after all- more like a romance/ relationship type of story. I think they got it exactly right by complete chance- it wad meant to be metaphor, not a product design.
Today spec-driven development is in the same place.
of course the reason it pops up again and again is because it fails to gain much traction, like an employee that gets hired left and right, but only because he keeps getting fired every week or so