The future is fewer people writing code?

Came here to say this. And text is still by far the most flexible modality, not physical blocks. Show me a templating or metaprogramming engine written in LEGO blocks and I'll show you a Grey Goo scenario.

This is a strawman. Coding has never been a prerequisite to creation. People were creative forever, and then computers came along and created new avenues for creativity. The vast majority of which is done with applications, and applications have improved by leaps and bounds every decade.

Only a very tiny portion of creative work requires actual programming, like demo scene programmers. Even video games and Pixar movies have far more artists then programmers. It's true that more and more programmers are required to extend and maintain the software, but the growth of the end-user base has far outpaced the programmers. The majority of programmers are implementing business logic of which they have minimal high-level creative input.

The things we can do with computers without code has only increased. Pontificating on how it would be better if we didn't have to write code is like someone who once used a circular saw pondering why can't artisanal wood carving also be done with simple straight-forward, easy-to-use tools instead of difficult-to-use hand tools. I mean its crazy how often we hear this refrain about coding as opposed to other professions. No one asks why can't we have a gadget to perform an appendectomy at home instead of paying a surgeon thousands of dollars, but for some reason people think that coding is somehow unnecessary magic which could be done away with by a bit of clever rethinking. But code is not some rube goldberg device designed to obfuscate and impress; code is a medium, like a blank canvas, or a sheet of typing paper, the only difference is it can control physical things. It is not one concrete thing with a specific purpose which can be optimized like a word processor, or a stove, or a faucet or a car. Less code doesn't mean a simpler world, it just means less of what code can do.

It's not about code. When you, as a programmer, consider the purpose of programming, and how computer-illiterate people view it, things are different. A programmer's job is not to type code. It's to find out what is holding other people back from achieving what they want and find a way to remove that barrier. It's to solve problems and help people make more valuable use of their time.

It could be the analyst that spends hours of drudgery printing out things from one system and retyping them into another (then going back to fix the typos) when what they want to be doing, what would enable them to provide value, is analyzing the output from the second system. It could be the junior exec that spends countless hours manually collating data to build spreadsheets and presentations about their projects, when they want to be doing is trying out new ideas and refining their projects.

Many people were raised to "write each vocabulary word 30 times" and see drudgery as a necessary, albeit frustrating, part of their jobs. Programmers automate that away so those people can do more important and useful things and produce more value. It's not just drudgery though. People have hard problems, often vaguely defined, and programmers help them understand, specify, clarify, and solve those problems.

Younger generations are more computer literate, but still often just use computers and don't realize how much control they could have over them. They may use programs that don't do quite what they need, not realizing how easy that would be to fix. Even if they're not the ones doing the programming, just recognizing that a programmer could help solve their problems is valuable.

At the same time, many non-programmers don't realize how hard some things are to program, or how clear, precise, and unambiguous things need to be defined in order for computers to produce the desired result. They assume something must be simple when they can't even define what the something is. Or they assume that because a program exists, any programmer could make an equivalent but slightly different program quickly and easily.

We don't need to teach everyone to code, we certainly don't need to teach everyone the syntax of some specific language. But we really do need to teach them to think in these terms. What problems do you face? Which of those could be automated or streamlined? How would you specify it clearly and unambiguously? What edge cases and special conditions do you need to deal with? etc. Given that line of thinking, those who are interested will learn to program and those who aren't will at least understand it. Some hypothetical pictocode/vocalcode/AIcode doesn't really matter. People need to understand the basic concepts of problem-solving and automation, how they can be useful, and what makes them relatively easy or difficult.

To each their own. Yes, I'm sure one day more people will use software that allows them to put together amazing programs using complex GUIs that do wonderful magic. These may be business programs that do statistics, or games, and we've already seen both (hello Excel, hello game studios). The problem, as it always has been, is that point when you want to do more and suddenly find yourself in asm land or looking to talk to mysterious "drivers". After all, what's a port anyways? Does that mean my computer has Docker built-in? As I hint, people will hit that wall of mystery, and lower-level programming become inevitable. After that happens, they eventually become accustomed to this idea of telling a computer what to do by strict commands according to a specific protocol. For the average guy who never gets into it, you could tell him it's kind of like talking to a dog. "Sit." It sits. "Love." It wags its tail. "You're so smart, pooch." It gives you a blank stare... and keeps wagging it's tail.

These days, when I look for a programming language, it's not about the syntax sugar, it's more about the feature set that comes with the language: things like the module and build system (e.g. Java is pretty easy), the ease at which both complex and trivial tasks can be accomplished, and the availability of support community and libraries.

That has changed significantly too though. Sorry about this being a long post, but having programmed through most of the last 50 years, I've seen a massive shift in the way people code even from a language perspective:

1) There's a massive reliance on reusable libraries these days. Don't get me wrong, this is a good thing, but it means people spend less time rewriting the "boring" stuff (for want a lazy description) and more time wring their program logic.

2) Most people are coding in languages and/or language features that are several abstractions higher than they were 50 years ago. Even putting aside web development - which is probably one of the widest used frameworks these days - modern languages and even modern standards of old languages have templates, complex object systems, and all sorts of other advanced features that a compiler needs to convert into a runtime stack. Comparatively very few people write code that directly maps as closely to hardware as they did 50 years ago.

3) And expanding on my former point, a great many languages these days compile to their own runtime environment (as per the de facto standard language compiler): Java, Javascript, Python, Scala, Perl, PHP, Ruby, etc. You just couldn't do that on old hardware.

4) Multi-threaded / concurrency programming is also a big area people write code in that didn't exist 50 years ago. Whether that's writing POSIX threads in C, using runtime concurrency in languages like Go (goprocesses) which don't map directly to OS threads, or even clustering across multiple servers using whatever libraries you prefer for distributed processing, none of this was available in the 60s when servers were a monolithic commodity and CPUs were single core. Hence why time sharing on servers was expensive and why many programmers used write their code out by hand before giving it to operators to punch once computing times was allocated.

So while you're right that we still write statements instructing the computer, that's essentially the minimum you'd expect to do. Even in Star Trek with the voice operated computers, it's users are commanding the computer with a series of statements. One could argue that is a highly intuitive REPL environment which mostly fits your "you still have to tell the computer precisely and unambiguously exactly what you want it to do..." statement yet is worlds apart from the they we program today.

Expanding on your above quote, "mostly in text": even that is such a broad generalisation that it overlooks quite a few interesting edge cases that didn't exist 50 years ago:

1) web development with GUI based tools (I some people will argue that web development isn't "proper" programming, but it is one of the biggest areas in which people write computer code these days. So it can't really be ignored. And there are a lot of GUI tools that write a lot of that code for the developer / designer. Granted hand crafted code is almost always better, but fact remains they still exist.

2) GUI mock ups with application-orientated IDEs. I'm talking about Visual Basic, QtCreator, Android Studio, etc where you can mock up the design of the UI in the IDE using drawing tools rather than writing creating the UI objects manually in code.

3) GUI based programming languages (eg Scratch). Granted these are usually aimed as teaching languages, but they're still an interesting alternative to the "in text" style programming languages. There's also an esoteric language which you program with coloured pixels.

So your generalisation is accurate, but perhaps not fair given the number of exceptions

Lastly: "The level of detail required today is somewhat less, due to better tools, but at a high level the work hasn't changed.":

The problem with taking things to that high level is it then becomes comparable with any instruction-based field. For example, cook books have a list of required includes at the start of the "program", and then a procedural stack of instructions afterwards. Putting aside joke esoteric languages like "Chef", you wouldn't class cooking instructions as a programming language yet it precisely fits the high level description you gave.

I think as programming is a science, it pays to look at things a little more in-depth when comparing how things have changed rather than saying "to a lay-person the raw text dump of an non-compiled program looks broadly the same as it did 50 years ago". While it's true that things haven't changed significantly from a high level overview, things have moved on massively in every specific way.

Lastly, many will point out that languages like C and even Assembly (if you excuse the looser definition) are still used today, which is true. But equally punch cards et al was still in widespread use 50 years ago. So if we're going to compare the most "traditional" edge case of modern development now, then at least compare it to the oldest traditional edge case of development 50 years ago to keep the comparison far rather than comparing the newest of the old with the oldest of the new. And once you start comparing ANSI C to punch-inputted machine code, the differences between then and now become even more pronounced :P