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"?
