Why Is Learning I7 So Difficult?
Learning a new programming language is not that hard, once you know a few; however, when you try to learn a new programming language that declares itself some kind of Natural Language authoring language, you might expect a little more trouble than usual.
Inform 7 in this capacity does not disappoint. It is throughly a design decision to allow one sentence order (“Now the steak sauce is boiling”) and not the other (“The steak sauce is now boiling”). Parsers are smart enough to figure it out, and yes, I have worked on designing parsers, so that is not some cheap and easy statement. So your first hurdle is struggling through these decisions and conforming your mind to the arbitrariness of the designers; good languages keep these sorts of arbitrary decision points as few as possible by allowing for multiple ways of doing the same thing (C and PERL are excellent examples of this). Without that sort of expressiveness, the language becomes a brittle construct, as friendly and as sensible as a senile schoolmarm.
Yet even an avante-garde language is possible to learn with the proper support and design. That is precisely where Inform 7 stumbles. By support, I mean help and/or manuals; by design, I mean support the language itself gives to the author (editing tools, error messages). If one side is insufficient, you can rely upon the other to shore up your understanding. What if both are weak?
The Inform 7 docs we have covered previously; but the error messages generated by the I7 preprocessor are as unhelpful as the documentation. This leaves most folks to crawl the various IF watering holes looking for answers. Of the two, the error messages are probably more egregious, as you can’t rely upon people to read the documentation. (That is the sad and sorry truth.) However, you can bet your bippy that they’ll read those error messages. They’ll not only read them, but re-read them, and scream them aloud at 2 AM. In short, those error messages had better be helpful.
In Inform 7, you encounter three bad types of error messages:
- The schizophrenic. This is an error message that has nothing at all to do with what made the code break, but reflects a confusion on the preprocessor’s part. Example: If within a rule you have two statements both ended by periods, the compiler gives you an error complaining about brackets, even though you have no brackets in the code. You have no idea how to fix the code, but you know that what the compiler said is wrong.
- The prolix. When something breaks, the last thing in the world you want is a prolix professor explaining to you the nature of the Shapir-Worf hypothesis. You want to know, tersely, what is wrong, so that you can fix it ASAP. That’s the nature of human frustration talking; however, on the off chance this is a gender preference, perhaps I7 could have a /female_off flag that allowed spartan error messages. The information you need to fix the code is buried down in this mess of words, somewhere, but it’s time-consuming to extricate the meaning.
- The bad advisor. Occasionally, I7 will suggest a course of action that is wrong. There are few sorts of rage less pleasant than that of a programmer who realizes he has been set up by a bogus error message. Take this for example:
Problem. In the sentence ‘if (the turn_count >= halftime) begin’ , I was expecting to read a condition, but instead found some text that I couldn’t understand – ‘(the turn_count >= halftime)’.
I was trying to match this phrase:if (( the turn_count >= halftime ) – a condition):
This was what I found out:(the turn_count >= halftime) = something unrecognised
Not only is that unhelpful, but if you try to please the parser by putting parenthesis around the statement, you’ll find the same error message staring you in the face, only nested one level further down in parenthesis, and on it goes.
There are now more than a few issues in the I7 bug tracking tool on error messages, so the problem is finally being addressed (three years after release). I am concerned that many were complacent for so long about things that made the language hard to learn.
Inform 7 presents a sort of Bermuda triangle to those approaching its mysteries, a three-pointed figure of confusion and despair: lack of expressiveness, insufficient documentation, and unhelpful error messages, are what makes learning Inform 7 difficult. These are easily remediable with virtually no effect upon the design of the language itself. Sadly, the opportunities the language has lost because of inattention to these issues are incalculable.
New Cat: Almost Alpha
The end of the main effort is in sight. I’m tagging things in the code with a “get back to this” note, as the scaffolding that needs to be filled in by brick and mortar. Soon, I will be alpha testing, and I’m still on track to present New Cat as a glorious Christmas present for anyone who likes literary, feline-oriented, interactive fiction games.
New Cat will strike a balance between Building and Zegrothenus, in the sense that it’s atmospheric, but the puzzles aren’t hard. The puzzles are present, and there are some red herrings, but they shouldn’t be anything that makes you want to cry, scream, or throw things at your monitor. Will I do a hint guide? Probably not. I might do a free feelie that consists of the map, some artwork, and notes on the game. I don’t think the puzzles are hard enough to command a price for a hint guide.
Congratulations to the Old Ones
Yes, I mean that in all open-hearted sincerity. The Inform 7 Suggestions and the Inform 7 Bug Tracker are not only useful, and not only encourage people to contribute, but mark a real step in the right direction, as far as openness goes. Does this herald a new dawn of actual communication, of lowered drawbridges, and a fundamental paradigm shift? Not likely, but the fact that these things are in daily use, are used for their intended purpose (despite the trollery of some aside), and actually result in improvements to the product, do say that the light is beginning to dawn. As a side note, I realize that I am late to the party; however, these tools were not orphaned, but seem to becoming more popular. That is an even more encouraging sign.
Not Alone
I never would have thought I’d have support from someone whose game workshop I quit, but today, I stumbled across this. It seems that someone was mightily ticked off at the beta-ness of I7, and it took pages and pages of explanation to answer his questions. Then, the answerer admits that her experience with English is non-normative. Oh dear. 
He goes on to accuse the makers of I7 of design hubris. Funny, I’ve felt the same way. Anyhow, it’s nice to realize, every once in a while, that I’m not alone out here. Although this post comes nearly a year after the newsgroup posting, my feelings are exactly the same. I7 is beta. There are major bugs that require a lot of sly programming to get around.
Mistakes I’ve Made a Few…
Still, in looking at the number of I7 issues I’ve reported, I feel like I’ve done a lot more good than harm. So far, my stats are:
- 6 closed items
- 8 verified mild/cosmetic items
- 1 resolved mild item
- 1 resolved critical item
So my miss ratio (assuming that all items closed are justifiably closed) is 6/16, or 37%. My hit ratio is 63%.
