The past and future of software development (ChatGPT)

 Seven Ages of Code — and the Next Act

The history of programming is less a straight line than a series of tectonic jolts. Move the cursor back to 1945 and you find pioneers standing ankle‑deep in solder and paper tape; fast‑forward to 2025 and an LLM is finishing your functions before you’ve hit the semicolon. Here, then, is a whistle‑stop tour through the shifts that truly rewired the craft, followed by a glimpse of the near horizon.

---

1. Valve‑Age Hand‑Coding (1945‑1956)

The beginning was literal wiring. Programs were patch‑cords and relay banks, bugs were singed fingers, and “debugging” meant a screwdriver, not a pull request. Code, insofar as it existed, was written in octal and punched into tape that stretched like an endless rosary of regret.

2. Compiler Dawn (1957‑1969)

John Backus's FORTRAN and Grace Hopper's COBOL pried open abstraction’s door: algorithms could now be written rather than etched in metal or listed in arcane symbology. Portability entered the lexicon, and the idea of the same program running on two different machines felt almost deliciously heretical.

3. Structured Republic (1970‑1984)

Enter Pascal, C, and the polemic against goto. Unix spread across academia like an amiable virus, interactive editors replaced card decks, and the terminal became a second home. Programs at last resembled prose—albeit prose punctured by semicolons.

4. Object & GUI Renaissance (1985‑1994)

Smalltalk‑80, C++, and the graphical interface shifted focus from procedures to things. The mouse scurried across the desk; windows overlapped like office gossip. Codebases now modelled business domains—and occasionally the programmer’s own ego.

5. Internet / Open‑Source Insurgency (1995‑2004)

The web blew the walls off the lab. “View Source” was the new textbook, Agile the new catechism. LAMP, Python, and CVS → Subversion (version control systems) armed a million hobbyists. Release cycles shrank from calendar years to coffee breaks.

6. Git & Cloud Frontier (2005‑2014)

Linus Torvalds gifted Git; Amazon rented out the data‑centre aisle by the hour. GitHub turned version control into a social network and Continuous Integration into a reflex. Software escaped the rack and found sanctuary in the ether.

7. Container‑Native Era (2015‑2021)

Docker boxed applications like so much takeaway, Kubernetes orchestrated fleets of them, and “Infrastructure as Code” became the mantra. YAML files bred like rabbits; post‑mortems became the weekly book club.

8. The Copilot Moment (2022‑2024)

Large‑language models—GPT‑4 and its cohort—took the boilerplate bullet. Surveys show 70‑plus percent of developers now lean on AI to draft, refactor, and test. The keyboard has acquired a ghost, and that ghost is chatty.

---

What Happens Next (2025‑2030)

Autonomous Spec‑to‑Deploy Pipelines
Declare intent; an orchestral suite of agents designs, codes, provisions, and tests. Humans sign off where risk or regulation demands a pulse.

Verification by Default
Formal methods, once the province of spacecraft, return to Earth. If an LLM can discharge SAT‑solver proofs faster than you write unit tests, you’ll let it. Bring it on!

Domain‑Trained Copilots
Generic models give way to boutique brains: fintech copilots fluent in COBOL derivatives; gaming copilots that dream in shaders; parish‑finance copilots versed in XBRL (eXtensible Business Reporting Language).

Self‑Maintaining Repos
Your codebase files its own pull requests—shifting libraries before the CVE lands, migrating APIs, perhaps even refactoring from monolith to micro‑kernel while you sleep.

And the caveat: expertise concentrates. Junior “code monkeys” thin out; senior developers become stewards—curators of prompts, arbiters of diff, translators between automated suggestion and organisational conscience. Less Tolstoy, more conductor with a baton made of regex...

Unusual Reasons

This post is about people who undertake significant life changes, but for unusual reasons.

1. Programming

Dr Hamid Lesan escaped to England from Iran, where, as a dissident, he was under the scrutiny of the Shah’s secret police, the SAVAK. He worked as a colleague of mine at STL in the mid-1980s on formal methods research and AI. I asked him once how he had gotten into programming; he replied that he had first engaged with programming as an interesting application of the lambda calculus.

[Dr Hamid Lesan received his Ph.D. in Mathematical Logic from the Department of Mathematics of the University of Manchester in 1978. After a brief period of teaching, he joined STL in 1980, where his work has been mainly concerned with Formal Methods and Natural Language Processing. He is currently working on tools for supporting the formal specification and development of software in the context of the ESPRIT project RAISE. (ICL Technical Journal, Volume 7 Issue 1 - May 1990). He died in August 2006 - I’m not aware of the circumstances.]

2. Joining the revolutionary left

In the early 1970s, when I was at Warwick University, there was a plethora of far-left organisations looking to recruit: the International Socialists (IS, later SWP); the Socialist Labour League (SLL); the Militant Tendency in the Labour Party; and the International Marxist Group (IMG), British Section of the Fourth International.

It was a time of unrest, and we talked big. Our perspective was becoming a mass revolutionary party as the Bolsheviks had achieved in 1917. Once, one of our leaders, Peter Gowan, came to Warwick to speak. He looked forward to the future mass party, but mentioned that today, most of the leading cadres had elected to join the IMG - rather than other bigger, higher profile organisations - specifically because of its link with the International.

Probably not one in one hundred thousand workers and students had ever heard of the Fourth International: I certainly hadn’t before I was recruited…

3. Being received into the Catholic Church

People join religious organisations for many, often prosaic reasons. But JD Vance joined after an intense study of St. Augustine’s massive City of God. In this fifth century work, Augustine condemns Rome, the City of Men, devoted to present excess, hedonism, selfish ambition and heedless individualism. Vance had no problem identifying those ancient Roman pagans with contemporary American coastal elites with their mindless hedonism; their secular, patronising arrogance.

Augustine counterposes the City of God, the community of those who love God and live according to His will. The Catholic Church is a visible manifestation of the City of God on earth, and promotes the virtues of humility, communitarianism and morality.

JD Vance considered the Catholic Church as the right organisation of resistance: he decided to join.

[St. Augustine wrote "The City of God" over a span of several years, beginning in 413 AD and completing it around 426 AD. This period was during a time of great turmoil in the Roman Empire, particularly marked by the sack of Rome by the Visigoths in 410 AD, which partly inspired Augustine to write the work. The full title of the work is "De Civitate Dei contra Paganos" (The City of God against the Pagans), and it addresses the decline of Rome and defends Christianity against the accusations that it was responsible for the fall of the Empire. (ChatGPT).]

Scale discrepancies

In the summer of 1977 I decided to leave teaching. I had spent a couple of years at Ormonde High School (now Maghull High School), an ex-secondary modern in Maghull, Liverpool teaching maths to the 11-16 year olds. I think it would be fair to say that my students were at the lower end of the ability range. I was burnt out and exhausted.

At that time computers were entering practical use in industry and there was an increasing need for programmers. The Government set up the so-called TOPS courses (Training Opportunities Scheme), which subsidised people changing career. I passed the tests and started a 20 week course to learn COBOL programming with KBS Computer Services in Dale Street, Liverpool. The class was told the course would be really intensive, seven day working , evenings thrown in, partners expected to be abandoned for the duration.

I was in competition with a guy named Paul. He was intuitive, writing code festooned with GOTO statements. I was more organised, knew that GOTO was considered harmful and taught myself structured programming. We were both taken on by KBS at the end of the course.

One module was IBM S/360 assembly programming. I recall working on a program with maybe a hundred or so instructions - load this register, add packed, and so on. I thought: 'It's taking me an hour or more to get this code right, yet when it executes it will take 100 microseconds'.

I found that scale discrepancy rather disquieting. It's true of every program but in assembler it's somehow more visceral.

---

We ran our programs on punch cards through the IBM 360 owned by the Merseyside Docks and Harbour Company. The machine was on the top floor of the Liver Building at Liverpool Pier Head, and we'd go in the evening when the machine was not in regular use.

Access was easy. It wouldn't work today. I once took Clare (who I was 'going out with' at the time) to see the unimpressive sight of those big blue cabinets and the dinner plate sized removable disk drives (20 Megabytes). She does not recall an epiphany.

Super-high-level programming languages

Not many posts recently as Alex is visiting. We were discussing programming languages, which divide between those focused on performance (C++, Go) and those focused on the problem domain (Java, Scala).

I floated Prolog past him, but with his engineering head on he wasn't that interested. The tutorial programs were 'hard to understand' and in any case 'could be coded much more efficiently in a procedural language such as Java'.

OK, I gave up on that but it did make me think: what would be a language at a much higher level of abstraction even than Prolog?

Richard Montague

There's a way of thinking about this as a logician, where you focus on different kinds of semantic models: those of higher-order logics, modal logics, type systems .. but I don't really want to go there. Richard Montague's 'throw the kitchen sink at it' logic for natural language is a kind of reductio ad absurdum for that kind of approach. You rapidly lose any computational capability.

Our intuitive idea of the inadequacy of current programming language expressivity derives from a comparison with natural language. What an advance it would be (we think) if we could engage with a computer system the way we today talk to the (human) analyst.

English as a super-high-level programming language?

For me the extra dimensions of natural language include the management of agency (hence speech acts) and context - the presumption of a detailed and extensive shared culture to make sense of implicit referents.

In the end it depends on what we think we're programming. If it's the behaviour of a non-intentional black box (every business system to-date) then a more-or-less souped-up predicate calculus specification language (which is adequately executable) will be optimal: a Prolog-variant.

If our target system is an intentional system, indeed a second-order intentional system - one which treats other systems such as ourselves as intentional systems - then the 'programming language' to engineer such systems will incorporate those additional capabilities we find in natural language.

Today's AI engineering community will hiss at this point: we don't program any more - our systems learn!

Don't worry, that pendulum will be swinging back soon enough. I expect legislation in due course that new AI systems will have to attend school.

Diary: programming is hard!

I remember a post by James Thompson (can't find it - sorry) describing the joy of giving IQ tests to bright students. Their smug condescension as they breeze through the early items; their horror as they hit their cognitive limits and start to sweat: "Wait a mo, .., just can't seem to see it ... ."

In artificial intelligence textbooks it's standard to cover the coding of theorem provers for propositional-calculus. Hidden away in the advanced exercises is the suggestion to extend the program to cover the full predicate-calculus. Inevitably, this is flagged as hard.

Tell me about it. Today I got basic binary resolution to work. Great! I can do inference. And yet this is not the central mystery of a predicate-calculus resolution theorem prover (RTP).

The conceptual problems arise from the layers of abstraction around the proof procedure. At the risk of boring you even further, binary resolution is driven by the unification of complementary literals (basic formulae). These two literals occur in the two clauses offered to the resolution function (hence binary resolution).

A  problem addressed by an RTP comprises: assumptions  = the axioms, a set of clauses, plus the problem itself, a goal clause.

Here's my working example. First come the axiom clauses:

(defvar *c3*   (mk-fact-clause '(likes rod horvath)))
(defvar *c4*   (mk-fact-clause '(likes sally renner)))
(defvar *c5*   (mk-fact-clause '(likes sally rod)))
(defvar *c6*   (mk-fact-clause '(likes hardy renner)))
(defvar *c7*   (mk-fact-clause '(likes hardy rod)))
(defvar *c8*   (mk-fact-clause '(amusing hardy)))
(defvar *c9*   (mk-fact-clause '(likes horvath moties)))
(defvar *c10* (mk-rule-clause '(likes sally ?x) '((likes ?x moties)) ) )
(defvar *c11* (mk-rule-clause '(likes rod ?x) '((likes ?x renner) (likes ?x rod)) ) )
(defvar *c12* (mk-rule-clause '(likes ?x ?y) '((amusing ?y) (likes rod ?y)) ) )
(defvar *c13* (mk-fact-clause '(likes ?x ?x)))

(defvar *g1* (mk-goal-clause '((likes sally ?who)) ) )  ; this is the problem clause

You may notice a "Mote in God's Eye" theme here.

Despite the simplicity of these facts and rules, you'll struggle a bit to figure out the complete list of who, exactly, Sally Fowler likes.

I expect better from my program - once completed.

---

So a clause might look like this (which you will recognise as a Prolog-style Horn-clause):

'( (likes sally ?x) ← ((likes ?x ?y) (likes ?y moties)) )   ; a rule clause

which is already a bit complicated.

Then we have to set up structures for the knowledge-base (facts and rules), the goals which emerge from the resolution process, and the pointers and bindings which allow a reconstruction of proofs.

---

In telling you this, my intention is not to document the program, my point is more psychological.

You need to keep a very great deal of abstract structure in your head simultaneously if you hope to put this not-entirely-trivial program together. Plus lots of functions.

It's very g-loaded, much like doing mathematics.

"It's quite hard getting figures but ... it appears that the average IQ of students applying for PhD programmes at good universities in computer science is around 128.

"That sounds right to me. Most software development companies don't take people without good first degrees or a higher degree in a STEM subject - and that's just the pool we're talking about here."

---

Parenthetically, thank God for Lisp, a gift from the deity for clear, conceptual, exploratory thinking.

---

I read endless texts in the media from innumerate journalists about how unemployed or newly-redundant workers are going to retrain as software developers. Those writers couldn't hack it themselves and sadly, neither will most of those no-longer-required workers.

"Wait a mo, ..., just can't seem to see it ... ."

At an IQ threshold of 128, we're talking about 2.5% of a population normed at 100.

A caveat. It's intellectually hard writing machine learning programs or configuring recalcitrant artificial neural nets on novel problem-domains .. or programming RTPs. Yet for everyone doing those things, there are ten people paid to use graphical web design tools or load databases, or do a bit of scripting. Things which are not that hard.

Like many occupations, there has been mission-creep in the definition of software developer.

---

And why am I making such heavy weather of this wretched theorem-prover? This.

Programming is so .. arid

Helena Cronin wrote:

"Women on average have a strong preference for working with people - hence the nurses and teachers; and, compared to men, they care more about family and relationships and have broader interests and priorities—hence little appeal in becoming CEOs. Men have far more interest in "things" - hence the engineers ... "

I'm sitting here looking at a short recursive function which returns a tree whose nodes are themselves a complicated data-type (Atom-list x Nat x Nat) and I'm trying to do minimax on it. The Lispworks 'Listener' has replaced the Atom lists with hash signs (why?) and the arithmetic min function complains it's getting something weird rather than Real - and has thrown me into the debugger.

Why?

The code looks good, although there are so many good-practice projector and constructor functions, cluttering the text.

I sit in frustration, trying to visualise the unwrapping of the computation as the nested mutually-recursive functions execute their combined paths to disaster. Part of me wants to chuck this code away; another part muses that this would mean I was getting even more stupid in my old age.

I review the psychological characteristics required for successful programming.

• An ability to mentally visualise complex and abstract structures - (heavily g-loaded)
• A minute attention to detail - the smallest typos kill you
• Obsessional perseverance when nothing goes right and time-wasting options beckon.

If ever an occupation required what Simon Baron-Cohen calls the 'systemizing brain', this is it.

---

Update: (Twenty minutes later).

OK, so it was a type clash. I forgot to update a previous sub-function. Needed to add some projectors. So now I have a result.

Shame it's not the one I actually need ...

---

Some print-journalism stays with you. I regularly recall a right-on female commentator on The Times using her column to weigh in on gender equality in programming. After some shocking statistics she recounts how she asked her daughter if she had considered becoming a programmer. Her daughter looks at her as if she is mad: "Why would I want to do anything as boring as that?"

The daughter's mother is not of course a programmer. She's an opinion-piece journalist, a job where you get to meet and socialise with important people and then write lots of stuff of interest to your like-minded pals.

*Sigh*.

---

In case it isn't obvious, I know there are good female programmers. I know there are good female physicists (see here). It's just .. we're talking distributions here - you know, bell-shaped curves? - and the male-female means are noticeably different.

Strive for equality of opportunity; do not expect equality of outcome.