Inform 7 and the Three Brains
ChicagoDave
commented either seriously or snarkily in many. One of the popular
discussions, in various forms, has been what Inform 7 does that other
things have not done or how does it do things differently.
My immediate reaction to Inform 7 was quite positive and I thought at
first this was because it "seemed" like the perfect way to do
Interactive Fiction. For me it has been an enormous lightning rod to
more IF productivity. I'm working on a sizable game (80 rooms, 8
regions, 10 NPC's) and things are going so fast I have to keep a
checklist of stuff that I can work on at any given moment.
Of course my reaction has not been the only one. There have been
negative reactions, indifferent reactions, angry reactions, amazed
reactions, and so on and so forth.
But then many people started using it and asking questions and finding
problems not only of the bug variety, but also of the implementation
variety.
I started thinking why feel so comfortable and productive with it and
others don't. Why?
Then I thought of the three brains. The idea is that all of us "attack"
an IF problem in generally different and similar ways. Similar in the
sense that we all have to write _some_ code and a lot of descriptive
language. How are we all different though?
The three brains.
It's my theory that some of us have a solid balance of language
construction and programming logic and are able to tackle nearly any IF
problem with the available tools. This means these people could
probably use DOS batch files and probably still create a sensible and
interesting IF game. Given Inform 6, TADS 123, or Hugo, these people
are highly efficient IF authors.
These people are what I call the conduit brains. They go back and forth
easily between programming logic and descriptive language without much
stress. How about a diagram?
-------------------------------------------
Writing Stuff Programming
Stuff
-------------------------------------------
I am not one of these people. I do not have that wide open space
between coding my IF stuff and delving into the story. I just don't
function that way.
I am a left funnel brain. Another diagram please!
---------------------\
Writing Stuff ========== Programming Stuff
---------------------/
When I develop an IF game it is _always_ from a story perspective
first, middlest, and last. I am hardly ever thinking "how do I code
this in OO objects?" or "what code do I need to implement all of these
story elements?" I am always always always writing. The minute I am
faced with a programming problem I dig in whole heartedly at first, but
then I forget my writing and then I forget my programming and then I
get really frustrated and turn my computer OFF.
This is why Inform 7 has been a huge productivity boost for me. I have
been able to focus nearly all of my time on the setting, the story, the
sub plots, a few puzzles, but most everything to do with the story I
want to write. The few moments I've had to deal with logic issues have
been really just garnering an understanding of Inform 7 "ways of doing
stuff" but I haven't really once fallen into a "coding" mindset.
I'll bet you know where this is going! Next diagrammed brain please!
The right funnel brain.
/--------------
Writing Stuff ========= Programming Stuff
\--------------
These people are coders at heart and although they're okay popping into
the text at some point, they really feel comfortable dividing up all of
their story elements into a systematic schema of objects. The slice,
they dice, they can even cut cans with their bare teeth. Of course when
it comes to actually developing a story for their code, forget it. They
run for the hills. They never finish their codefests because, well,
it's all just code. They've forgotten the story. "I got a map. Some
puzzles. Now what?"
Summary
So in all the banter of whether Inform 7 is a good thing, the right
way, the better platform, the coolest toy, or whatever you think it is,
remember that not everyone approaches IF in the same way.
Oh sure, the sentimental IFer will long for the days of writing _their_
games in MDL on an 8-bit processor. Some will long for the days of
memory management problems. And some might even wish they had a paper
terminal in their office.
Inform 7 is not the bestest greatest thing to ever reach IFkind. It is
simply the best tool for some of us folks to use to implement our
ideas. We've done the Inform 6 and TADS thing and we did _okay_, but we
always longed for something better. We attacked the problem from an IDE
point of view and it turns out we were so so far off on that score. We
tried to think of new ways to code IF. We complained about how hard it
was to do IF in the current platforms (violins please).
And here someone else was listening. A fellow from a far away land (for
some of us) was hunkered in his attic (so I picture) tapping on a shiny
new apple notebook, devising a way to make all of us left funnel
brained people happy. And he really was focused on _that_ problem. He
wasn't interested in the conduit brains...shoot, they had their day. He
wasn't interested in the right-funneled brain folks, because well, if
you can't write story, you have no business trying to code one either
(alone that is...partnering is encouraged).
He was completely and absolutely focused on people that wanted to write
interactive fiction and really wanted to keep the coding to a minimum.
I think he succeeded. There's more work to be done. Some of it might
even appease the conduit brainiacs. Some of the coding OO purists are
going to scoff at my three brains theory.
(Whisper "they don't understand...just let them keep chattering while
we keep writing cool games in I7!")
But in the end I believe that Graham Nelson has successfully promoted
Interactive Fiction to a far more open landscape than it ever could
have achieved with OO-C-based platforms.
And this I thank him for, simply because it has brought me closer to
the hobby that I have loved for 26 years. I can now write the piles of
stories I have on my computer and in my brain. And for that, I am
grateful.
David Cornelson
Dennis G. Jerz
Those who are already expert coders will probably see a productivity
hit if they try to learn Inform 7, but those who are writers first --
who haven't already learned how to code -- will probably do a lot
better telling a story with Inform 7 than they would with any other
system.
ethan...@gmail.com
> I've paid attention to most of the threads over the last two months and
> commented either seriously or snarkily in many. One of the popular
> discussions, in various forms, has been what Inform 7 does that other
> things have not done or how does it do things differently.
I've seen a lot of the same traffic. Part of the "how does it do
things differently" I think comes from folks with experience with
traditional OO and procedural languages attempting to map what they
know on top of analogous concepts in Inform 7, a natural thing to do
when you are starting from somewhere past zero.
> My immediate reaction to Inform 7 was quite positive and I thought at
> first this was because it "seemed" like the perfect way to do
> Interactive Fiction.
I, on the other hand, got the reaction of a C programmer to COBOL...
This is *not* a criticism. I agree that for many people Inform 7 is a
great tool. I do not think I am one of them.
> Then I thought of the three brains...
>
> Oh sure, the sentimental IFer will long for the days of writing _their_
> games in MDL on an 8-bit processor. Some will long for the days of
> memory management problems. And some might even wish they had a paper
> terminal in their office.
Some of us still _do_ have working hardcopy terminals, but I never kept
one in the office even back in the day - they are too noisy. I _do_
have a dumb CRT terminal within reach - I use it for 100% VT100
compatibility with emacs under TOPS-20 (on which I run the MDL version
of Zork ;-)
I realize I am somewhat anachronistic about things - my newest computer
started life as a boxed motherboard in 1999...
> Inform 7 is not the bestest greatest thing to ever reach IFkind. It is
> simply the best tool for some of us folks to use to implement our
> ideas. We've done the Inform 6 and TADS thing and we did _okay_, but we
> always longed for something better. We attacked the problem from an IDE
> point of view and it turns out we were so so far off on that score.
I'm also opposed to IDEs... I want to use my own tools to build all
software, not just IF, but that's a different windmill to tilt at.
> And here someone else was listening...
> He was completely and absolutely focused on people that wanted to write
> interactive fiction and really wanted to keep the coding to a minimum.
>
> I think he succeeded.
I do, too. I7 is a great tool for the right sort of writer.
> There's more work to be done. Some of it might
> even appease the conduit brainiacs. Some of the coding OO purists are
> going to scoff at my three brains theory.
I think your "three brains" theory does an elegant job of categorizing
the kinds of folks who would be writing IF. I'm enough of an "OO
purist" that I've used Inform 6 to write noddy little OO (non-IF)
programs when I wanted something quick and dirty and encapsulated in a
saner sandbox than Java provides. For the record, I do write (I was a
liberal arts major in college) and I do code (I've been programming for
money since High School) - so on a good day, I might hit "conduit
brain" mode, but on most days, I'm probably biased towards breaking
down problems into objects and dealing with coding details and side
effects and bugs. I've certainly spent many, many more hours
dismantling existing stories to see how they work than I have writing
my own (I got my start writing IF in BASIC for the PET over 25 years
ago - by today's standards, it's all *dreadful*, employing nearly every
IF cliche known to exist and probably two or three new ones (magic
words, mazes, scavenger hunts, incongruities like an elevator in the
middle of a meadow, and on and on).
> But in the end I believe that Graham Nelson has successfully promoted
> Interactive Fiction to a far more open landscape than it ever could
> have achieved with OO-C-based platforms.
I have a friend I've known since we were kids - he's written a number
of stories with tools like Adrift, etc. As soon as I7 came out, he
jumped all over it. He's already working on a story for one of the
upcoming competitions. I hold him up as an example of someone, like
yourself, who is full of stories but has been in search of a better
tool that will let him write more and code less. I7 is *great* for
him.
I've honestly tried to dip into I7 (I saw it a while back when it was
still in Beta). I didn't find it easy for me to use then and I don't
find it easy for me to use now. I think part of it is that I've been
programming for nearly 75% of my life in assembler, in BASIC, in C, in
Perl, in DCL, in FORTRAN, in Java, in Inform 6, etc. (you get the
picture), and as such, I'm quite comfortable reducing a problem to
concentrated symbolic form and emitting concentrated symbol-laden
output that makes sense to a machine. I7 is so wordy, to me, that I
find it more difficult to juggle swaths of it in my head than I do,
say, graphic transforms in assembly code or hairy regular expressions
in Perl.
This does not mean that I7 is a bad tool - it probably does mean that
it will never be a tool I'm comfortable with. I've read through Emily
Short's examples - they are interesting to read (and fun to play!), and
I can see how things hang together, more or less, but it all just seems
so spread out that by the time I get to the bottom of one "chapter",
I've forgotten what was at the top two chapters back.
If the tool works for you, great. I don't know that I'll ever jump on
the bandwagon, though.
-ethan
John Prevost
(like Prolog, or ELF) than anything else--and this is a programming
paradigm that very few people have experience with. I'd actually toyed
with the idea of using a logic programming language for IF in the past,
so it makes a lot of sense to me.
Getting used to this programming paradigm is difficult at first (just
as it can be slightly difficult for some people to move between
functional programming and procedural programming), but it can be very
worthwhile. Essentially, these three programming language models make
different tasks easier and harder--just like moving from one language
to another. (As an example of the latter: string processing is
horribly painful in C, reasonably painful in Java, and utterly trivial
in Perl.) However, the differences are significantly more basic to the
very model of how you write a program. (As a note: object oriented
programming is more-or-less an elaboration that can be tacked on to any
of these models. It does encourage different coding in all of them,
but moving from procedural to procedural-with-objects is a smaller leap
than a change from procedural to functional. In a way, there's no such
thing as logical-with-objects, because you can define OO in a true
logic programming language almost for free.)
In an imperative language, you think primarily of static "programs"
working by modifying state as they consume input and produce output.
This type of language obviously makes it very easy to track changing
state. It is rather harder to reason about what the code *means*,
however. (And by reason about, I mean rather strictly: for example,
proving things about what the code does and does not do.) It is
possible to write code in a procedural language that it is easy to
reason about, but it's more natural to write code that just works.
In a functional language, you think in terms of values, and functions
that transform those values. One specific feature of most functional
languages is that functions themselves are values. A functional
programming language typically makes it harder to work with state
(providing imperative features for that behavior, although there are
exceptions), but makes it very easy to reason about the meaning of a
program. It is possible to write code about state in even the purest
functional languages, but it is generally awkward (which is why most
such languages include imperative features for when you really want
them, just as many modern procedural languages have at least some basic
functional programming features.) Functional languages are also
typically much better at processing purely symbolic data than
imperative languages (whereas imperative languages are often better at
processing encoded data.)
As an example of the difference between these two programming language
models: In an imperative language, building a parser with code (as
opposed by writing code to parse) is generally done by constructing a
data structure that describes what to look for, then running a single
procedure that interprets that data structure as it reads in data. In
a functional programming language, one might be more likely to compose
functions together to form a single function that interprets the data.
The same information is embodied in both the data structure and the
function, but the code that produces the two structures differs
dramatically.
Finally, in a logic programming language, one things in terms of
assertions and queries. This is significantly more alien to most
people, when they think of "writing a program", but more natural when
they think of the program as a sort of database of facts. Of course, a
"database" is a much less flexible thing than the set of facts in a
logic program, since the "facts" have to be a lot more regular, and the
queries more constrained. In any case, logic programming languages
excel at building large complicated models with many rules, and then
being able to pull out subsections of those models in interesting ways.
Working with state can be done (as in I7) by adding and removing facts
from the world. Processing input and output, however, is very alien to
logic programming, as is working with "functions". (In a logic
program, a definition of a "function" can just as easily go from the
result of the function to its possible inputs as it can go from inputs
to outputs.) In fact, it's this last point, that "functions" (or, more
properly, "relations", although not in the I7 sense of the word) go
both ways that makes logic programming languages shine.
A very simple example of something you could do in a logic programming
language: say you have the addition function. Call the addition
function "add(X, Y, Z)", where X + Y = Z. If you say "add(2, 3, Z)",
the language will come back with "Z = 5". If you say "add(X, 3, 5)",
it will come back with "X = 2". If you say something like "X is in [1,
2, 3]. Y is in [0, 2, 4]. add(X, Y, 5), it will come back with "(X, Y)
is in [(1,4), (3, 2)]" (or the like), giving all of the ways you can
sum up to five with a value in those two lists.
Inform7 is *mostly* a logic programming language--and that's the place
where it shines. It's not the "English syntax" that matters so much as
the fact that you can run most things backwards-and-forwards. For
example, you don't have to define a function or procedure that works
over all of the rooms in the game in order to get a list of every room
that contains a red rose--you just say [list of rooms containing a red
rose], and there you are. And that would be just as powerful if you
had to express it as "contains(R, 'red rose')" as it is with the
"natural language" syntax.
And, to be honest, just as alien to most programmers.
Still, it's definitely worth spending some time learning to work with
the logic programming model. Just like spending time with a functional
language will teach you a different set of tricks to use when writing
procedural code (procedural languages being the only variety most of us
use at work), spending time with a logic language will teach another
useful and interesting set of tricks. Some of you may even
occasionally spend time with a language that contains some LP features
already, without even realizing it. (SQL and XSLT [or XPath, more
generally] spring to mind.)
So, anyway--don't let the verbose syntax turn you away from the
experience.
John.
Michael Martin
ethan...@gmail.com wrote:
> I think your "three brains" theory does an elegant job of categorizing
> the kinds of folks who would be writing IF. I'm enough of an "OO
> purist" that I've used Inform 6 to write noddy little OO (non-IF)
> programs when I wanted something quick and dirty and encapsulated in a
> saner sandbox than Java provides. For the record, I do write (I was a
> liberal arts major in college) and I do code (I've been programming for
> money since High School) - so on a good day, I might hit "conduit
> brain" mode, but on most days, I'm probably biased towards breaking
> down problems into objects and dealing with coding details and side
> effects and bugs.
I note that I've dived quite happily into Inform 7 despite being much
of the same (though I was a computer science major), so this can't be
the whole story.
> I'm quite comfortable reducing a problem to
> concentrated symbolic form and emitting concentrated symbol-laden
> output that makes sense to a machine. I7 is so wordy, to me, that I
> find it more difficult to juggle swaths of it in my head than I do,
> say, graphic transforms in assembly code or hairy regular expressions
> in Perl.
And this is very likely where the key was, for me. It's not the format
of the input -- my reaction to that was "It's like procedural code in
Perl, but it's actually legible." My current WIP was originally Inform
6, and the reimplementation of what I had took something like three
days, and wound up including quite a bit more. Once I internalized
that:
- Maps were essentially a series of constraints I got to set, and
- Interesting behavior is a set of rules divorced in large part from
the objects they act upon,
My original design began growing as I wrote, and it's increased its
complexity considerably. Something that was originally practically a
cutscene became an affair of eight rooms and three possible ways
through, just because I didn't have to worry about stomping on anything
when implementing the additional solutions. The NPCs have wound up
being a lot more reactive and willful, too (though in this case, that
really means more that I *have* some NPCs worthy of the name).
At this point, I think my greatest design worry is that I'll be
shifting gears on the player far too frequently, and thus involving
what would have been (for me) excessively exotic interaction models.
That would definitely not have been a risk in Inform 6 (where, in the
original design, the danger was in everything interesting being
cutscened).
--Michael
Vivienne Dunstan
> My feeling is that Inform7 is closer to a logic programming language
> (like Prolog, or ELF) than anything else--and this is a programming
> paradigm that very few people have experience with. I'd actually toyed
> with the idea of using a logic programming language for IF in the past,
> so it makes a lot of sense to me.
Interesting analogy, and one I thought of on seeing Inform 7 too. I'm a
long-term Prolog programmer (before university and every year there
while studying computer science) and still dive into it for situations
where I need a quick solution to something that can be easily declared
in Prolog by a number of simple rules defining facts and queries (did it
just the other day for a task/project management system: would have
taken aeons of programming in C or similar). Inform 7 immediately struck
me as close to this form of declarative programming. where you mainly
describe the end results rather than how to get there.
Strangely though I'm still finding Inform 7 a little bit uncomfortable.
My initial reaction was very positive, and I'm happy quickly setting up
definitions of rooms, objects etc. But it's all a bit magical and the
imperative programmer side of me (the one who's done Assembly language
and C and numerous other languages) would still be more comfortable with
coding where I've got more of a handle on the underlying data
structures. Inform 7 takes that away which is fantastic, but for a
long-term imperative programmer it can take some adjusting to.
In terms of David's three brains analogy I'm not sure where I fit in but
probably a mix of the three. A large programming background (suggesting
conduit) doesn't make me automatically the most enthusiastic coder ever,
and I'd always rather think of the story first i.e. left funnel. Then
again due to extensive training it's easier for me to code than to write
so there's a right funnel element to my brain too. Erm! Not an easy
solution in my case and I think that many other people will have
elements of the different types within them.
Meanwhile I'll persevere with Inform 7!
Viv
Jeff Nyman
hypothesis because the scientist in me compels me to think that a theory
would mean it has withstood the test of time and I am not sure if that has
happened yet. That is what I am waiting to see.) I have been playing around
with both TADS 3 and Inform 7 to use as two examples as I figure out how
much I find the natural language interface useful.
Initially, I really liked the cool-ness factor (if you will) of the natural
language approach. In fact, in my work-life I have implemented natural
language parsers that take specification documents and convert those into
manual test conditions and then take the test conditions and convert those
to automated test code.
I bring that up because therein I found an interesting parallel,
particularly with this comment from David: "They [people with 'conduit
brains'] go back and forth easily between programming logic and descriptive
language without much stress."
Why the parallel? Because I found the business analysts could readily wrap
their brain around the concept of a somewhat contrived natural language
approach to converting a document of how they think (requirement
specification) into another document that somewhat matches how they think
(test specification). By David's terminology, they were more
"funnel-brained." However, I found that programmers of automated testing
scripts had a much harder time wrapping their [conduit] brain around the
concept of writing those automated test conditions "naturally" (via manual
test conditions) and converting those to automated test code. I would often
find they skipped the natural language interface and went right to the
automated tool to write the scripts in code.
My working hypothesis so far is that this is a mental "force-to-fit" issue.
(Cognitive friction, for those of you who prefer that term.) In the case I
just described of writing the parser for requirements (minimally constrained
natural language) to test conditions (slightly more constrained natural
language) the elements are constrained: specifications are written in
natural language by definition. So are test conditions. So there was not as
much "force-to-fit" issues there because people were used to writing in a
not totally free-form natural language. There were more of those
"force-to-fit" issues when I went from the test conditions to the automated
language because even the constrained natural language of manual test
conditions did not always map well to automated test code. Even then, in my
opinion, it was still a relatively easy mental shift because everything in
the manual conditions boiled down to just telling someone how to work with
an application. (A very limited "world model", if you prefer, and thus not
many variations on how to word things or how to do things.)
Initially, I am finding that is not the case with IF for me. I am finding
that things that are inherently programming are (again, for me) seemingly
best treated as such. Putting a natural language spin on that is what I am
not sure of yet. But that is probably because I come from a programming
background. Again, in the work situation I describe, having automated
testers code all automated tests via a natural language interface was, for
some of them, more cumbersome than having them just learn automated code or
having them learn enough code to utilize an already existing code base that
they could otherwise largely ignore.
However, relative to IF, writing test conditions to convert to automated
code is not akin to writing a story. In that sense, I see where I7 is
actually a huge leap forward in a lot of ways, because it does seemingly
open things up to people who found other (programmatic) elements in I6 or
TADS daunting. Time will tell if this opening up is actualized by the number
of games released by people who probably would not have released any before.
I also think that part of what will tell how successful I7 is, purely in
terms of its approach with natural language, is how often you have to
"break" the natural language to utilize constructs of a programmatic nature.
For example, every time you have to include I6 code in (- -) elements would
be breaking the model for me. (It would be like if I had to have the
business analysts in my work example above write some of their requirements
in the language of the autoamted test tool.)
In the final analysis, I really like I7 for what it attempts to do and I am
very curious to see if people who have never written a full IF work (myself
included) actually do so now.
- Jeff
Neil Cerutti
> This does not mean that I7 is a bad tool - it probably does
> mean that it will never be a tool I'm comfortable with. I've
> read through Emily Short's examples - they are interesting to
> read (and fun to play!), and I can see how things hang
> together, more or less, but it all just seems so spread out
> that by the time I get to the bottom of one "chapter", I've
> forgotten what was at the top two chapters back.
I hope logical operators are in the works. Writing the following
code caused actual rage:
Instead of examining the flashlight: if the flashlight is
switched on begin; if the battery is part of the flashlight, say
"It's providing a warm glow."; otherwise say "With no battery, it
is dark."; otherwise; if the battery is part of the
flashlight, continue the action; otherwise say "It seems to be
missing a battery."; end if.
That is rewritten from memory, and even after having been
extremely careful in my punctuation, I've no confidence that it
does what I want.
Note that trying to say the same thing with a description works
even less well.
> If the tool works for you, great. I don't know that I'll ever
> jump on the bandwagon, though.
It has made me think of and use new methods of solving old
problems, methods I wouldn't have thought of using in Inform 6,
but actually could have implemented. I can't remember who said
that a new programming language is no good unless it makes you
think differently. Well, Inform 7 succeeds admirably in that, for
me.
--
Neil Cerutti
Robin Johnson
> My feeling is that Inform7 is closer to a logic programming language
> (like Prolog, or ELF) than anything else--and this is a programming
> paradigm that very few people have experience with.
I'd had a bit of an "ack! COBOL!" reaction so far, but if that's true,
I will take a proper look. I love XSLT more than a man should love a
programming language, and Prolog is cool too.
I'm still sceptical of the fake-English notation, but that's all been
said. I'm also just not very comfortable reading it - for a simple
example, the words "begin" and "end" don't go directly into my brain as
parts-of-code, the way a pair of braces do. (This is very hard to
explain but possibly other programmers will know what I mean.) Is there
a more 'codish' syntax available instead, or a possibility of one in
the future?
--
Robin Johnson
ChicagoDave
> ChicagoDave wrote:
>
> I am a left funnel brain. Another diagram please!
>
> ---------------------\
> Writing Stuff ========== Programming Stuff
> ---------------------/
>
I would like to point out that which brain you are has very little to
do with how much programming experience you have, but possibly the
_type_ of experience.
I have been writing code for 21 years professionally and 26 years
overall. But I started with PDP-Basic, dabbled in COBOL, did some RPG
II/III, and then more Basic for many years. I picked up C in the mid
90's and C# these past 5 years. I didn't pick up OO concepts until the
late 90's and I probably still don't entirely feel comfortable with the
harder OO concepts. So in a sense, I am a procedural programmer at
heart.
But I still don't see that as the reason Inform 7 makes me more
productive. I believe it's that I'm entirely focused on the story and
not the coding _at all_.
And here's the other part of my background that might have made me the
way I am. I grew up in a house with logic puzzle books all over the
place. So in a way, I learned to break down problems in a narrative
form. It wasn't until years later that I found out you could do this
mathmatically too.
David C.
John Prevost
> I'd had a bit of an "ack! COBOL!" reaction so far, but if that's true,
> I will take a proper look. I love XSLT more than a man should love a
> programming language, and Prolog is cool too.
>
> I'm still sceptical of the fake-English notation, but that's all been
> said. I'm also just not very comfortable reading it - for a simple
> example, the words "begin" and "end" don't go directly into my brain as
> parts-of-code, the way a pair of braces do. (This is very hard to
> explain but possibly other programmers will know what I mean.) Is there
> a more 'codish' syntax available instead, or a possibility of one in
> the future?
I am not an I7 compiler coder, so I don't know the answer to whether
there will be a more "codish" syntax. But I'd kind of doubt it. It
did make me think "Hmm. Pre-processor turning code into NL which
produces code that compiles to...", but let's not go there.
However, I do have some experience with languages that use a lot less
punctuations than the C-descended languages most folks use, and I can
give some advice: you aren't forced to do it, but use indentation
wisely, anyway. This is just as true in brace-oriented languages--they
can be made completely illegible by not using whitespace appropriately.
It's just that when a language is mostly keywords, there's this urge
to overindulge.
If you look at Emily Short's worked examples, you'll see that while
she'll often take shortcuts for parts that are reasonably clear (simple
if statements), she uses indentation and line breaks to make more
complicated examples clear:
Instead of looking under a thing which is underlaid by something
(called the lost object):
say "You reach around under [the noun] and turn up [list of things
which underlie the noun].";
repeat with item running through the things which underlie the noun
begin;
now the item does not underlie anything;
now the item is carried by the player;
end repeat;
I wouldn't have written the passage above in exactly the same way, but
it makes both the loop and the sequence of things to do reasonably
clear. Sure, you could write it all as one line, but it would be
hideously unreadable. Just like if you wrote a C function as all one
line.
The aforementioned author also uses indentation and line breaks in
other cases even when she could get away with leaving them out:
Carry out reverse linking it to:
now the noun affects the second noun;
now the second noun affects the noun;
now the noun protects the second noun;
now the second noun protects the noun.
In the above passage, the only reason for the line breaks and
indentation is to make it clear that the last four lines are individual
steps taken in the definition of the first line. In this case, you
could absolutely put everything all on one line and have it be
readable--but it's much much more readable on multiple lines like this.
So: more "code-like" in terms of using lots of punctuation marks
instead of keywords, no. However, each author has the power to make
their code (and code it is) as clear or as muddy as they wish--and how
you lay something out is just as important as what you say.
John.
Neil Cerutti
I would normally do that sort of thing religiously, but it looks
so ugly when line-wrap takes place and ruins the visual flow.
The alternative is attempting to shorten my sentences, so
line-wrap doesn't occur, but I'm not sure that's possible in
strings.
> I wouldn't have written the passage above in exactly the same
> way, but it makes both the loop and the sequence of things to
> do reasonably clear. Sure, you could write it all as one line,
> but it would be hideously unreadable. Just like if you wrote a
> C function as all one line.
But it some sense, it looks *right* to me, in I7. I'll need to
learn to strike a balance between paragraphs and code blocks, and
just get used to the fact that code is going to look
inconsistently formatted.
> The aforementioned author also uses indentation and line breaks
> in other cases even when she could get away with leaving them
> out:
>
> Carry out reverse linking it to:
> now the noun affects the second noun;
> now the second noun affects the noun;
> now the noun protects the second noun;
> now the second noun protects the noun.
>
> In the above passage, the only reason for the line breaks and
> indentation is to make it clear that the last four lines are
> individual steps taken in the definition of the first line. In
> this case, you could absolutely put everything all on one line
> and have it be readable--but it's much much more readable on
> multiple lines like this.
The other very useful thing it does is to highlight the parallel
nature of those phrases.
> So: more "code-like" in terms of using lots of punctuation
> marks instead of keywords, no. However, each author has the
> power to make their code (and code it is) as clear or as muddy
> as they wish--and how you lay something out is just as
> important as what you say.
Yup.
--
Neil Cerutti
Any time Detroit scores more than 100 points and holds the other
team below 100 points they almost always win. --Doug Collins
JDC
brain in this analysis. When starting an IF project, I tend to start at
the foundation and work up from there. I include both plot/theme and
game mechanics here. So my first considerations would be:
- What is the goal of the player, i.e. what is the PC ostensibly trying
to accomplish?
- What is the goal of the story, i.e. what am I trying to communicate
to the player?
- How does the world behave, e.g. is there some underlying new
technology, magic, geography, etc?
I tend to set up the basic plot structure first (which in I7 might
involve laying out scenes). I next consider what I think the crucial
technical details will be and try to lay the groundwork for this
(creating kinds, relations, and basic rules). Only then do I start
implementing particular objects and writing actual text.
I find that I7 fits this style very well. Others have commented on the
logical programming aspects of I7; I happen to do research primarily in
mathematical logic and set theory so perhaps this explains I7's appeal
to me (I don't really have experience with other LP languages, unles
you count having to prove in lectures every few years that the
recursive functions are those functions representable in PA...). I have
also tried I6 and feel that I could ultimately accomplish the same
things with it as with I7, but I think it is a little harder for me to
do this sort of ground-up construction since I find myself wanting to
have the objects created first in order to attach behaviour to them.
This may just be my inexperience with OO-programming, though. When it
comes to the actual coding I'm pretty comfortable (equally mediocre) in
a lot of languages, but I like I7's capabilities for structural layout.
For numerical computations or complicated parsing, though, I think I
would presently be more comfortable in I6.
I also think that certain types of games are more easily implemented in
I7 whereas other types might be easier in something like TADS 3 (with
which I have little experience). A game with a fundamentally new world
model seems well suited to I7, where the author is left to define more
basic kinds, relations, and behaviours (something like Damnatio
Memoriae, for instance). On the other hand, a game with a large supply
of stock objects (tables, chairs, torches, etc.) would probably be
easier in something like TADS 3 which has a vastly larger standard
library.
-JDC
OKB (not okblacke)
>> Instead of looking under a thing which is underlaid by something
>> (called the lost object):
>> say "You reach around under [the noun] and turn up [list of
>> things
>> which underlie the noun].";
>> repeat with item running through the things which underlie the
>> noun begin;
>> now the item does not underlie anything;
>> now the item is carried by the player;
>> end repeat;
>>
>
> I would normally do that sort of thing religiously, but it looks
> so ugly when line-wrap takes place and ruins the visual flow.
The solution to this is that wrapped lines should remain indented
as far as the first character instead of wrapping all the way to the
margin.
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
Andrew Plotkin
>
> I'm still sceptical of the fake-English notation, but that's all been
> said. I'm also just not very comfortable reading it - for a simple
> example, the words "begin" and "end" don't go directly into my brain as
> parts-of-code, the way a pair of braces do. (This is very hard to
> explain but possibly other programmers will know what I mean.)
I, like Emily, have been relying very heavily on indentation. (The
linewrap doesn't bother me. Wrapped lines are a half-tab deeper than
the indentation they start with, which is just what I want.)
> Is there a more 'codish' syntax available instead, or a possibility
> of one in the future?
Not currently available. It's certainly possible, but I don't expect
Graham to make it a priority.
I will note, as a possibly-strained analogy, that TADS 2 had two
different syntaxes available (C-like and, er, the other one.) My
impression is that this only led to confusion, and that TADS 3 sticks
to a single syntactic form.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison without trial,
it's for one reason: they don't feel like it. Not because you're an American.
Kevin Forchione
news:e8mdt0$ijr$1...@reader2.panix.com...
> I will note, as a possibly-strained analogy, that TADS 2 had two
> different syntaxes available (C-like and, er, the other one.) My
> impression is that this only led to confusion, and that TADS 3 sticks
> to a single syntactic form.
You betcha. The idea of moving toward a more Java-like syntax occurred early
in the development, and there was much rejoicing when Mike decided to move
most of the intrinsic functions onto objects. Interestingly, my own projects
have involved working with the TADS 3 application (i.e. the game) as an
interpreter for a Lisp-like syntax, which involves no eye-candy beyond
parenthesis. There's a lot to be said for simple syntax.
--Kevin
Andrew Plotkin
> I hope logical operators are in the works. Writing the following
> code caused actual rage:
>
> Instead of examining the flashlight: if the flashlight is
> switched on begin; if the battery is part of the flashlight, say
> "It's providing a warm glow."; otherwise say "With no battery, it
> is dark."; otherwise; if the battery is part of the
> flashlight, continue the action; otherwise say "It seems to be
> missing a battery."; end if.
>
> That is rewritten from memory, and even after having been
> extremely careful in my punctuation, I've no confidence that it
> does what I want.
It does what it looks like it should do, so I think it's right.
A more I7-friendly (or at least friendly to the rule model) phrasing
would be:
--------------------
Instead of examining the flashlight:
if the battery is part of the flashlight, continue the action;
otherwise say "It seems to be missing a battery."
Instead of examining the flashlight when the flashlight is switched on:
if the battery is part of the flashlight, say "It's providing
a warm glow.";
otherwise say "With no battery, it is dark."
--------------------
(I'm indenting for clarity, but these two chunks would be simpler even
if they were written as flowed paragraphs.)
You could in fact split it out into separate cases:
--------------------
Instead of examining the flashlight when the flashlight is switched
off and the battery is not part of the flashlight:
say "It seems to be missing a battery."
Instead of examining the flashlight when the flashlight is switched on
and the battery is part of the flashlight:
say "It's providing a warm glow."
Instead of examining the flashlight when the flashlight is switched on:
say "With no battery, it is dark."
--------------------
But that starts to get confusing again, with all the repeated
conditions.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison
without trial, it's for one reason: they don't feel like it. Not
because of the Fifth Amendment.
David Tanguay
> I'm still sceptical of the fake-English notation, but that's all been
> said. I'm also just not very comfortable reading it - for a simple
> example, the words "begin" and "end" don't go directly into my brain as
> parts-of-code, the way a pair of braces do. (This is very hard to
> explain but possibly other programmers will know what I mean.)
I think you mean: Punctuation should look like punctuation.
The "begin" .. "end" (et alii) makes it look like a telegraph message.
This is not particular to fake-NL -- e.g., Pascal. See Lisp/Forth/Postscript
for the other extremes.
--
David Tanguay Kitchener, Ontario
na...@natecull.org
and coding elements. I find I come up with story *ideas* easily enough,
but not ones that fit naturally into an IF form.
Initially, I thought that I7 would help me write easier. I love the
rule-based form. But there are two major hassles, one that I struggle
with and one that really is a deal-breaker:
1. The NL syntax is just so unpredictable that it induces actual rage
in me. So many times, I know what I think I want to say, but because of
the lack of a simple, regular syntax, I have no idea when I get a
compile error if it's a semantic or a syntactic mismatch.
2. (the big one): The heavy reliance on an IDE means that for me, whose
only home machine runs on Linux, I simply can't work with it, because
the only Linux IDE is currently in a state of major breakage (I can't
even compile anything after installing from scratch).
This is something that is a total deal-breaker that simply wasn't an
issue at all with Inform 6 - the Linux toolset worked just as well as
the Mac OS and Windows toolset. And I could use my text editor of
choice. Now, I'm forced to use a half-implemented, severely
hacked-together, second-rate IDE with no official support that even
when it works, actually impedes my writing far more than it helps:
confusing copy-paste support, not-quite-integrated web pages,
I'm sure that for Windows and Mac folks, the experience is great. But,
see -- one of the reasons I got interested in IF in the first place was
that it was a cross-platform nirvana. It Just Worked, everywhere.
Mostly.
Not any more. I'd be writing a game now (or at least tinkering with
one) if I could get the blasted thing to even compile. But I can't.
I'll need to completely strip down and rebuild an IDE from scratch, it
seems, to get any further into the I7 world.
Sorry, but if I can't dance, it's not my revolution.
Aris Katsaris
Andrew Plotkin wrote:
> --------------------
> Instead of examining the flashlight when the flashlight is switched
> off and the battery is not part of the flashlight:
> say "It seems to be missing a battery."
>
> Instead of examining the flashlight when the flashlight is switched on
> and the battery is part of the flashlight:
> say "It's providing a warm glow."
>
> Instead of examining the flashlight when the flashlight is switched on:
> say "With no battery, it is dark."
> --------------------
>
> But that starts to get confusing again, with all the repeated
> conditions.
I think that Inform 7 should have some easy way for the programmer to
repeat the beginning of sentences, something that could be used like
this:
Instead of examining the flashlight when the flashlight is -*
*- switched off and the battery is not part of the flashlight:
say "It seems to be missing a battery."
*- switched on and the battery is part of the flashlight:
say "It's providing a warm glow."
*- switched on:
say "With no battery, it is dark."
That's probably the number one improvement I would make in the language
if it was in my hands...
-Aris Katsaris
John Prevost
na...@natecull.org wrote:
> 2. (the big one): The heavy reliance on an IDE means that for me, whose
> only home machine runs on Linux, I simply can't work with it, because
> the only Linux IDE is currently in a state of major breakage (I can't
> even compile anything after installing from scratch).
Assuming you can get the NL compiler (nl.exe) to run under wine (which
I assume because the Linux IDE needs that, broken or not, to do
anything), you could easily treat it as a command-line compiler, just
like inform6. If I were working on Linux, I'd most likely be doing
that, and using emacs to edit the source and firefox to view the html
documents in the index.
Stuart "Sslaxx" Moore
> I think that Inform 7 should have some easy way for the programmer to
> repeat the beginning of sentences, something that could be used like
> this:
>
> Instead of examining the flashlight when the flashlight is -*
> *- switched off and the battery is not part of the flashlight:
> say "It seems to be missing a battery."
> *- switched on and the battery is part of the flashlight:
> say "It's providing a warm glow."
> *- switched on:
> say "With no battery, it is dark."
>
> That's probably the number one improvement I would make in the language
> if it was in my hands...
Submit this as a feature request to Graham, perhaps?
--
Stuart "Sslaxx" Moore
http://sslaxx.livejournal.com/
Andrew Plotkin
I'd suggest setting it up with ellipses:
Instead of examining the flashlight when the flashlight is...
...switched on: say "With no battery, it is dark."
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
It's a nice distinction to tell American soldiers (and Iraqis) to die in
Iraq for the sake of democracy (ignoring the question of whether it's
*working*) and then whine that "The Constitution is not a suicide pact."
ChicagoDave
> Andrew Plotkin wrote:
>
> I'd suggest setting it up with ellipses:
>
> Instead of examining the flashlight when the flashlight is...
> ...switched on: say "With no battery, it is dark."
I think we're onto something here. Using the ellipses fits into the NL
"style" and this syntax change _is_ a convenient shortcut.
David C.
Eric Eve
> I also think that certain types of games are more easily
> implemented in
> I7 whereas other types might be easier in something like TADS 3
> (with
> which I have little experience). A game with a fundamentally new
> world
> model seems well suited to I7, where the author is left to define
> more
> basic kinds, relations, and behaviours (something like Damnatio
> Memoriae, for instance). On the other hand, a game with a large
> supply
> of stock objects (tables, chairs, torches, etc.) would probably be
> easier in something like TADS 3 which has a vastly larger
> standard
> library.
If I ever got round to doing a comparison of TADS 3 and I7, this is
precisely one of the points I'd make. I'm now pretty comfortable
working with TADS 3, and there's a limit to how far I'd want to
reinvent large parts of its world model in I7 if I needed them in a
game. This is not simply a matter of stock objects such as tables,
chairs and torches, but also of other parts of the world model such
as actor posture (standing, sitting or lying), lighting levels,
sense passing between rooms, and above all the handling of NPC
actions and conversations. If, for example, I want to write a medium
to large game with quite a bit of conversation employing the
ASK/TELL paradigm, TADS 3 has masses of stuff built in to handle it
out of the box (and it's not that hard to extend it); presumably it
would be possible to code similar functionality in I7, but (a) I
wouldn't want to bother to reinvent what TADS 3 already does very
well and (b) I suspect the resultant NPC conversation code would end
up looking messier and harder to maintain in the I7 version. For
other types of conversation, however, I7 might do the job perfectly
well - particular if you want to devise something outside the normal
ASK/TELL paradigm (like the conversation in Emily Short's "Glass"
example for instance).
A further point is that, at least as things stand at the moment,
TADS 3 would in any case be my system of choice for larger games.
The first reason is simply that until I7 can compile to Glulx, it
comes up against size limitations much sooner than TADS 3 (I don't
know if it's even practically possible to write a game too big for
TADS 3 [as opposed to the hardware it's running on] - a real game,
that is, as opposed to an exercise in bumping up against limits).
The second is related to your point, in that a larger game is more
likely to make use of a more complex world model, which TADS 3
supplies out of the box. The third is that with larger projects the
ability to split the source over multiple files with separate
compilation becomes more and more helpful, and the wonderful TADS 3
debugger becomes more and more indispensible. The fourth is related
to the third but is rather more subjective: for some people the fact
that I7 allows you to range your code in almost whatever fashion you
like is doubtless a great benefit; for me the fact that TADS 3's OO
approach tends to impose a certain order on code is something of a
benefit - at least I think I'd find it easier to find my way round
the source of a large TADS 3 game I'd authored than that of a large
I7 game, but that's just me.
There are other powerful features of the TADS 3 library and language
I shan't go into here, other than to say that the larger and more
complex the project, the more likely I am to miss them in another
system.
Again, purely subjectively, I find both systems pleasant to use,
apart from certain frustrations which crop up at different places in
each, and I expect in the future I shall quite happily use both,
though for different types of work. At least in its present
incarnation I7 would tend to be my tool of choice for smaller
projects, or perhaps more experimental ones not making use of the
kind of "standard" world model supplied by TADS 3 (not that TADS 3
lacks flexibility). I7 is a very pleasant system to use for a number
of reasons (which have been eloquently stated by a number of posters
elsewhere). For example, I'm writing (or rather, have more or less
written) an entry for Dave Cornelson's Dream MiniComp in I7, and
it's proving to do this job very well; it would have been easy
enough to write the same game in TADS 3, but TADS 3 would have felt
like overkill.
Finally, I'm not sure which kind of brain it makes me, but I quite
like being able to use more than one system, and to switch between
them for a bit of variety.
All of which simply amplifies what you said, with perhaps the
subtext of encouraging you to take a closer look at TADS 3 as well!
-- Eric
Neil Cerutti
That looks peachy. Thanks! Leveraging rule specificity is not
yet the first thing that comes to mind when I'm coding special
behavior, but when I *do* think of it, I like it.
--
Neil Cerutti
I pulled away from the side of the road, glanced at my
mother-in-law and headed over the embankment. --Insurance Claim
Blooper
na...@natecull.org
Quite right, yes, and that's just what GtkInform does under the hood
(it uses a compile.sh script). Also, I had my own hacked-together
script working originally. But I seem to have somehow borked my
installation severely enough that even the command-line NI compiler
won't run any more, and that's after deleting my .wine folder
completely. It's all very hair-pulling.
I'm going to try Jason Ramboz' trick for running the Windows IDE itself
and see if that gets me back in the game.