Another Response to I7
steve....@gmail.com
It's a straight, confessional treatment, hoping to open and advance
some discussion. I wanted to get out a response now, and I may revise
my views as I investigate I7 further.
My overall feeling about the system is tentatively positive, certainly
interested. My overall feeling about its theorization (so far) is
partly negative, owing to the fact that Graham has confused some
issues. That's understandable, but it's also worth rectifying.
But before I proceed, let me quote Kevin Forchione:
"
>From what I've seen so far, Inform has made *great* strides with this
release, and the developers deserve a standing ovation for creating a
system that appears to be very newbie-friendly and an integrated
development environment that supports the entire development process.
The presentation layer is well-designed and looks like it takes much of
the tedium out of story development. That took a lot of work and is in
itself a major contribution to the interactive fiction community.
"
I agree with the sentiment and intention here. Kevin's words are golden
true.
==Two Themes==
I'm going to elaborate two main themes. The first is a critique of the
syntax, which I find is problematic (I'm tempted to say, needlessly
problematic) but certainly not fatal. The second is a critique of the
"rule-declaration plus black box" approach, which again is problematic,
but again not hopeless -- and certainly a direction I have long been
hoping IF would explore. (And I will always thank Graham for exploring
this avenue, even if I ultimately conclude that the approach is
impractical.) While the latter is of far greater personal interest to
me, for the moment I have more to say about the former.
As far as the theorization goes, Graham has been half-pretending (not
really, but rhetorically) that I7 really is a natural language
processor (NLP), and confusing these two entirely distinguishable
elements of the system: the syntax (Fake NL) and the underlying
structure (rule-based programming). I'll know more about the motive for
this confusion once this article I've been hearing about comes into my
possession; I'll hold off my judgment until then.
My hope is that I will find some other people who want to have a
serious discussion of this stuff, who do not have a stake (for whatever
reason) in confusing the issues.
Speaking of which, Graham writes, in response to someone who is giving
I7 quite more than a chance: "I'd suggest that people give the 'candy
sugary pseudo natural language syntax' a chance." For this discussion
to progress it is necessary to take these terms seriously.
First and foremost, I7 is not an NLP. On the contrary, it is, as Graham
acknowledges, a *Pseudo* NLP. The "Pseudo" part is absolutely essential
for understanding what it is. (In case you're not hip to the Greek,
"pseudo" simply means "fake.") And so, the first point:
==Fake NLP==
A Real NLP, properly speaking, is a program which takes a text which
was initially intended for human consumption, and does its best to do
with it one thing or another: automatic translation, data mining,
probablistic language processing, and other neat stuff like that. The
essential thing is that the machine processes text which was *initially
intended for human consumption*: the human is the addressee.
A Fake NLP is one which figures itself the addressee; its designer
pretends that it's sort-of human-like, and asks that the machine be
addressed in a sort-of human-like fashion. The ones we call Fake NLPs
are often based in science-fiction and techno-fantasy, from the Lexus
(luxury car) that understands "windows down" to the Enterprise (Star
Trek) that understands "computer: abort self-destruct sequence override
alpha gamma alpha." Some highly lame faux-friendly search engines
attempt something like this, and naturally, the conventional IF
command-interface is one of these also.
There's a lot of variation, but you can think of all these Fake NLPs on
the same conceptual level, in that the input is a concealed programming
language -- not communication in the natural sense, but coded
instruction. You remove that concealment -- "candy sugary syntax" if
you prefer -- and I7 is manifestly equivalent to C, Prolog, TADS or any
other programming language. The syntax is not natural: quite the
contrary: it is absolutely determinate.
My immediate thought on the I7 syntax was that it perfected the
pseudo-English pretensions of I6. In the syntax of I7, I saw the
logical conclusion of the simple I6 statement "has light".
"It has, has it?" I have said to myself more than once, with a little
smile at the English pretenses of I6. It always felt a bit pathetic --
not really anachronistic or nostalgic, not the embarassing and manifest
misguidance of years gone by, but evoking a very similar feeling. I
figured the I6 language would be cleaner if these pathetic pseudo-NL
bits were combed away.
My reaction is very different to I7's pseudo-NL. Impressive, yes. Neat,
sure. But let's slow down and take a more serious look.
==Sages' Clothes==
There's nothing terribly wrong with dressing up programming language in
sages' clothes, so long as you don't proceed to confuse the program
with the sage. Very unfortunately, Graham does just that:
Natural language is as optimised for talking about human situations -
the physical world, and the world of people - as C [or TADS] is for
low-level filtering of data in files.
This is a very contentious and unclear argument, which deserves a whole
lot more careful attention. First of all, it's based on a false
distinction. I7 is no closer to natural language than C (or TADS),
Prolog or I6, except cosmetically. The whole claim falls practically to
shreds once we admit that we're not actually talking about natural
language, but pseudo-natural language. By what logic and by whose craft
has pseudo-NL been optimized for talking about human situations? That's
the real claim here, and it's a highly non-trivial and I would say
quite contentious claim. And by what logic is pseudo-NL better than C
(or TADS) for -- not "talking about," but -- "programmatic modeling and
representation of" human situations? This is the beginning of a
discussion, not a foregone conclusion -- not, to my mind, even a likely
conclusion, although I would very much enjoy the discussion.
Really it's misleading to describe I7 even as "parsing of a subset of
natural language," as Stephen Granade does in his recent Brass Lantern
article, <http://brasslantern.org/writers/howto/i7intro.html>.
Granade's construction is not his own invention: Graham has pushed the
discussion in this direction. Thankfully, Granade produces the correct
qualification of the point:
I7's language is a subset of English. Graham Nelson's guiding principle
in designing I7 was that "the natural language in which to write
interactive fiction is natural language." Despite this, I7 does not use
natural language, but a subset of it. It's very similar to IF's in-game
parser in that way: there is the promise of the system understanding
anything you type, when in reality it understands only certain phrases
and constructions.
After a diversion, Granade returns us safely to "reality." Alas, that
diversion is really misleading, since we are decidedly *not* talking
about natural language parsing in the first place. (It's like an
advertising campaign which promises that the product will make your
hair grow, but then mentions in passing that any actual acceleration of
hair growth is entirely coincidental.)
The simple and essential point that Graham's claim attempts to
side-step: ALL computer programming code is a subset of natural
language. C, TADS, Prolog, etc., are just as much Pseudo-NL parsers as
I7. *The only difference is how far they pretend to be Real NL
parsers.*
==Conclusion on the First Point==
I'm not going to get into the question of whether it's ultimately
better for total novices if you (a) dress up the program's logic or (b)
expose it in bare shorthand from the beginning. Personally, I'd
recommend jumping into the real thing right away, but maybe that's the
cruel "teach the kid to swim by throwing him in" approach, and if you
want to start with Anglicized remedial logic, that's nice and kind I'm
sure. But whether it widens or sharpens the learning curve is not
clear, and it seems pandering to justify the novice's alienation, and
may even amplify it. Still, people learn differently, and you can make
up your own mind about this; obviously I lean towards clean and clear
code, but I'm not rabidly against pretending, so I'm not going to press
this issue -- not at this point anyway.
What I can say: a regular user is always going to appreciate the
shorthand, just as close friends develop a shorthand for communicating
with each other. Plus, when the logic is represented symbolically, it
becomes a lot clearer, and loses all its natural ambiguity, and with
just a tiny bit of practice, it's a whole lot faster to read. (For me,
that's probably the biggest plus.) Finally, the logic is so central --
it's *the* thing you're doing when you program -- and so it makes sense
to thematize it and make it as explicit as possible -- and certainly
not conceal or cloud it!
Stephen Granade is correct to point out a similarity between I7 and the
conventional IF player's-command-interface. He might go on to observe
that the same arguments we have against a Pseudo-NL command-interface
apply at least equally well to I7. The problems are probably legion,
but the first moment is the admission that, no, you have to follow
certain rules for writing the program. What are they? -- the immediate
question. As soon as you get there, once the cat is out of the bag,
you're probably better off being clear what the rules are.
One major charm of the IF command-interface is that it hides its rules,
conceals what you can and cannot do; it softens the limit -- not
actually -- but as an aesthetic effect. It tricks you into thinking
that it's more sophisticated than it actually is, by concealing and
making you guess at its potentials. I'm not saying that I7 does exactly
this: indeed it is clearly possible to document an obfuscated "candy
sugary" syntax as rigorously as a clean one, and I'm sure that all I7
manuals will try to do this. I'm still a bit skeptical about faking out
the user, encouraging guessing rather than learning, and whatever other
psychological effect is produced by I7.
So, as far as the pretensions at NL, at best it's arguably a mixed gain
for newbies. It may make things a little less alienating at the very
beginning, but by the time the newbie learns the structures which could
as well be presented in shorthand, the fact that it's in pseudo-English
is at best irrelevant, and could be misleading and confusing,
obfuscating in a bad way. For the power user, it risks being a constant
distraction, an onerous longhand, and a source of regular confusion,
not only of legal formations, but of the actual logical meaning of
one's own code.
==I7 minus Syntactic Sugar equals Rule Based Programming==
Stripped of the syntactic sugar, the sages' clothes, that is,
presenting the disposable Englishy bits in a transparent and much more
readable shorthand, like other languages do -- stripped of all that, I7
is a system for rule based IF programming. *THAT* is its strength, not
its pretensions at NL (which at best is a mixed gain for newbies, and
not much more). THAT is what makes it a really exciting experiment.
Rule-based programming is certainly not a bad thing, but it's a
problematic thing.
Rule-based programming is problematic because the algorithm and
program-flow occur outside of the view of the programmer. It's damn
difficult to debug, in particular because it's impossible to see if
it's right. It's often called a "black box" programming environment,
because you write these rules, and you basically put them into this
black box, and the box does whatever it does, entirely behind the
scenes.
Andrew Plotkin has theorized a very similar system, the main problem of
which, he explains, is the handling of rule precedence. My reaction to
I7 as a rule-based system is the same as my reaction to Plotkin's
theory (which I imagine was influenced by his exposure to I7
development). My reaction is, with a system like this, you lose the
program flow in the rules, just like you lose the forest in the trees.
That said, black boxes obviously totally obfuscate, and this is an
initial sacrifice towards some projected gain. I7 does well for making
this brave move, regardless of its success or failure in the final
analysis. So I close, as I began, thanking Graham for making this move,
because I think it had to be made, just as further versions of this (as
Andrew Plotkin is considering, for example) will have to be made.
If there's any ground for Graham's claim that I7 has a "sinewy
strength," it's that rule-based programming, despite the problems, is a
good approach to writing IF. This may or may not be the case, but
there's something to it, and at the very least I'm grateful the
experiment was done.
==Closing==
I'm tempted to say that the success or failure of I7 will eventually
become obvious. All we got to do is wait for history to write itself.
But history is merely a recollection of data, and now is the time for
the generation of that history.
There is no doubt that some people will have some success with the
thing. Its utility will be demonstrated by some successes. And although
I believe that we can see the major failures now at the beginning, time
will inform and affirm this also.
I hope this discussion becomes sufficiently critical, and that I7 does
not gradually, under false pretenses, become the status-quo -- that its
false claims are not granted uncritically. Things like this have a
tendency to gradually sink in until they're accepted, whether they're
good or not, simply because they're eventually normal. So it's
important at this point to look critically at the questionable claims,
before enough time passes that the question becomes too old to sound
like a question any more.
In the interest of full disclosure, I dug up a couple fragments that
had some influence on my thinking on the first of my two points:
http://groups.google.com/group/rec.arts.int-fiction/msg/6c069a160cb5685e
http://www.tads.org/howto/t3res.htm (paragraph 3 of the section, "What
does 'logical' mean, anyway?")
I certainly don't speak for Mike, but I agree that straight programming
notation (as opposed to cosmetic/pseudo-NL programming notation) is
ideal for programming, for a number of reasons I have mentioned above.
But there is at least one more...
Who is the addressee really, when you're writing in TADS? It's the
computer certainly, but the computer could have been addressed in any
arbitrary syntax; why this one in particular? My answer is somewhat
counterintuitive, but the answer is: you, the programmer, are the
addressee. And as a programmer, I want to be able to look at my code
and check the logic. I want to "brain" it, to see the whole logic, to
see that I haven't left anything out. I guess this is my predilection
for a certain kind of programming.
Andrew Plotkin
>
> Rule-based programming is problematic because the algorithm and
> program-flow occur outside of the view of the programmer. It's damn
> difficult to debug, in particular because it's impossible to see if
> it's right. It's often called a "black box" programming environment,
> because you write these rules, and you basically put them into this
> black box, and the box does whatever it does, entirely behind the
> scenes.
>
> Andrew Plotkin has theorized a very similar system, the main problem of
> which, he explains, is the handling of rule precedence. My reaction to
> I7 as a rule-based system is the same as my reaction to Plotkin's
> theory (which I imagine was influenced by his exposure to I7
> development).
Actually, the influence was two-way, if I may say it myself. When I7
was in a very early stage -- this was nearly three years ago -- I got
into an email discussion with Graham. In the middle of that, I came up
with this crazy rule-based model for IF programming, and wrote several
pages of "concept code"; not based on any rigorous model, but
demonstrating how I would do common IF tasks in a rule-like way.
I7 does not embody my theory wholesale, but it does use some aspects
of it. I will happily declare that this was my influence. :)
> My reaction is, with a system like this, you lose the
> program flow in the rules, just like you lose the forest in the trees.
The built-in tracing ("rules" or "rules all") helps with this. So does
the "Rules" summary in the Index page of the UI. One of the things I7
is trying to do is *not* be a black box, or at least to keep the box
part as small as possible; you can browse the world model in several
ways.
> That said, black boxes obviously totally obfuscate, and this is an
> initial sacrifice towards some projected gain. I7 does well for making
> this brave move, regardless of its success or failure in the final
> analysis. So I close, as I began, thanking Graham for making this move,
> because I think it had to be made, just as further versions of this (as
> Andrew Plotkin is considering, for example) will have to be made.
I would certainly like to create a language and a compiler which is
*completely* based on my rule ideas. (There are bits that I7 doesn't
include at all!) However, Graham did the three years of work, and I
didn't. So the comparison will have to wait... sigh.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
9/11 did change everything. Since 9/12, the biggest threat to American
society has been the American president. I'd call that a change.
Adam Thornton
<steve....@gmail.com> wrote:
>Finally, the logic is so central --
>it's *the* thing you're doing when you program -- and so it makes sense
>to thematize it and make it as explicit as possible -- and certainly
>not conceal or cloud it!
And here, I think, is the kernel of Steve Breslin's objection, and--I
think--the reason for much of his hostility.
I *think* one of the points of I7 is to make the act of writing IF more
akin to storytelling than to programming.
"But that's impossible! You have to be a programmer in order to write
IF!" I hear you cry.
To that I have a question:
Do you have to be a programmer in order to write a detective story? If
you answer "yes," then your definition of programming is uselessly
overbroad, as it means "The ability to construct logical chains of
causality." If you answer "no," then you have, I think, just admitted
that there may be non-programming ways to write IF.
As I've said to Graham before, I feel a bit like Moses contemplating the
Promised Land, knowing I myself won't reach it. I'm very comfortable
programming; I see no particular reason to change that, and this old dog
may simply not find it worth his time to learn a new storytelling
paradigm. On the other hand, I don't think I have a lot emotionally
invested in the proposition that programming is the only way to tell an
IF story, and if Graham can demonstrate that it ain't, then more power
to him.
Adam
Kyle Pierce
> There's a lot of variation, but you can think of all these Fake NLPs on
> the same conceptual level, in that the input is a concealed programming
> language -- not communication in the natural sense, but coded
> instruction. You remove that concealment -- "candy sugary syntax" if
> you prefer -- and I7 is manifestly equivalent to C, Prolog, TADS or any
> other programming language. The syntax is not natural: quite the
> contrary: it is absolutely determinate.
>
These are heady times, and despite my lack of portfolio, I will
respectfully dispense my opinion. I started learning TADS3 two years
ago, C++ 15 years ago, and Prolog 20 years ago. I recently posted
something here about designing a Prolog program that could start from a
high-level description and then generate a bunch of TADS code. Lo and
behold, here comes Inform 7, promising to make my dreams come true, and
then some (except for the TADS code part).
So I am feeling cautious about getting my hopes up too high, but I also
have something to say about how I believe I7 gets it right. Being
rule-based isn't enough to "get it right" if the semantics aren't there
to support the right level of description. I have certainly spent
plenty of time banging my head against Prolog for this reason -- it is
simply too sparse a language to use easily for IF, in terms of the
semantics. That is, you *can* get to the right level of description in
Prolog, but would you really *want* to do what it takes to get there? I
have asked myself the same question about all the IF languages I have
looked at. At this very early stage, it appears that I stand a better
chance of making the more challenging things happen with I7 than the
others. Time will tell.
I think the "syntactic sugar" arguments are a bit shy of the more
central point that could be made. The property of being a "sorta-NLP"
cosmetic layer on top of a procedural layer is not nearly as
interesting as the property of allowing the more fluent expression of
complex relational semantics. While it would surely be possible to
express the relational semantics of I7 in a more "code-like" style, I'm
not at all sure that it would be workable, at least for me -- given my
experience with Prolog. Even though I'm used to being a coder, I'm
interested in becoming a better IF writer rather than a better coder.
Thank you for your kind indulgence.
Kyle
Graham Nelson
been optimized for talking about human situations?"
The logic Inform uses is the model theory of first-order predicate
calculus with generalized quantifiers - it really isn't your typical
LALR(1) compiler inside - and as for "by whose craft", I would suggest
a look at the literature of linguistics, where the striking resemblance
between this logical formulation and natural language has been a
commonplace since about 1960. For what they are worth, my own views can
be found in:
http://www.inform-fiction.org/I7Downloads/Documents/WhitePaper.pdf
As for "pseudo-NL", if you are going to define "natural language" as
that context of discourse in which the reader is not addressed with a
specific intent agreed between both parties, then you must also exclude
laws, cookery books, dictionaries, encyclopaedias, and so forth. I
doubt such a definition can be viable.
Speaking personally, I was never embarrassed by "has light", any more
than I was embarrassed that C has a statement "continue" rather than
calling it "xl88_t". Still, while "key in Lodge" (I6) might be
embarrassing to someone of such sensitivities, "all except two of the
keys are in an adjacent room" (I7) is not so transparently a
paraphrase.
I do slightly object to quoting me thus:
"Natural language is as optimised for talking about human situations -
the physical world, and the world of people - as C [or TADS] is for
low-level filtering of data in files."
What is "[or TADS]" doing here? TADS is highly optimised for creating
IF, and is an excellent tool for doing so. We can agree on that,
surely? I hope it will not be thought I have ever said otherwise.
Andrew Plotkin
>
> I do slightly object to quoting me thus:
>
> "Natural language is as optimised for talking about human situations -
> the physical world, and the world of people - as C [or TADS] is for
> low-level filtering of data in files."
>
> What is "[or TADS]" doing here? TADS is highly optimised for creating
> IF, and is an excellent tool for doing so. We can agree on that,
> surely? I hope it will not be thought I have ever said otherwise.
Never mind TADS -- how is C optimized for filtering data in files? In
my experience, it's *horrible* at that.
--Z (and then, the Perl vs Python argument began)
(Seriously, C is optimized for working with fixed data structures in
memory. It can be abused into working with dynamic data structures,
and with data in files (and other I/O traffic). I offer myself as an
example of the long-term damage that abuse leads to...)
--Z (vs awk, vs sed...)
Aaron A. Reed
prove to become confusing as the new user starts wading into deeper and
more complex games. But there's an important angle I think may have
been overlooked: not everyone's brain is organized in the same way.
I've released two major games and have three others in variously
despairing states of incompleteness. I've written thousands of lines of
Inform code, and in the past have programmed in Java, C++, Pascal,
Perl, etc. But here's the thing: I'm a terrible programmer. I still
struggle to look at a block of code and figure out what it does. I
constantly have to refer to manuals for syntax; I get lost in my own
Inform 6 code; I'm a hopeless mess trying to navigate C. Maybe my brain
isn't quite wired the right way to do complex abstract symbol
manipulation--I don't know. But Inform 7, so far at least, has made
this far easier (for me) because it latches on to a metaphor that my
brain is much better at dealing with: the English language. Sure, it's
not natural language processing, but the experience is now framed in an
environment I'm better at dealing with, much like, say, a fisherman
might have better luck with his own rod than with a stranger's.
You're right that I7 is still programming, no matter how it's dressed
up, and you certainly still need to engage the same logical,
problem-solving circuits as when coding in any language. But a more
comfortable environment affects not just comprehension, but writing new
code as well. It's a lot easier (again, for me) to remember to say "The
red herring is a fish" than something like "private RedHerring = new
Fish(); ". I understand that saying "I hereby declare the red herring
to be a fish" is not going to work, just like a better programmer would
inherently understand that moving the punctuation marks around in a
line of Java code isn't going to have positive results. It's hard for
me to remember programming syntax, but I'm likely to immediately
remember an exact English phrase without having to pull up a manual.
Somebody said this is going to be a language that programmers hate and
bibliophiles love. I'm curious to see what kind of programs the
bibliophiles will write.
steve....@gmail.com
> I7 does not embody my theory wholesale, but it does use some aspects
> of it.
Credit awarded as due. (I should have guessed.)
> > My reaction is, with a system like this, you lose the
> > program flow in the rules, just like you lose the forest in the trees.
>
> The built-in tracing ("rules" or "rules all") helps with this. So does
> the "Rules" summary in the Index page of the UI. One of the things I7
> is trying to do is *not* be a black box, or at least to keep the box
> part as small as possible; you can browse the world model in several
> ways.
I gotcha. But I think (I hope) you can understand my qualm. (In case
you don't, some representative back story: I once went on a long tirade
against the TADS 3 parser, because the pattern matching stuff is
intrinsic. You can define the grammar rules that are matched, but you
don't get to see the algorithm that resolves the matching; it's native.
Even though it's arguably irrelevant, I wanted it to be exposed,
because closing this kind of thing off does limit the technical
development of the genre.)
steve....@gmail.com
> I *think* one of the points of I7 is to make the act of writing IF more
> akin to storytelling than to programming.
That's certainly one prevailing way of looking at it. It's lovely. But
substantial? Nope.
> "But that's impossible! You have to be a programmer in order to write
> IF!" I hear you cry.
Me? Man, you may as well call it unanimous. I mean, what IF theorist
has ever responded to "I want to write IF, but I hate code" with
anything other than an assurance that writing IF requires some skill
with code, no matter what. That's a go-to point on this newsgroup.
I, for one, am against go-to points. I like being devil's advocate. I
like challenging assumed positions. But in this case I'm going to make
an exception. Yes, you have to be a programmer to write IF. (Actually,
let me revise that slightly: "You have to be a programmer to write
interesting IF.")
> I feel a bit like Moses contemplating the
> Promised Land, knowing I myself won't reach it.
Join the club. IF is an unformed genre. I feel exactly the same way. I
don't want it badly limited, and in the same thought, I don't want it
badly steered.
> I don't think I have a lot emotionally
> invested in the proposition that programming is the only way to tell an
> IF story, and if Graham can demonstrate that it ain't, then more power
> to him.
No, that's not what he's doing. Maybe that's what he's pretending to
do, or maybe that's what he'd like to be trying to do, but that's
definitely not what he's doing. Fake NL programming is still just as
much programming as C or TADS or Prolog. He is not taking the
programming out of it, not one iota.
Craig Latta
> ...what IF theorist has ever responded to "I want to write IF, but I
> hate code" with anything other than an assurance that writing IF
> requires some skill with code, no matter what.
I respond with "well, then let's see if we can make writing IF
more like *playing* IF". We might lose a few people who want to write
it but don't like playing it, but that's okay. :)
-C
--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]
steve....@gmail.com
> [I] have something to say about how I believe I7 gets it right. Being
> rule-based isn't enough to "get it right" if the semantics aren't there
> to support the right level of description.
This is a fine question for rule-based IF development. What syntaxes
are ideal, and how each impacts the underlying structure.
(The main problem I have with Graham's presentation is that he colludes
syntax and structure. I'm going to read his article now, and maybe I'll
change my mind.)
> I think the "syntactic sugar" arguments are a bit shy of the more
> central point that could be made. The property of being a "sorta-NLP"
> cosmetic layer on top of a procedural layer is not nearly as
> interesting as the property of allowing the more fluent expression of
> complex relational semantics.
Exactly. I agree entirely.
> [I]t would surely be possible to express the relational semantics of I7
> in a more "code-like" style
I'm not recommending a "more code-like style" -- not exactly. I'm
saying the format should be easy to read: brief and clear, and
representative of what the underlying system does with it.
> Thank you for your kind indulgence.
Likewise.
ChicagoDave
>
> > I don't think I have a lot emotionally
> > invested in the proposition that programming is the only way to tell an
> > IF story, and if Graham can demonstrate that it ain't, then more power
> > to him.
>
> No, that's not what he's doing. Maybe that's what he's pretending to
> do, or maybe that's what he'd like to be trying to do, but that's
> definitely not what he's doing. Fake NL programming is still just as
> much programming as C or TADS or Prolog. He is not taking the
> programming out of it, not one iota.
I think this is at best an emotional grasp at something desperately
wished for, but in truth is a false statement and we have to define
semantics to clarify the point.
I define "programming" in a traditional sense. I've been doing this
thing called "programming" for 27 years (since I was 15) and it always
has revolved around lines of syntax with code blocks inside of
functions and subroutines. This syntax has taken on several forms, most
of which revolve around what is commonly called 3rd generation
programming syntaxes. 2nd generation was assembly and 1st generation
was machine code.
Inform 7 is what I would call a 4th generation programming language. So
in a sense Steve, you are correct. But your arguments tend to want to
say that I7 is in fact a 3rd generation programming language, which it
is most certainly not.
There are no subroutines, no functions, no lines of code, no "calls",
no separation of logic at various points.
It is built in the manner of a script, in the English language, and
using rules that are more or less specific to writing Interactive
Fiction.
I have two quabbles with your sentiment. One is that reading english is
way they hell easier than reading code and I've been reading code for
nearly three decades. Code requires translation from its syntax to
english. My brain at least registers english, not code. So when I see
this:
private int foo(int bar)
{
return bar + 2;
}
...I think to myself "the foo function increments the passed argument
by two"
I don't _think_ "private integer function foo accepts the argument bar
and returns bar plus 2"
There's a significant difference in how my brain functions from how I
write traditional code.
I can only imagine that someone untrained in 3rd generation programming
might be horrified to see squiggly braces but if they see this:
Incement bar by 2.
..well I think your whole argument that Inform 7 is "just programming"
goes right out the window.
I know that reads quite a lot simpler to me and I'm 100% absolutely
positive that the non-programmer will be able to read that perfectly
fine without any translation on my part.
Now....there's another subject here that you've left out. How do
non-programmers view logic. Speaking from many interview experiences, I
can honestly say that not everyone is comfortable speaking or thinking
in logical terms. Even if they are an expert at some task and you ask
them to break it down into logical steps, many people will become
flustered and completely lose their grip. They aren't trained in
thinking logically.
But training someone to think logically is not the same as programming.
I have known many business analysts that are far better at logical
thinking than I am, but I'm a better programmer.
I know writers that are far better at logical writing than I am, but
they couldn't code their way out of a paper bag.
So it's my belief that where Inform 7 is concerned, a non-programmer
will absolutely have an easier time and even some of us programmers
will have an easier time writing IF than we would doing it in code.
There is less translation from english to a second syntax and as long
as we're comfortable with basic logical thinking, we can easily succed
where we would get frustrated and quit if we had to do the translation
to a traditional 3rd generation syntax.
In an absolute sense you may call Inform 7 "just another programming
language", but as Graham pointed out, by your definition every type of
communication on the planet is a programming language. But my argument
is that you don't need to "code", you simply need to think and write
logically in english....which to me is _not_ coding, but it is in fact
writing.
David C.
steve....@gmail.com
> "I7 is no closer to natural language than C (or TADS), Prolog or I6,
> except cosmetically... By what logic and by whose craft has pseudo-NL
> been optimized for talking about human situations?"
>
> The logic Inform uses is the model theory of first-order predicate
> calculus with generalized quantifiers - it really isn't your typical
Yes, I gathered that you custom wrote it yourself.
Speaking of which, you did presumably write the system, so I expect you
could give a clear account of it, minus the disingenuous rhetoric
rambling.
You're avoiding the question. Your cavalier claim was that NL is
optimised for talking about human situations. My point is that you're
not actually talking about NL, and we're not actually talking about
human situations. We're talking about Fake NL, and algorithmic modeling
and description of human situations. It's a very sketchy analogy
indeed, and begs the entire question.
I'd love to evolve this into an intelligent discussion, but you've got
to cooperate a little bit.
> - and as for "by whose craft", I would suggest
> a look at the literature of linguistics, where the striking resemblance
> between this logical formulation and natural language has been a
> commonplace since about 1960.
I'm familiar with the range of modern logic, which is a sequence of
such striking resemblances, going back a couple centuries. What is it
in particular that I'm supposed to be struck with, and how is this
related to your project in particular?
> For what they are worth, my own views can
> be found in:
>
> http://www.inform-fiction.org/I7Downloads/Documents/WhitePaper.pdf
Thanks. I'll scope it out.
> As for "pseudo-NL", if you are going to define "natural language" as
> that context of discourse in which the reader is not addressed with a
> specific intent agreed between both parties, then you must also exclude
> laws, cookery books, dictionaries, encyclopaedias, and so forth. I
> doubt such a definition can be viable.
I'm not defining it like that at all, and if you thought about it for a
split second, you'd know it. I'd like to be charitable, but this is
almost undeniably disingenuous. I'm not asking that you participate in
the discussion or not, but only that you don't corrupt the discussion.
> Speaking personally, I was never embarrassed by "has light", any more
> than I was embarrassed that C has a statement "continue" rather than
> calling it "xl88_t".
Yeah, I understand. I don't want to convince you that you should be
embarassed about that. But I would like to convince you sort-of WHY I'm
a little embarassed about it. So I hope you will not mind a tiny parody
of the language:
lantern
has light
looks brass
touch great
lantern good
I don't mean this in mean spirit. Just to give a sense of what the
language kind-of sounds like to me.
> Still, while "key in Lodge" (I6) might be
> embarrassing to someone of such sensitivities, "all except two of the
> keys are in an adjacent room" (I7) is not so transparently a
> paraphrase.
You entirely confused me there.
> I do slightly object to quoting me thus:
>
> "Natural language is as optimised for talking about human situations -
> the physical world, and the world of people - as C [or TADS] is for
> low-level filtering of data in files."
>
> What is "[or TADS]" doing here?
You're making a distinction between procedural programming languages
(such as C) and "natural language" which which you associate I7. TADS
is obviously in the former category.
Adam Thornton
<steve....@gmail.com> wrote:
>Yes, you have to be a programmer to write IF. (Actually,
>let me revise that slightly: "You have to be a programmer to write
>interesting IF.")
In your opinion, do you have to be a programmer to write a
competently-executed (I won't even insist on "interesting") detective
story?
If not, then why do you think that you must be a programmer to write IF?
I think the sets of fundamental logical and puzzle-construction skills
required for each craft are quite close to each other.
Adam
Giles
Aaron A. Reed wrote:
>
> Somebody said this is going to be a language that programmers hate and
> bibliophiles love. I'm curious to see what kind of programs the
> bibliophiles will write.
Hear, hear. I am suspicious of calling a subset of NL 'FakeNL' anyway.
No one human (savants aside) knows all the words in the english
language, yet their inability to talk phrase the finer points of
esoteric subjects does not proscribe them being called English
speakers. I don't want to spend any time in the Chinese Room, so I'll
just say that regardless of the size of the jump, this is a fascinating
leap in a couple of interesting directions and I look forward to seeing
where it lands.
-Giles
Damien Neil
> <steve....@gmail.com> wrote:
> >Yes, you have to be a programmer to write IF. (Actually,
> >let me revise that slightly: "You have to be a programmer to write
> >interesting IF.")
>
> In your opinion, do you have to be a programmer to write a
> competently-executed (I won't even insist on "interesting") detective
> story?
>
> If not, then why do you think that you must be a programmer to write IF?
You need to be a programmer to write IF in exactly the same way that you
need to be a cook to cook a hamburger, a driver to drive a car, or a
runner to run.
- Damien
--
NewsGuy: Inserting spam in customer's posts since 2006.
Joshua Houk
> You need to be a programmer to write IF in exactly the same way that you
> need to be a cook to cook a hamburger, a driver to drive a car, or a
> runner to run.
Mmm... if you follow your analogies, you need to be a *writer* to write IF.
- joshua
Damien Neil
That too.
- Damien
--
Waiting for my NewsGuy account to expire before finding a spam-free
provider.
Andrew Plotkin
That too.
--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.
Adam Thornton
Damien Neil <neild-...@misago.org> wrote:
> ad...@fsf.net (Adam Thornton) wrote:
>> <steve....@gmail.com> wrote:
>> >Yes, you have to be a programmer to write IF. (Actually,
>> >let me revise that slightly: "You have to be a programmer to write
>> >interesting IF.")
>>
>> In your opinion, do you have to be a programmer to write a
>> competently-executed (I won't even insist on "interesting") detective
>> story?
>>
>> If not, then why do you think that you must be a programmer to write IF?
>
>You need to be a programmer to write IF in exactly the same way that you
>need to be a cook to cook a hamburger, a driver to drive a car, or a
>runner to run.
That's a ridiculous statement.
You need to be a programmer to program.
No one has yet convinced me that writing IF is fundamentally
programming. I fail to see that it's any more fundamentally programming
than it is fundamentally writing a detective story.
Adam
Andrew Plotkin
> In article <neild-usenet4-DEF...@news.newsguy.com>,
> Damien Neil <neild-...@misago.org> wrote:
> >
> >You need to be a programmer to write IF in exactly the same way that you
> >need to be a cook to cook a hamburger, a driver to drive a car, or a
> >runner to run.
>
> That's a ridiculous statement.
Oh, come on. It may ultimately be wrong, but it's not ridiculous. The
IF works we have today are programs. Today, you need to be a
programmer to create them. We don't refer to human-computer
interaction as "diplomacy" just because AI is coming along someday.
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>Here, Adam Thornton <ad...@fsf.net> wrote:
>> In article <neild-usenet4-DEF...@news.newsguy.com>,
>> Damien Neil <neild-...@misago.org> wrote:
>> >
>> >You need to be a programmer to write IF in exactly the same way that you
>> >need to be a cook to cook a hamburger, a driver to drive a car, or a
>> >runner to run.
>>
>> That's a ridiculous statement.
>
>Oh, come on. It may ultimately be wrong, but it's not ridiculous.
It is ridiculous in so far as it is essentialist. Given that the
paragraph in question equates the verb and the noun in every other case,
it seems reasonable to believe that Damien claims that the creation of
IF *is* essentially programming. I am not at all sure I believe this.
On the other hand, I have no beef with "You need to be a writer to write
IF." Or, indeed, "You need to be a programmer to program IF." I am not
at all convinced that writing IF is, in any essential sense, programming
IF, unless you call plotting a detective novel "programming" it.
I wonder why there weren't more detective IF games. Other than the
Infocom trilogy, of which Deadline was the only really successful one, I
can't think of any. But surely the form is a natural fit to IF: a
closed world, a carefully-delimited set of objects, and the backstory
emerging from a reconstruction of those objects' interaction.
Adam
Aaron A. Reed
>I wonder why there weren't more detective IF games. Other than the
>Infocom trilogy, of which Deadline was the only really successful one, I
>can't think of any. But surely the form is a natural fit to IF: a
>closed world, a carefully-delimited set of objects, and the backstory
>emerging from a reconstruction of those objects' interaction.
Perhaps because many of the objects interacting in detective stories
are people, which are difficult to both write _and_ program well...
Roy Stogner
> Do you have to be a programmer in order to write a detective story? If
> you answer "yes," then your definition of programming is uselessly
> overbroad, as it means "The ability to construct logical chains of
> causality." If you answer "no," then you have, I think, just admitted
> that there may be non-programming ways to write IF.
I'd answer "no", but I think I've only admitted that there may be
non-programming ways to write F.
To make that F into IF, you need to make that writing vary depending on
input, and however you choose to do so it will start to look like
programming pretty quickly - even if a recognizing a functional
pseudo-English programming language takes a minute for most programmers
used to procedural languages with lots of curly braces.
---
Roy Stogner
Personman
>IF, unless you call plotting a detective novel "programming" it.
I can't imagine what writing IF without programming would look like.
Can you provide any examples? It seems that even something as simple as
a choose your own adventure book requires thought processes that could
be thought of as programming, and once you move even a llttle bit
beyond that you're pretty irrevocable writing code, one way or another.
As soon as anything needs to loop conditionally or have its state
toggled or its value incremented, the author is going to have to have
some of the skills we call 'programming' to understand what he is
doing.
In fact, upon reflection, I do consider certain aspects of writing a
detective novel or choose your own adventure book 'programming.' More
precisely, writing such books requires programming the _reader_. In a
book, both the input, if any, and the computation must be done in the
reader's brain, and it is the author's job to a) provide the content,
but also b) set up the rules under which any necessary calculations
must be done. That might be defining a set of rules for deciding what
page to go to next (which can get quite complex - cf. the Lone Wolf
books, etc.) or simply establishing the suspects, pieces of evidence,
etc. Of course, in a detective novel, both the set up and the *result*
will be shown to the reader in text form, but the result (the final
chapter of exposition in which all is revealed) is meaningless if the
reader cannot perform the computation (follow the chain of logic)
successfully. Thus, the success of a detective novel is on some level
determined by the ability of the author to turn the reader into a
computer and program that computer.
Whether or not that is actually 'programming' is irrelevant to this
discussion. My point is that crafting any logic-based narrative
requires programming-like skills, and IF specifically requires
programming skills, as it is done on a computer. Inasmuch as one with
programming skills is a programmer, I am fairly convinced that one must
be a programmer to write (interesting) IF.
I am, however, very interested to hear how a non-programmer might go
about writing IF, as you have suggested is possible. I have several
non-programmer friends who are interested in writing IF, but of course,
the need to be able to program has always been a hurdle. I7 promises to
at least ease the transition a bit, and it may actually get at least
one of them writing a game pretty soon. But I think in the end, no
system can do much beyond ease the transition. When an IF author gets
to the point where he needs to make complex machinery, highly
manipulable objects, etc., he needs to be able to program a computer.
Quintin Stone
Huh, I seem to read his post a bit different from everyone else. I think
the point he's making is that you don't *need* to really be a cook to cook
a burger. I've made plenty of good burgers, even though I would never
consider myself a cook. In addition, I've run without thinking of myself
as a "runner", and I've driven without being labeled as a "driver". In
other words, you should be able to (and can) program IF without being
thought of as a "programmer".
Clarification, Damien?
==--- --=--=-- ---==
Quintin Stone "You speak of necessary evil? One of those necessities
st...@rps.net is that if innocents must suffer, the guilty must suffer
www.rps.net more." - Mackenzie Calhoun, "Once Burned" by Peter David
Adam Thornton
Roy Stogner <royst...@SPAMices.utexas.edu> wrote:
>To make that F into IF, you need to make that writing vary depending on
>input, and however you choose to do so it will start to look like
>programming pretty quickly - even if a recognizing a functional
>pseudo-English programming language takes a minute for most programmers
>used to procedural languages with lots of curly braces.
Counterexample 1: CYOA books.
Counterexample 2: D&D modules.
Adam
James Cunningham
Yes, well, Choose Your Own Adventure books *are* programming, in their own way:
If you want to enter the basement, turn to page 77.
If you want to walk upstairs, turn to page 213.
Otherwise, turn to page 92.
How is that anything but a highly simplistic bit of programming? (And
fun, too: I miss those damned things.)
The fact of the matter is that any description of a system of *stuff*,
that reacts to different player input in different ways, is always
going to be something like programming. Unless you mean in the trivial
sort of way that "Computer, give us a Sherlock Holmes mystery with an
opponent that can beat Data" isn't programming.
For as soon as you want to give the computer any more precise
instructions, it *becomes* programming. Maybe someday I can say
"Computer, make me a web browser. I want it to use the Gecko engine."
When I say "When the user clicks "reload", reload the page, but when
they click "shift" first and then "reload", I want you to regrab all of
the stuff from the server", then I'm engaged in programming, despite
how high level it is.
Best,
James
kalamos
Alan and Adrift but with minor forays into Tads and Inform. My feeling
is that a detective novel is programmed but in a rather rudimentary
sense. The logic involved in coding something as simple as a
combination lock on a door in an IF game can be as complicated as the
whole train of logic explaining a locked room murder. The thought
process is, indeed similar, but IF demands so much more of it!
You can even encounter "bugs" in detective novels. A popular problem is
that while shuffling the story around you end up with a character
knowing something before he could've found out.
Probably the reason I like to tinker with interactive fiction systems
is the same impulse that makes me enjoy tinkering with mystery puzzles,
however I don't believe a nonprogrammer will be able to write really
good (as opposed to say, OK, or fairly interesting) interactive fiction
unless he or she is able to become a programmer.
This is just my opinion, but I think that people tend to see a largely
false dichotomy between the "creative" part of art and the technical
aspect of communicating the artist's vision to the audience. There is
this idea that a writer, or a painter, for example, has an *vision* and
then it is a matter of gaining the technical skill to bring that vision
to the pages of a manuscript or a canvas.
I believe it is much more complicated than that. Every medium has its
own constraints and strengths and conventions. You're not going to get
a pleasing result by dreaming up an idea and then trying to jam it into
the medium. What the medium is capable of doing and what skills the
artist possesses figure in the original inspiration, or should if the
resulting work is going to be any good. A lot of what an artist
imagines is based on what the artist knows can be done in his or her
chosen mode of communication.
Perhaps I7 will entice some nonprogrammers, who would have been scared
off by typical code, to be drawn into interactive fiction and learn to
program. Maybe programming in I7 is easier. The interface is so
incredible it almost begs to be played with. In fact, I6, with that
interface, might be easier to learn.
To me, the natural language syntax sounds in some ways very much like
Alan's natural language syntax, and there is even a resemblance in that
Alan is heavy on rules and "events" (like I7 scenes). And, of course,
the aim of allowing games to be written without programming sounds the
same as the aim of Adrift. So it is almost as if some heretofor very
seperate streams of IF thought and activity are converging. But, of
course, Alan and Adrift both involve programming.
As one of the world's many nonprogrammers, I must say it's nice to see
so many developers working on our behalf, but, although I enjoy
dabbling for my own amusement, I know I won't be able to produce
anything worthwhile for an audience unless someone comes up with a
system for programming that it's easy enough to allow me to become a
programmer.
Damien Neil
> > No one has yet convinced me that writing IF is fundamentally
> > programming. I fail to see that it's any more fundamentally programming
> > than it is fundamentally writing a detective story.
Can you offer an example of an IF work that did not involve programming
in its creation?
Quintin Stone <st...@rps.net> wrote:
> Huh, I seem to read his post a bit different from everyone else. I think
> the point he's making is that you don't *need* to really be a cook to cook
> a burger. I've made plenty of good burgers, even though I would never
> consider myself a cook. In addition, I've run without thinking of myself
> as a "runner", and I've driven without being labeled as a "driver". In
> other words, you should be able to (and can) program IF without being
> thought of as a "programmer".
No, quite the opposite.
I think that you're making a very strange and artificial distinction
here. Being a programmer, or a runner, or a cook, or a writer isn't
some sort of badge you wear. There are no entrance exams, no secret
society you have to join. Want to run? Run. And, hey, now you're a
runner.
Creating a work of IF will involve programming. It might require some
very tricky and advanced programming, or it might only require something
very simple and basic, but I've never seen any work of IF that didn't
have some programming that went into it.
Does this mean you need to be a programmer to create a work of IF? Not
exactly. It means that if you create a work of IF, you *are* a
programmer. You've programmed. Just like I'm a cook every time I make
myself dinner. Maybe I'm a *bad* cook (you'd agree if you tried my
omelettes), maybe I'm a good one (try my fried chicken instead), but I'm
cooking either way.
- Damien
--
NewsGuy appends spam to my posts whenever I forget to add a .sig.
Mark J. Tilford
Gumshoe
Beyond
The Great Xavio
Murder at the Aero Club
Private Eye (gamebook in IF form, though)
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
Adam Thornton
Damien Neil <neild-...@misago.org> wrote:
>Does this mean you need to be a programmer to create a work of IF? Not
>exactly. It means that if you create a work of IF, you *are* a
>programmer. You've programmed. Just like I'm a cook every time I make
>myself dinner. Maybe I'm a *bad* cook (you'd agree if you tried my
>omelettes), maybe I'm a good one (try my fried chicken instead), but I'm
>cooking either way.
Ah. I misunderstood the point you were making then.
I think I7 brings us much closer to the point at which a writer, who
does know how to form causal chains of events, but who does not know how
to program in any traditional sense, can write interesting IF.
Perhaps this is just a reaction to the first time I've every *really*
looked at a declarative, rather than procedural, language (I count OO
languages as fundamentally procedural: just because you glue the
functions to objects and call them "methods" doesn't mean they're not
still basically procedures.)
Adam
Adam Thornton
James Cunningham <jameshcu...@google.com> wrote:
>If you want to enter the basement, turn to page 77.
>If you want to walk upstairs, turn to page 213.
>Otherwise, turn to page 92.
>
>How is that anything but a highly simplistic bit of programming? (And
>fun, too: I miss those damned things.)
OK...but where is the line? Or is there one at all?
Is it programming to say (as you might find in a D&D module) "The
Vampire Lord will probably lead off with his _Charm Person_ ability, but
if he realizes that it isn't having an effect on the party, he will send
his minions to harrass the spellcasters while using his slam attack and
level drain against the strongest-appearing fighter-type in the party.
If he's seriously threatened, he will assume gaseous form and attempt to
retreat to his coffin." ?
If so, then I think you're making the claim that tactics and strategy
are programming--which seems bizarre to me. But if not--well, I could
easily represent that set of tactics in an algorithm. So, hell, I
dunno.
Adam
Damien Neil
> James Cunningham <jameshcu...@google.com> wrote:
> >If you want to enter the basement, turn to page 77.
> >If you want to walk upstairs, turn to page 213.
> >Otherwise, turn to page 92.
> >
> >How is that anything but a highly simplistic bit of programming? (And
> >fun, too: I miss those damned things.)
>
> OK...but where is the line? Or is there one at all?
Programming is the act of writing a program. A "program" is what we
call a set of instructions for a computer to follow. (Okay, a "computer
program", if you want to be really pedantic.) So if you're setting down
instructions for a computer--or something computer-like--to follow,
you're programming.
I wouldn't consider a CYOA book to be programming, since there isn't
anything to program. Nor would I consider a recipe to be programming.
> Is it programming to say (as you might find in a D&D module) "The
> Vampire Lord will probably lead off with his _Charm Person_ ability, but
> if he realizes that it isn't having an effect on the party, he will send
> his minions to harrass the spellcasters while using his slam attack and
> level drain against the strongest-appearing fighter-type in the party.
> If he's seriously threatened, he will assume gaseous form and attempt to
> retreat to his coffin." ?
Depends on whether the computer understands that. If it does, sure, I'd
call it programming.
Writing computer programs isn't some high and magical art that only the
secret masters are allowed to participate in. It can be pretty simple,
as demonstrated by the way I was doing it (on a very basic level) when I
was six years old.
I think people tend to get hung up on the belief that certain activities
are off-limits to anyone who hasn't been initiated into the arcane
mysteries. Programming, changing the oil in your car, baking a
pie...it's all just stuff. Sure, some people are better at it than
others. And sure, if you study and work at it for twenty years, you'll
(probably) be better at it than most people. But just because lots of
people know way more about mechanics than I do doesn't mean I can't
change the oil in my motorcycle.
- Damien
--
Spamming is easy, too. Just post through NewsGuy!
Quintin Stone
> Quintin Stone <st...@rps.net> wrote:
>> Huh, I seem to read his post a bit different from everyone else. I
>> think the point he's making is that you don't *need* to really be a
>> cook to cook a burger. I've made plenty of good burgers, even though I
>> would never consider myself a cook. In addition, I've run without
>> thinking of myself as a "runner", and I've driven without being labeled
>> as a "driver". In other words, you should be able to (and can) program
>> IF without being thought of as a "programmer".
>
> No, quite the opposite.
>
> I think that you're making a very strange and artificial distinction
> here. Being a programmer, or a runner, or a cook, or a writer isn't
> some sort of badge you wear. There are no entrance exams, no secret
> society you have to join. Want to run? Run. And, hey, now you're a
> runner.
I guess it's simply a matter of perspective, since the end conclusion we
both came up with is the same: these are activities that most anyone can
do, if they simply choose.
Artificial, yes. Strange, not really. These are simply the distictions
people make all the time based on nothing more than their own personal
viewpoint. I've written stories, though I don't think of myself as a
writer. And likewise, just because I make burgers a couple of times a
month doesn't mean I think of myself as a cook. Neither one is my
profession nor even one of my hobbies. Therefore, I don't consider either
to "define" me as an entity. There are so many things that people do, it
seems that to apply them all as labels would dilute them enough to make
them all meaningless.
But like I said, I think that we're saying pretty much the same thing.
You believe that anyone who makes IF can be considered a programmer. I
said that you don't need to think of yourself as a programmer to make IF.
Six of one, half a dozen of another. *shrug*
steve....@gmail.com
> I think this is at best an emotional grasp at something desperately
> wished for, but in truth is a false statement and we have to define
> semantics to clarify the point.
Graham's vague and surprising claims about I7-NL are indeed an
emotional grasp at something despreately wished for, but far from
achieved. I couldn't have put it better myself.
> I define "programming" in a traditional sense. I've been doing this
> thing called "programming" for 27 years (since I was 15) and it always
> has revolved around lines of syntax with code blocks inside of
> functions and subroutines. This syntax has taken on several forms, most
> of which revolve around what is commonly called 3rd generation
> programming syntaxes. 2nd generation was assembly and 1st generation
> was machine code.
>
> Inform 7 is what I would call a 4th generation programming language.
I understand the distinctions you make between the first three
generations. Each next-gen represents a paradigm shift in programming
structure.
> So
> in a sense Steve, you are correct. But your arguments tend to want to
> say that I7 is in fact a 3rd generation programming language, which it
> is most certainly not.
Since the dawn of 3rd generation programming, there have been a number
of novel paradigms. Amazing stuff. We already have a number of fourths,
arguably fifths. I7 is keeping up with a certain form of modern
programming (expert systems), but it's nowhere near the cutting edge of
systems theory.
It is cute, though. And it's neat for our little world.
> I have two quabbles with your sentiment. One is that reading english is
> way they hell easier than reading code[.]
Just to be clear. I am claiming that reading code is faster, and (I
think) you're claiming that reading "english" is easier.
Maybe we can agree that reading pseudo-code is faster and easier. But
see below...
> Code requires translation from its syntax to
> english. My brain at least registers english, not code. So when I see
> this:
>
> private int foo(int bar)
> {
> return bar + 2;
> }
>
> ...I think to myself "the foo function increments the passed argument
> by two"
>
> I don't _think_ "private integer function foo accepts the argument bar
> and returns bar plus 2"
>
> There's a significant difference in how my brain functions from how I
> write traditional code.
>
> I can only imagine that someone untrained in 3rd generation programming
> might be horrified to see squiggly braces but if they see this:
>
> Incement bar by 2.
>
> ..well I think your whole argument that Inform 7 is "just programming"
> goes right out the window.
I think once they recognize the power of locals and properties and
such, and they learn what += does, a person will prefer "bar += 2" over
"Increment bar by 2" -- for a number of reasons. (Not least of which
being that it has an unambiguous meaning, and you can read it faster.)
I honestly don't buy this "I think in English, not logic and math"
argument. When I read code, I think in code. And when I read pseudo-NL
I7, I have to translate it into code, so it's really an extra step.
> Now....there's another subject here that you've left out. How do
> non-programmers view logic. Speaking from many interview experiences, I
> can honestly say that not everyone is comfortable speaking or thinking
> in logical terms.
Well, if I have a logically disinclined buddy, I can happily recommend
a fuzzy system that does whatever it thinks best, when it detects that
the author got the logic wrong. (But I'm not going to use it
personally.)
I guess there's a similarity between our hypothetical fuzzy system and
the I7 black box system.
> In an absolute sense you may call Inform 7 "just another programming
> language", but as Graham pointed out, by your definition every type of
> communication on the planet is a programming language.
Let me quote what reference I think you're making:
> [I]f you are going to define "natural language" as
> that context of discourse in which the reader is not addressed with a
> specific intent agreed between both parties, then you must also exclude
> laws, cookery books, dictionaries, encyclopaedias, and so forth. I
> doubt such a definition can be viable.
He's pretending I made this claim. (You can decide for yourself why
he's pretending this.)
Anyway, I did not make this claim. Nothing even close.
If you want a simple picture of my concept of fake-NL: fake-NL is
language that looks very superficially like English, but which is so
designed that it can be immediately translated into a common
programming structure (such as the programming structure underlying the
fake-NL syntax in I7), and is in fact a translation from that common
programming structure into fake-NL.
I mean, this is pretty obvious, but in a way the concepts are a bit
slippery. So maybe Graham is just confused in some subtleties he dug
himself in to?
steve....@gmail.com
> In your opinion, do you have to be a programmer to write a
> competently-executed (I won't even insist on "interesting") detective
> story?
If you're arguing that the minimum skill-set for writing detective
fiction encompasses the minimum skill-set for writing
competently-executed IF, then that's just great. But could you explain
what are the elements of those skill sets, and why you think the one
completely overlaps the other?
> I think the sets of fundamental logical and puzzle-construction skills
> required for each craft are quite close to each other.
Okay.
Probably mere tree design (CYOA) shouldn't be called programming.
Adam Thornton
<steve....@gmail.com> wrote:
>Adam Thornton wrote:
>> In your opinion, do you have to be a programmer to write a
>> competently-executed (I won't even insist on "interesting") detective
>> story?
>
>If you're arguing that the minimum skill-set for writing detective
>fiction encompasses the minimum skill-set for writing
>competently-executed IF, then that's just great. But could you explain
>what are the elements of those skill sets, and why you think the one
>completely overlaps the other?
A very interesting, and a fair, question.
In each case, you have a certain, fairly-well-circumscribed, set of
relevant objects, and the set of their interactions with each other
should be understandable by the reader--probably intuitively, without
having to come up with any major leaps of faith, although requiring
deduction is certainly fair.
The story--such as it is--largely comes about as a result of the
interactions of those objects with each other to produce the observed
effects. Note that here I'm basically talking about classic
"puzzle-oriented" IF and about a relatively small subset of
mysteries--let's say, "police procedurals" or "murder mysteries",
although I think it's a bit broader than that. The reader in each case
has a limited set of objects to play with, from which the mysteries or
challenges found in the current environment can be explained or solved.
Where this breaks down, of course, is that the library in current IF
systems isn't actually rich enough to support all common-sense
interactions of Relevant Items, such that the author has to end up
coding their implementations himself. However, I believe this to be a
failing of current library implementations rather than inherent in IF.
One can certainly imagine a library good enough that objects represented
with it behaved in common-sense ways for all likely actions applied to
them, and in fact the Inform library is generally not terribly far from
this ideal.
However, within these strictures, there are entertaining and interesting
stories to be told, and I think that the fundamental art of constructing
an interesting locked-room murder mystery and the art of constructing a
puzzle-oriented piece of IF are--if the author of the IF is provided
with a library to implement things in a sufficiently common-sensical
way--close to (though probably not exactly) coterminous.
Adam
ChicagoDave
you that I read english faster than I read code. This is indisputable.
You may very well have a wild talent for reading code faster than
english, but you are among a very small minority of people. We're not
The Borg. Most people read and write in natural language. Nearly all
business communication is done at the natural language level. All
scholastic education is done in natural language.
You seem to be suggesting that we all can read code faster or more
easily, we're just too lazy to try.
I'm done with this argument though.....your ego is nothing short of
breathtaking. But dude....you are so wildly wrong....to bad you don't
even know it.
David C.
Adam Thornton
Benjamin Caplan
> Most people read and write in natural language. Nearly all
> business communication is done at the natural language level. All
> scholastic education is done in natural language.
Yes, but how many people *think* in natural language? Not me: my
thinking is somewhere between visual and kinaesthetic. (I like to call
it proprioceptive.) That's why I prefer code to natural language when
I'm programming: because the visual layout of the page helps me form
the mental structures necessary to understand what the code is doing.
na...@natecull.org
> I'm not asking that you believe some wild belief of mine. I'm _telling_
> you that I read english faster than I read code. This is indisputable.
I dispute this. There are vastly different problem domains that English
(and other coding systems) are used to describe. And we don't all use
just English all the time, especially in technical fields.
I can read a Terry Pratchett novel in a couple of hours, but give me a
history or philosophy book of equal length and I can be puzzling over
it for days. They're both in English, but one is a simple narrative
with well-crafted jokes, and the other is a set of densely structured
facts.
But then take a mathematical paper - some English, lots of formulae. If
English is *always* so fast to read, why don't all mathematicians use
raw English instead of those weird squiggly lines? They're just doing
it to slow their readers down, right? It sure takes me ages to try to
read one!
And as for business correspondence, a lot of it uses charts,
photographs, figures, tables and graphics to convey things that simply
*aren''t* as quickly graspable - or describable at all in any detail -
in English.
Then what about art, and architecture? A large part of IF design, for
me, is not just sculpting *language* (though it is), but designing
*objects* and *places* - spatial connections on a map, scripted events
that occur in simulated time and space. A problem domain that seems
very similar to me is building 3D FPS / MMORPG map levels. There's a
whole artform in that field of constructing landscapes, lighting, mood
music, ambient sounds, scripted events. Do you think 3D game level
designers use English language to draw polygons, align textures, place
spawn points, build animation and reaction scripts for NPCs and
enemies? Do architects and engineers use English language to draw
blueprints? Do film directors use English language to storyboard shots?
Which would you rather have: a diagram of a wiring closet with coded
symbols indicating simply and without fuss which wire connects to
which, or a long essay describing the relative positions of each cable
using English adjectives?
English is good for many things, and for aspects of IF design that
involve manipulation of English text it may well be superior, but it's
*not* by any means the universal symbol system that you're claiming so
strongly that is. We make do with it in technical fields in everyday
life because it's so well known, and network effects make that
powerful, not necessarily because it's the best fit for every
application. And we augment it with specialised jargons, and then
further with specialised non-English symbol systems, for those cases
where even jargon is not precise enough.
IF design is - or has the potential to be as our tools expand toward a
multimedia Holodeck-like environment - a complex technical field with
overlapping elements of narrative composition, architectural design,
photography, animation and engineering. So why do we necessarily want
to limit the conceptual and linguistic tools for designing IF to *just*
English?
Watts Martin
than, as you put it, fake-NL. The claim is that I7 is not "a
translation from that common programming structure into fake-NL." I7
decomposes its "source code" into a world model and sets of rules and
relations, then translates *that* into code, which is not the same
thing at all: it's where the power of the system actually comes from.
No one disputes that "Increment foobar by 1" is wordier than "foobar++"
(not that one actually would use the former in I7, from what I can
tell), but let's look at something a little less glib.
-----
Overlooking relates various rooms to various rooms.
The verb to overlook (it overlooks, they overlook, it overlooked, it is
overlooked, it is overlooking) implies the overlooking relation.
The Garden overlooks the Shrubbery. The Folly overlooks the Garden. The
Shrubbery overlooks the Sundial Plot. The Old Ice House overlooks the
Garden.
After looking:
say "This wintry vantage point overlooks [the list of rooms
overlooked by the location].";
let the way be the next step via the overlooking relation from the
location to the Sundial Plot;
if the way is a room, say "To sledge downhill to the Sundial, aim
for [the way].";
otherwise say "It is not possible to sledge downhill to the
Sundial."
-----
I don't think anyone could honestly argue that there's an intuitively
obvious and straightforward representation of the above code snippet in
I6 (or TADS, or any other procedural language). I can't help but
suspect the code in Inform 6 to do that would be considerably MORE
verbose -- and more fraught with bug potential, and more difficult to
debug in the event of a problem -- than the I7 equivalent.
Bob
I'm definitly not a programmer. The knowledge of basic for my Commodore
64 was limited to "load" and "run". I'm a lawyer by profession. Yet, I
had tremendous fun fiddling with I7 and managed to write a very basic
but nice text adventure with five rooms, 4 takeable objects, some
scenery and even two puzzles. I did so just by reading the
documentation (I'm not very far: chapter 3.21) and trying to find out
things by myself. It really wasn't programming, but like playing a text
adventure (trying to do things that don't work, look exactly what I had
written, trying other things, even solving guess-the-verb problems). I
did that for five hours straight and had - as I said - enourmous fun.
Of course the result isn't perfect and I'd probably give it a 3 in the
IF-Comp, but still: I have written a piece of IF - without becoming a
programmer by that.
Thanks to G. Nelson for one of the most fun games I played in years!
Bob
steve....@gmail.com
> Which would you rather have: a diagram of a wiring closet with coded
> symbols indicating simply and without fuss which wire connects to
> which, or a long essay describing the relative positions of each cable
> using English adjectives?
Exactly. And if someone wants present this layout in English, you have
to translate it back into a visually digestible diagram.
This is basically what I mean when I say I read code faster than its
English equivalent (and that I sort-of have to translate I7 into code
when I read it, or read it as code with an obese syntax, and not as
English). I certainly don't mean that I have a Borgian facility with
code -- FAR from it.
If I were some genius exception, my response to I7 would be singularly
irrelevant. But in terms of an IF coder, I'm pretty average Joe (and
arguably worse than average). So I *think* my experience reading
fake-NL is a common one. Indeed, I think you'd have to be some
Anglo-Borgian savant to be able to read English faster, when the
English is describing a program (yet still I think you'd have to
translate it back into code).
Watts Martin writes:
> I don't recall ever seeing a claim that Inform 7 was anything other
> than, as you put it, fake-NL.
Nope. Nobody claimed that I7 understands natural language. The claim
was that you can write I7 code in natural language, er, I mean, a
subset of natural language. Yeah.
So that's one objection, that this "natural language" advertising
slogan confuses the discussion.
> The claim [on the contrary] is that I7 is not [as I wrote] "a
> translation from that common programming structure into fake-NL."
All I mean is that I7 is a programming structure which can be
represented in fake-NL, but which needs to be read in terms of the
underlying programming structure, if you're to understand what the
program does. It could have picked a syntax that makes this underlying
structure more explicit, but as it is, we sort-of have to translate a
lot of it into that structure if we're going to understand it.
So that's another objection, but a relevant one this time -- that the
syntax occludes the code and makes it slower to read and harder to
understand.
> I7
> decomposes its "source code" into a world model and sets of rules and
> relations, then translates *that* into code, which is not the same
> thing at all: it's where the power of the system actually comes from.
I wasn't talking about how the I7 (pre-)compiler reads the code, but
rather how the programmer reads it.
> [code snipped]
>
> I don't think anyone could honestly argue that there's an intuitively
> obvious and straightforward representation of the above code snippet in
> I6 (or TADS, or any other procedural language).
It would take an hour or two to set up a relational logic kit
(including the macros to access it), but then it would be pretty easy.
Again, instead of pretending it's English, I'd set it up to maxmize
clarity and ease-of-reading, so instead of...
The Garden overlooks the Shrubbery. The Folly overlooks the Garden. The
Shrubbery overlooks the Sundial Plot. The Old Ice House overlooks the
Garden.
...I'd do something like...
gRelation('overlook')
[[garden, shrubbery],
[folly, garden],
[shrubbery, sundial],
[iceHouse, garden]]
(I hope you see what I mean when I say that the former seems like a
translation of the latter, and not the other way 'round.)
Graham Nelson
problem for three years, and to conduct an actual experiment, before
talking about it in public. These are not easy questions.
This latest definition of "fake-NL" - I see we are no longer to call it
"pseudo-NL" - is no more satisfactory than the last. If I understand it
correctly, it asserts that any form of natural language which could be
translated into a run-time story file is "fake", since it would be
converted into data structures and procedural code. So by that
argument, when the authors of "Zork: The Undiscovered Underground"
(Marc Blank and Mike Berlyn) sent descriptions of their design by email
to their Inform programmer (Gerry Kevin Wilson) to implement, were
those emails not written in natural language?
(Also, it is not immediate to "translate" Inform source text into a
"common programming structure". A non-trivial program is needed. Nor is
it historically accurate that "in fact" Inform's sentence grammar is
some kind of translation from existing run-time facilities. That wasn't
how the thing was written.)
Inform's language includes generative grammar in a Chomskian sense, and
employs a selection of vocabulary and syntactic structures acquired by
children in the relevant community (i.e., English speakers) before the
age of ten; so it passes most tests for what constitutes "natural
language". Certainly it's only a very small dialect, for a specialised
usage - like air-traffic control language, for instance. That does not
make it a fake. Real human beings use such dialects for real purposes.
A more defensible argument would be that Inform's dialect is unnatural
because it is addressed to a computer, which, ipso facto, is not a
fellow human being: and which, since it lacks an appreciation of social
nuances, contextual knowledge, etc., is therefore not "understanding"
what is being said: and that Inform source text, being intended only to
be fed into a mechanical grinder, is not natural even if it looks a bit
that way. But I think this overlooks the fact that Inform source text
is not addressed only to the computer. The author is also writing to
himself - or, say, to the person he will be in three years' time, when
a bunch of bug reports come in and he decides that he really ought to
re-release "Stiffy Makane and the Preposition of Doom", which means
looking back over source text he has forgotten writing. And of course
Inform source text is also addressed to the eventual player: quite a
deal of it is used directly in play. If I say "An orange pepper is on
the kitchen counter", then noun phrases in that simple sentence are
directly read by the eventual player - another human being.
steve....@gmail.com
> Perhaps I am indeed "just confused": my approach was to study the
> problem for three years, and to conduct an actual experiment, before
> talking about it in public. These are not easy questions.
It is only by artificially complicating the question that you can make
it confusing.
I daresay that it is "not easy" to argue that I7 is in some way exceeds
fake-NL. But both sides of this argument are not equally difficult:
"A equals A" is no more NL than "A=A". An "English" description of a
rule base is no more NL than a Prolog description of a rule base.
> This latest definition of "fake-NL" - I see we are no longer to call it
> "pseudo-NL" - is no more satisfactory than the last. If I understand it
> correctly, it asserts that any form of natural language which could be
> translated into a run-time story file is "fake", since it would be
> converted into data structures and procedural code.
Satisfactory or not, I certainly didn't assert that. This is the second
time you've tried to paraphrase me into an absurdity. Disingenuous * 2.
Fake-NL, as I have said from the beginning, is programming code
varnished by macros (or productions, whatever) designed to give said
code a superficial appearance of English.
Don't get me wrong though -- I like the underlying structure. It's neat
like expert systems. A worthwhile experiment, certainly. Thanks.
> So by that
> argument, when the authors of "Zork: The Undiscovered Underground"
> (Marc Blank and Mike Berlyn) sent descriptions of their design by email
> to their Inform programmer (Gerry Kevin Wilson) to implement, were
> those emails not written in natural language?
Now you're just being argumentative.
Daryl McCullough
>A more defensible argument would be that Inform's dialect is unnatural
>because it is addressed to a computer, which, ipso facto, is not a
>fellow human being: and which, since it lacks an appreciation of social
>nuances, contextual knowledge, etc., is therefore not "understanding"
>what is being said: and that Inform source text, being intended only to
>be fed into a mechanical grinder, is not natural even if it looks a bit
>that way. But I think this overlooks the fact that Inform source text
>is not addressed only to the computer. The author is also writing to
>himself - or, say, to the person he will be in three years' time, when
>a bunch of bug reports come in and he decides that he really ought to
>re-release "Stiffy Makane and the Preposition of Doom", which means
>looking back over source text he has forgotten writing. And of course
>Inform source text is also addressed to the eventual player: quite a
>deal of it is used directly in play. If I say "An orange pepper is on
>the kitchen counter", then noun phrases in that simple sentence are
>directly read by the eventual player - another human being.
There are two aspects to the use of natural language as a
programming language: How helpful is it to the person writing
the program, and how helpful is it to someone who tries to
read the program later on. I think that Inform 7 works very
well in the latter case: It is possible to read Inform 7
code and understand what it is supposed to be doing without
any particular knowledge of Inform syntax. That's a very nice
feature.
As for the person writing the program in the first place, it
is less clear to me. The fact that it is a subset of natural
language can lead someone to think that you just have to
write what you want in the most "natural" way. But a feature
with natural language is that the same thing can be expressed
in many different ways. Only one (or a small number) of these
will actually be understood by Inform. To give one example:
The Big Room is a room. The description is "This is a really
big room."
works, but
The Big Room is a room. Its description is "This is a really
big room."
does not. (It produces the unhelpful error message
You wrote 'Its description is "This is a big room."': but this
seems to say that a thing is a value, like saying 'the chair
is 10'.
Another example:
A fox is a kind of animal.
In the Big Room is a fox.
works, but
A fox is a kind of animal.
A fox is in the Big Room.
This sort of thing isn't too bothersome, you just have to
remember that some ways of saying things work, and some
ways don't. That amounts to saying that for the programmer,
you have to learn a grammar, just like you would if you
were programming C++. The fact that it is a subset of
natural language doesn't really help much.
--
Daryl McCullough
Ithaca, NY
--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth
Neil Cerutti
> All I mean is that I7 is a programming structure which can be
> represented in fake-NL, but which needs to be read in terms of
> the underlying programming structure, if you're to understand
> what the program does. It could have picked a syntax that makes
> this underlying structure more explicit, but as it is, we
> sort-of have to translate a lot of it into that structure if
> we're going to understand it.
>
> So that's another objection, but a relevant one this time --
> that the syntax occludes the code and makes it slower to read
> and harder to understand.
Examples, please.
> It would take an hour or two to set up a relational logic kit
> (including the macros to access it), but then it would be
> pretty easy. Again, instead of pretending it's English, I'd set
> it up to maxmize clarity and ease-of-reading, so instead of...
>
> The Garden overlooks the Shrubbery. The Folly overlooks the
> Garden. The Shrubbery overlooks the Sundial Plot. The Old Ice
> House overlooks the Garden.
>
> ...I'd do something like...
>
> gRelation('overlook')
> [[garden, shrubbery],
> [folly, garden],
> [shrubbery, sundial],
> [iceHouse, garden]]
>
> (I hope you see what I mean when I say that the former seems
> like a translation of the latter, and not the other way
> 'round.)
I hope you see that the latter looks like utter gibberish.
--
Neil Cerutti
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Neil Cerutti
> There are two aspects to the use of natural language as a
> programming language: How helpful is it to the person writing
> the program, and how helpful is it to someone who tries to read
> the program later on. I think that Inform 7 works very well in
> the latter case: It is possible to read Inform 7 code and
> understand what it is supposed to be doing without any
> particular knowledge of Inform syntax. That's a very nice
> feature.
I always felt that Inform 6 (and earlier) had similar properties,
but of course I was coming at it as a person famailiar with
Algol-like languages. But this property came from the way in
which the library was used, not in particular from the syntax,
which I actually found hard to master.
> As for the person writing the program in the first place, it is
> less clear to me.
Agreed. But the payoff, after the code is written, is probably
worth a great deal.
Graham Nelson
it's "programming code varnished by macros (or productions, or
whatever) designed to give said code a superficial appearance of
suggests that the intention of the creator is what counts. While
better, this is still a debateable definition. Post-Chomsky, systems of
productions exist which define very large subsets of English - indeed,
Chomsky's whole project, and that of the whole field of generative
linguistics, is essentially that productions do exist which define
natural languages. Productions exist such that all valid programs on a
given computer are valid strings for that grammar, and you have said
that you don't assert that all reducible-to-story-file descriptions are
"fake-NL". So I think "productions, or whatever" might have to go from
your definition.
What I take you to mean is that "fake-NL" is something which is turned
into a conventional programming language by simplistic rewriting
macros, typically used in such a way that a small number of macro
substitutions turns one form into the other. That's fair enough as an
aesthetic idea, even if it is difficult to make precisely
distinguishable from "real-NL", as I suppose the antonym would be. On
the other hand, it's not what Inform does at all.
Let's consider your example, for instance: "A equals A" being only a
lexical rewriting of "A=A", or in C it would be "A==A". Sure. "A equals
A" is, however, not what one writes in Inform. One tends instead to use
the more natural verb "to be", which is very much more complex in
meaning than "to be equal to", even in the present tense, even used
positively, even used declaratively. Consider, for instance, some of
its simplest uses:
The score is 20.
The bronze door is open.
East is a dead end.
The prevailing wind is a direction that varies.
Here we have (a) a value assignment, (b) an assertion that something
partakes of a property, (c) an assertion that a previously unmentioned
thing (which therefore requires construction) lies in a particular
place in the map and has a given kind, (d) a declaration of type. The
situation becomes rather more complex when one goes from definite
assertions to much vaguer conditions, where "to be" becomes a
pattern-matching operator of a kind not found in any programming
language I'm familiar with. A simplistic approach using macros ("or
productions, or whatever") could not practicably specify the set of
valid sentences in this grammar.
In the end this is an aesthetic discussion. Inform does what it claims
to, but that won't be to everyone's taste.
James Cunningham
>> gRelation('overlook')
>> [[garden, shrubbery],
>> [folly, garden],
>> [shrubbery, sundial],
>> [iceHouse, garden]]
> I hope you see that the latter looks like utter gibberish.
Steve's being an utter asshole[1], here, but I must say that I agree
with him, or at least that I share the mental strangeness that makes
his example more clear than a long and repetitive string of English
sentences.
Once you're acquainted with the paradigm, here - that you can have a
relation p and list ordered pairs of nouns that are elements of p -
what he's written is quicker to type, and it's more immediately clear
what's going on. (gRelation defines a relation. In the English
example, you have to read and parse the sentences describing elements
of the relation before you know what's going on.)
Best,
James
[1] What, did Nelson sleep with your mother and not call the next day?
Christ, man, it's calleld *decorum*, and when you use it, it makes
people more likely to see your point.
Neil Cerutti
> On 2006-05-05 09:40:13 -0400, Neil Cerutti <lead...@email.com> said:
>
>>> gRelation('overlook')
>>> [[garden, shrubbery],
>>> [folly, garden],
>>> [shrubbery, sundial],
>>> [iceHouse, garden]]
>
>> I hope you see that the latter looks like utter gibberish.
>
> Steve's being an utter asshole[1], here, but I must say that I
> agree with him, or at least that I share the mental strangeness
> that makes his example more clear than a long and repetitive
> string of English sentences.
The nested brackets and lack of connection between
gRelation('overlook') and the rest of the statement are what
makes it confusing (and I'm a Schemer!). In general I believe
that a good Algol-like or Lisp-like syntax could be invented. But
that wasn't it.
> Once you're acquainted with the paradigm, here - that you can
> have a relation p and list ordered pairs of nouns that are
> elements of p - what he's written is quicker to type, and it's
> more immediately clear what's going on. (gRelation defines a
> relation. In the English example, you have to read and parse
> the sentences describing elements of the relation before you
> know what's going on.)
I did have to do that, but it was really, really easy. ;)
--
Neil Cerutti
Let us join David and Lisa in the celebration of their wedding
and bring their happiness to a conclusion. --Church Bulletin
Blooper
Kevin Forchione
news:1146816454.1...@j33g2000cwa.googlegroups.com...
That's the major advantage of the IDE (language syntax aside). This, in my
opinion, is a *tremendous* boon to Inform development: the idea that you can
add a new snippet of code, click a button, and instantly view the output
(whether error or game) is something long enjoyed by users of other IDEs
(TADS has it, and the TADS debugger is one reason I enjoy using the IDE so
much). Imagine if you had to code the same thing driven by the old dos bat
file approach...
--Kevin
Kevin Forchione
news:1146826922....@g10g2000cwb.googlegroups.com...
> This is basically what I mean when I say I read code faster than its
> English equivalent (and that I sort-of have to translate I7 into code
> when I read it, or read it as code with an obese syntax, and not as
> English). I certainly don't mean that I have a Borgian facility with
> code -- FAR from it.
You never know, the monocle-like eyepiece might make a comeback in men's
fashions someday. I'd keep it in a spare parts drawer if I were you. During
the boom there were stories about Silcon Valley geeks who could "see"
patterns in the bytecode and intuitively "feel" bugs in the patterns. I'm
shocked you're lacking in this ability. I guess you're facility is more akin
to mine -- trial and error with more time in toil and in flashes of
brilliance, eh? So how's the TADS extension going? ;)
--Kevin
Kevin Forchione
news:1146827591.7...@u72g2000cwu.googlegroups.com...
> A more defensible argument would be that Inform's dialect is unnatural
> because it is addressed to a computer, which, ipso facto, is not a
> fellow human being: and which, since it lacks an appreciation of social
> nuances, contextual knowledge, etc., is therefore not "understanding"
> what is being said: and that Inform source text, being intended only to
> be fed into a mechanical grinder, is not natural even if it looks a bit
> that way. But I think this overlooks the fact that Inform source text
> is not addressed only to the computer. The author is also writing to
> himself - or, say, to the person he will be in three years' time, when
> a bunch of bug reports come in and he decides that he really ought to
> re-release "Stiffy Makane and the Preposition of Doom", which means
> looking back over source text he has forgotten writing. And of course
> Inform source text is also addressed to the eventual player: quite a
> deal of it is used directly in play. If I say "An orange pepper is on
> the kitchen counter", then noun phrases in that simple sentence are
> directly read by the eventual player - another human being.
Example code is also read by authors. What the language seems to do though,
which is something I rather like, but is not to everyone's taste obviously,
is that it encapsulates much of the low-level details that explain "how"
something is being done, and simply describes "what" is to be done. Now I
realize that this is the "black box" that is sometimes a heinous thing, but
I believe it is only heinous if the model doesn't reveal the "how" under
interrogation. In other words, I don't mind working with statements that
encapsulate a lot of meaning (any language above assembler does anyway), so
long as it is possible to gain an understanding, when necessary, of the
process that is being encapsulated, and if some means are provided for
tweaking the process where necessary or desirable.
A statement such as "An orange pepper is on the kitchen counter" tells me
something about the classes and states of the objects involved in a way that
orangePepper.location = kitchenCounter cannot. Indeed the statement enfolds
several levels of meaning at once: (a) what objects are involved; (b) some
indication of what kind of objects are involved; (c) what relationship the
objects have to each other. These levels of meaning would require a lot of
low-level code definition. Moreover, you couldn't easily replicate this kind
of encapsulation in a library extension (i.e. in TADS for instance) without
resorting to dynamic object creation, because the nature and relations of
objects is, as has been pointed out, an accretion throughout the compiled
source.
--Kevin
Adam Thornton
James Cunningham <jameshcu...@google.com> wrote:
>[1] What, did Nelson sleep with your mother and not call the next day?
Wait, Graham Nelson is actually Space Moose? What?
Adam
Adam Thornton
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>he decides that he really ought to
>re-release "Stiffy Makane and the Preposition of Doom"
Damn and blast! Nelson, you have given away my development road map!
Curse you! Good day, sir!
Adam
Aris Katsaris
> gRelation('overlook')
> [[garden, shrubbery],
> [folly, garden],
> [shrubbery, sundial],
> [iceHouse, garden]]
And instead of:
Jim, Jack and Mary are children of Thomas and Jane.
you'd do something like
gRelation("children")
[[Jim, Thomas]
[Jim, Jane]
[Jack, Thomas]
[Jack, Jane]
[Mary, Thomas]
[Mary, Jane]]
but frankly the first seems to me more clear, concise, and less prone
to accidental omissions.
-Aris Katsaris
The Wanderer
> Nate Cull wrote:
>
>> Which would you rather have: a diagram of a wiring closet with
>> coded symbols indicating simply and without fuss which wire
>> connects to which, or a long essay describing the relative
>> positions of each cable using English adjectives?
>
> Exactly. And if someone wants present this layout in English, you
> have to translate it back into a visually digestible diagram.
>
> This is basically what I mean when I say I read code faster than its
> English equivalent (and that I sort-of have to translate I7 into code
> when I read it, or read it as code with an obese syntax, and not as
> English). I certainly don't mean that I have a Borgian facility with
> code -- FAR from it.
This much makes sense, and seems to me like it should apply fairly
generally.
>> [code snipped]
>>
>> I don't think anyone could honestly argue that there's an
>> intuitively obvious and straightforward representation of the above
>> code snippet in I6 (or TADS, or any other procedural language).
>
> It would take an hour or two to set up a relational logic kit
> (including the macros to access it), but then it would be pretty
> easy. Again, instead of pretending it's English, I'd set it up to
> maxmize clarity and ease-of-reading, so instead of...
>
> The Garden overlooks the Shrubbery. The Folly overlooks the Garden.
> The Shrubbery overlooks the Sundial Plot. The Old Ice House overlooks
> the Garden.
>
> ...I'd do something like...
>
> gRelation('overlook') [[garden, shrubbery], [folly, garden],
> [shrubbery, sundial], [iceHouse, garden]]
This, however, is to me FAR less readable than the English-sentence
version above. Perhaps that's just because I'm not familiar with the
syntax of the language on which you are basing this declaration;
however, dense code is in fact usually more difficult to read than a
'natural-English' (sorry) statement of the same thing.
This latter point is, I think, part of why it's generally considered to
be a good idea to write out descriptions of a program you're intending
to write - and algorithms you're intending to use, and so forth - before
actually writing the code; I've only run across one example of an
algorithm complicated enough that I've actually done that, but it has
more than once been much easier for me to refamiliarize myself with the
algorithm involved by reading my somewhat-legalistic-English nested list
of steps than it would have been for me to do the same by reading code
implementing the algorithm - unless said code were heavily and clearly
commented, in which case the English explanations rather than the code
itself would still be providing the (easily accessible form of the)
information.
> (I hope you see what I mean when I say that the former seems like a
> translation of the latter, and not the other way 'round.)
No, I don't think so; it seems exactly the reverse to me.
(I think I had an additional point to make in this discussion, a day or
two ago, but I didn't think it was important enough to make a separate
post at the time and now I don't remember offhand what it was.)
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
Neil Cerutti
>> (I hope you see what I mean when I say that the former seems
>> like a translation of the latter, and not the other way
>> 'round.)
>
> No, I don't think so; it seems exactly the reverse to me.
>
> (I think I had an additional point to make in this discussion,
> a day or two ago, but I didn't think it was important enough to
> make a separate post at the time and now I don't remember
> offhand what it was.)
Since I've just finished reading Graham's very interesting white
paper on the design of Inform 7, I can report that the opposite
is indeed the case. Inform translates the statements using
predicate calculus into a list of predicates, and then uses model
theory to build a world model that satisfies the predicates in
the simplest possible way (assuming they make sense).
You could design a syntax to write the predicates directly
instead, but I believe from the white paper that would be a major
hinderance to the model building step, which looks back and makes
use of the grammar, context, and other peculiarities of the
original text.
--
Neil Cerutti
I am free of all prejudices. I hate everyone equally. --W. C.
Fields
Watts Martin
> It would take an hour or two to set up a relational logic kit
> (including the macros to access it), but then it would be pretty easy.
That depends a lot on how good the programmer in question is with
designing relational logic kits. I am a reasonably good programmer, but
it would not take *me* an hour or two. :) But we could assume that this
only has to be done once, and whoever does it would then make the
library available, so I would say "require gRelation" or what have you
in code.
> Again, instead of pretending it's English, I'd set it up to maxmize
> clarity and ease-of-reading, so instead of...
>
> The Garden overlooks the Shrubbery. The Folly overlooks the Garden. The
> Shrubbery overlooks the Sundial Plot. The Old Ice House overlooks the
> Garden.
>
> ...I'd do something like...
>
> gRelation('overlook')
> [[garden, shrubbery],
> [folly, garden],
> [shrubbery, sundial],
> [iceHouse, garden]]
But there's the rub! Your version maximizes *efficiency,* but does it
actually maximize clarity or ease-of-reading? When you read the pair
[garden, shrubbery], which one overlooks the other? The more verbose
way immediately makes that clear. Are the elements in that list of
lists related to one another -- that is, is there a connection between
[folly, garden] and [shrubbery, sundial]? In the quasi-English, there's
nothing to suggest that. With the quasi-code, maybe you'd better look
up gRelation in the manual again.
And now, how do we access that? We have 'overlook' as a string, so we
probably do something like, say,
if (garden.relation('overlook','shrubbery')) then...
instead of,
If the Garden overlooks the Shrubbery, then...
...yet that doesn't appear to have saved us that much space after all.
And are the parameters "(relation,object)" or "(object,relation)"? Is
the method name "related" or "related?" or "has_relation"? Drat, back
to the manual.
> (I hope you see what I mean when I say that the former seems like a
> translation of the latter, and not the other way 'round.)
Yes, I do, and I agree that on some level it is. (The "gRelation"
statement is not too far off from predicate logic notation, after all.)
My point is that the code-like statements are only easier to understand
and less ambiguous if you've internalized the formal syntax to start
with. The question is really whether I7's syntax, *specifically with
respect to writing interactive fiction,* is easier to internalize
because its syntax rules are a subset of English syntax rules.
I don't have any doubt that there are programmers who will continue to
use Inform 6, or use TADS 3 or Hugo or another system, in large part
because they're more comfortable with them. I also don't have any doubt
that I6 can do some things I7 cannot, while the reverse is not true.
But at risk of being a little facetious, we can substitute "assembly
language" for "I6" and any high-level language you care to name for
"I7." Even so, I know I'd rather program in C++ than assembly (and I'd
much rather program in Ruby than either).
The larger question to me is whether I7 will make writing interactive
fiction easier by being closer to the way writers "think" about stories
-- even writers who are also programmers. Writing a story is, despite
the logic and rigor that (usually) needs to be applied to plot
construction, a very different process than writing a program; it's
worthwhile to test the hypothesis that the best tool for writing
interactive fiction would be something that successfully combines
*both* processes. No matter how perfect or flawed I7 proves to be in
the coming months, this is, from a writer's standpoint, really pretty
damn exciting stuff.
steve....@gmail.com
> I believe we are narrowing the definition of "fake-NL" further now:
Nothing has changed but your rhetorical strategy. My point is the same
it was at the top post: I7 has the semantics of a programming language,
thinly disguised as NL.
> it's "programming code varnished by macros (or productions, or
> whatever) designed to give said code a superficial appearance of
> English". That "designed to..." part may be a red herring, since it
> suggests that the intention of the creator is what counts.
Design goals have a lot to do with what comes out in the end. If you're
trying to make a clear, formal syntax, and you're not bending over
backwards trying to make it look like English, you'll have something
that looks a lot different from I7. You'll have something that nobody
would call fake-NL, though it be precisely as far from NL as what you
have now.
> While
> better, this is still a debateable definition. Post-Chomsky, systems of
> productions exist which define very large subsets of English - indeed,
> Chomsky's whole project, and that of the whole field of generative
> linguistics, is essentially that productions do exist which define
> natural languages.
Is this supposed to convince anyone that I7 is anything other than what
I have described? (A programming syntax with a varnish of English.)
> Productions exist such that all valid programs on a
> given computer are valid strings for that grammar, and you have said
> that you don't assert that all reducible-to-story-file descriptions are
> "fake-NL". So I think "productions, or whatever" might have to go from
> your definition.
Slow down there Charlie. I have no idea what you're talking about.
> What I take you to mean is that "fake-NL" is something which is turned
> into a conventional programming language by simplistic rewriting
> macros, typically used in such a way that a small number of macro
> substitutions turns one form into the other. That's fair enough as an
> aesthetic idea, even if it is difficult to make precisely
> distinguishable from "real-NL", as I suppose the antonym would be.
That's fairly reasonable, although my point has nothing to do with the
complexity of the rewriting macros.
> On the other hand, it's not what Inform does at all.
The unspoken difference being that I7 does this with *complicated*
rewriting macros, not simplistic ones? Come on -- you're just dancing
'round the point again.
> Let's consider your example, for instance: "A equals A" being only a
> lexical rewriting of "A=A", or in C it would be "A==A". Sure. "A equals
> A" is, however, not what one writes in Inform. One tends instead to use
> the more natural verb "to be", which is very much more complex in
> meaning than "to be equal to", even in the present tense, even used
> positively, even used declaratively. Consider, for instance, some of
> its simplest uses:
>
> The score is 20.
> The bronze door is open.
> East is a dead end.
> The prevailing wind is a direction that varies.
>
> Here we have (a) a value assignment, (b) an assertion that something
> partakes of a property, (c) an assertion that a previously unmentioned
> thing (which therefore requires construction) lies in a particular
> place in the map and has a given kind, (d) a declaration of type.
So like I was saying above, if you were trying to make a clear syntax,
you'd do it differently. But you want to make it sort-of reflect normal
English in the syntax... so much that you make the meaning of operators
context-dependent.
In order for the user to understand the code, he has to parse it, just
like the machine does. The more complicated you make the parsing, the
more difficult it is to read the code. It's not more English, it's just
more occluded.
[...]
> In the end this is an aesthetic discussion.
I do not think the difference between fake-NL and natural language is
only aesthetic. Clearly it is aesthetic to a degree: I would call I7
UNnatural language, in that it sounds so wooden and wierd if you read
it as genuine English and not disguised computer code. That's
aesthetic.
But it's more than just aesthetic.
It's practical: if my objective is to give the machine some specific
instructions, I want to talk in *its* language, or at least some
compromise language like C, and not NL. NL just isn't a good language
for specific instructions -- just look at any ANSI spec, or any legal
document; just ask yourself why mathematicians use symbols in their
formulae.
It depends what you're trying to do. If you're trying to communicate to
a machine a specific set of instructions, the language you use to
communicate to the machine will not be English, no matter how
sophisticated is its NLP interface: it will boil down to program code.
If, on the other hand, there's a machine designed to convert a novel
into IF (say it takes _Pride and Prejudice_ and figures out the names
of the actors, some of their phrases, and a couple settings -- hell it
could do no worse than the recent movie (poor Donald Sutherland!)) --
this would be a real NLP. The language would be real English, not
computer code badly disguised as English.
> Inform does what it claims to, but that won't be to everyone's taste.
I'm sorry: I didn't know it was claiming to do anything beyond what it
objectively does. Is there some important reference I'm missing?
Benjamin Caplan
> "An orange pepper is on the kitchen counter",
> then noun phrases in that simple sentence are
> directly read by the eventual player - another human being.
I'd like to see the same functionality in a more codelike syntax, one
in which the forms of the symbols are used to create a spatial
arrangement of code that structures the mind of a human reader of the
source code to understand the mechanics that are being implemented.
For example:
pepper [an, orange, On: counter (kitchen) ]
Or, if this is also the first definition of the counter, then:
pepper [an, orange, On: counter [the, kitchen] ]
I feel that this more codelike style of syntax (which conveys exactly
the same information) encourages more rigorous thought and easier
grokking of the machine.
Kevin Forchione
news:slrne5mqov....@FIAD06.norwich.edu...
> On 2006-05-05, James Cunningham <jameshcu...@google.com> wrote:
>> On 2006-05-05 09:40:13 -0400, Neil Cerutti <lead...@email.com> said:
>>
>>>> gRelation('overlook')
>>>> [[garden, shrubbery],
>>>> [folly, garden],
>>>> [shrubbery, sundial],
>>>> [iceHouse, garden]]
> The nested brackets and lack of connection between
> gRelation('overlook') and the rest of the statement are what
> makes it confusing (and I'm a Schemer!). In general I believe
> that a good Algol-like or Lisp-like syntax could be invented. But
> that wasn't it.
So you'd probably prefer something like:
(gRelation 'overlook' (garden shrubbery) (folly garden) (shrubbery sundial)
(iceHouse garden))
That would be fairly easy to implement in REPL, you'd just have to define
the keywords and then provide a class that handles the evaluation process -
lol, that's the easy part. Of course, you'd have to build in the whole
infrastructure to handle relationships and what it means to overlook
something...
--Kevin
steve....@gmail.com
Watts Martin wrote:
> Steve Breslin writes:
>
> > It would take an hour or two to set up a relational logic kit
> > (including the macros to access it), but then it would be pretty easy.
>
> That depends a lot on how good the programmer in question is with
> designing relational logic kits.
Well, I just mean the problem you initially pose. Under time challenge,
I could probably patch together some old code and have something
running (with the hood off) in like 10 minutes. But the questions is,
how to optimise its usability, and expand it to cover all desirable
relations and calculations. That's the real work.
> But there's the rub! Your version maximizes *efficiency,* but does it
> actually maximize clarity or ease-of-reading? When you read the pair
> [garden, shrubbery], which one overlooks the other?
I have no doubt that my example syntax could be improved. Please don't
dismiss the idea because you don't like the sample syntax I proposed.
By the way, if you have even just a quicko suggestion for better
syntax, I for one would be happy to hear.
> The more verbose
> way immediately makes that clear.
Many have already pointed out that I7 code is essentially
self-documenting. Still, code always gets messy, and when I7 code gets
messy, I bet it gets really messy indeed, and no amount of
self-documentation is going to get you out of it. (Wouldn't it be fun
to see messy fake-NL code with true-English comments?)
> No matter how perfect or flawed I7 proves to be in
> the coming months, this is, from a writer's standpoint, really pretty
> damn exciting stuff.
I like it too. My main interest is the logic relational stuff, which
seem to me entirely separate from the NL pretentions. I don't know
about from a writer's standpoint. If it were true NL, sure. But being
that it's just logic programming in a meagre disguise, I don't see how
that helps the writer so much. The NL pretentions might make it a bit
more newbie friendly, is my thinking.
Kevin Forchione
> You could design a syntax to write the predicates directly
> instead, but I believe from the white paper that would be a major
> hinderance to the model building step, which looks back and makes
> use of the grammar, context, and other peculiarities of the
> original text.
Yes, it's a very sophisticated approach. All the more so because it then
manages to leverage the I6 library as well.
--Kevin
steve....@gmail.com
> In each case, you have a certain, fairly-well-circumscribed[...]
Many years ago, when I was in high school, in English class I read a
poem which included that word, "circumscribed." But I, being somewhat
dyslexic, misread "circumscribed," seeing instead "circumcised." I
don't remember very well my reading of the poem (which I explained to
the class, in what amounted to a rather uncomfortable scene), nor what
poem it was. But I've had a special affinity for the word ever since.
> However, within these strictures, there are entertaining and interesting
> stories to be told, and I think that the fundamental art of constructing
> an interesting locked-room murder mystery and the art of constructing a
> puzzle-oriented piece of IF are--if the author of the IF is provided
> with a library to implement things in a sufficiently common-sensical
> way--close to (though probably not exactly) coterminous.
Yeah, strictures. Coterminous, too. Now you're really starting to scare
me. Thanks again.
James Cunningham
> And instead of:
>
> Jim, Jack and Mary are children of Thomas and Jane.
>
> you'd do something like
>
> gRelation("children")
> [[Jim, Thomas]
> [Jim, Jane]
> [Jack, Thomas]
> [Jack, Jane]
> [Mary, Thomas]
> [Mary, Jane]]
>
> but frankly the first seems to me more clear, concise, and less prone
> to accidental omissions.
Of course, you could shorten that up by some conceit (maybe having one
'side' of the relation being an ordered pair):
gRelation( 'parentof' )
[ [ ( Thomas, Jane ), Jim ]
[ ( Thomas, Jane ), Jack ]
[ ( Thomas, Jane ), Mary ]
Something like "Thomas and Jane are parents of Jim, Jack, and Mary" is
pretty, clean, yeah, but you've got to write this too:
"Parenthood relates one thing to another (called the child). The verb
to be a parent of implies the parenthood relation."
This sort of thing confuses me, perhaps, far more than Steve's fake
relation syntax that I've used above. Why? I dunno; it's not that I'm
a programmer (I'm a *terrible* programmer). But it may have something
to do with all the different words that have to go into describing the
relation - parenthood; to be a parent of; et cetera. It's a lot to
keep in my head at one go.
parentof -> elements of parentof
is void of unnecessary baggage.
Best,
James
Kevin Forchione
news:2006050523135916807-
> Something like "Thomas and Jane are parents of Jim, Jack, and Mary" is
> pretty, clean, yeah, but you've got to write this too:
>
> "Parenthood relates one thing to another (called the child). The verb to
> be a parent of implies the parenthood relation."
>
> This sort of thing confuses me, perhaps, far more than Steve's fake
> relation syntax that I've used above. Why? I dunno; it's not that I'm a
> programmer (I'm a *terrible* programmer). But it may have something to do
> with all the different words that have to go into describing the
> relation - parenthood; to be a parent of; et cetera. It's a lot to keep
> in my head at one go.
>
> parentof -> elements of parentof
>
> is void of unnecessary baggage.
Does strike me as a lot of work to avoid using the simple English statement.
The trouble is that in order to accomplish the same kind of effect in
"typical" code you have to provide english-like method or property names and
then represent groupings with some kind of enclosure pair: {}, [], ().
Because of the nature of most of the algol syntaxes you then have to
decipher the meaning of the statement from its original definition, which
can be fairly arbitrary as one moves from definition to definition.
Take for instance the above 'parentOf' example. How are the relationships to
be organized if we are passing them as arguments to a isChildOf() method, or
as part of a gRelationship() method? The groupings of the arguments passed
in these methods is arbitrary, and hence their sematic meaning isn't clear
from simply reading the code. Obviously isChildOf((tom mary) (sue tim)) is
semantically ambivalent. We might be able to deduce the meaning if certain
symbols appear across groupings, but we cannot tell without referencing the
original function definition whether the first grouping represents parents
and the second children, or if each grouping is a complete relationship.
Furthermore the syntax of isChildOf() need not necessarily be the same as
the syntax for isParentOf() or of any isXxxxOf() construct. The definition
is arbitrary and entirely at the caprice (or hopefully consistency) of the
author.
On the other hand, the statement "x and y are SomeRelationship of A and B."
is a construct whose organization is apparent at a glance, and whose syntax
is obviously consistent across various relationships. We know for instance,
at a glance who the "parents" are, and who the "children" are without having
to reference the original definition of the construct.
Furthermore because an English word or phrase can be "overloaded" like the
"+" might be in many language syntaxes, we can establish different
operations for the phrase while still maintaining the same consistency of
syntax. So whether a word like "is a child of" refers to something like
object derivation or containment or some other relationship whose meaning
has relevance only within the world of the story, the syntax for the
construct is consistent. In an ordinary coding language the syntax of the
overloading may in fact be different. In one case the argument arrangements
may mean one thing based on their number and type, and something else when
otherwise configured. So the author is then pressed with the burden of
consulting the original definition (or scanning through syntax choices if
his editor is sophisticated enough).
Psychologically, of course, we've been raised up through our education to
believe that the English statement is less precise and accurate, more to be
suspected, and hence that mathematical symbols are the language of true
unambiguity. That may very well be true, but in order to create a system of
predicates that could be mapped onto unambiguous object and class
definitions the particular subset of English would have to be void of
ambiguities or in cases where an ambiguity might exist, must provide some
kind of simple rule of precedence. For instance, in most mathematics courses
the rules of precedence for a statement such as 4a + 3b have been clearly
delineated and inculcated from the outset so that one understands this
statement as (4a) + (3b) and not as ((4*(a + 3))*b). So I7 must consist of a
rigorous subset of English, a grammar, if you will, whose rules are more or
less consistent.
Furthermore, since the statements are English-like they must obey rather
closely the syntax of natural English. So you're unlikely to see a construct
that breaks the rules of English grammar for the sake of fulfilling the
requirements of a programming construct. For instance, we can chain method
calls in TADS something like:
gPlayer.getLocation.getContents().printName().
Now arguably this is perhaps the clearest example of a concise use of
codelike syntax. The English equivalent cannot possibly be translated either
reading from left to right or right to left as a single statement. To
accomplish this same kind of construct in English you would have to say
something like
"Print the names of all of the objects in the location of the player."
This is merely an example of an English-like statement, and not an I7 one,
but it demonstrates that the rules of English grammar must (by and large) be
adhered to, and that this does not necessarily conform to the order of
operations adopted as convention in the more familiar coding styles. What it
shows is that the style is less slavish toward the requirements of the
"machine" and more slavish (if you will) to the requirements of the human
mind.
The question still remains to be answered, however, "Do androids dream of
electric sheep?" My personal belief is that some of them probably do...
--Kevin
jaunty alan
complexity of the rewriting macros.
among other things, the complexity of the rewriting (of anything) is
clearly key. complexity is what takes something from trivial and
mechanical to interesting and helpful.
Jon Ingold
> If, on the other hand, there's a machine designed to convert a novel
> into IF (say it takes _Pride and Prejudice_ and figures out the names
> computer code badly disguised as English.
Is it relevant that such a machine would be rubbish? Figuring out the
actors names and a couple of settings just isn't an achievement of note.
I could do that just by hunting for capital letters, and phrases like
"' * ,' <possible person> said"
and throwing 99% of the text away. As for generating anything like the
real P&P as IF -- I'm a pretty good NL parser myself, and I'd have
trouble doing it, so if that's your benchmark for NLP you're unlikely to
make any progress beyond "Are we nearly there yet?"
Seriously, what you're missing is that Inform isn't trying to parse NL
anyway. It's a format choice, designed to offer a compact and efficient
way to express the components of text adventures. In the end, all
programming languages do the same thing:- create instructions to flip
bits of the memory in pretty patterns.
There are too many obvious advantages to a) "The big red book is on the
kitchen table" and b) "if a random person (called the winner) is
collecting something (called their prize) on the prizes table, move
their prize to the winner" to argue this with much seriousness, I think.
The only objection I can find is there's a learning curve, and gosh,
it's awful not being totally in command of a computer, isn't it?
Jon
Watts Martin
> dismiss the idea because you don't like the sample syntax I proposed.
> By the way, if you have even just a quicko suggestion for better
> syntax, I for one would be happy to hear.
In quasi-Ruby, it might go something like:
require 'relation'
class <<Room
extend Relation
end
garden = Room.new("Garden")
ice_house = Room.new("Old Ice House")
garden.add_relation(:type=>'overlook', :from=>'ice_house',
:to=>'garden')
(Although offhandedly, I'm not entirely sure where the relations are
actually stored in this arrangement. Apparently on the object they're
added to, but I'm not sure that'd be the best implementation. But I
digress.)
I'm not dismissing the idea -- I'm just declaring an uncertainty that
the code-like approach is objectively clearer in all (or even most)
cases. Yes, that does make it "newbie-friendly," to be sure, but I'm
not sure it's only good for newbies. In I7 you might write:
The Boring Chamber is a room. "This chamber is impressively boring.
There are exits north and south." The Exciting Chamber is north of the
Boring Chamber. The Emotionally Neutral Hall is south of the Boring
Chamber.
In I6 syntax (I started to do a Ruby-esque version, but supposed it to
be a little pedantic in a discussion about Inform!), that'd roughly
equate to:
Object BoringChamber "Boring Chamber"
with description
"This chamber is impressively boring. There are exits north
and south.",
n_to ExcitingChamber,
s_to NeutralHall,
has light;
Object ExcitingChamber
s_to BoringChamber,
has light;
Object NeutralHall
n_to BoringChamber,
has light;
They're about the same in word length, but the I7 one "feels" more
concise and direct to me. It also strikes me as slightly less prone to
gathering simple programming mistakes, although in part that's because
of assumptions it makes: for instance, that an exit is usually two-way
rather than one, and it makes more sense to require us to explicitly
say two rooms have a one-way exit between them rather than have to
define the exit in both. It strikes me that I7 has a lot of those
sensible assumptions in its default set of rules, and they may not just
be a matter of adding a line or two to I6 source as an equivalent. I
can't think of a way to implement "exits should be two-way as a
default" without a moderately sophisticated preparser, for instance.
It seems most skepticism of I7 is from people who are very comfortable
with programming language syntax and are writing off the NLP aspect as
syntactic sugar. To me, though, the argument comes down to whether the
"meagre disguise" helps the programming aspects of interactive fiction
or hinders them. It would certainly seem that a few people who've
actually, well, *written* interactive fiction in both styles -- people
who are definitely not "newbies," either -- are leaning toward "help"
rather than "hinder."
Richard Bos
> On 2006-05-05, James Cunningham <jameshcu...@google.com> wrote:
> > On 2006-05-05 09:40:13 -0400, Neil Cerutti <lead...@email.com> said:
> >
> >>> gRelation('overlook')
> >>> [[garden, shrubbery],
> >>> [folly, garden],
> >>> [shrubbery, sundial],
> >>> [iceHouse, garden]]
> >
> >> I hope you see that the latter looks like utter gibberish.
> >
> > Steve's being an utter asshole[1], here, but I must say that I
> > agree with him, or at least that I share the mental strangeness
> > that makes his example more clear than a long and repetitive
> > string of English sentences.
>
> The nested brackets and lack of connection between
> gRelation('overlook') and the rest of the statement are what
> makes it confusing
No. They're what makes it confusing _to you_.
Richard
steve....@gmail.com
> James Cunningham wrote:
> > parentof -> elements of parentof
> Does strike me as a lot of work to avoid using the simple English statement.
That's looking at it backwards. From its inception, precisely this is
the preferred syntax in logic and knowledge base programming. The
initial reason for this was not to avoid the English statement, but to
express the relation in the same form that the core algorithm is
designed to understand it: to lay bare the logic.
This is more direct -- no need for any second-level transformation; so
the system designer has fewer things to worry about. The syntax also
has the benefit of being compact and perfectly visually organized; one
very quickly gets the knack for reading it (and writing it), so ease-
and speed-of reading is maximized. (As Nate Cull was arguing.)
But perhaps the most important benefit (which doesn't actually appear
until someone comes along and suggests a different way), is that the
user is thinking in the same terms that the machine is. This may sound
terribly Borgian, but I think it's important to recognize and
appreciate. In the worst case, the user is writing in terms of one
model, and the machine is processing in terms of another model -- and
the translation and the disjoint is either invisible or obscure. If I'm
writing in Prolog, I'm thinking in terms of Horn clauses; if I'm
writing in I7, I'm thinking in terms of god knows what: my guess at
what the system is going to understand my meaning. I don't feel the
weight off my shoulders, "ah now I can just write" or so; instead, I
have to think several times as hard.
That said, there's nothing wrong with using English words as operators,
or even English grammatical constructions as syntactic patterns. The
absolutely necessary ingredient is to recognize them as operators and
programming patterns, so we don't fall into the inevitable confusions
of fake-NL.
> Psychologically, of course, we've been raised up through our education to
> believe that the English statement is less precise and accurate, more to be
> suspected, and hence that mathematical symbols are the language of true
> unambiguity.
The argument against using English can certainly turn dogmatic. I agree
that English language operators and constructs can help. (Hell, that's
what 'while' 'do while' 'foreach' 'break' and the rest are.) But once
the fact that they're operators and constructs becomes occluded, that
is, once we begin pretending that it's NL, we're up to a very different
business, and it seems to me pretty problematic.
How to avoid it? I guess simply don't over do it. Use English as it
suits, but use shorthand where appropriate. Never favor English where a
symbolic one will make clearer the underlying programming model.
steve....@gmail.com
Jon Ingold wrote:
> > If, on the other hand, there's a machine designed to convert a novel
> > into IF
> Is it relevant that such a machine would be rubbish?
No, I don't think so. I'm just explaining the distinction between real
NL processing and fake NL programming. I don't claim that real NLP is
going to produce thrilling results.
Mark J. Tilford
> I
> can't think of a way to implement "exits should be two-way as a
> default" without a moderately sophisticated preparser, for instance.
It's given as an exercise in the DM4.
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
Gene Wirchenko
[snip]
>Huh, I seem to read his post a bit different from everyone else. I think
>the point he's making is that you don't *need* to really be a cook to cook
>a burger. I've made plenty of good burgers, even though I would never
>consider myself a cook. In addition, I've run without thinking of myself
>as a "runner", and I've driven without being labeled as a "driver". In
You probably have a card that labels you a driver: a driver's
licence.
>other words, you should be able to (and can) program IF without being
>thought of as a "programmer".
Nope. As someone else said, it is not a badge. There are very
low standards to be an Xer: just X. Now, if you want to be a good
Xer, that comes with a lot more work. (Burn the burgers, and no one
will call you a good cook. Well, maybe the dog will.)
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
David Alex Lamb
Andrew Plotkin <erky...@eblong.com> wrote:
>Here, steve....@gmail.com wrote:
>> Rule-based programming is problematic because the algorithm and
>> program-flow occur outside of the view of the programmer.
>> ...
>> Andrew Plotkin has theorized a very similar system, the main problem of
>> which, he explains, is the handling of rule precedence. My reaction to
>> I7 as a rule-based system is the same as my reaction to Plotkin's
>> theory (which I imagine was influenced by his exposure to I7
>> development).
>
>Actually, the influence was two-way, if I may say it myself. When I7
>was in a very early stage -- this was nearly three years ago -- I got
>into an email discussion with Graham. In the middle of that, I came up
>with this crazy rule-based model for IF programming, and wrote several
>pages of "concept code"; not based on any rigorous model, but
>demonstrating how I would do common IF tasks in a rule-like way.
It may be time to mention again that, 25 or so years ago, the world's largest
'production system' (rule-based) was Haunt, a text adventure. I have
completely lost touch with that segment of the computing community, and have
little energy for reconnecting, but perhaps other readers are more familiar
with what's happening with rule-based programming these days.
--
"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5
http://www.cs.queensu.ca/~dalamb/ qucis->cs to reply (it's a long story...)
David Alex Lamb
James Cunningham <jameshcu...@google.com> wrote:
>On 2006-05-05 15:41:18 -0400, "Aris Katsaris" <kats...@gmail.com> said:
>> And instead of:
>> Jim, Jack and Mary are children of Thomas and Jane.
>> you'd do something like
>> gRelation("children")
>> [[Jim, Thomas]
>> [Jim, Jane]
>> [Jack, Thomas]
>> [Jack, Jane]
>> [Mary, Thomas]
>> [Mary, Jane]]
>>
>> but frankly the first seems to me more clear, concise, and less prone
>> to accidental omissions.
>
>Of course, you could shorten that up by some conceit (maybe having one
>'side' of the relation being an ordered pair):
>
>gRelation( 'parentof' )
>[ [ ( Thomas, Jane ), Jim ]
> [ ( Thomas, Jane ), Jack ]
> [ ( Thomas, Jane ), Mary ]
or
gRelation('parentsHaveChildren')
[ [ (Thomas, Jane) (Jim, Jack, Mary) ]]
which is pretty close to the original. And close to something that could be
directly represented in GEDCOM, the ancient standard for genealogical
databases.
Though, of course, representing modern family structures would be a heck of a
lot more complex.
David Alex Lamb
<steve....@gmail.com> wrote:
>All I mean is that I7 is a programming structure which can be
>represented in fake-NL, but which needs to be read in terms of the
>underlying programming structure, if you're to understand what the
>program does.
This is only true in a very literal sense. To "truly" understand what a C or
Java or ... program is doing you need to understand the underlying machine
language, which is why we still teach machine architecture in computing
curricula. But lots of people write perfectly good C programs without having
to mentally translate "i += 2" into "load 3rd word indexed by register 5 into
register 6; load constant 2 into registger 7; add register 7 into register 6;
store register 6 into 3rd word indexed by register 5".
So it is with any "different" programming paradigm. It ultimately translates
down to machine language, but most people rarely have to think about that --
they think in abstractions provided by the paradigm.
I haven't seen Inform 7, and as a non-writer of IF I may not for a long time,
but I expect I'd be able to do most of my thinking and writing in terms of the
concepts Graham presents.
David Alex Lamb
<steve....@gmail.com> wrote:
>Graham Nelson wrote:
>> While
>> better, this is still a debateable definition. Post-Chomsky, systems of
>> productions exist which define very large subsets of English - indeed,
>> Chomsky's whole project, and that of the whole field of generative
>> linguistics, is essentially that productions do exist which define
>> natural languages.
>
>Is this supposed to convince anyone that I7 is anything other than what
>I have described? (A programming syntax with a varnish of English.)
The ultimate goal of "automatic programming" in artificial intelligence was to
take "natural language" statements and turn them into programs. Are you
claiming this could never be anything different thatn a programming language
with a varnish of English? Is it always "fake NL" until it handles
everything, however obtuse, that a native speaker might write? does an ESL
student only understand "fake NL"?
You're turning a matter of degree into some kind of absolutist claim.
steve....@gmail.com
> >All I mean is that I7 is a programming structure which can be
> >represented in fake-NL, but which needs to be read in terms of the
> >underlying programming structure, if you're to understand what the
> >program does.
>
> This is only true in a very literal sense. To "truly" understand what a C or
> Java or ... program is doing you need to understand the underlying machine
> language, which is why we still teach machine architecture in computing
> curricula. But lots of people write perfectly good C programs without having
> to mentally translate "i += 2" into "load 3rd word indexed by register 5 into
> register 6; load constant 2 into registger 7; add register 7 into register 6;
> store register 6 into 3rd word indexed by register 5".
>
> So it is with any "different" programming paradigm. It ultimately translates
> down to machine language, but most people rarely have to think about that --
> they think in abstractions provided by the paradigm.
I really appreciate what you're saying. There's a difference between
(a) understanding how the machine performs its operations (which, by
design, C occludes/glosses, as you exemplify), and (b) being able to
refer directly to those operations, and thinking in terms of them
(which, by design, I7 occludes, as I have argued).
In I7, there seems a disjunct between the operation, the paradigm, and
the syntax/grammar. Other programming languages attempt to perfectly
reflect the paradigm in the language, but the operation and paradigm of
I7 is occluded.
(Thanks for the "Haunt" reference.)
David Alex Lamb
Damien Neil <neild-...@misago.org> wrote:
> ad...@fsf.net (Adam Thornton) wrote:
>> <steve....@gmail.com> wrote:
>> >Yes, you have to be a programmer to write IF. (Actually,
>> >let me revise that slightly: "You have to be a programmer to write
>> >interesting IF.")
>You need to be a programmer to write IF in exactly the same way that you
>need to be a cook to cook a hamburger, a driver to drive a car, or a
>runner to run.
Actually that "cook" example is kind of interesting. If by (human) "cook" you
meant "anyone who cooks a hamburger is by definition a cook" it's trying to
define terms so you win the argument, which is what I think may (*may*) be
happening with the "must be a programmer" statement. A while back someone may
have needed to be a moderately competent cook to produce decent hamburgers.
These days you can pop some patties in the microwave and push a few magic
buttons and it's done -- you're not a "cook" in the classical sense at all.
Which may have something to say about "high level programming paradigms".
steve....@gmail.com
> The ultimate goal of "automatic programming" in artificial intelligence was to
> take "natural language" statements and turn them into programs. Are you
> claiming this could never be anything different thatn a programming language
> with a varnish of English?
I don't know anything at all about "automatic programming" theory, so I
cannot respond to this body of work. This theory may strictly define
"natural language statements" for all I know. I *can* say that
NLParsing and NLProgramming seem quite different to me. In the first
case, it's the computer trying to make sense of what the human said; in
the second case, the human is trying to figure out how to form an
(English-sounding) sentence that represents the intended instruction.
> Is it always "fake NL" until it handles
> everything, however obtuse, that a native speaker might write?
Please don't absolutize the distinction into an absurdity. It's a
distinction somewhat valuable.
But to answer your question, NLProgramming becomes indistinguishable
from NLParsing when giving the computer instructions is no more certain
to produce the desired results than giving the computer a human-like
impression of what you're after.
David Alex Lamb
James Cunningham <jameshcu...@google.com> wrote:
>For as soon as you want to give the computer any more precise
>instructions, it *becomes* programming. Maybe someday I can say
>"Computer, make me a web browser. I want it to use the Gecko engine."
>When I say "When the user clicks "reload", reload the page, but when
>they click "shift" first and then "reload", I want you to regrab all of
>the stuff from the server", then I'm engaged in programming, despite
>how high level it is.
Hmm. This made me pretty uncomfortable. I want to call what you're doing
'specifying' (what you want to have done) and equate 'programming' with
'implementing' (how you want to get it done). Unfortunately there doesn't
seem to be a clear distinction between the two since 'implementing' involves
writing yet another (perhaps lower-level) specification
Perhaps it might be useful to toss in the concept of 'refinement', which made
its way into the formal specification community a while back. One writes an
initial, high-level mathematical specification, which states things as clearly
and concisely and generally as possinly, but which may contain expressions
impossible to implement on current computers (such as quantifying over
infinite sets). One then adds detail, getting something formally equivalent
to the original but expressed in concepts easier to implement.
So maybe one can start with a very English-like IF description, which looks a
lot like something a complete non-programmer would write, and call that a
natural language description (or specification). Then when it turns out not
to be quite possible to translate that into something executable, one adds a
few more bits that express details more clearly, until it gets to the point
where the translator can handle things on its own without more help.
The skill of refining is related to, but different from, the skill of writing
the initial specification. Some people might have trouble seeing how to
figure out a smaller-than-infinte set to iterate over. So perhaps a beginner
might be able to write something reasonable as their first cut, with someone
else able to help add the implementation-necessary details later; it fits the
'refinement' idea rather than the 'rewrite' idea if the original can remain
mostly intact.
I don't know whether this fits I7 at all.
David Alex Lamb
Damien Neil <neild-...@misago.org> wrote:
>Programming is the act of writing a program. A "program" is what we
>call a set of instructions for a computer to follow. (Okay, a "computer
>program", if you want to be really pedantic.) So if you're setting down
>instructions for a computer--or something computer-like--to follow,
>you're programming.
This looks to me like another case of trying to win the argument by defining
terms. Anytime I'm instructing a computer, I'm programming? Then what about
Picard giving orders to Data? (in writing, I suppose, because of the "setting
down instructions" bit)
>I wouldn't consider a CYOA book to be programming, since there isn't
>anything to program. Nor would I consider a recipe to be programming.
A recipe is a non-program only by your definition, since it's instructions for
a human rather than a computer. You need to read an old out-of-print book
called 'the sachertorte algorithm' where in one chapter the author uses his
aunt's sachertorte recipe as an example of refining an abstract specification
into an algorithm in terms of operations ithe processor (the author in this
case) could implement.
David Alex Lamb
<steve....@gmail.com> wrote:
>In I7, there seems a disjunct between the operation, the paradigm, and
>the syntax/grammar. Other programming languages attempt to perfectly
>reflect the paradigm in the language, but the operation and paradigm of
>I7 is occluded.
So far I've been able to react to general things people say, but for this one
I'm going to have to look closer at I7 to see if I agree with you.
Unfortunately, that may take a while for me.
David Alex Lamb
<steve....@gmail.com> wrote:
>David Alex Lamb wrote:
>> The ultimate goal of "automatic programming" in artificial intelligence was
to
>> Is it always "fake NL" until it handles
>> everything, however obtuse, that a native speaker might write?
>
>Please don't absolutize the distinction into an absurdity. It's a
>distinction somewhat valuable.
If I'd written my thought out in full it might have been "surely you don't
mean the absurdity of ..."
>But to answer your question, NLProgramming becomes indistinguishable
>from NLParsing when giving the computer instructions is no more certain
>to produce the desired results than giving the computer a human-like
>impression of what you're after.
Hmm. This sounds interesting but I'm not sure I grok the implications. The
likelihood of translation error has to be nontrivial? I meant this seriously,
not as an oblique criticism.
I think that would be more an issue of the complexity of the context the
parser needed to "understand" the statement. Of course there's both
mistranslation and known failure to understand -- in the latter the parser
(human or otherwise) just says "huh?"; in the former (s)he/it charges along
with false assumptions.
I'd guess you'd agree both are undesirable, but are you saying they have to be
nontrivially possible for NL parsing to be different from NL programming?
steve....@gmail.com
> >from NLParsing when giving the computer instructions is no more certain
> >to produce the desired results than giving the computer a human-like
> >impression of what you're after.
>
> Hmm. This sounds interesting but I'm not sure I grok the implications. The
> likelihood of translation error has to be nontrivial?
Well, I'm more into conceptual distinctions, rather than "has to"'s.
But yeah, that's where I'd let the distinction fall. I mean, that's the
distinction between explaining and programming, right? But I think I
have communicated to you the spirit of this distinction, and you
understand the terms very well, so I'm sure you can improve on this
rather hasty theory.
Paolo Nusco Perrotta
language" is defined as the general-purpose language of humans, code
that looks like natural language to humans is actually closer to
natural language just for looking like it.
BTW, I guess the proof is in the pudding. If you're uncomfortable with
the fancy I7 syntax, I'm sure it wouldn't be difficult to come up with
a different concrete syntax and a translator. A syntax that has been
designed from scratch to look like English is still easily wrapped into
a more symbolic-looking syntax. The other way round is difficult (try
to write a syntax for C that makes it look like English). So, I7
already bought me something, and that's a chance to choose my poison.
Paolo Nusco Perrotta
>colludes syntax and structure.
Yes, he colludes concrete syntax and abstract syntax. The interesting
thing in I7 is that they do somewhat work together. If you define
something in I7, it look like a first-class citizen of the language,
because its symbolic name is also one of its runtime attributes - a
characteristic which works well in the peculiar field of IF.
Trying to make myself understood, here's a line of code from I7's
manual:
now Mr Darcy can see the mouse
You could express this with a different concrete syntax:
darcy->can_see = mouse
But then you'd have to explicitly define the entities:
obj darcy
obj mouse
rel can_see
And you'd have to give "print names" to the entities for the final
user's consumption:
darcy.name : "Mr Darcy"
mouse.name "mouse"
can_see.name "can see"
That's why I7's approach looks really smart to me.
I still share some of your worries, as I7's lack of formatting makes my
head spin when I look at the code. But maybe I'm just warped by
computer programming.
steve....@gmail.com
Paolo Nusco Perrotta wrote:
> Yes, [Graham] colludes concrete syntax and abstract syntax. The interesting
> thing in I7 is that they do somewhat work together.
(and)
> If you're uncomfortable with
> the fancy I7 syntax, I'm sure it wouldn't be difficult to come up with
> a different concrete syntax and a translator.
You're right that they do work together somewhat. The (somewhat)
relationship between the language and the underlying model is obscured
by the parse transformation. But they mutually determine each other, so
it might indeed be difficult to come up with a concrete syntax: we're
not in Prolog any more, and it may be that we're in a fake-English
modal logic no-man's land.
Adam Thornton
David Alex Lamb <dal...@qucis.queensu.ca> wrote:
>The ultimate goal of "automatic programming" in artificial intelligence was to
>take "natural language" statements and turn them into programs. Are you
>claiming this could never be anything different thatn a programming language
>with a varnish of English? Is it always "fake NL" until it handles
>everything, however obtuse, that a native speaker might write? does an ESL
>student only understand "fake NL"?
>You're turning a matter of degree into some kind of absolutist claim.
Chinese Box cries!
Adam
Adam Thornton
Gene Wirchenko <ge...@abhost.us.NOTTHIS> wrote:
>(Burn the burgers, and no one
>will call you a good cook. Well, maybe the dog will.)
Maybe YOUR dog will. Mine prefer their burgers raw.
Adam
Adam Thornton
<steve....@gmail.com> wrote:
>Adam Thornton wrote:
>> In each case, you have a certain, fairly-well-circumscribed[...]
>Many years ago, when I was in high school, in English class I read a
>poem which included that word, "circumscribed." But I, being somewhat
>dyslexic, misread "circumscribed," seeing instead "circumcised." I
>don't remember very well my reading of the poem (which I explained to
>the class, in what amounted to a rather uncomfortable scene), nor what
>poem it was. But I've had a special affinity for the word ever since.
I'll make a note of that, for the next time Space Moose needs a
malapropism.
>> However, within these strictures, there are entertaining and interesting
>> stories to be told, and I think that the fundamental art of constructing
>> an interesting locked-room murder mystery and the art of constructing a
>> puzzle-oriented piece of IF are--if the author of the IF is provided
>> with a library to implement things in a sufficiently common-sensical
>> way--close to (though probably not exactly) coterminous.
>
>Yeah, strictures. Coterminous, too. Now you're really starting to scare
>me. Thanks again.
Ooh. The _Argumentum ad Vocabularium Maijorem_; haven't seen that one
in a while.
Adam
steve....@gmail.com
> >> However, within these strictures, there are entertaining and interesting
> >> stories to be told, and I think that the fundamental art of constructing
> >> an interesting locked-room murder mystery and the art of constructing a
> >> puzzle-oriented piece of IF are--if the author of the IF is provided
> >> with a library to implement things in a sufficiently common-sensical
> >> way--close to (though probably not exactly) coterminous.
> >
> >Yeah, strictures. Coterminous, too. Now you're really starting to scare
> >me. Thanks again.
>
> Ooh. The _Argumentum ad Vocabularium Maijorem_; haven't seen that one
> in a while.
Nah, merely further fuel for malpropriation. I like your theory of the
closed room mystery/riddle. I agree it intersects with IF simulationism
in an interesting way. Not sure what to make of it beyond that. Figured
my response would be relatively irrelevantly unreverenetially, uh,
irrevulent?
And while I was being irrevulent, I figured I'd malappropriate in good
fun. No argumentum (or offense) intended (of course).
John W. Kennedy
> I still share some of your worries, as I7's lack of formatting makes my
> head spin when I look at the code. But maybe I'm just warped by
> computer programming.
COBOL programmers learned years ago that just because a language doesn't
need formatting, it needn't eschew it.
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
Adam Thornton
<steve....@gmail.com> wrote:
>And while I was being irrevulent, I figured I'd malappropriate in good
>fun. No argumentum (or offense) intended (of course).
There are none at all here to take!
Adam
Paolo Nusco Perrotta
lots of formatting. Code tends to look like free-form text, which is
exactly the point. Still, I get a bit lost when I look at it.