Lisp does way more than that. Far too much to be a plausible EUP design. The work in the Lisp community is mostly about using Lisp to make complicated generic control structures, but none of that is needed for EUP. The thing missing for EUP is a human relevant stdlib and you don't need anything fancy for that. Again literally just lists of strings, function calls, and comparators.
Isn't this just another species of the same fallacy: that programming is just a special case of natural language use -- and to get all the non-programmers in on it, we just need to make a more humany language?
This isn't true. Programming is the expression of your understanding of a problem in a totally novel medium, as with painting or mathematics. I dont think there's "End User Math" for describing the problems of daily life. The ability to express oneself in a target domain totally unlike the original requires a skill set of translation and expression that isn't reducible to "making the tool better".
The thing stopping people building their own houses isn't the hammer. Painting their own landscapes the paint. Formalizing their motion through their house, the symbols of math.
These are the smallest barriers to understanding. The appear significant, to you, who has already acquired (to a great degree) the skill of programming. The painter who is very practiced may well think that the ultimate problem preventing the masses from painting is how "thick the oil gets sometimes". Since that is his preoccupation.
> Isn't this just another species of the same fallacy: that programming is just a special case of natural language use
No, because I'm describing a bounded system with a very simple grammar. Statements like:
say "Will this solve the problem?"
onAnswer "yes", unlockBillableClock
... that's not natural grammar. That's a function call. And strings.
And second, I'm not talking about ALL programming, I'm talking about end-user programming. Below this layer is a lot of code written by profession programmers in lots of languages.
You're not going to write a web browser with only function calls and string literals.
What I would question is the orthodoxy that there is NO place in your codebase where you could refactor to a non-programmer understandable form by forcing yourself to use only calls and lists of strings.
I agree with you that programming is a skill that has to be learned, and that not possessing this skill is a greater barrier than the tooling.
However, I think that a lot of problems currently dealt with by programmers do not actually require programming skill, and could be solved by the end-user if they had a better interface available.
I think something similar has already happened with the standard libraries and package ecosystems of modern languages. You no longer need the skill necessary to write a performant hash table, or XML parser, or HTTP client; if you want to quickly throw something together, you just import what you need and then add glue as necessary.
So in a way, a "human relevant stdlib" could actually provide lots of people with the tools to do things that are currently "programming", but that aren't actually inherently complex. I'm not really sure what should and could be in such a toolbox, but trying to make programming more accessible seems like a good way to find out.
Well it seems like you've just described turning the 70s cohort of C programmers into 2000s cohort of PHP programmers.
It's a programmer group -> programmer group transformation.
Solving problems, as programmers do, is just going to create groups of programmers.
Programmer's can design interfaces, specailized to a problem, that may give the end user some flexibility in that problem.
However I fear that this perspective of yours is the same one which recurs at a certain level of mastery over a particular skill: to now no longer be consciously aware of all the things you need to know, and therefore to assume your highly adapted and sophisticated behaviour is not something that this been trained into you; that is essential and natural to the things you're doing.
The professional plumber may as well be saying, "surely there is some sort of end-user plumbing system for these 'simple' tasks could". It probably seems to him that turning a bolt with the right spanner in the right place is as easy as breathing, but it is not. He just does it now with a similar reflex.
> Programmer's can design interfaces, specailized to a problem, that may give the end user some flexibility in that problem.
Yes, that's what I'm talking about.
For example, moving all photos within a certain date range into a different folder could be done using a quick shell script. Only a programmer could do that, right? But then if you give an ordinary user a file manager where they can switch to a tabular view, click on the Date column to sort the files and then do a range selection, they can suddenly do it, without any programming ability.
There is a spectrum of kinds of tools, from a single button that says "Do it", to a simple form where you fill in some details and then click "Do it", to a toolbox where you can perform various actions in sequence, combining them freely to get to your goal (the file manager example), to a general-purpose programming language.
Along this spectrum, the increasing number of options makes the tool more powerful, but it also becomes more difficult to use, because the user has to make more decisions to arrive at their goal. Making the right decisions requires having a mental model of the effect these decisions have, and in the case of programming languages, this mental model is essentially equivalent to "programming skill".
However, not all problems that currently require a programmer to solve are really so hard, and it might be possible for an expert user with the right toolbox to do it just as well.
> However I fear that this perspective of yours is the same one which recurs at a certain level of mastery over a particular skill: to now no longer be consciously aware of all the things you need to know, and therefore to assume your highly adapted and sophisticated behaviour is not something that this been trained into you;
While I am not usually consciously aware of everything I know, I am aware that it required training to get where I am and that not everyone has this training or will ever have it.
For example, I know that there are people, generally quite adept at using computers, who would be unable to complete the file manager example I gave above; either because they don't know how to do one of the steps, or else because they could not mentally connect them to get from what they have to what they want.
However, I am fairly sure that there are more people who could do that than those who could write a program to achieve the same effect; that is what counts in my book. If you can move a problem from requiring an expert tool maker to only requiring an expert tool user, you should do it.
Regarding your plumber example: there is an "end-user plumbing system" that allows you to get running water and regulate its temperature by turning the right knobs, and everyone can learn to use it, no plumbing experience required.
Sometimes, not always, but sometimes, programming is like that.
