Though I'd like to write a tutorial for writing AIF with I7, this starts off as sort of an essay/rant that only relates peripherally to AIF, so bear with me.
Why I Use Inform 7
Inform 7 is a programming system that uses natural language. You can download Inform 7 here.
I've always liked programming but I've never been particularly good at it. I7 is the only programming language I've mastered to a degree (that is, I'm better than the majority of its users, but not quite as good as those people who really get dirty into I6). When I reflect on why, I think it's partly because I'm a language oriented person. Some people can look at E=MC^2 and think, "Oh, energy and matter are the same thing how interesting." Others, like me, need to be illustrated with lavishly complex examples before it "clicks". It's not because I'm less smart (at least, I hope so), but it simply needs to be spelled out for me: "The amount of energy in the universe is equal to the mass of the universe times the speed of light squared." Oh, right.
So, basically, Inform 7 allows me the use of the verbal part of my noggin, because my math side is shriveled and decaying.
Me Whining
It is a general complaint of mine, then, that tutorials about programming aimed at non-programmers rarely actually explain the "logic" of the language. Yes, you are taught to do simple, rather uninteresting tasks that bore you to death, but no one ever explains how things are supposed to fit together. This is what makes TADS tedious to learn, after going through the same tutorial over and over again, learning how to do stuff but never really know the why or how of it. That's why I still can't wrap my head around ADRIFT 5, because the documentation tells me what tasks are and how to use them but not really what a task-oriented approach is.
The Inform 7 documentation, truth be told, is not much better. It took a long time for me to finally "crack" I7, and the day I did, I exclaimed, "Oh! It's just a checklist!" What is a rule-oriented language? It's a language that uses a "checklist" to figure stuff out. An object-oriented language is similar but instead of a checklist it uses labels stuck on the object itself. As soon as I learned this, I became much, much more competent at I7.
In this respect, it seems odd that you'd put something so crucial so far from the front of your documentation. A quick browse through the documentation that the first mention of rules are in section 2.2, but the subject isn't revisited until Chapter 7, and only explained in depth in Chapter 18. As beginner, I never got the sense of how important and flexible rulebooks were and the sort of role they should play. It's easy to become focused on object properties, which I7 frankly handles very inefficiently, compared to rulebooks, which it handles very well. It certainly explains why so many veteran programmers happen to do things "wrong" from my perspective, using lots of memory-intensive properties and relations when a rulebook would do the job better.
The Logic of Inform 7
Everything in I7 boils down to rules. I7 is amazingly efficient at handling rules and not so efficient at handling "things", something TADS is better at. Squeezing performance out of I7 is an exercise in making the best use of rules. Rules rules rules. Rules, dammit, rules.
What is a rule? Unless you skipped the first section (don't blame you) an individual rule is basically a checkbox. A lot of rules are essentially a checklist, we call these checklists "rulebooks".
Imagine before you did anything you consulted a checklist. We are trying to put toast in a toaster. The first check (or rule) might be: do we have the toast? If we don't, we need to pick it up. The second check asks whether we took of the toaster out of its box, the third checks to see if we bothered to plug it in, and so on.
But I7 isn't just a checklist, it's a checklist made from other checklists, with each checklist covering a different aspect of what we want to do. One checklist tells us whether we can do what we want to do. Another checklist tells us how to do it. Another tells us what we should do after. And not only that, the checklists communicate with each other. One checklist can stop another. A checklist can consult another checklist. And on and on.
Let's advance our example into jumping. If we were designing a checklist for jumping, what might it look like?
Is jumping right now logical?
-- Is there space above me?
-- Do I have legs to jump with?
-- Am I standing on a solid surface?
If it is logical, how do I jump?
-- Bend your knees.
-- Push your feet against the ground in a springing action.
-- Allow gravity to pull you back to Earth.
We can think of the underlined components as rulebooks, and each nested component as an individual rule within that rulebook. The first rulebook asks whether we can jump. The second rulebook asks: if I can jump, how do I do that? We can surmise that if the first checklist fails, the second checklist won't even be considered. This is a very important and powerful tool in I7.
The order of the second rulebook is critically important, whereas for the first rulebook it matters little. If we let gravity pull us down first, we'd then jump and never get back on the ground. This is why we divide our rules like this, because while the content of the rules are the exact same the behavior would get all muddled without being organized into rulebooks.
But the true strength of Inform 7 rule system is that we can add new rules. As our world model gets more complicated, we can add new rulebooks, and put rulebooks in our rulebooks, all to decide what happens. For example, let say our world was host to a variety of awful pestilences and nasty things to land on, we can have a checklist like this:
Is jumping right now logical?
-- Is there space above me?
-- Do I have legs to jump with?
-- Am I standing on a solid surface?
-- Do I suffer from (if so, stop):
-- osteoporosis?
-- a spinal injury?
-- Lou Gehrig's Disease?
If it is logical, how do I jump?
-- Bend your knees.
-- Push your feet against the ground in a springing action.
-- Allow gravity to pull you back to Earth.
What are the consequences if I land on:
-- spikes? Severe injury.
-- cushions? No injury.
-- kittens? Severe allergy.
There are a lot of checklists in I7, all consulted for different reasons, though the six most authors will be concerned with are the following:
Before -- What should I do before I even start thinking about jumping?
Instead -- Is there anything that would stop me jumping, or a special circumstance that would cause me to jump in a special way? If so, stop.
Check -- Is it logical for me to jump? If it isn't, stop.
Carry out -- What steps do I take when I jump?
After -- Is there anything special I should after I jump? Perhaps a consequence for jumping in a special circumstance? If so, stop.
Report -- What should I tell you if you jump but nothing interesting happens?
Next time: the anatomy of a rule.
No comments:
Post a Comment