You’re right; I meant declarative, not descriptive. I appreciate the correction. It’s good to have clearly defined terms…
From Wikipedia: “In computer science, declarative programming is a programming paradigm—a style of building the structure and elements of computer programs—that expresses the logic of a computation without describing its control flow.”
Despite it’s use of verbs, SQL is widely considered declarative, not procedural. Just ask Google. Each statement describes what is to be done and then the SQL engine does that. The flow control (looping, etc.) is completely under the covers. The statements are relatively high level, almost English-like, and feel quite foreign if you are coming from a purely procedural background.
What I meant in my prior post was that the flow control elements borrowed from procedural programming ruin some of the magic of Inform 7 for me. It feels like they were added to placate some of the naysayers who disagreed with a purely declarative language or perhaps they were added just to make sure that things that hadn’t been thought of yet were possible.
It’s a reasonable compromise, but I feel like anytime you have to reach for flow control structures (think while loop for example) it indicates a hole in the declarative part of Inform that deserves to be revisited and filled in with new kinds of statements.
The more that Inform reads like English, the better, and low level flow control statements break the effect of code reading like a novel.
Why? What exactly do I get for that, aside from the headache of playing guess-the-verb with the compiler and writing something unnecessarily verbose? I don’t see any advantage in clarity or efficiency in having to write I7 code like (to take an example from an earlier game of mine):
To decide whether the poker game is active:
if the poker game status is game over:
no;
else:
yes;
(And why doesn’t I7 just use the standard ‘boolean’ or the equivalent, instead of insisting on “truth state”?) If Inform is supposed to be English, it has an unfortunate tendency for forcing things like (from the same game):
Instead of talking generally to:
try answering the noun that "hello".
which is the kind of English they speak in the uncanny valley.
Inform isn’t English, and I write Inform code and English text for completely different reasons and in completely different contexts. The code of a game is not a novel; it doesn’t make any sense to read it as a novel; and its audience is usually just the few people who wrote it. I7’s attempts to pretend to be English aren’t a virtue.
That’s the big thing I was trying to emphasize at the start. Inform’s biggest advantage isn’t that it’s easier to write. English syntax isn’t any easier to write than C++ syntax or Python syntax.
But it’s a whole lot easier to read, because as English-speakers our brains are tuned for skimming English text and finding the important parts very quickly.
Even if the audience is only the same people who wrote the code, your average line of code is read many more times than it’s written. When you come back to a project years later, Inform’s syntax is designed to tap into our English-skimming skills and make it easier to get a quick grasp of what’s doing what. If I pull up a paragraph of Inform code I wrote a decade ago:
After going from a mystical room (called the place):
if the elemental symbol of the place is off-stage:
say "As you leave, [the elemental symbol of the place] reappears in your hand.";
move the elemental symbol of the place to the player;
continue the action.
It’s much faster for me to skim this paragraph than a piece of C++ code I wrote a decade ago. Which means it takes me less time to find the bit of code I need to change.
The whole point of code is to emphasize the important parts and strip out all the boilerplate and verbiage. For example, this bit of I7 code (from the same example):
To decide whether the speech manner is correct:
let x be entry 1 from the speech queue;
if x is held by the speechwriter:
yes;
otherwise:
no.
is not an improvement in readability over this vaguely-C++ pseudocode:
bool correctSpeechManner?() {
return (speech_queue[0] in speechwriter);
}
Just let me write “int x” instead of “x is a number that varies,” and “x = queue[0]” rather than “let x be entry 1 from queue.” All the extra prose doesn’t accomplish anything. I’m all for legible code is any language, but I7 tries too hard to be readable as English, and it often behaves in the way that the English-skimming part of my brain wouldn’t expect. For example:
Me: There is a dragon named Spot in the dungeon.
English speaker: There is a dragon. Its name is “Spot,” and it’s in the dungeon.
Inform: There is a dragon named “Spot in the dungeon.” I’m going to stick it off-stage somewhere.
Yeah, that’s the thing, the syntax is every bit as unforgiving as C++. That’s what I mean about it not being easier to write: it wants “in the dungeon is a dragon called Spot” and will misinterpret the reverse just like if you typed =+ 5 (set to positive 5) instead of += 5 (increment by 5).
This is also why I think that marketing Inform as easy to write is misleading. You still have to learn the syntax.
Personally, I find the natural-language syntax much easier to skim than code in other languages. But to each their own.
For me, the biggest benefit of Inform is an entirely personal one: I tend to write code that flows in natural sentences better, and that leads me to use variable names and functions that have descriptive and useful names. So when I go back and read the code, it’s easier to see what my intentions were.
So I don’t think Inform is any easier to write with at all, but for my personal style of coding, it is far easier to debug and re-read.
Depends. If you have a US QWERTY keyboard, no. If you have basically any other keyboard that needs to make space for more letters (e.g., ÄÖÜ), then yes, I7 syntax is easier to type than C++ because all the []{}<>\ special characters will have been relegated to awkward tertiary key functions.
The first thing you need to understand about Inform is that some people will like, benefit from, enjoy and/or agree with its approach to literate coding. And some will not. And these two groups are unlikely to shift their positions much through discussion.
In part because they are debating from a perspective that is personal to them and may not apply in the same way to others. And, perhaps more importantly, because neither side of the debate is objectively correct, and neither therefore can conclusively prove its position.
Self-documenting code that is genuinely fun to read
Encapsulation of low level details
Less intimidating to folks with little to no experience coding
Reduced cognitive load from code-switching between English for the narrative bits and a programming language for the procedural bits.
I think the last one is pretty major, which is why I don’t like the more procedural parts of Inform and wish they could be replaced with more declarative counterparts.
This is not to say that Inform is the end all and be all of IF platforms. I think it takes the book metaphor too far. Books are linear. IF is not. There is a reason that Twine is so popular with its network diagramming.
The ideal IF system would combine the natural language aspects of Inform with the networking aspects of Twine. I’m working on a JavaScript API for IF with these ideas in mind. I’m about 80% there. Whether it will be a meaningful contribution to IF remains to be seen, but I’ve enjoyed the opportunity to think about these issues deeply.
Huh. I had always thought it was considered procedural since its lines were executed in sequence, as compared to HTML which has no time element. Learn something new every day.
For the former, I’d argue Twine is so popular because there’s a bigger audience for choice-based IF than for parser.
For the latter, that sounds more like a choice-based system using natural language scripting than a parser system using a branching-style interface. Parser IF is not, in general, branching in the sense that Twine games are.
Other people can use whatever language they want, but as for why I personally should care about Inform, none of the elements in that list are things I care about. I’m all for readable code, but considering I7 literally self-documenting given some of the twists it puts the writer through (and the lack of useful documentation) is a stretch. I’m not sure what specfiic low-level details you’re referring to, but I’ve never run into serious issues there with I6 (as much as I like, say, the rule-based system in I7); or, at least, the low-level hacks I have to get into in I6 still require hacking in I6 code in I7. I have a lot of experience coding; and frankly, the time spent by someone completely new to coding in learning a language as eclectic and domain-specific as Inform would probably be better spent learning a more standard or generally applicable language. I’ve never run into any issue with the code-switching; besides, I don’t have the same approach to merging narrative and procedural stuff that I7 assumes that every writer has or should have.
Anyway, my original point was that using I7 requires buying into a particular idea about how IF games should be designed and written. It would be nice if there were alternatives, but there’s barely room for one set of tools in the area, given the size of the pool of people interested in writing IF. I think that interactive fiction already has a problem with people insisting that there’s a One True Way of doing it, and I7’s reinforcing that doesn’t help. But that’s getting into a discussion for another thread.
I think the nuance often missing from this debate is that procedural and declarative are relative descriptions of directions on a continuum rather than binary characteristics of a programming language.
Jean Luc Picard’s ‘Make it so’ would be the epitome of declarative style, whereas at the imperative/procedural end of the scale might be a join-the-dots puzzle, whose strictly-defined sequence of steps produce an outcome related only in the most oblique way to any purpose evident in the steps themselves.
Computer programs inevitably fall somewhere between these extremes, but the higher level the language, the more declarative the written code is likely to be, with more imperative processing hidden under the hood and taken care of by compilers, algorithms, state machines, abstraction layers and the like. In this sense, hand-assembled binary machine code is likely to be the most procedural programming style of all. And SQL is more procedural than HTML, but both are toward the declarative end of the spectrum.
I mean, TADS still exists, with a more traditional programming syntax. Or ZIL, if you’re into LISP (though it’s really only the syntax, the underlying structure isn’t very LISP-like…does still have macros at least), or Dialog, if you’re into Prolog.
I still do most of my IF work in Inform, but Dialog might be the most beautifully and elegantly-designed programming language I’ve seen. (But it still has a significant learning curve if you’re coming from C or Python, since you have to get used to not only its syntax but the whole idea of “predicates” and what they can do.)
Depends on how you think about it. I think the two are more similar than they appear on the surface. If you think of an IF system as an operating system, then choice IF uses a menu system and parser IF uses a command line. Either way you are navigating an operating system.
Anyhow that’s the main idea for the hybrid system I’m building. Commands are commands. Doesn’t matter how they’re entered. Click, drag/drop, key-- it’s all good.
Also, it’s less natural language and more fluent interface, but the goal of code legibility is maintained. Writing in an IF system should be fun and intuitive.
I realize new systems have very little chance of succeeding, but these ideas are interesting to me for their own sake and I want to see what I can do with them.
(And no, you weren’t being snotty. Terminology is important.)
A key difference, though, is that parser IF is generally built around a world model, which is if I understand correctly, difficult in Twine and similar systems.
Interestingly, that’s about as much of a world model as the Scott Adams system had: a big pile of boolean flags and a counter that can go up or down. The one thing it had that Twine didn’t was the concept of “objects” which each have a name and a location (and nothing else). Any state beyond the location of an object had to be a flag or a value of the counter.