Inform system developers, do you approve the Plain English Programming?

It probably contains the word “weiner” somewhat more than War and Peace does.

(Explanation: To avoid namespace clashes, authors were encouraged to use a unique identifier for special actions etc. that were being defined in their rooms. I used my last name. This made it fun to do things like define a wiping action and define kinds of action that ordinarily would have gone like “Touching is contact. Squeezing is contact. Rubbing is contact.”)

3 Likes

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

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.

5 Likes

I recall a teacher once telling me in an introductory programming course that we have computer languages so that computers can understand humans. I believed it at the time, but I now think that we have computer languages so that humans can understand computers.

2 Likes

Late on this, but please tell me you discovered that if you read the manual in the Inform 7 IDE that you eventually found the little boxes to click that automatically copy the code from the documentation into the source text so you can try it out.

I suppose coding is not equal to writing. Authors are usually accustomed to hammering out multiple pages of prose at a time.

This surprises me, because I think for me personally it was the other way around. I was programming in BASIC before I knew English, so words like “let”, “for”, and “if” only had one specific, technical meaning. There’s no way I would have accidentally used these words in another sense (to make something up: “print if x is odd or even”).

But for all I know, the subjects in these studies might be more familiar with English than I was. If the subjects were adults, that could also make a difference.

1 Like

Recall that the IDE was implemented in the language itself. My best guess: Scrollbars were too difficult to implement, so they were left out, and the decision was later rationalized (and unfortunately cemented) by means of rhetoric.

I did see that, but I think it’s not the best way to learn the language. I would generally type things in then experiment with them. For me that gives a better feel for how I would be using it down the road.

There a few reasons why I don’t like Inform’s approach (and I recognize that this can be personal). Let’s say you have something like this in Inform (I have no idea if this is actual Inform syntax, but it looks pretty similar to all the examples):

When the kitchen is entered, put candy in the bowl of the room that was last exited by the player.

In C# I’d do something like this inside class Kitchen:

OnEntered() { Player.PreviousRoom.Items.Add(new Candy()); }

There are a lot of benefits to this format. The first is that pretty much anyone who has learned C# would write this in the same way. The English language could express the Inform sentence in a lot of different ways, and when I was experimenting with Inform I found it did a fine job at being human readable but it was awfully picky about the form of the sentence. Code generally understands that parsers don’t do ambiguity well and just leans into it.

Another benefit is that this structure is easy to debug. I can place breakpoints on individual actions. I can examine each variable and each function pointer at runtime. I can step through the logic sequentially just as the computer will do it.

Another benefit is that it groups sequential actions together. Everything that happens when you enter a kitchen is going to be right there in that method. It is all laid out in a sequential manner, completely deterministic in its order of operations, and presented to you in that order. I could write an event based model, similar to Inform’s style but I would only do this in cases where that would provide value beyond the complexity cost.

All that said, a sufficiently studied student of Inform certainly can get by with candy items showing up in the world. The real problem with Inform and most the other tools for IF now is not how they do what they do, but what they can’t do.

What if I want the word ‘candy’ to animate around the screen for a while then move off in the direction of the room from which the player came? What if I want a puzzle where the keystrokes from the player are instantly translated into a cryptographic scheme when they are displayed, but resolve to their literal value as parts of the cryptographic code are broken?

There are millions of creative things that could be done in games that are still largely text based, but which are either impossible or prohibitively complex in the current set of tools being used by the community. Instead we tend to get very creative games all boxed in to the confines of Zork-like or Hypertexty presentations. The community has done a pretty good job exploring within the limits imposed by the authoring tools, but I think so much more could be done.

1 Like

Please do create this system next chance you get! I don’t know C#, so I’ll use I7 in the meantime!

That sounds like @DavidC’s project and he’'s looking for help: Refly (new IF platform) & izyuk (in-memory IF-oriented graph database).

I’m also working a Javascript library that’s also graph oriented. I’ve only gotten as far as writing the parser, but it’s coming along nicely: https://whitewhalestories.com. The challenge is to encapsulate the complexity of these systems without compromising flexibility or power.

What you describe could be done with Vorple, which allows an Inform story to execute JavaScript commands. But I agree all its potential has not really been exploited. (I think one of the reasons is that you need to know JavaScript, and a lot of people here are not programmers by trade and just write IFs as a hobby.)

Also, Inform 7 is going to be platform-agnostic in the future, in the sense that it will allow to compile the story in other format than the Z-machine/Glulx. So with the appropriate work, one could make Inform output C# for use in Unity.

See the recents talks of Graham Nelson for more information, and for explainations about the reason Inform was designed the way it is, with natural language (that last part is more relevant to the original topic).

1 Like

I mean, you learned one coding language already called Inform. If you want the advantages of another, you’ll have to learn that one too. I tried learning both (I’ve taught myself dozens of programming languages over the years) and just came to the conclusion that C# is better.

There’s nothing really to create. Unity and Unreal exist. You either have to learn to use them or do what most game designers do and partner up with an engineer who knows how to use them.

I suppose some IF-centric Unity libraries could be made or perhaps Refly will have some legs, but you have a lot of power available to you now.

The advantage, though, is I already know English and it wasn’t too much of a jump to adjust to the specific syntax I7 requires. C# (and good god, JS is the bane of my existence) is a completely new thing.

That’s the point of this whole “natural language” discussion though. People tend to have an adept brain for actual coding or not. Some people find it easy to just pick up complete new languages and some don’t, so it’s not valid to just say “oh, just learn the new thing…” Easier said than done for some of us.

I’d venture it’s a similar difference in difficulty range of an English-speaker learning Spanish which uses the same character set and an English-speaker learning a Middle Eastern or Asian language where the character set is completely different.

2 posts were split to a new topic: “Pain Points” learning/working with JavaScript

FYI

If you are looking toward Unity, a good system to add text story lines in a game format is Fungus. It integrates with Unit allowing text interactivity within Unity.

Fungus Games

It is lua / C# based.

Jeff

Almost: you refer to “the list” and “the other list”. So it recognizes “a list” as an argument named “list” and when it sees “another” it sticks the word “other” onto the beginning of the following name.

It only allows two of any given name: if you try to use “another list” again it will abort with “Dude, you already have a parameter called the other list.” But it doesn’t do any type checking or treat most words as anything but plain text, so “a list” doesn’t mean “you must pass a list here”, it just means “the compiler is going to use the name ‘list’ for this argument”. So you could just write a “third list”, “fourth list”, and so on. Or…y’know, give them names that reflect their function (if they have one) instead of just their position in the argument list, e.g. To find a needle in a haystack or To find a needle string in a haystack string.

1 Like

Thanks for that explanation!

So is there a notion of kinds? I was thinking about the vertex, which seems like it has to be defined somewhere… it’d be pretty hard to work without kinds somehow, it seems?

Oh, sorry. There are definitely kinds. They’re just not tied to the argument names. Or wait, are they? Oh, they are! I was totally wrong in my last post. a list does mean “this argument is a list kind” It’s just that you can stick in extra words to name that particular list.

OK. The indefinite articles-ish (“a”, “an”, and “some”) mark kinds. So when you say the following, an x coord is a type? No, a coord is a type, and then you can put in extra words (‘x’ or ‘y’) to name that coord argument. It would probably also work to say Create a vertex given the x coord and the y coord. I didn’t know you could abbreviate by leaving out the type name like that.

To append an x coord and a y coord to a polygon:
Create a vertex given the x and the y.
Append the vertex to the polygon’s vertices.

You can also give things other names with, e.g. Create a vertex called Rachel given the x and the y.

OK, so it’s pretty normal dynamic typing stuff. And then he must do some kind of pattern matching to find the right routine to run. So when you say Append Rachel to the polygon's vertices. it’s looking for a routine called “append xxx to yyy” which wants xxx to be “a vertex” and yyy to be “some vertices”.

Hopefully I have that right.

1 Like