> There may always be tasks for which we need someone to write a process description in a Turing-complete language, but even as a programmer, almost all of the non-programming tasks I do today would have required programming 30 years ago.

And the end result of this is what? More or less code gets written? Is there a need for more or less programmers over time? What's the trend, do you think?

Maybe the computing pie gets bigger faster than the software needs can be turned into non-programming tasks.

That's a great question, and I'm going to sidestep it a bit by saying I think the limiting factor isn't technology.

95% of the projects I've worked on have been some fairly simple permutation of ETLs, CMSs, and ops -- all of which are sufficiently constrained problem spaces that we've got good systems for them which work well without the need for Turing-complete programming languages.

But as long as we're constrained by legacy codebases, overly complex third-party APIs, and the need to maintain business models, we're not going to be able to make things as simple as we know they should be. It's not just services: I've got 100 legacy file formats on my disk, and they mostly are completely different and require different tools for no good reason.

I've wasted many months (years?) of my life figuring out how to plug the API from service X into the API for service Y and put the results on a simple webpage, with some CSS that a designer gave me. That's not the sort of thing that ought to require a Turing-complete programming language. It's almost all accidental complexity.

Someday we'll sort this all out, and then maybe we'll go on to discover some other unexplored area where we need lots of (Turing) programmers, or maybe we won't, but that's beyond the inflection point. Our next 50% barrier isn't technical, and as long as we've got artificial socioeconomic barriers in the way, I can't guess what's after that.

> Maybe the computing pie gets bigger faster than the software needs can be turned into non-programming tasks.

Most "software" needs these days are business related. Legions of engineers are just adding minute variations to the same CRUD frameworks to make slightly different products. I think the kind of programming that goes into making a CRUD startup and the kind of programming that went into making a device driver in the '80s is very, very different.

I can imagine this being the future, but it's quite a long way off. I was thinking about this as I was doing some work in Python earlier today - back when I was working in C, variable-length lists and hash maps were so inconvenient that I often just convinced myself that fixed-length lists and sequential searches were "good enough" for the case at hand (and, often, I was right). With Python, of course, I don't even think twice about using relatively higher-level concepts (in fact, I don't have a choice), so even as a professional programmer, I've popped one meta-level up in the abstraction stack. That said - there are a LOT more meta-levels that tools need to pop up before somebody who doesn't even understand what a linked list is is going to be able to produce software that serves a useful purpose. Even in that future world, there will be a need for "low-level" folks who can at least think in assembler when necessary - but I imagine that role will be more like that of a surgeon in meatspace.

> With Python, of course, I don't even think twice about using relatively higher-level concepts (in fact, I don't have a choice), so even as a professional programmer, I've popped one meta-level up in the abstraction stack

But these existed in programming languages before Python's inception, at least back to Lisp in the 60s. And newer languages like Go eschew some of the higher level flexibility of a Python on purpose.

Also, despite the widespread use of languages like Python, JS and Ruby, C/C++ and Java remain just as widely used as ever.

> there are a LOT more meta-levels that tools need to pop up before somebody who doesn't even understand what a linked list is is going to be able to produce software that serves a useful purpose

I can think of lots of useful web applications today built by people with no knowledge of linked lists (or at least, they didn't need any such knowledge for those applications). The entire CMS market seems to exist to enable this.