> I'm talking about human-guided programming without using traditional programming language, creating a design document to lay out what it does and how data flows and allowing the computer to sort out the details based on a stored data set.

Creating clear and accurate design documents is so much harder and more specialized a skill than programming that many places that do programming either avoid it entirely or make a pro-forma gesture (often after-the-fact) in its direction.

(I am only about half-kidding on the reasoning, and not at all about the effect.)

"creating a design document to lay out what it does and how data flows and allowing the computer to sort out the details based on a stored data set."

This is exactly what programmers do today. We just call the "design document" a "program".

Over time, our design documents become higher and higher level, with the programmer having to specify fewer details and leaving more of the work of sorting out the actual details to the computer.

Yes, exactly! That's what the article is claiming.

Why do you assume that this design document would be simpler to create than the traditional computer program? Because otherwise, this is exactly what happens now.

There are some fairly aspirational claims about how it might be different in this paper, which is a great read:

http://shaffner.us/cs/papers/tarpit.pdf

There has already been some significant progress on this front. E.g., SQL and logic programming let you describe what you want to happen, and let the computer figure out some of the details. Any compiler worth using does this, too. Smarter machines and smarter programs will mean smarter programming languages.

Design is always going to be a part of creating something. What this article is arguing is that manual typing of text by humans using traditional programming languages will not be the primary means of implementing those designs in the future. We don't yet know how to make computers into good designers, but we know that we can create tools that translate designs into executable code that can be less error-prone and more reliable than people typing letters into a text editor.

My question is how is drawing rather than writing simplifying anything i.e. what is the gain from moving from traditional programming to some sort of theoretical picture programming? Is it that you can draw lines between things rather than just assuming that the line from one symbol points to the next symbol on the line? Does that simplify things, or make them more complicated?

> we know that we can create tools that translate designs into executable code that can be less error-prone and more reliable than people typing letters into a text editor.

I disagree. Maybe you know, but I haven't seen any indication of the sort.

Drawing rather than writing is just one method. A lot of it will likely be conversational. I could imagine a designer with an AR overlay speaking to a computer which offers several prototypes based on an expressed intent. The designer chooses one and offers criticism just as a boss would review an alpha version and suggest changes. The machine responds to the suggestion and rewrites the program in a few fractions of a second. The designer continues the conversation, maybe draws out some designs with a pencil, describes a desire, references another program which the machine analyzes for inspiration, and the machine adjusts the code in response. This is just one of many possible examples. The point is that software design is trending toward more automation. Coding is not a new essential skill that everyone will need on the future. Human-machine interactions are trending toward natural and automated methods, not manual code entry. Most people need to learn to be creative, think critically, analyze problems, not learn the conventions of programming languages.