There are some excellent ideas in here, but like most of these opinionated little languages/IDEs, there are also a lot of bad or silly or just plain irrelevant ideas, so I suspect it’s unlikely to ever gain widespread traction. I could see it finding a dedicated niche community though.
Personally I’d find it hard to recommend a system whose authors think things like this are good ideas: “No window borders, no widgets, no icons, no tool bars, and no palettes. We thus encourage the student to focus on the content in the foreground, not the background (which we leave in the background where it belongs). Whoops! Almost forgot. No scroll bars. Ever.”
All of those things serve useful and well-documented and researched purposes, and many of them are especially useful for beginners. There are sometimes good reasons to leave them out, but they’re exceptions. And this guy isn’t making a case for why his applications is one of those exceptions, he’s just making a blanket rejection, which makes me doubt his knowledge and competence.
There’s a lot of stuff like that in both the article and the documentation.
The instructions.pdf
file is likely not something you would want to give to small children, e.g. “When you start me up, I will quickly take over your screen so you no longer have to look at that painted whore of an interface that comes with the kluge.”
I like the simple flexible syntax. It does, of course, suffer from the problems that brings: if you can redefine any word it’s hard to tell what any particular thing means, because it might have changed out from under you at any time. That’s unavoidable. But I do wonder if a system with clearer markers for the types and functions of things would be more beginner-friendly. That’s certainly a big part of the design of things like Scratch and Blockly: making definitions and comparisons and loops and commands visually distinct.
Personally I’m on the fence about programming in a natural language. Here are a couple thoughts, in no particular order:
-
It almost certainly lowers the bar for entry. Even if that’s only a perceptual thing (because you still have to learn what these words mean to the computer, which isn’t the same thing they mean to human beings) it’s still a very good thing. I’ve seen three different people start off with flowchart-like box-and-wire programming and do it long enough to become decent programmers. All of them eventually got fed up with the inefficiency (it takes much longer to enter than text and you can fit much less code on screen at once so you have to scroll around a lot more and can’t see as much of your program at once) and moved on to text-based languages. At that point they were like, “Oh! This is just the same as what I’ve been doing, only text!” But they would likely never have gotten there without the easy on-ramp.
-
Communicating with a computer is not like communicating with a human being. Choosing names and language designs that reduce the amount of problems where you-think-you-know-what-this-means-but-actually-you’re-wrong is a hard design problem. It seems like about a third of Inform 7 questions stem directly from misunderstandings driven by the English language words it has chosen for a given concept. It would be interesting to see a study on whether that sort of thing slowed learning or caused more errors for beginners in natural-language programming vs. conventional programming languages.
-
There have been a couple of pilot studies about translating programming languages (the built-in names like if
, else
, function
, and so on) into other natural languages for teaching purposes. So far they seem to suggest that it’s about 10% more work to learn to program (in a conventional programming language) if you don’t speak English. So very measurable but not enormously significant. Most of the effort is in learning how the language and computer work. Again, it matters, but there are other things that often matter more.
-
A common objection to “literate programming” is that you have to think in two modes: code and prose. I’ve never had the slightest trouble with that in traditional settings, so it’s hard for me to judge. But I found in Inform 7 that I did have a little difficulty switching gears since both things looked alike. It’s not too bad with syntax highlighting, but I found it very tedious to follow some of the examples in the documentation where they don’t have that. So for me it’s easier to have another visual cue that this is code and that’s prose.
-
Using parentheses or square brackets or curly braces for grouping is convenient and and more visually clear than parsing sub-clauses in sentences (though we’ve had more practice at the latter). And I suspect that brackets can be nested a couple levels deeper than clauses without getting confusing. And there are a lot of existing tools that will let you select chunks of text by matching brackets, which is something I always hate having to live without when I’m coding in Lua or something that has begin and end markers that my editor doesn’t support. Obviously you can code in a style that doesn’t require nesting other than by calling subroutines (the Plain English system doesn’t allow nested if statements or loops at all). And that often works excellently for simple stuff. But at some point it becomes a liability: you end up in a maze of little named bits of code, and when you find a bug, which ones don’t do what you think they do?
I dunno. In general I think programming languages could usefully move toward having a lot less punctuation. But I’m not sure going for something that tries to closely approximate natural language really makes a whole lot of difference, except as a an onboarding technique, a way to convince people that programming isn’t as far outside their experience as they think. But that’s certainly a valuable thing. And there are already a bajillion programming languages out there, and all of them work for someone, so hey, the more the merrier.
OK, I guess I’m coming around to the idea of natural-language-like programming now.
Huh. I had never thought about it, but that’s a really good point. When I’m playing parser games it’s always a constant irritation that the input is so obnoxiously verbose and inconsistently abbreviatable. I type pretty quickly, so I have only once or twice given up on a game because the author used such annoyingly long and difficult-to-type names, but it’s always a thing that’s sitting there bugging me.