Abstraction

I ended this essay with a pattern rather than a prediction. Someone raises the level of abstraction so that more people can build more things with less ceremony. The people who mastered the older, lower level object that the new level hides too much and understands too little. The new level turns out to be useful anyway, its rough edges get sanded down over a few years, and it becomes the unremarkable ground that the next generation stands on. Then someone proposes to raise the floor again. I am watching the floor rise now, in my own career, and this time the pattern has a wrinkle I did not fully sit with before. Every earlier layer still expected a programmer to write the layer above it. FORTRAN expected formulas. C expected C. The compiler translated what a person had already composed. The layer arriving now inverts that. The artifact a person hands down is a description in something close to English, and the thing standing on that description and turning it into running behavior is not a junior engineer but a machine that read a great deal of code and can write more. ...

Every era of programming has been an argument about the same thing. How much of the work should the human do, and how much should we hand to the machine? Each time we have answered “give more to the machine,” someone has objected that the machine cannot be trusted with it, that real programmers work closer to the metal, and that the new convenience is a toy. And each time, within a decade, the convenience has become the floor that the next generation of programmers stands on without a second thought. This is a story about that floor rising. It runs from a woman feeding subroutines to a UNIVAC on tape in 1952 to a teenager in 2026 building a working web application by describing it to a language model in English. The technologies could not look more different. The motive behind them is identical. ...