What's wrong with Software nowadays and how we can fix it

That's one of my all-time favourite books so if I hadn't read it I'd be eternally thankful to you for pointing me to it =) It definitely blew my mind.

It didn't make me feel that mathematics is somehow limited though. As far as I understand Gödels theorem, all he says is that there is no such thing as a contradiction-free system of axioms a la Principia Mathematica.

But that's fine with me. I keep tons of contradicting believes in my head all the time. And I'm actually not that interested in simulating an entire brain (although that would be very exciting) but the thing I really care about is the ability to express a part of my mind that I care about in software, sort of like expert systems do. And as a software developer, that's exactly what I do everyday with the minds of my clients. That's also the main idea behind DDD in my opinion.

This topic deserves an essay. If I manage to wrap my head around it, I'll publish something on my blog this week.

If I understand you correctly you're probably thinking about how more concise notation systems make things easier for experts but harder for novices, e.g. maths and music scores, and probably Haskell as well.

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.

Ah, now this is a very interesting conversation and you're right, the manifesto doesn't get any of that across.

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.

I basically agree with you here. However, JavaScript is a better language than most people think. Ignorance and trying to treat it like something it isn't is responsible for much of the hate. Obviously it being the only choice in the browser is part of it. However it's a better language than many of the ones that people (or at least groups) use by choice.

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.