If you've seen some of Edwards' work and listen to what he is saying about aiming for non-programmers you may get an idea of how different his idea of programming is from what most programmers do (I admit I am a traditional programmer).
I think the problem is that the basic definition of programming relies on editing textual and mainly static source code that describes processes at a low level. As soon as you start to get away from that your tool by definition is not a programming tool and therefore programmers don't want to be associated with it.
Its a problem of a failure of imagination and worldview and a psychological issue of insecurity. Programmers are like traditional wood workers who look upon automated manufacturing with disdain.
Ultimately superior artificial general intelligence will arrive and put those mainstream programmers with their overly complex outdated manual tools out of work.
But programmers will hang on to their outdated paradigm until the end of the human age. Which by the way is coming within just a few decades.
I think you have a mistake in your analogy. We're more like mechanical engineers drawing complicated CAD diagrams. It's just that we don't need a whole factory to produce our product, because it's not physical. All we need is a compiler and copy the bytes of the output.
There are 100 decisions every minute that need very complicated thought processes to solve, this is as true in manufacturing as it is in software development. Do you make this button out of plastic or metal? What kind of metal or plastic? How big should it be? Should it click or not? Does it have multiple functions based on the state of the vehicle? Does it have a label? Where does the label go? What does it say?
You could write this all into a spec, but the spec would end up being the same as the CAD drawing / program. So you end up relying on the experience of the engineer to make all the decisions without it all being 100% specced out. Maybe it's a button on a top end Mercedes that gets pushed a lot, so it should be metal to complete the feeling of luxury. Maybe it's a button on a mid-end Nissan that gets pushed a moderate amount - make it a decent plastic, etc.
> We're more like mechanical engineers drawing complicated CAD diagrams.
In engineering of any kind, you have functional requirements and you have outputs that you design to satisfy them. In software engineering, you may be trying to help people manage finances; in mechanical engineering, maybe you're trying to remove water from a mine shaft. Your outputs are a graphical computer program and a pump. You have certain resources available, such as operating system X or a steel mill. Your job is to bridge the gap between resources and outputs by creating the minimal viable instruction set that results in the output.
The instruction sets are, respectively, source code and a CAD drawing.
The mechanical engineer has a CAD program that already knows a lot about pumps, and a library of standard screws, threads, and sockets. The program can infer constraints, suggest placement of parts, substitute components based on formulae, read data from Excel or CSV files, simulate stress due to different loadings, and even knows a bit about manufacturing so that it can tell if the part can be made or not. It can help generate drawings that the steel mill can use to create the pump. The mill, too, is pretty smart and has a lot of leeway to make the pump however the want, as long as it works.
All this is basically equivalent to the what the software engineer has available: test suites, frameworks, reusable functions and libraries, cross-platform compilers. The difference is workflow:
While working on the design, the engineer can switch between a variety of layouts, color schemes, transparencies, and zoom levels. S/he can visually show constraints (using symbols and colors), directly manipulate parameters and positioning of objects. The engineer doesn't have to memorize commands or syntactic conventions in order to be productive. In a modern system, these kind of interactive operations are intuitive to perform and distinct from the manipulations of the source object (the CAD file). The equivalent for software engineering doesn't really exist. It's like instead of separating engineering and implemenetation, you're trying to do everything on the factory floor.
The effect of this is that you have plenty of smart people (in science, business, whatever) frustrated in translating their ideas into "code"[1]. In the long run, what we should, and probably will, see is smarter compilers, more sophisticated IDEs -- abstractions above the level of implementation (the problem level) rather than below (the machine level). This is similar to what happened with the process of putting ideas into words for people to read: at first, only scribes could read and write; then, anyone could read and write, but only printers could publish books; now, anyone can read, write, publish, and distribute anything via the internet.
None of this is to say "you're doing it wrong," but rather "we're not there yet." Software engineering is not going away in the same way that mechanical engineering is not going away because of CAD and simulation programs. More sophisticated tools are a path towards "Simple things should be simple, complex things should be possible" (quote from Alan Kay).
[1] There is a reason it's called code, after all.
I think the problem is that the basic definition of programming relies on editing textual and mainly static source code that describes processes at a low level. As soon as you start to get away from that your tool by definition is not a programming tool and therefore programmers don't want to be associated with it.
Its a problem of a failure of imagination and worldview and a psychological issue of insecurity. Programmers are like traditional wood workers who look upon automated manufacturing with disdain.
Ultimately superior artificial general intelligence will arrive and put those mainstream programmers with their overly complex outdated manual tools out of work.
But programmers will hang on to their outdated paradigm until the end of the human age. Which by the way is coming within just a few decades.