What I want are new tools that leverage powerful concepts to allow me to efficiently express complex ideas. These tools by their very nature are hard for the non-programmer to understand. Look at what's being proposed in this manifesto. They're advocating for what is in essence internet enabled Excel. Do we really want to start trying to write applications in Excel? Can you imagine the horrible spaghetti code that would result in? Imagine how much code you're going to have to write to express even mildly complicated concepts? Imagine trying to maintain one of these beasts.
Further more, for this idea they propose to get off the ground, the vast majority of programs would need to be written in this new language they're proposing, which is, quite frankly, not going to happen anytime in the next 20 years at least. We're still using C and assembly, and they don't look to be going anywhere anytime soon (although maybe Rust can dislodge a little of the C). I do think it would be good for more of the population to at least have a passing understanding of basic programming concepts, at the very least learning how to solve problems using abstract thinking would be useful, but I don't think trying to create some kind of "simple" programming language is the way to do it. There are "simple" programming languages out there, just look at any of the toy languages designed to teach children how to program. But that's the thing, they'll always just be toys, they expose a very limited subset of capabilities for solving a limited subset of problems (mostly they focus on making it easy to draw on the screen since it allows for simple games that provide positive feedback for children learning).
So I suppose you mean "Things that are easier to understand for novices [...]".
But that's not always the case which is incidentally proven by your examples. Assembly Language is a lot easier to write and understand for novices than machine code. And Fortran even more so. Bret Victor illustrates this very nicely in the video I linked to.
I'm convinced that the power that makes something more concise and at the same time easier to write and understand is abstraction. Or more precisely, the right abstraction, since a bad one can have to opposite effect. So I agree with you that better and more powerful abstractions are always good. Spreadsheets for example are a great abstraction for some problem but terrible for others.
So in order to "leverage powerful concept" and "express complex ideas" you need to be able to create your own abstraction. In this way my proposal is very different from Excel which barely allows to create any new abstractions.
What the manifesto apparently doesn't make clear is that I'm not proposing a new programming language but a programming model. The language part is more like byte-code than Java but it's really a protocol. The result is something that would serve a similar purpose as HTTP but would be vastly more powerful.
I think the mistake that these "language designed for children" that you have in mind is that they add training wheels instead of removing the pedals. The latter manages way better to teach you the basic concepts (steering, balancing) first and once you mastered these, gears and transitions increase your efficiency.
When it comes to software, I would take a similar approach and create a software authoring/execution environment that can be used by novices and experts alike. Novices would learn the concepts (message passing, abstraction) without actually writing code. The coding would then be added to increase the user's efficiency by providing a more concise notation. The actual language used would best be domain-specific to achieve maximum efficiency.
Abstractions are the key to powerful programming languages, but they're also the thing that people struggle with the most when learning programming. It appears a certain segment of the population is just not capable of thinking in abstractions in the way that programming requires (or at least they do not care to invest the effort to learn how). Math has a similar problem, with high level maths requiring a level of abstract thinking most people are not comfortable with.
The flip side of that though is that all abstractions leak. Abstractions are convenient shorthand, but to properly use them you still need to understand the thing they're abstracting over and that becomes more true the larger and more powerful the abstraction is. The leap from machine code to assembly language for instances is a very small abstraction, it's mostly a matter of mechanical symbol replacement with very nearly a 1 to 1 mapping from assembly keyword to machine OP (there's some small nuance around single vs. multi-byte ops as well a register vs. immediate vs. address ops). Because the abstraction to machine code is so thin it's not terribly important to understand the actual machine code because the abstraction when it does leak does so in only very small and minor ways and it's usually easy to figure out what's going on. Once you start working in larger and more powerful abstractions it becomes a lot more important to be able to peek behind the curtain as it were. Understanding classes for instance and the nuance involved in dynamic dispatch in something like C++ is very important to properly understanding their behavior, limitations and tradeoffs.
When you talk about using this new Excel like model as a generic programming model I'm immediately reminded of the actor model. It's a very similar design, but it's also not really a good fit for certain kinds of tasks. That's part of the problem when you start talking about some kind of generic model (or abstraction as the case may be), it likely will work quite well for certain classes of problem but be wholly unsuitable for others. I also don't see it actually addressing the issue the manifesto brings up which is to promote programming literacy. The vast majority of people are going to have no interest in learning about the various abstractions programmers employee. It could be argued that they would benefit from doing so, and that some classes that teach basic programming abstractions should be mandatory in either Highschool or College level courses, but I suspect we'd see as much success there as we do with the higher level maths like statistics and calculus.
As for the toy languages most of them aren't too terrible but in the interest of not getting bogged down in a study of advanced topics they tend to force certain abstractions such as being loosely typed, or having no namespacing. For most real languages various escape hatches are provided to allow you to bypass the abstractions when necessary (in extreme cases FFI allows for escaping the language entirely), but all those escape hatches tend to introduce dark and mysterious corners in the language that are very hard to explain to novices because they tend to strip away all the layers of abstraction exposing the dangerous moving parts of the language. In order to avoid confusing novices with features it's assumed they'll never use most of the toy language elide the escape hatches you'd expect of a real language and instead simply say "No, you can't do that" in instances where the student wants to do something that isn't built into the language. In particular being able to link to and utilize C libraries is a hugely powerful feature that most real languages support, but which tends to introduce all kinds of complications not only at the language level but also at the tooling and build level that most toy languages want to avoid.
Have you not worked in business much? Or software development (or b2b software development, or vertical integration software development, or...)?
Everything you mention in these few sentences has already come to pass, almost as soon as Excel was released. You would not believe the ungodly horrors we software developers have seen since then...then been forced to maintain, or re-write, or attempt to document.
I once found an ANN implemented as a set of Excel worksheets - thankfully, this wasn't a real-world system, but rather a tutorial designed to help teach ANNs to those with only Excel knowledge...but I know that someone - some manager, likely - somewhere out there - has chosen to add this beast into his or her own Excel worksheet system, and that it lurks, waiting like Cthulhu for a hapless sacrificial victim.
An Internet-enabled open source Excel would be, well, at least better than Excel, which runs more of the world than we'd probably like to admit. Of course, the chances of that happening are effectively zero.
It looks more like Smalltalk, which actually isn't known for being easy to read. So I'll reserve judgment for now, but I support the ambitious effort.
That's sort of one of my points though. They're going to come up with basically one of two things:
A) Something that's conceptually simple (so the average person can understand it without needing to take a bunch of programming classes) but which leads to most programs being very hard to read because they have to implement all the complexity in the program.
B) Something that's conceptually complex (and which will require a bunch of programming classes to understand) but allows for simple and easy to understand programs (once you understand the language).
Smalltalk is somewhere between the two. It uses a number of relatively complex concepts but tries to hide them behind some fancy tooling. It was a hugely influential language and pioneered a number of interesting, although perhaps ultimately misguided, concepts and abstractions. Personally I think the message passing concept Smalltalk pioneered (the predecessor to todays actor model and one of the originators of the OO concept) is going to go down as an evolutionary dead end that's poorly suited as a model for general purpose programming (it has certain niche uses that it's very well suited for but shouldn't be applied to the general case).
(Also, the hate JS gets is unfair and diminishes your point.)
The problem with JS is that we don't have any choice about it. For a quick and dirty scripting language that you're going to write some throw away code in JS isn't too bad, it's basically on par with something like lua (although I think lua is designed a bit better). The problem is that by being the lingua franca of the web browser we're now forced to contend with it even when we really should be using a more powerful language, hence all the hate.
The frameworks and build systems are largely necessary because the web platform is rather weak, and of course to add language features.
A type system would help a lot, as will modules once they are universally used. Typescript, Flow, etc will probably settle on something useful. Evolution is generally better than revolution in language design. It's a bit slower for JS because of the nature of the web.