[orclev]

On the contrary, I want programming to be easier where possible, but the goals of this manifesto (and all the similar ones before it) are trying to fix the wrong thing. Better and more powerful abstractions are always good, I'll always welcome a new tool that makes my job easier. However the goal of this project is to make a tool that's explicitly designed to make code that's easier to read for the average person, not easier to program in. This is in many ways a set of opposing goals. Things that are easier to understand tend to lead to more verbose code and vice versa. Look for instance at assembler. Conceptually assembler is very simple but because of that simplicity implementing anything non-trivial in assembly tends to be very verbose. On the other extreme languages like APL and Haskell are very concise but they're hard to understand because they're very complex and leverage a lot of very powerful concepts.

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

[rtens]

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.

[orclev]

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.

[cr0sh]

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

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.

/sob

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.

[orclev]

Sadly yes, yes I have. One of the very first professional projects I worked on was a system to replace an Excel spreadsheet because they were having issues with locks when trying to concurrently modify it on their network share. The project requirements where literally "implement what Excel does", and the answer to any question about the program behavior was "What does Excel do? Do that". On the one hand it was wonderfully simple and a great opportunity to play around with Backus-Nauer forms and the guts of an interpreter. On the other hand spending months re-implementing Excel rather than solving the actual problem was rather soul destroying.

[inimino]

I can't tell from the manifesto what this supposed to do, but the goal of making programming more accessible seems worthwhile.

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.

[orclev]

> It looks more like Smalltalk, which actually isn't known for being easy to read.

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.

or

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

All the horrible Excel and Access code out there (not to mention some of the worst Javascript out there) are basically the first category, while most serious programs and programming languages are the second category, or somewhere in-between the two.

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

[inimino]

There is a ton of low-hanging fruit in just making the basic logistical details of programming more accessible. (Try to imagine explaining npm to the average Excel user.) Now this project may go after that and produce an incremental improvement that finds a niche in education or wherever, or it may pursue a re-invent computer science, boil the oceans strategy and end up with a smoldering heap of nothing after much effort.

[orclev]

Well now you're talking about something else. If they just want to put some better tooling around an existing language (or maybe apply a slight tweak to one) that would be great, more power to them, although that's not at all what their manifesto seems to be talking about. That said for the love of Turing please don't put yet another build system on node. Haven't we poured enough effort into the garbage fire that is Javascript yet?

[inimino]

What I mean is that the best way to encourage software literacy is probably not going to start by designing a totally new language and development environment.

(Also, the hate JS gets is unfair and diminishes your point.)

[orclev]

Going to ignore the main point of your comment for now, I somewhat disagree but that's a long a nuanced discussion that has more to do with education reform than it does programming. Instead I'd like to focus on your aside about Javascript.

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.

To add further insult to injury someone went and decided to make node which is going the exact opposite direction from where we should be going, we shouldn't be trying to put Javascript everywhere, we should be trying to rip Javascript out of the browsers (or at least provide some kind of alternative). All the churn we see in the Javascript community is basically a symptom of the fact that Javascript is being used for something it really has no business being used for. Javascript sucks as a language for writing applications in, so everyone is constantly trying to "fix" it by putting various layers on top, but you can't fix a broken design by plastering things on top like that (talking about frameworks and libraries here, a transpiler is something a little different). Fundamentally there are two root problems with JS, first it lacks a sane type system, and second it lacks a proper module or namespacing system. They're attempting to fix the later with ES6 modules but it remains to be seen how good that solution is going to be. Typescript goes a long way towards fixing the former problem although it's only capable of so much so it's still more of a bandaid than a real solution. In the meantime we have to contend with the constant churn of new tools and frameworks that are all trying to "fix" Javascript by building on its broken foundation instead of ripping it out and using something that's solid from the beginning.

As an aside to the above, for what it was originally designed for Javascript wasn't a bad solution but it needs to grow up now, and the work being done for things like ES6 really does help. It's just frustrating to see the plodding pace of this evolutionary solution to the problem rather than a more disruptive but faster revolutionary solution.

TL;DR: until the Javascript language itself changes all the frameworks, libraries, and build systems are just window dressing. Right now ES6 and transpilers like Typescript are leading the charge in an evolutionary fix to the language, but a revolutionary one would be much faster.