|
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. |