Precisely. Every barrier in place between using a system and programming it serves to elevate the decisions of its designers over those of its users. The greatest power of computers is their ability to be reshaped to meet whatever need the user has, but we mostly lock that power away from them.

There's a subsection of people who are very well served by that. And it has already been happening. SQL, Python, HTML/CSS/JS are all things that people use who are not primarily programmers. Applications like Unity, Excel, some Adobe stuff also blur the line here.

But let's not forget that there are a ton of people (many more than the above) who are constantly overwhelmed by computers even though they only use very few features. There's people who can't use ATMs and smartphones. Most computer users only ever use the most common applications (browsers, music/video players etc).

Perhaps users want to use apps without needing to program apps?

Perhaps some want to play in a garden without needing to dig and plant and weed and…

> Multics Emacs proved to be a great success—programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.

~ https://www.gnu.org/gnu/rms-lisp.html

I think you shouldn't need to program if you don't want to understand the problem domain.

Do you think someone should need to program if they want to understand the problem domain?

Speaking for myself, I’ve never found a better way to understand something new.

Perhaps a way to understand abstract categories.

think i've seen the term 'operator' used in this context?