DISCLAIMER: This is going to be perceived as a critic of I7 (it is in part), because it is something NEW and DIFFERENT, which is quite GOOD so: I find I7 EXTREMELY interesting and a joy to experiment with (it´s been more than a decade since I were involved in IF and I´m coming back just because of I7). Also, I´m probably going to contradict myself multiple times ... I may even agree with what I write :) I only dissect things I really like, what I do not, I just ignore ;) .
This post is based on a discussion on rec.arts.interactive-fiction in March 08 about some writers choosing TADS instead of Inform 7 for a course.
- I find the whole IF (including Graphic Adv) to be conceptually OO to the core. What attracted me to it was all the model/simulation aspects of it (in the broadest sense possible ...).
- I do not think an IF writer (vs modeler or developer or library creator) must be interested in the internal mechanisms by which his definitions get finally executed in minute detail.
I find Inform to be a lot more difficult to explain than other, less tied systems, like advsys (to put a lispy-oo example). Likewise, internally SCUMMVM is surely much more complex than Wintermute ... To grok Inform you may have to grok VMs, partially the historical development of ZIP, Inform 6, how Inform 7 notation gets translated into I6 (law of leaky abstractions of sw).
- I detect a (partial) rejection of I7 based on its GUI ( writers are used to simpler editors or word processors, idea processors or even script tools) and pure text is their core competency. It is even fashionable to consider TUIs as superior (just more expressive in exchange for being more opaque). It takes time to master an IDE, but it is not worth the fuss for just a few weeks of use. The UI is the SW.
- Another dissonance may be with presenting a uniform pseudo NL for all parts of the work. I think some writers may feel I7 syntax is a bit of a transvestite ... It is hard to modularize rule sets without experience, guidance. With a pure OO model you just look for responsibilities (responsible object).
Most of us devs, can look at I7 source for rules and mentally translate to Horn clauses or whatever formalism suits us best, but probably a writer with no formal training on math cannot. And some may be getting the message: hey you are not good at your core competency. I do not find the current form of rules in I7 (I'm just starting using them) to be the best representation. I find the NL approach to describe the object relations, static structure, containtment hierachies ... superb.
- Procedural code/stateful programming is EASY to grasp, specially if given in small doses (just the part of the algorithm I am concerned about, the one that this method of this object has to deal with ...). Flags and simple vars have always been part of (almost) any IF tool.
- Otoh, Event programming (concurrency too) is hard to grasp, and most notations/practices suck for this (actors being one of the best, and actors are OO to the core). A simple REPL loop is easy to master (user input-system response) but when you have cascading triggers and reactions: not well modularized rules are hard, even objects without scenarios/collaborations are hard, but you can always fall back on to an object structure/class inheritance tree with responsibilities. Multiple hooks require you to know the whole algorithm the framework follows to some depth (hiding the alg does not help at all). We are very bad at following the execution path so rule systems seem to
- Declarative prog is harder to grasp: you have to be a good modeler, you have to be good with complex logical expressions and transformations and you have to be able to relinquish control (when, where, how is this exactly going to be fired, executed or even implemented, have I covered all cases? ....). Hell (sorry), the whole "professional" sw scenario is an example of letting declarative prog enter little by little (from configuration, to containers, to business rules, to object creation, to initialization of complex structures...). Anyone with enough experience developing knows that more declarative code is the way to go but it takes a lot of time to accept/embrace it, at least to those with a deep procedural background (most?) ...
I7 is still too new, there seems to be missing yet good examples and collective experience in it strong points and faults. I sense leaky abstractions there ...
But choosing is fearsome specially if you do not have enough experience to evaluate and I7 seems to make a point of being minimal (less in the core, more libraries) and letting you choose more. This is GOOD for flexibility but to beginners it can be bane ! Too much can also be daunting (but I have no experience with TADS libraries) The JDK is a monster but beginners love they have it there and can selectively pick up things (they usually implement things that are there already or search for things so particular that really have no place in a SDK .... but sometimes they are there too!).
I7 strings or formatting/printing facilities are a bit cumbersome (all that you cannot write ", ...) and maybe underpowered. Why not use escapes and references? Strings should be one of the most powerful abstractions in an IF language. This surprises me as I though Graham would have done this (I had him for a quite perly guy). Even the NL references (pronouns) I feel are underpowered (cumbersome).
Also, in i7, not having some sort of mixins, traits, multiple inheritance, interfaces or the like makes a OO implementation conceptually crippled (though simpler typewise). Not that you cannot find a way to simulate-implement this but this should be at the language level (perhaps in I8?).
- You usually start implementing (your firsts) IF works by creating objects (definitions, declarations, rows, structures) and then adding (code) snippets for special functionality. IF presents a TUI that consists of "verb with objects" commands, and rather than create some sort of cascading switch in verbs (the easy route) you'd rather put code in the objects. This is object based "prototype" programming.
Rules, as has been said (Plotkin even has shown it can be rules all to the bottom), are more flexible and can go from the "use level" (global switches) to the minimal and most specific event in the most special situation but you are forcing me to think ahead (and not about what I naively may think is the important part). By the way (sorry we all OO heads have to say this), rules are objects too ...
Even the IF practice shows it is easier to exchange objects behind the scenes than to transform them radically. (Non) likewise it is many times simpler/safer to copy and modify than to refer to the same shared data ... It is safer to always declare functions and internally use whatever is best (constants, variables).
In the end I think this boils down to: It is easier to objectify than to abstract. It can be objects all the way down, rules all the way down or in between (probably the best but you are forcing me to think ...) ... give me patterns, give me guidance, give me the ten testaments, when I do not need them I´ll break them, don´t worry ...
PD: Inform is in better shape than ever, the GUI is an ELEGANT piece of sw, I feel I will not need to delve deep into the generated files or I6 except in very special cases and it may be a good declarative frontend (perhaps with a little bit more of punctuation or structure) to other backends, VMs ...
