I think you are severely underestimating difficulty of understanding non-trivial code. Even good programmers would need days if not weeks to understand how software like card processing AI works. And even when you understand the code behind it the AI like deep networks produce models that cannot tell to a human "how" it works.
So when a person uses a software component for real-life purposes I don't think there's a difference between someone who knows how to code and someone who doesn't - it's a black box.
> Even good programmers would need days if not weeks to understand how software like card processing AI works
I think there will be a shift in how we design software. Right now, software is mostly organized into monolithic packages which are about the maximum size a professional developer can make sense of in 40 hours per week. For the most part, all corners of the codebase are written with the expectation that they will be read by an expert in the language who understands the whole codebase. Lots of side effects, advanced control structures, etc. In order for programming literacy to take off, we will first have to start organizing some of our software for widespread human understanding.
Instead of one giant pro-level repository, you will have a toplevel layer which is mostly configuration code, but which is written in very domain-relevant language, using only simple programming primitives: functions and literals. It will be boxed into small, understandable modules, and editable in a browser like any simple document.
The next layer down will be generic algorithms and data structures, also written using simple programming primitives, and designed with very forgiving APIs, again using as much domain-specific language as possible and pushing non-domain specific implementation details down into libraries.
The third layer will be implementation-specific code, highly optimized, using the full spectrum of language tools and programming constructs. Only the domain of professional programmers.
Everyone, including children and executives will dabble in the top layer. Domain professionals (everyone in your organization who is not a full-time programmer) will work in the second layer, only in the part of the software that they specifically interact with in their work. Full-time coders will maintain the third layer, and will think of their role more as a support role, building tools to support the organization, rather than maintaining total control over the codebase.
So far there were multiple approaches that looked something like what you described: component programming, visual programming, "4GL" languages. Heck, even Steve Jobs wanted to sell software components. But these things failed. "Coding" won.
Nothing I described is "not coding". I described using a subset of existing language constructs for certain parts of a codebase, and structuring some interfaces in a certain way.
I certainly didn't say anything about visual programming.
4GL... I think you meant something else there? Ruby and PHP are 4th generation languages and are obviously doing quite well.
As for component programming... I think that's the closest historical precedent for what I'm describing so I'll go deeper there...
Unlike "component people", I don't think there is any single interface for high level domain-specific libraries. Every domain will be different. Objects are certainly not a panacea. And I have no illusions that domain-specific libraries would ever be automatically compatible with one another. I have no illusions of some universe of easily integrated components. I'm just talking about an isolated, high-level API on top of a single, internally consistent codebase.
A simple example, instead of a repo with a bunch of configuration data and a "start" command, build a service as a library without any deployment specifics, and then have a separate repo that has a simple script that uses that library to set up a specific instance.
Or, build a site as a library without any content, and then have a separate repo that just binds in the content to the app, so that anyone could play around with the content without having to dig through the implementation details, and with a smaller chance of breaking something.
It's just about separating the part of the codebase that vaguely makes sense to non-engineers from the part of the codebase that makes zero sense. I'm not talking about any kind of radical technological shift.
> A simple example, instead of a repo with a bunch of configuration data and a "start" command, build a service as a library without any deployment specifics, and then have a separate repo that has a simple script that uses that library to set up a specific instance.
If the service does something useful then it must use things like databases and external APIs. So you need interfaces to abstract them - and they will be big and complex. It looks like you end with the "component problem"?
So when a person uses a software component for real-life purposes I don't think there's a difference between someone who knows how to code and someone who doesn't - it's a black box.