Inform7 Will Not Be Fixed
Yesterday, I realized that Inform7 will not be fixed; the public bug-tracker and the suggestion board are nothing more than the usual smoke and mirrors, the customary shell game conducted by people who wish to appear open and committed to principle, but who in reality, are not. It’s a whitewash, and the developers (and their coterie) remain wedded to their own particularities instead of a consistent vision.
Although the problems I reported inevitably ended up being classed as “cosmetic” rather than design flaws, I still had hope.
Although I saw no action on the ideas I had suggested on the suggestion board, I still had hope.
I lost hope when the justification for not fixing a bug was, “that will break existing games!” That one moment revealed a deep-seated resistance to consistency, and then I knew that the gig was up.
What Inform 7 is, in the end, is nothing more than a petulant toy that bears the imprint of all the idiosyncrasies of its designers. It is not serious; it will not be serious; it cannot be a world-class language. It is, and forever will be, just another oddity. That this is a shame goes without saying, but it is a shame because the designers of the language refuse to commit to principles of design.
Conditions After Periods Equal New Lines!
Yet another bad design decision, courtesy of the modern artists over at I7:
You are one ugly dude. [if DirtyHands is true] Your hands are dirty.[end if][if WetHands is true] Your hands still smell like pomegranate.[end if][if BathCat is true]Your hands are scarred due to misadventures in cat-bathing.[end if]
Instead of one status paragraph, the above code produces one paragraph for each condition that is true. This doesn’t make sense, as nothing in the paragraph clues you in that the language will behave like this. I filed a bug on this and it was rejected because “It’s been that way since the beginning.”
It doesn’t matter what GAMES will be broken; it matters whether this makes the LANGUAGE more consistent, more English-like, and easier to learn. How many revisions of Inform have broken games, anyways? Just about every other one, right? Yet this won’t be fixed. *facepalm*
Inform 7 itself has become a grande example of how NOT to design a language; either you live up to your goal of making code that reads like English, or you design yet another halfbreed language that requires users to learn specifics instead of principles. This all feels like I voted for “hope and change” and got $4.00/gal for gas, 10% unemployment, a crushing debt, union violence, and my health care in the hands of government.
Anyways, this is a bad decision because:
- The functionality is invisible. Nothing in the code informs the author that a line break is included after each sentence.
- The functionality is illogical. Why does a period indicate a new paragraph? It doesn’t in English, and yet Inform 7 claims to generate code that reads like English.
- The workaround makes no sense. The answer is to put a period in the next part of the condition instead of the first part, yet why would anyone naturally do that? It’s silly to have to break up complete sentences because the Inform 7 preprocessor will automatically throw in line breaks if you don’t! Again, the author is forced to know the particularities of the preprocessor in order to write the game. So much for that Natural Language Programming thing, I guess.
Again, Inform 7 is like natural language, only when it isn’t. I can’t wait to get done with New Cat so that I can turn my back on this mess once and for all.
Consistency (Case of the Missing A)
One of the things that bothers me about Inform 7 is that it’s woefully inconsistent. This makes learning the language hard, and harder than it needs to be. If the prospective programmer/author can’t learn general principles, then he has to learn a sea of specifics. Which of the two leaves him better able to master the language? For certain, it is not the latter. The latter is a brittle system that leaves the learner timid, uncertain, and unwilling to go beyond what he has learned, because all he knows are a set of specifics which do not make much sense together. In the former case, the learner is encouraged and supported in his creativity by the language itself. The former case is like giving someone wings; the latter is like surrounding them with an army of kobolds, which bang them on the toes every time they step outside of the circle.
Now, here’s a specific case of I7 inconsistency:
Say “You jump artfully to the floor and land on all four paws.”;
Now elevation of player is 0 feet;
Move player to location, without printing room description;
This fails to compile, of course, because the last line omits the article “a” before “room description.” I kid you not. This is inconsistent, not only with objects (which can easily be created without an “a” or “the” at all), but it’s maddening from a learnability perspective, senseless from a linguistic perspective, and it’s schoolmarmish and lazy from a coding perspective. The code here was not written with the linguistic sensitivity that I7 claims; it was written to find THAT EXACT PHRASE. The article can safely be omitted without compromising the understanding of the sentence. There is no need for the parser to look for a phrase that includes the article and doing so feels like a ruler rap across your knuckles.
More Bad Design Decisions (Named Actions)
I7 strikes again.
Instead of doing anything except kwhirling’ (source text, line 1795), which seems to introduce a rule taking effect only if the action is ‘doing anything except kwhirling’. But that did not make sense as a description of an action. This looks like a list of actions to avoid: ‘kwhirling’ only made sense as a named kind of action, which can be used on its own but not in an action list; so I am unable to place this rule into any rulebook.
This code will produce the above error:
Smelling the tree is kwhirling.
Climbing the tree is kwhirling.Instead of doing anything except kwhirling:
The problem here is yet another bad design decision, specifically, inconsistent design. All actions can be placed in an action list except named actions, which forces the user to remember that there are multiple kinds of actions and furthermore, to remember that some can be used in some places, and others in other places.
Sigh. The I7 designers really need to learn a thing or two about being consistent.
