I7 philosophical questions
Hector Rodriguez
I understand that the design was largely driven by semantic
considerations, but I am not sure exactly what that means, on a
practical how-do-I-design this language level. I read Graham's
research paper, but I am not yet clear on the practical design
implications of semantics-driven design.
Does the application of semantics to language design in some sense
require/suggest natural language programming? Or are these independent
issues? Is the use of natural language, rather, a solution to the
problem of how to make programming into an expressive medium? Are they
interconnected? Is a semantics driven programming language somehow
more appropriate to expressive uses?
How important are kinds to the design of the language? How are kinds
different from classes?
Many books on cogntion stress two methods (among others) of
representing knowledge: concepts and rules. I7 seems somehow to
combine both. (I take kinds as somehow akin to concepts). Is that a
fair impression?
Sorry if these questions sound stupid, but I wanted to hear other
people's views on these. You are welcome to direct me to other
threads, if these issues have already been discussed.
Jim Aikin
wanted to comment on this:
> Is the use of natural language, rather, a solution to the
> problem of how to make programming into an expressive medium? Are they
> interconnected? Is a semantics driven programming language somehow
> more appropriate to expressive uses?
Programming is an entirely utilitarian activity. It is not expressive.
(Please read carefully -- I *didn't* say it's not creative!)
A programming language -- any programming language -- is strictly a user
interface with which the programmer interacts with the compiler.
The design of a user interface can arguably have a definite impact on the
finished work. Simply put, if the user interface makes certain things easy,
authors will be inclined to do them, whereas if it makes certain things
difficult, authors will be inclined to avoid them (or may never consider
doing them in the first place).
A user interface can also be attractive in its own right -- it can be fun to
use, or it can be ugly and off-putting. This dimension is entirely
orthogonal to the question of whether it makes it easy for the author to
produce expressive effects. A fun interface could be great at producing
expressive effects, or it could be lousy at them. (I've spent a LOT of time
reviewing expensive music software. You can trust my judgment on this
point.)
It's the output -- the finished work of IF, music, graphics, or whatever --
that is expressive (or not). To the extent that the user interface makes
expressive effects easier to produce, the interface lends itself to
expressive uses. And vice-versa.
The question of whether a semantics-driven language inherently makes
expressive effects easier or more difficult to produce is probably
unanswerable. There can be good semantics-driven languages, and there can be
lousy ones. (For purposes of discussion, I'm assuming that "good" is
equivalent to "makes expressive effects easier." There are certainly other
valid measures of goodness.)
I'm not competent to evaluate Inform 7 with respect to either (a) being good
at producing expressive effects or (b) being fun to use. I'll leave that to
others. However, I think it's clear that the question of whether a
semantics-driven interface is more fun to use than a traditional programming
interface is up to the individual's taste. Some people will say yes, others
will say no.
--Jim Aikin
Adam Thornton
>Programming is an entirely utilitarian activity. It is not expressive.
>(Please read carefully -- I *didn't* say it's not creative!)
No, you didn't, but you're still wrong.
>A programming language -- any programming language -- is strictly a user
>interface with which the programmer interacts with the compiler.
You've never read Knuth on literate programming, have you?
I would argue that the *principal* audience of the program is *NOT* the
compiler. The compiler doesn't care *how* you express yourself, as long
as it's syntactically correct. It doesn't care whether your variable is
named "i", "loop_index", "I_004", or "threebatsandanaardvark", or
whether you've commented your code at all.
The person who has to maintain your code after you've departed, on the
other hand, *DOES* care, deeply, about these things, and it's this
person--and not the compiler--who should be your primary audience.
Expressivity is as important in code as in any other form of
communication.
Adam
Andrew Plotkin
> I have two questions about the underlying design philosophy of I7.
> I understand that the design was largely driven by semantic
> considerations, but I am not sure exactly what that means, on a
> practical how-do-I-design this language level. I read Graham's
> research paper, but I am not yet clear on the practical design
> implications of semantics-driven design.
> Does the application of semantics to language design in some sense
> require/suggest natural language programming? Or are these independent
> issues? Is the use of natural language, rather, a solution to the
> problem of how to make programming into an expressive medium? Are they
> interconnected? Is a semantics driven programming language somehow
> more appropriate to expressive uses?
> How important are kinds to the design of the language? How are kinds
> different from classes?
> Many books on cogntion stress two methods (among others) of
> representing knowledge: concepts and rules. I7 seems somehow to
> combine both. (I take kinds as somehow akin to concepts). Is that a
> fair impression?
Caveat: my perspective is whacked. I am not a designer of I7, but I
thought a lot about the rule system, back in the early days. Some of
that thought was in chats with Graham, and so it influenced I7
(indirectly).
I was thinking (back then) about a rule-based IF system which did
*not* use natural language. The rule model is *natural* to me, as a
programming model; it's how I've thought about IF design since Inform
6 (really, Inform 5). I don't consider it to be *linguistic*, per se.
But then I'm a programmer first and a writer second, and I
conceptualize programming in a visual/geometric/topological way, not
linguistically.
I think of I7 kinds as being classes, in the familiar OO sense. (They
are very close to I6 classes.) I am not sure that I like I7 kinds.
I7 kinds, properties, and relations all seem to me to do overlapping
jobs in different ways. Last year I posted some sketches of a
unification of those three ideas, into a single programming construct
which would Do It All.
(Obviously, sketching is not the hard part. I have not succeeded in
defining my ideas rigorously, much less implementing them.)
I am not really coming to any single point here...
I think of I7's mechanisms as programming mechanisms, not cognitional
tools. It's a working tool. I get stuff done with it (by which I mean,
I make adventure games.)
The rule and property mechanisms fit the way I write IF very well.
Other I7 mechanisms (like kinds and phrases) are not *perfect* fits,
but they are very familiar from my programming experience (classes and
functions), and I have no problem using them in IF. (I was able to do
that in I6, after all.)
I think the NL format of I7 is good for expressing IF concepts (which
tend to be real-world concepts, and therefore easy to say in English).
That was basically the point of Graham's paper. I also agree that I7
is exceptionally readable -- and skimmable. (Particularly for programs
which are divided into many small non-hierarchical pieces of code,
as IF is.) As a programmer, I write code once, read it dozens of
times, and skim around it (to navigate the source file) scores of
times. So that's a win.
On the other hand, if I7 had been designed from the beginning with a
traditional "mathematical" programming syntax, I would not be out on
the streets demanding that NL go in. I am good at reading traditional
programming languages -- particularly if they are cleanly designed, so
that common idioms are expressed compactly.
I6 is rather hit-and-miss in terms of compactness; some idioms in my
I6 code are very tight, some are big blobs of boilerplate. I7, despite
its word-by-word verbosity, is compact and readable for a very wide
range of IF tasks.
So I guess my conclusion is that there are many ways that I6 could
have been improved, and I7 chose a fine one of those.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Bush's biggest lie is his claim that it's okay to disagree with him. As soon as
you *actually* disagree with him, he sadly explains that you're undermining
America, that you're giving comfort to the enemy. That you need to be silent.
Jim Aikin
news:0k16j4-...@quicksilver.fsf.net...
> In article <f3ph9b$lkj$1...@aioe.org>, Jim Aikin <edi...@musicwords.net>
> wrote:
>>Programming is an entirely utilitarian activity. It is not expressive.
>>(Please read carefully -- I *didn't* say it's not creative!)
>
> No, you didn't, but you're still wrong.
I read the original poster as being interested in emotional expression. I'm
an artist, so quite possibly I misinterpreted. If that wasn't what he meant,
then I was responding to something that wasn't said. If it _was_ what he
meant, then I stand by my comments. Commenting your code is certainly
important -- but it isn't a form of emotional expression.
>>A programming language -- any programming language -- is strictly a user
>>interface with which the programmer interacts with the compiler.
>
> You've never read Knuth on literate programming, have you?
No, I haven't. Life is too short. I'd rather play the cello, thanks. I _do_
know enough to give my variables and functions sensible names. How many
hundreds of pages of Knuth would I have to read to pick up that tip?
> I would argue that the *principal* audience of the program is *NOT* the
> compiler. The compiler doesn't care *how* you express yourself, as long
> as it's syntactically correct. It doesn't care whether your variable is
> named "i", "loop_index", "I_004", or "threebatsandanaardvark", or
> whether you've commented your code at all.
>
> The person who has to maintain your code after you've departed, on the
> other hand, *DOES* care, deeply, about these things, and it's this
> person--and not the compiler--who should be your primary audience.
Ain't nobody gonna be maintaining my code after I'm gone, bubba. And I would
argue that that statement applies to virtually 100% of the text-based IF in
existence today, tomorrow, next year, or ten years hence.
I'm sure you're entirely correct that in a multi-person coding venture it's
vital that one format code in ways that will be easy for others to
understand later on. That's true in private, personal coding too -- I may
want to come back to a game five years from now and update it.
But that's not expressivity. Not unless we've wandered into the land of
Humpty Dumpty, where words mean precisely what you want them to mean.
--JA
Max Payne
news:0k16j4-...@quicksilver.fsf.net...
But this doesn't apply to IF source code, since IF source code is rarely
(ever?) maintained after the original author's departure. And since it
doesn't have an audience, its expressiveness is of little consequence. It's
a by-product, like defecation. It may hold sentimental or didactic value,
but it has no aesthetic relation to the end-product. Elegant source code may
compile into an inelegant game, and brainless spaghetti code may compile
into a brilliant game.
If anything, I would advise authors to destroy their source code prior to
departure. Reading the source code of a game you love is like watching your
grandparents having sex. That's why my will contains instructions for the
destruction of all my IF source code. I can almost hear my future
biographers moaning with despair. I'm sorry guys, but the very thought of
having you poke at the springs and gears of my games sends shivers up my
spine.
ChicagoDave
> "Adam Thornton" <a...@fsf.net> skrev i meddelandetnews:0k16j4-...@quicksilver.fsf.net...
>
>
>
>
>
> > In article <f3ph9b$lk...@aioe.org>, Jim Aikin <edi...@musicwords.net>
>
> - Show quoted text -
This is entirely untrue, especially with the advent of TADS 3 and
Inform 7, which rely on shared open source extensions with common
functionality. These extensions are hardly encapsulated pieces of code
and are usually published with at least some minimal level of
commenting and logical structure.
And a great deal of Inform 7 code has been produced by Graham and
Emily that is arguably clean and readable and very important to the
Inform 7 user base.
Now you write your own game and sure, no one need ever see that code,
but understanding good coding practices is just as helpful to an IF
author as it is to a C++ programmer. You're only hurting yourself if
you write sloppy code.
David C.
Adam Thornton
>grandparents having sex.
That explains so many things about so many things.
Adam
Hector Rodriguez
something like Knuth's concept of literate programming (sorry if the
term was confusing). I was primarily interested in the question of
whether anybody in the group treats the source code itself as a medium
(rather than a tool). In calling it a medium, I mean that it can be
appreciated in its own right, as an integral part of the artwork, or
perhaps that a full appreciation of the artwork requires some
appreciation of the source code. (I am not saying that I really
believe this; I only wanted to open up the question).
Many responses to my original post suggest that most authors see their
programs as tools that are not integral components of the art work as
art work.
Another issue I was interested was whether, at least in the case of
Inform 7, there is some relationship between progrmaming language
design and cognition (ie., some theory or ideology or philosophy about
what cognition is), or whether a programming language really is purely
utilitarian (ie., just a tool to get the job done).
I was also trying to understand something I read (I think it was in
Graham's paper) to the effect that natural language programming is
somehow more suitable to the writing of IF. But if the source code is
just a tool to get the job done, I am not sure that the use of natural
language makes any difference (except that it has utilitarian
benefits: making development faster and more fun, faciliating
learning, etc.).
Adam Thornton
Hector Rodriguez <smh...@cityu.edu.hk> wrote:
>When I wrote "expressive code" in the first posting I was thinking of
>something like Knuth's concept of literate programming (sorry if the
>term was confusing). I was primarily interested in the question of
>whether anybody in the group treats the source code itself as a medium
>(rather than a tool). In calling it a medium, I mean that it can be
>appreciated in its own right, as an integral part of the artwork, or
>perhaps that a full appreciation of the artwork requires some
>appreciation of the source code. (I am not saying that I really
>believe this; I only wanted to open up the question).
I do.
_SMTUC_ had source available. My WIP will almost certainly have source
available with it, and it's been available to my testers all along,
although I don't think they have been looking at it.
I try to make it as pleasant to read as possible, and to call attention
to the things I'm doing in it for the edification and amusement of those
reading the code.
For example, from the _SMTUC_ sources, for the, ah, eponymous object,
some commentary:
! The Infamous Stiffy
! Please note what a gorgeous object-oriented style I'm using.
!
! turgidity is a private property, which, had I real data types, would
! be represented by a signed char. So I enforce the value constraints
! in the setStatus() method.
!
! Because turgidity is private (oh, don't we wish it were, for
! Captain Makane!), you must therefore go through the
! appropriate access methods (heh) to manipulate (heh) it.
!
! These methods:
! setStatus(x): sets turgidity to x (-128 <= x <= 127).
! An argument outside these values will be silently clipped (ow!) to
! -128 or 127.
! changeStatus(x): adds x to turgidity
! getStatus(): returns turgidity
! inflate(): adds one to turgidity
! deflate(): subtracts one from turgidity
!
The code does pretty much what you would expect from that.
>Many responses to my original post suggest that most authors see their
>programs as tools that are not integral components of the art work as
>art work.
Well, not me. Not that I claim, generally to be creating art.
Adam
Andrew Plotkin
> something like Knuth's concept of literate programming (sorry if the
> term was confusing).
It may be relevant that the I7 compiler itself is written using CWEB,
Knuth's literate programming thingie. On the other hand, the I7
compiler source is not available yet, so this may not be very relevant
at all.
> I was also trying to understand something I read (I think it was in
> Graham's paper) to the effect that natural language programming is
> somehow more suitable to the writing of IF.
I think it is. For utilitarian reasons... I guess I think of
programming as being defined *entirely* by utilitarian factors.
(Clarity, elegance, fluidity, and fitness of tool to task are all
utilitarian.)
John Roth
> When I wrote "expressive code" in the first posting I was thinking of
> something like Knuth's concept of literate programming (sorry if the
> term was confusing). I was primarily interested in the question of
> whether anybody in the group treats the source code itself as a medium
> (rather than a tool). In calling it a medium, I mean that it can be
> appreciated in its own right, as an integral part of the artwork, or
> perhaps that a full appreciation of the artwork requires some
> appreciation of the source code. (I am not saying that I really
> believe this; I only wanted to open up the question).
There's a very old software developer's maxim: comments lie.
Expressive code means, to me, that the code itself is expressive - a
suitably experianced developer can read it like a book and understand
it without explanatory comments.
I tend to take a modern viewpoint: code should be accompanied by a
suite of developer (NOT unit) tests that are organized to tell the
story of how it was developed and what it's supposed to do from the
developer's viewpoint. The fact that they're executable means that
they have to tell the truth at least to the extent that they work.
Parenthetically, there are at least two well recognized holes in using
this as the only documentation: it is very difficult to create an
overview, and it doesn't lend itself to discussing why one approach
was chosen over another. Neither difficulty applies to documenting at
the low level, which is where most programmers are urged to write
comments.
It should also be accompanied by a suite of customer-facing tests that
tell the story of what it's supposed to accomplish from a customer
viewpoint. These also have to be executable, and for the same reasons.
Text lies. Running code doesn't.
>From my viewpoint, I7 is a huge improvement in the first factor: it's
a lot easier to read from a game developer's viewpoint. It's truely
awful from the other two viewpoints: the developer test facilities are
rudimentary at best, and the play testing facilities don't lend
themselves to any meaningful automation.
This is not to say that I've got any better suggestions; I've been
mildly bemused about how to do automated testing the way I'm used to
in IF for quite a while.
To drill a bit deeper, and with all due respect to Don Knuth, I think
that Literate Programming is a mistake. To reiterate my first
sentence: documentation lies. Executable code doesn't. What Literate
Programming is good for is writing computer science textbooks
illustrating algorithms that aren't going to be under active
maintenance.
This may actually be a good choice for I7 - Graham Nelson has, I
think, somewhat of the same objectives as Don Knuth: to present the
work for an academic and student audience, rather than just for
software developers interested in extending it.
Also in counterpoint, the I7 program itself is accompanied by a very
good set of automated customer facing tests: the examples in the
documentation. It remains to be seen how Graham Nelson's exposition of
the code would compare with a good set of developer tests.
> Many responses to my original post suggest that most authors see their
> programs as tools that are not integral components of the art work as
> art work.
>
> Another issue I was interested was whether, at least in the case of
> Inform 7, there is some relationship between progrmaming language
> design and cognition (ie., some theory or ideology or philosophy about
> what cognition is), or whether a programming language really is purely
> utilitarian (ie., just a tool to get the job done).
You might want to look at material on DSL (Domain Specific Languages)
for a take on this. From my viewpoint, I7 is a domain specific
language, the other authoring systems are conventional programming
languages with domain specific features.
> I was also trying to understand something I read (I think it was in
> Graham's paper) to the effect that natural language programming is
> somehow more suitable to the writing of IF. But if the source code is
> just a tool to get the job done, I am not sure that the use of natural
> language makes any difference (except that it has utilitarian
> benefits: making development faster and more fun, faciliating
> learning, etc.).
To continue on the theme of I7 being a Domain Specific Language: these
languages are intended for domain experts to write their own programs,
rather than have to work with a professional development team. A well
designed DSL is a joy to use because it directly expresses the domain
concepts without the necessary programming language stuff getting in
the way more than necessary. Equally, it's a PITA to use outside of
its intended domain.
For the rest of it, I think it's a false dicotomy. Automated
entertainments aren't entirely new; there seem to have been some lost
experiments in robots and suchlike from classical Greece through the
Medievals, and possibly in other parts of the world. What goes on
behind the scenes isn't part of the art; that's what the viewer sees.
John Roth
Jacek Pudlo
>>When I wrote "expressive code" in the first posting I was thinking of
>>something like Knuth's concept of literate programming (sorry if the
>>term was confusing). I was primarily interested in the question of
>>whether anybody in the group treats the source code itself as a medium
>>(rather than a tool). In calling it a medium, I mean that it can be
>>appreciated in its own right, as an integral part of the artwork,
If it "can be appreciated in its own right," then it's an independent
entity, not an integral part of the artwork.
>> or
>>perhaps that a full appreciation of the artwork requires some
>>appreciation of the source code. (I am not saying that I really
>>believe this; I only wanted to open up the question).
Of course you don't believe it -- the supposition is flatly fallacious.
> I do.
What, Adam?
> _SMTUC_ had source available. My WIP will almost certainly have source
> available with it, and it's been available to my testers all along,
> although I don't think they have been looking at it.
Most women have bad figures and look their best with their clothes on. The
same applies to IF.
> I try to make it as pleasant to read as possible, and to call attention
> to the things I'm doing in it for the edification and amusement of those
> reading the code.
Say a potential player reads your source code and understands *exactly*
what's going on. Is there *any* reason for said player to play the game?
Hector Rodriguez
because it directly expresses the domain concepts without the
necessary programming language stuff getting in the way more than
specifically for IF ought for some reason to use natural language.
Other very successful DSL's, such as CSound (to mention one that I am
also familiar with), don't. Same applies to YACC. So I wonder whether
natural language programming is required in order to express domain
specific concepts in the case of IF. One argument could be that NLP is
needed to align the language used by the programmer and the language
used by the player. (Again, I seem to remember something in Graham's
paper to this effect). But why is such an alignment important? Why
pursue this goal? It is true that IF differs from other kinds of
fiction (ie., traditional books, stories, etc.) in that the literacy
needed to write it differs from the literacy needed to read/play it
(ie., the author needs to know a programming language, but the player
does not). But does anything of any significance follow from this
concerning the design of the language?
I also thought of another thread, concerning Victor's entry in the
innovation comp. In a sense, the idea is to let the player herself had
some input into the design of the world (and this might mean, perhaps,
letting the player adopt a role that is a little like being a
programmer). Could it be that natural language programming, and the
sort of writer-player alignment that it provides, facilitates such a
project? Would this provide a good justification for the design
decisions involved in I7?
To follow another line of thought: The point was raised by another
poster that perhaps the source code is not integral to an IF work
because a player who reads and fully understands the code would no
longer want (need?) to play the game. This is an interesting point,
but I am not sure (I mean that, I am really not sure) that it is true.
Let me give an (admittedly remote) example to clarify what I mean: a
colleague of mine designed a ray tracing algorithm which violates
physical laws (the angle of incidence is not equal to the angle of
reflection, and the difference depends on an arbitrary procedure). He
could understand very well the design of the algorithm (he wrote it)
but he still did not know what the rendered images would actually look
like. He had to wait to render the images. Knowledge of the algorithm
does not detract from the experience of looking at the images, which
experience is full of wonder, even to the author of the source code.
Is this so different from IF? I wonder whether actually understanding
the code makes playing the game superfluous. Do programmers not feel
surprised by what happens during gameplay, even though they designed
the game?
I wonder whether a better (more fine-grained, more informed)
appreciation of an IF work might mpt require some understanding of the
programming issues involved (just as a full appreciation of a
photograph does require some understanding of camera basics like F-
stops, etc.). Of course, anyone can look at a picture and enjoy it,
without any knowledge of the difficulties/craft involved in making it,
but I am sure that a full appreciation requires some background
understanding of the techniques involved. Just as anyone who wants to
appreciate a photograph in depth should understand the interaction of
the camera technology and the finished image, it might be that a
person who wishes to appreciate IF might need to be (at least
somewhat) informed about the relationship between the source and the
game play. To understand this relationship, one needs to understand
both elements, and their interactions.
Again, I am not sure of anything here, take all of this as a spring
board for disagreement, contestation, whatever. I am only sure I am
expressing myself badly.
greg
> I guess my question was whether a DSL designed
> specifically for IF ought for some reason to use natural language.
I can't see any reason why that should be so. There
are counter-examples -- I would say that Alan is
just as much of an IF DSL as I7, and while much of
its syntax is clearly inspired by English, it
couldn't remotely be mistaken for natural language.
As I understand it, the reason Graham chose to use
natural language wasn't because of anything inherent
to the problem domain, but to try to make it attractive
to people who are scared off by anything that looks
like programming. Anecdotal evidence suggests that this
may be working to some extent.
There's a price to be paid for this, however. The NL
layer tends to distort and obscure the underlying
structure of the system, and when you need to do
some general programming -- which you eventually do
in order to achieve anything new and interesting in
IF -- the NL syntax makes it much more difficult
than it would otherwise be. So it can be frustrating
for people who *are* programmers and don't need or
want the NL sugar coating.
--
Greg
Jeff Nyman
news:5ci2dqF...@mid.individual.net...
> There's a price to be paid for this, however. The NL
> layer tends to distort and obscure the underlying
> structure of the system, and when you need to do
> some general programming -- which you eventually do
> in order to achieve anything new and interesting in
> IF -- the NL syntax makes it much more difficult
> than it would otherwise be. So it can be frustrating
> for people who *are* programmers and don't need or
> want the NL sugar coating.
I do, in general, agree with this.
In another thread I mentioned how I'm teaching Inform 7 as part of a class
of creative storytelling, one audience of whom is children. When I do *just*
that, Inform 7 works marvelously well. It lets the children immediately
start creating interesting stories because, in all, they don't want to delve
too far into "IF conventions", for lack of a better term. So, for them, the
natural language aspect works perfectly well.
In another class that involves adult writers (with little programming
experience) I find an interesting thing: the problems they run into are
similar to what I, as a programmer, have run into: when you try to make
Inform 7 do something "complex" or "interesting" in terms of IF, you often
run into issues. Dealing with walls is one example. Another was a thread I
posted regarding giving proper names to objects. There are many other
examples I've come across.
Now, I'm not saying Inform 7 can't handle these things. It usually can, in
some way. But you get into these situations where you're sort of "fighting"
the natural language in order to mold it to the shape you want so it will do
what you need. Eventually the code you produce is far removed from anything
that's truly "natural language."
If you already know Inform 6 or if you already know Inform 7, these things
are easy to gloss over, particularly if you have a programming background or
are used to the conventions and concepts that surround IF development
systems. When you present the language, however, to people who don't already
know those things, the opinion I'm coming to is that the natural language
ultimately does obscure too much. Again, unless the venue in which you are
using it (i.e., in the case with the children using it to construct stories)
is rather limited.
And, again, just to be clear: I'm not saying that Inform 7 is necessarily
limited; rather, it's the usefulness of the natural language that I
ultimately find limited, which often has to be "broken" as you get into more
complex constructs.
- Jeff
travel2light
> appreciation of an IF work might mpt require some understanding of the
> programming issues involved (just as a full appreciation of a
> photograph does require some understanding of camera basics like F-
> stops, etc.). Of course, anyone can look at a picture and enjoy it,
> without any knowledge of the difficulties/craft involved in making it,
> but I am sure that a full appreciation requires some background
> understanding of the techniques involved. Just as anyone who wants to
> appreciate a photograph in depth should understand the interaction of
> the camera technology and the finished image, it might be that a
> person who wishes to appreciate IF might need to be (at least
> somewhat) informed about the relationship between the source and the
> game play. To understand this relationship, one needs to understand
> both elements, and their interactions.
This is just my 2 pennies - but I think it is the sign of a good
photographer, that he or she can communicate to a viewer without the
viewer having any understanding of the science and techniques of
photography. On the other side of the same coin - a photographer
really needs very little technical knowledge to produce a great
photograph. This is especially true if the equipment used is
technically advanced enough. Photography is a creative process, and so
the artist is communicating his own perceptions, both inner and outer.
Without perception, and without 'who the artist is' there is nothing
created of much merit. You could even say that it would merely be
copying.
The same is true with interactive fiction writing. Maybe the intention
of Inform is to be a step along the road towards a fully automatic,
easy to use, digital SLR camera. I don't think anyone would say it is
quite there yet. So far my impression is that it is still a
programming language. Basically we are still having to deal with
functions and conditional statements. There has been some power added,
some ease of use. Whereas before we may have needed to set the
aperture and shutter speed independently (using tables) - maybe now we
have the advantage of aperture priority mode. So now we can simply set
the aperture and the shutter speed is automatically calculated and
set. But I don't think the natural language programming of inform has
yet reached the stage of a fully automatic, multi-segmented automatic
exposure system with image stabalisation and automatic sensor
sensitivity adjustment. So to use Inform 7 we still need to be able to
think like a programmer, and express ourselves like a programmer. As
if were a technically trained photographer who is still relying on an
old OM-1 SLR film camera.
Michael
Andrew Plotkin
>
> In another class that involves adult writers (with little programming
> experience) I find an interesting thing: the problems they run into are
> similar to what I, as a programmer, have run into: when you try to make
> Inform 7 do something "complex" or "interesting" in terms of IF, you often
> run into issues. Dealing with walls is one example. Another was a thread I
> posted regarding giving proper names to objects. There are many other
> examples I've come across.
>
> Now, I'm not saying Inform 7 can't handle these things. It usually can, in
> some way. But you get into these situations where you're sort of "fighting"
> the natural language in order to mold it to the shape you want so it will do
> what you need. Eventually the code you produce is far removed from anything
> that's truly "natural language."
I've only done one medium-sized I7 game, but that actually wasn't my
experience. Or rather, it was... but not quite for the reasons you're
describing.
In _Wallpaper_, I hit places where I had to drop out of I7 entirely --
so "natural language" wasn't an issue at all. (I'm including "X
translates to [I6 property] Y" in this category. Or lines like "Kind X
is always an Inform library male.")
However, most of what I did in _Wallpaper_ -- which was at least a
*little* outside the common boundaries of IF -- didn't push the limits
of the I7 *syntax* at all. I defined kinds, properties, relations,
phrases, and rules, exactly as described in the manual. No line of
code was structurally any weirder than the manual examples.
Now, I agree that the naturalness of I7 gets strained in some areas.
The first time you go to make a room, you type "The Kitchen is a
room", and it works. The first time you go to make and use a relation,
you make six mistakes before stumbling into the right wording. (This
was my experience. Take it or leave it.) But this didn't feel to me
like "fighting the natural language"; what I wound up with was as
natural as any other possibility. What I was fighting was a parser
that was more brittle in that area than in other, more commonly-used
ones.
So I had, at one point:
Destinality relates various portals to one room.
The verb to inject (it injects, they inject) implies the destinality
relation.
You don't get much wiggle room with those sentences. And the first one
is practically guaranteed to be a WTF; you have to make up a silly
name for the relation. (Although I admit that once I realized that, I
chose "destinality" as being particularly silly. And "inject", as well.)
So, is that the sort of thing you're talking about? Or was it stuff
like the "if begin end if" construction, which I must have gotten used
to when I was writing _Wallpaper_, but which sort of slaps me upside
the eyeballs now that I look back at it?
(More I look at it, the more I want to tell the indentation-haters to
suck it up and cope... good thing I'm not in charge of the language.)
--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."
Jeff Nyman
news:f41v9p$rvf$1...@reader2.panix.com...
> So, is that the sort of thing you're talking about? Or was it stuff
> like the "if begin end if" construction, which I must have gotten used
> to when I was writing _Wallpaper_, but which sort of slaps me upside
> the eyeballs now that I look back at it?
Both parts of what you bring up are part of what I was referring to. I'm
looking at it from a series of different viewpoints (which probably isn't
necessarily fair to Inform).
One such viewpoint is just your basic programmer type who is familiar with
the IF "tropes," so to speak, and what it takes to get a game working. So
you're used to perhaps how such systems handle directions or walls or
various other things. This refers to probably many of the people on this
newsgroup who have been writing text-based interactive fiction for many
years, whether with Inform or some other system. (Note that this
programmer's skills could be solely in the realm of interactive fiction
systems.)
Another viewpoint is the non-programmer who may or may not have an interest
in programming in general but does have an interest in writing text-based
interactive fiction as a type of game. So here I'm talking about the
non-programmer who wants to write a game and sees text-based interactive
fiction as a viable route to that goal. This is sort of where I think the
lowered entry barrier for new authors comes in.
Another viewpoint is the non-programmer who has no interest in programming
but does have an interest in writing text-based interactive fiction as a
type of writing style. So here I'm talking more about the writers who see
text-based interactive fiction as a viable medium upon which to ply their
trade (or at least a variation of their trade).
I see Inform 7 (based on some of what I read) trying to cater to each type.
So ... when I "fight" Inform sometimes in the first category, here I mean
that no more than I would have fought with Inform 6 over the same kinds of
issues. Here I'm more speaking as someone who has tried various such systems
(TADS 2/3, Hugo) and has tried to compare which I "fight" with less, in
terms of it allowing me to do what I want to do without having to jump
through too many hoops. I find that Inform 7, for me, makes the fighting
more obvious, perhaps because the expectations of the natural language are
not as easy to set. (Very provisional statement there!) The issue with the
proper name that I brought up in a separate thread is perhaps a good
example. In Inform 6 and TADS 3, when I learned how to do this it was really
no harder, in terms of amount of code, than that of Inform 7. But in Inform
7 I found that I had to conceptually think about it differently than the
surrounding Inform 7 code. That's not something I dealt with in Inform 6 and
TADS 3.
When I say I "fight" Inform relative to the third category, here I mean that
Inform 7 seems to be saying, as part of its design, that natural language is
a way to conceptualize writing text-based interactive fiction and, further,
that people who have other goals ("a tool for writers intrigued by
computing") would find the natural language more amenable. However, when I
work with writers (of various pedigree) I find them having very interesting
conceptual difficulties. In many cases, those difficulties are things I
would have glossed over due to my past experience with (a) programming and
(b) programming text-based interactive fiction specifically.
When I started to chart what things I would have glossed over and my group
of writers was not glossing over, I found it interesting in that the
concepts, with Inform 7, tended to fall along those lines where you were
doing anything other than simply defining rooms and objects or some basic
interactions (such as instead/before/after rules). That probably seems
obvious but now consider that in most cases I've found that people don't
have issues with the if...otherwise type stuff. Rather, it's with the notion
of relations and the notion of procedural rules. When I try to drill down
into the why's of this, I find that people are stumbling over how they think
about their story and how they then relate the structure of the story they
want to tell with those particular structures in Inform 7.
Yet ... and here's something interesting. (Well, to me, at any rate.) When I
presented the same concept of relations and rules via the relation.t and
rules.t modules of TADS 3 (which is all non-NL programmatic, of course) I
found that my non-programmers picked up not only the concepts much easier,
but could repeat the programmatic details in a different context much
quicker than they could with Inform 7. (Caveat: it's not the same group of
people. I have one group using Inform 7 and another group using TADS 3.)
I'm really curious to follow this up more. I suppose to be consistent, I
should probably have used Inform 6 but I'm going with TADS 3 because one
thing that TADS 3 and Inform 7 make abundantly clear is a difference in
world model presentation as well, which is something I found to be an issue
for writers and for those not familiar with IF concepts, again from a
conceptual view.
- Jeff
Adam Thornton
Jacek Pudlo <ja...@jacek.jacek> wrote:
>Say a potential player reads your source code and understands *exactly*
>what's going on. Is there *any* reason for said player to play the game?
Sure. Reading through the Table Of Persephone's Chatter is a different
experience than asking her about a bunch of stuff.
Adam
Andrew Plotkin
> presented the same concept of relations and rules via the relation.t and
> rules.t modules of TADS 3 (which is all non-NL programmatic, of course) I
> found that my non-programmers picked up not only the concepts much easier,
> but could repeat the programmatic details in a different context much
> quicker than they could with Inform 7. (Caveat: it's not the same group of
> people. I have one group using Inform 7 and another group using TADS 3.)
Hm. Yes, that is interesting. :)
Do you think it is relevant or irrelevant that I7 is thoroughly
enmeshed with rules and relations, whereas T3 has them as extensions
for optional author use?
--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.
Jeff Nyman
> Do you think it is relevant or irrelevant that I7 is thoroughly
> enmeshed with rules and relations, whereas T3 has them as extensions
> for optional author use?
To be perfectly honest, I have no idea.
I think part of what I'm noticing is that people have one way they think of
the ideas in their heads and then they want to translate that thinking
directly to the code. With TADS 3, the code makes it clear what it will and
will not accept because of its structure. With Inform 7, the code is no less
structured, but it doesn't always make it clear when or how that structure
should be used. In other words, I think the heuristics for doing things are
not always clear. That's vague, but it's the best way I can think of it
right now.
But as I write that out, even that's not quite correct because people, I
find, can eventually learn the structure of Inform 7 just as well as
anything else. What it more seems to be is that point where they try to
translate the idea from their head into the code. More to the point, I found
people understood relations and rules as a concept, but were continually
"fighting" to figure out when it made sense to use them. Whereas, with TADS
3 I didn't find that people were confused as much about when to apply
something.
Interestingly, in most cases, they found they didn't need to use relation.t
and rules.t at all. The only time they used rules.t is when they
conceptually couldn't think of something as applying to any particular
object at all. Otherwise, conceptually it made sense to them to attach their
"concepts" to objects. I found that when people were thinking in terms of
the objects, they were better able to generalize and use similar solutions
in other objects or determine when it made sense to use something like
rules.t. With Inform 7 I found that wasn't always the case; people had
trouble seeing how you could generalize situations or when it would make
sense to do so.
As an example, some writers wanted to use the idea of relations to establish
NPC knowledge about things in the world that had been found as part of an
investigation. (Suspect A hates Suspect B, but Suspect B secretly loves
Suspect A. Suspects C and D believe Suspect B is the murderer. Suspect D
believes Suspect C is lying about his belief that Suspect B is the
murderer.) People, I find, can put the relations to use in terms of saying
what relates to what. But then it's effectively putting those relations to
use that the conceptual difficulties start coming in.
For example:
<I7 code>
Suspicion relates one thing to another (called the suspect).
The verb to suspect (it suspects) implies the suspicion relation.
Person A suspects the Person B.
</I7 code>
Then you might have logic like:
<I7 code>
if Person A suspects someone (called the target suspect).....
</I7 code>
But where I find people have a problem is determining how to actually get
the 'target suspect' for Person A in a way that's usuable for the purpose of
actually doing something with that concept in terms of the story.
Now, I should make something clear. In my previous post, I said: "When I
presented the same concept of relations and rules via the relation.t and
rules.t modules of TADS 3 ..."
The part to make clear here is not that people found relation.t easy to use.
In fact, the opposite. They found it vastly confusing. However, they also
saw that they really didn't need it anyway, as I indicated before. They were
more comfortable with the idea of various suspects being distinct objects
and setting the value of "properties" for those suspects that indicated who
they did and did not suspect. They *did* find rules.t useful for situations
where things in the game crop up that cause people to change their
suspicions, but not related to just one object.
However, the rules aren't that much of a problem even with Inform in all
cases. To wit, in some things, Inform 7 clearly was more intuitive for what
people wanted. Here's an example of one such idea:
<I7 code>
Murder is a scene. Murder begins when the player is given enough time.
Going a direction is exploring.
Carry out exploring for the tenth time: now the player is given enough
time.
Yourself can be given enough time.
When Murder begins:
say "The murder has occurred."
</I7 code>
Here's one idea of that in TADS 3:
<T3 code>
exploring : ActionRule
counter = 0
action = TravelAction
exec()
{
counter++;
}
;
murderScene : StoryPoint
{
checkActive()
{
if (exploring.counter == 10)
return true;
return nil;
}
doPreCmdCode()
{
"The murder has occurred.";
}
}
</T3 code>
Notice how the Inform 7 version let's the writer not so much consider the
notion of "turn" but rather allows for the idea of the notion (concept) of
'exploring' tied to the idea of 'going a direction.' *That* kind of thing is
where the writers of the group greatly prefer Inform 7. I can hide the
"turn" concept a bit with the TADS 3 code, as I did, but the "counter" is a
bit of a giveaway.
Hmm. In writing all this out, it occurs to me how I might start approaching
this a bit differently in terms of the relations concepts. I'm thinking of
perhaps a type of value that has "above suspicion" and "below suspicion" or
something like that. Each suspect would have one of those values. Then I
could say something like "if Person A suspects someone (called the target
suspect) and the target suspect is not above suspicion" and then take it
from there.
What's also interesting as I write this out is that I realized that people
prefer a more "code-like" feel when doing certain things but appreciate the
"NL-like" feel when doing other things. Mind you, the people I'm talking
about here are non-programmers. Unfortunately, I don't have anywhere to go
with that point right this second, but it just occurred to me and perhaps it
suggests that part of the confusion is that even the code-like parts that
they prefer with Inform 7 are still too NL-like so that's where the
conceptual difficulties come in.
- Jeff
mikegentry
> Now, I agree that the naturalness of I7 gets strained in some areas.
> The first time you go to make a room, you type "The Kitchen is a
> room", and it works. The first time you go to make and use a relation,
>
> So I had, at one point:
>
> Destinality relates various portals to one room.
> The verb to inject (it injects, they inject) implies the destinality
> relation.
The first relation I defined in Anchorhead:SE went like this:
An indignity is a kind of thing.
Suffering relates one person to various indignities.
The verb to suffer (he suffers, they suffer, he suffered, it is
suffered, he is suffering) implies the suffering relation.
I actually spent several days with a thesaurus, trying to find a
wording that would let the source "read" nicely.
Jacek Pudlo
> The first relation I defined in Anchorhead:SE went like this:
>
> An indignity is a kind of thing.
> Suffering relates one person to various indignities.
> The verb to suffer (he suffers, they suffer, he suffered, it is
> suffered, he is suffering) implies the suffering relation.
>
> I actually spent several days with a thesaurus, trying to find a
> wording that would let the source "read" nicely.
You needed several days of thesaurus perusing to find the word "indignity"?
Next time you need help with your English, Mike, give me a call. It'll save
you days of work.
Hazard Suit
Year, sure, bash the Anchorhead-author for bad wording.
*I'm sorry I fed the troll, but I just love Anchorhead*
Jacek Pudlo
Authors deserve to be bashed for bad wording, just as surgeons deserve to be
bashed for bad surgery, leaders for bad leadership, cooks for bad cooking,
etc. The point is that without criticism there'd never be any improvement.
Hazard Suit
Year, but there is no bad wording in the game...The thing you took for
bad wording was in the source code for an upcoming one...
namekuseijin
> > interface with which the programmer interacts with the compiler.
I don't completely agree, but in a sense different interfaces have
serve different purposes and have different strengths and weaknesses.
Some lead better to an elegant solution at a specific domain space
than others.
> > I would argue that the *principal* audience of the program is *NOT* the
> > compiler. The compiler doesn't care *how* you express yourself, as long
> > as it's syntactically correct. It doesn't care whether your variable is
> > named "i", "loop_index", "I_004", or "threebatsandanaardvark", or
> > whether you've commented your code at all.
As an author, I'd certainly care. Someone pointed out, once a work of
IF is perfected, it's rarely maintened. However until it reaches that
point, surely wandering through well-written, compact, expressive --
as in "saying more with less words" -- code is better than a spaghetti
mess...
On 1 jun, 17:25, "Max Payne" <box...@mindspring.com> wrote:
> since it
> doesn't have an audience, its expressiveness is of little consequence. It's
> a by-product, like defecation. It may hold sentimental or didactic value,
> but it has no aesthetic relation to the end-product. Elegant source code may
> compile into an inelegant game, and brainless spaghetti code may compile
> into a brilliant game.
>
> If anything, I would advise authors to destroy their source code prior to
> departure. Reading the source code of a game you love is like watching your
> grandparents having sex. That's why my will contains instructions for the
> destruction of all my IF source code.
LOL! it may still have didatic purpose, like some kind of recording
of the creative process of the author, kinda like DaVinci's
sketches... :)
namekuseijin
> There's a very old software developer's maxim: comments lie.
True. I mean, they do lie. :)
> Expressive code means, to me, that the code itself is expressive - a
> suitably experianced developer can read it like a book and understand
> it without explanatory comments.
yes. And a natural language-like declarative PL with well defined
"commented out" sections is specially expressive. I don't feel that
much a need for comments in I7 code, it's self-explainable.
> It's truely
> awful from the other two viewpoints: the developer test facilities are
> rudimentary at best, and the play testing facilities don't lend
> themselves to any meaningful automation.
what's exactly wrong with "teste me"?
> It remains to be seen how Graham Nelson's exposition of
> the code would compare with a good set of developer tests.
You seem obsessed with Unit Testing. Relax, this is not enterprise-
framework-programming-with-JavaEnterpriseEdition, it's a literary
narrative with puzzles. "test me" does the a fine job of just of
testing a given walkthrough and telling the "truth".
> From my viewpoint, I7 is a domain specific
> language, the other authoring systems are conventional programming
> languages with domain specific features.
I7 is mostly a preprocessing facility to transform the NL-like code
into I6 code, AFAIK. So, in your take I6 and TADS are conventional
programming languages with DSL features, huh? If that's true, why
have GN and MJR gone through all the trouble of designing such
languages and their compilers in the first place instead of simply
taking an existing language and writting a text-adventure library and
framework for said languages? You know many people in the past wrote
IF directly in C, Basic and shell languages, don't you?
I think instead they opted to have a DSL from the ground up and kept
adding some powerful general-purpose programming abstractions as they
needed.
> > I was also trying to understand something I read (I think it was in
> > Graham's paper) to the effect that natural language programming is
> > somehow more suitable to the writing of IF.
It certainly makes a lot of scene. In the past, OO programming was
employed precisely to map more easily everyday concepts and objects to
a programming model. If the compiler or preprocessor can accept NL-
like phrases the better. It's still OO underneath and under that just
binary digits running in a Turing machine.
In fact, I wonder if the I7 compiler is a first step in the direction
of true interactive storytelling. You know, that time when, rather
than having the player reading through room and character descriptions
and ask/telling or take/examining objects, the player can actually
more activelly participate in the storytelling by saying just like the
designer: "John and Mary are here. They look surprised at seeing me
as they thought I would be at my father's house."
Throw in some drama manager and some clevener AI manager and we
eventually get there... :)
> A well
> designed DSL is a joy to use because it directly expresses the domain
> concepts without the necessary programming language stuff getting in
> the way more than necessary.
yes, shame it's not seen more often, management bureaucracy requiring
instead everyone's heads to spin around java and tons of frameworks.
> Equally, it's a PITA to use outside of
> its intended domain.
...as there'd be no purpose whatsoever to use outside its domain
space. That's the purpose of making it a DSL in the first place.