Lists of strings + function calls + function definitions, that gets you pretty far. Anything that tries to reach much beyond that will fail. Function definitions are probably just lists of strings. Deeply nested statements are probably counterproductive.
I think even IF statements are probably not necessary. Comparison operators plus function calls get you conditionals and so much more.
> Lists of strings + function calls + function definitions
Cue LISPers in 3, 2, 1...
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.
No, because I'm describing a bounded system with a very simple grammar. Statements like:
say "Will this solve the problem?"
onAnswer "yes", unlockBillableClock
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.
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.
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.
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.
I'd rather be able to send anyone my-data.mesh.html, they double click it, it opens in their browser, they can modify it at will, and there's a button that's functionally equivalent to a Save button to let them overwrite the orginal file. (Like a quine on steroids. Think TiddlyWiki.) This can be done, the only problem is that you don't get the typical Ctrl+S workflow—you use the in-page button instead, and it wouldn't let you get around the "Save As" dialog, but I'm thinking it should be only a minor nuisance.
If you do it right, you could even standardize your serialization so that other tools could ingest a meshfile.
This is really neat, and I'm going to play with it tomorrow.
Embedding Mesh and its dependencies in the file itself is really clever. The file would get a bit bloated but maybe that's OK if:
(a) when the file is consumed by other code, the interface exposed is clear
(b) when the file is opened as a Mesh program, all the user can see is the program shown in the spreadsheet, not Mesh's code.
It is potentially more risky from a security perspective if it is not easy to verify the Mesh source embedded in the file hasn't been changed to be malicious.
What is the use case here? The readme describes vaguely that it's more suited to arbitrary length data processing and generation... but I can't come up with a practical example for which this IDE is applicable. I wish the developer would showcase SOMETHING besides the base interactions. Anyone have any ideas?
Clicking through on the link that says "more discussion here"  the OP does at least explain the original problem with Excel that he was trying to address:
>Mesh was started because I couldn't find a way in Excel to output the results of a formula across an arbitrary number of cells. ...
This is definitely on the right lines.
My one nitpick is that I want to be able to just try it in my browser right now. Oh also you really need a target project with something like this. In other words, you need problem you are trying to solve, so that you can know once you've solved it.
There are no shortage of instances where Excel plays a depressingly crucial role in critical LOB operations (including shops that you'd expect to know better). Essentially what happens is places like big manufacturing corps pour all their engineering budget into staffing themselves with folks who have domain-specific knowledge, but no idea how to build something resembling sane IT infrastructure, let alone focus on rolling out anything that could scale. So they all fall back to what they know from school, which are terrible (terrible!) hand-crafted spreadsheets that get passed around through email or thrown on a network store that everyone gets write access to. As in: this is literally how things run at the fab that produced the chips in your phone or the silicon in your big name desktop GPU.
Occasionally, someone comes along who knows how to do pivot tables or use VBA to create basic macros and is revered as a wizard. Even in the best cases they end up being unmaintainable messes.
Heck, a quick and dirty TiddlyWiki-like tool that just lets average people make basic tables would go far in dislodging Excel from places where it's burrowed down and is screaming "wrong tool for the job".
This is a cool project, I'm excited to see where it goes
Bruce Hauman has some good talks about his tools, which are GUI application-centric and a joy to use 
If you aren't doing web or native mobile GUI stuff then the default tools have immediate unit test/linting/spec compliance feedback triggered every time you save a file.
Unless you mean you want a very simplified language, in which case you should look elsewhere. Clojure has definitely chosen the high power side of that trade-off, but this also allows some truly first class tools to be developed.
 https://www.youtube.com/watch?v=G7Z_g2fnEDg <- this one in particular is original and outstanding in my opinion
But it seems like a powerful way to process data, not a way to write programs, am I right?
I hope I remember to install and try it when I get home.
If you get a chance to try it, please let me know if you have any feedback!
On whether it feels like a 'spreadsheet' - is it just the absence of location-based referencing, or did you have other features in mind?