Dialog vs. Inform 7

Authoring Dialog
1

I thought I’d share a few more thoughts on comparing Inform to Dialog, from the lens of converting existing Inform projects (first Sand-dancer, now my newer work).

First of all, I think it is fair to say that Inform is chock-full of features that aren’t present in Dialog. There are concise ways to have Inform track player events over time (check player taking the cookie the third time: ...); there’s a built-in scene system, there’s (if memory serves) a way to specify the tense (e.g., switch to first person instead of the default second person), there’s the Skein, and map generation, and documentation generation, there’s … well, just so much stuff.

But even after years of working with Inform, I had trouble getting things phrased just right, or even figuring out where to tease out of its massive export of library and game information just the right wording I need. Inform is a whole collection of different grammars (or domain specific languages) … for instance, the DSL embedded in say strings supports a some conditional logic, but it isn’t quite the same way conditionals occur outside of say strings.

Also, Inform can get confusing (perhaps, more so, for an experienced coder) in the distinction between names and other words intended for the compiler, and names and other words intended for the player to enter as commands.

Dialog is just one single grammar, and that’s such a relief. You can easily integrate
text, conditional logic, updates to the world model, or anything else, all in a single block.

There’s also a lot of complexity in how Inform decides which rule applies at which point, along with rulebooks and meta rules about rulebooks to provide various overrides; Dialog has a very simple rule here, defined by the language itself: order in the source. There’s never a doubt about ordering, though you sometimes have to be careful in the order of rules in your source.

That ethic: simple, transparent rules, based on the simplicity of the core language, extends throughout Dialog. When I have problem, I can often just do a search in the standard library’s source and get an answer quickly (if it isn’t obvious from the documentation).

For all that Inform can be more concise, I’m not seeing almost any difference in word count between my Inform and Dialog versions.

Beyond all that, the existence of the Dialog debugger, and its live code reloading capability, makes it far more productive than Inform. I see a typo or mistake, update the source, @g and see the fix immediately. That power can’t be overstated.

Other Dialog features I love:

  • I can organize my code as many small files instead of a single giant document
  • The compiler is blindingly fast
  • The debugger starts almost instantly
  • Documentation organized so I can find what I need quickly
  • Compact bytecode output, especially for aamachine
14 Likes
2

This is an interesting comparison, but you should really change the title to ‘Dialog vs Inform 7’, as Inform 6 is quite a different language that doesn’t have some of those disadvantages you mentioned with Inform 7.

4 Likes
3

I’ll give you can example of why Dialog’s uniformity is cool.

In my Inform7 code, I had something to the effect of:

after looking in Special Room the first time:
  say "Go you!";
  increase the score by one.

Now, I could have a global flag to see if we’ve performed the [look] action while in the Special Room, but instead, we can use (select) to handle that:

(after [look])
  (current room #special-room)
  (select)
    Go you!
    (increase score by 1)
  (or) (stopping)

This lets Dialog deal with the flag (or counter) used to ensure you only get the special score once.

The point is, although (select) appears to be used only for varying text, because of Dialog’s structure, it can be used for other things as well. This applies to many other features of Dialog.

4 Likes
4

You are a gifted programmer.

2 Likes
5

To be fair you can easily put phrases to change the score etc inside of the "[one of]...[or]...[stopping]" I7 phrase too.

There’s also this trick that lets you put any arbitrary phrase into a say phrase (without it you’d need to make a new to say increment the score phrase):

To say perform/@ (ph - phrase): (- if (0==0) {ph} -).

So the above can be converted to the following I7 code:

After looking in Special Room:
    say "[one of]Go you![@ increase the score by one][or][stopping]".

However the performance is slightly better if you do after looking in Special Room the first time because then it can skip invoking the rule. But it’s not likely to be a noticeable performance difference.

Now maybe Inform 7 could be changed to allow you to simply run phrases in text without needing the @ trick. I’m not sure what the implications of that would be, whether it would be sufficiently type-safe etc.

6

I think what’s being pointed out is, I7 has very different syntax inside text vs outside, whereas Dialog has no distinction between them. Inform has built-in “…for the first time” rule headings and “[first time] [only]” substitutions, but the two look—and function—quite differently; Dialog uses the same construction for both.

(You of course can put all your I7 routines inside text, but it’s not what the language is designed for so some parts get rather awkward.)

7

Can you use (select) to choose between numbers, objects, etc? I only saw text examples in the manual.

Maybe the biggest difference between Dialog and Inform 7 is that Dialog assumes a predicate will output text, but Inform 7 doesn’t assume a phrase will do so, which makes all Dialog predicates act like I7 text substitutions. Is that accurate?

Moving towards more uniformity in I7 would be a worthy goal for the future. Maybe once it’s open sourced.

8

I’m not sure I’d say it’s an assumption of the systems—after all, a lot of I7 phrases output text, and a lot of Dialog predicates don’t.

But “all of Dialog acts like I7 text substitutions” seems accurate to me. Anything not in brackets (I7)/parentheses (Dialog) is printed to the screen; things in brackets/parentheses control flow and side effects, such as if/then/endif and one of/or/stopping.

2 Likes
9

Also a fair point, but I’d counter that I7 benefits from the lack of uniformity. The different syntax inside and outside text (and the subtly different syntax in topic/understand lines, etc) is annoying for newcomers to learn, but it makes I7 source code easier to read—and I’ve always thought of that as the overall design goal of I7, making the code as easy to read as possible (even if it’s not necessarily easy to write).

Anecdotally, when looking back at old code I’ve written, I find it easier to grok code written in I7 than any other language. Which is a nice feature, even if it comes at the cost of idiosyncratic and inconsistent syntax.

3 Likes
10

There is one more piece of this puzzle: Dialog treats all text as sequences of words and punctuation, which it can print by inserting whitespace in the proper places. Therefore, text in the source code can flow freely across lines (and across the boundaries of e.g. “if” and “select” statements), and there’s no risk of duplicate or missing space or linefeed characters. In contrast, Inform 7 treats text as strings, i.e. sequences of characters, including whitespace. Therefore, text in the source code must be delimited by quotes, and embedded logic cannot easily be reformatted across multiple lines.

It sounds like a small difference, but I think it’s absolutely necessary for interleaving prose and logic in the same language.

6 Likes
11

Dialogs text formatting is a joy compared to others. It “just works”. I spent zero time fiddling around with spaces. And line breaks and paragraph breaks are very explicit and in your complete control.

2 Likes
12

(congratulations to @paulseawa on being the first non-lft person to publish a complete original work in Dialog)

4 Likes
13

Thanks. I’m honestly surprised I’m the first.