A cryptic review of I7
Samwyse
sufficiently radical remake of Inform could be renamed Enlighten. In
almost every aspect, I7 more than meets the criteria for my suggestion.
Imagine Inform 6 as a book or a telegraph wire, a way for an author to
send relatively simple messages to an audience. Assign it the color orange.
Imagine TADS 2 as a record player or a radio, a way to send messages
that capture much more of an author's nuances. Assign it the color yellow.
Imagine Inform6 with Glulx as USENET or a CD-ROM, mostly carrying the
same sort of messages as the first example, but able to send much larger
messages with much less trouble. Assign it the color green.
Imagine TADS 3 as television or a DVD player, a restucturing and an
extension of radio that allows many more facets to be communicated due
to greater bandwidth between author and audience. Assign it the color blue.
Inform 7 is eBay, a complete system that allows the delivery of all of
the above and more, but to use it requires accepting Paypal. Assign it
the sound of middle C on a piano.
The first four examples can be laid out on a line of increasing
complexity and ability. The last lies so far off that line that it is
hard to see how it can be judged as an evolution of any of the others.
In some important ways, I7 does something that I've advocated on this
list for years with my work on RAP, log2inf, and recent work with IFM.
In many ways, it provides a way to unify under one roof the sort of
stuff that I've been doing. (Although let me make clear that it does
not do any of the things that I've mentioned.) For this reason I love
it, but that unification is done via an extremely high-level language,
instead of a series of distinct domain-specific languages, and I'm not
sure if that is the best path to be taking. For one thing, that
extremely high-level language may be more difficult to port for
non-English speaking authors.
On the other hand, to use I7 requires (in a way) giving up my cash and
checkbook and moving my finances to Paypal. I'm allowing a system to
take over many things that I'm used to doing for myself, and I'm still
unsure if that's a step that I'm willing to take.
Kevin Forchione
news:j9XNf.62367$PL5....@newssvr11.news.prodigy.com...
>A couple of years ago, I suggested on the Inform maintanance list that a
>sufficiently radical remake of Inform could be renamed Enlighten. In
>almost every aspect, I7 more than meets the criteria for my suggestion.
> On the other hand, to use I7 requires (in a way) giving up my cash and
> checkbook and moving my finances to Paypal. I'm allowing a system to take
> over many things that I'm used to doing for myself, and I'm still unsure
> if that's a step that I'm willing to take.
You're right... that's pretty cryptic, and the metaphors aren't very useful
to me. However, if it is indeed the case that I7 encapsulates a great deal
of functionality in a high-level language, this may not be a bad thing. Only
time will tell.
It does remind me of the thread on the TADS3 newsletter regarding the
grammar production's parseTokens() method, an intrinsic method that hid its
implementation details. This method essentially takes a token list and
returns a grammar match tree ... quite a substantial encapsulation of
functional detail, and very powerful.
Eventually the need arose to expose some of those details so that its
behavior could be replicated/modified. Otherwise anyone wishing to modify
the behavior of the method was required to rewrite substantial sections of
the parser. While demand for this kind of behavior modification is indeed
rare, it came up, and it's possible that this will be the case with aspects
of I7... but I'm sure that Graham Nelson will meet those challenges when
they arise and produce his usual elegant solution to meet the needs of I7
authors.
--Kevin
Aaron A. Reed
For example... purely hypothetical, I assure you... should authors with
new game ideas hold off on starting to develop them until the details
of Inform 7 are announced?
Andrew Plotkin
>
> For example... purely hypothetical, I assure you... should authors with
> new game ideas hold off on starting to develop them until the details
> of Inform 7 are announced?
mean learning the new language. This will involve some learning
curve[*], so you can't really compare it with just starting a new
project in a language you already know. Different costs, different
benefits.
With neither a deadline nor an idea of what the language is, it's
probably a bad idea to rearrange your life around its release. That's
all I'm trying to get at. :)
[* I honestly couldn't tell you whether it's more or less than
learning I6 was.]
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because you're innocent.
ChicagoDave
I would add that you can most certainly flesh out the story, text,
logic, and map and this will all still be viable for Inform 7.
David C.
Aaron A. Reed
And by the way-- despite the rude and negative posts being thrown
around in the other thread, I for one am extremely grateful to the I7
team for putting in the time to develop what sounds like a real step
forward in IF authoring tools. I think everybody is now well and fully
intrigued.
In short: you guys rock.
--Aaron
ChicagoDave
that would be considered close to the development process. My guess is
that it is mostly Graham, Emily, David Kinder and Andrew Hunter.
The rest of us were on the Inform maintenance list that's gotten a peak
at a midstream alpha/pre-beta version about 6 months ago.
I'm just as much a fan of this whole thing as anyone else. I'm just as
excited and can't wait to see the public beta.
David C.
Samwyse
> Any idea when we get to stop being cryptic?
When I7 comes out. I really don't want to spoil Graham's "surprise" for
everyone, but I'm as fidgety as a five year old the day before their
birthday. I will say that I don't think that there's anything in I7
that hasn't been discussed in this very newsgroup in the past few years;
in fact, just over two years ago something vaguely similar to I7's
syntax was discussed.
> For example... purely hypothetical, I assure you... should authors with
> new game ideas hold off on starting to develop them until the details
> of Inform 7 are announced?
I7 is further from I6 than TADS-3 is from TADS-2. If you have given any
thought about how you'll code your next game, go ahead with your target
language. If you have gotten no further than, say, a transcript *and*
you don't mind a bit of a wait, then I7 may be worth waiting for.
Samwyse
>
> In some important ways, I7 does something that I've advocated on this
> list for years with my work on RAP, log2inf, and recent work with IFM.
Now that Zarf has let one of the cats out of the bag, I'll be a bit less
cryptic. I7 is a domain-specific language that translates into I6. The
only version that I've seen is the early beta provided to the Inform
maintainance list six months ago, so things may have changes a bit, but
I'm fairly certain that what I'm about to describe is still true.
> In many ways, it provides a way to unify under one roof the sort of
> stuff that I've been doing. (Although let me make clear that it does
> not do any of the things that I've mentioned.)
I7 does this by allowed things (rooms, objects, etc) to be described in
multiple places, and then pulling those bits and pieces together into
one bit of I6 code. In my Perl scripts, I've been moving towards the
creation of XML descriptions of things. These descriptions are then
merged together and turned into I6 code.
> For this reason I love
> it, but that unification is done via an extremely high-level language,
> instead of a series of distinct domain-specific languages, and I'm not
> sure if that is the best path to be taking.
My scripts each use different ways to describe things. The current
version of 'log2inf' (unpublished) takes a transcript file and produces
a more computer-friendly description of rooms and scenery. 'ifm2inf'
(also unpublished) takes a description intended for the Interactive
Fiction Mapper and produces similar descriptions of puzzles. The
emphasis of the first script is to produce 'description' properties for
things, the second (indirectly) produces 'before' properties. I have a
third Perl script that merges these descriptions together and produces
an I6 file containing objects with both detailed 'description'
properties and 'before' methods. It shouldn't be hard for me to modify
my scripts to produce I7 code instead of XML, and then use the I7
compiler in place of my third script. This has me very excited,
especially since I expect that many people in this newsgroup have no
idea what XML is or why using it is usually a Good Thing.
OTOH, I'm using input languages that are, in a way, optimized for their
domains. Writing a "fake" transcript is a very efficient way to produce
a lot of descriptive text. Out of the box, I7 isn't quite as consise.
Most programing languages use a lot of special keyboard symbols, like {
and }, or # and &. The downside is that a newcomer has to learn what
this new vocabulary means in order to use it, but there are two upsides.
One is that this new way of "speaking" is very consise. For example,
in Inform I can say this:
Array my_pets cat dog goldfish;
To express this in English, you might instead say this:
I have a list (call it 'my_pets') of three objects: a cat, a dog and
a goldfish.
I want to hastily emphasize that the preceding isn't an example of I7.
However, it does illustrate how a language that wants to be friendly to
newcomers can require a lot more typing. In the 1950's, a programming
language called COBOL went down this path, with mixed results. COBOL
tried to be English-like, but hidden within was a syntax just as
constrained as any other programming language: you just had to use
specific English words and phrases instead of special characters. It
turned out that this made the language just as hard for people to use as
the other common programming languages of the day, despite it's iniital
appearance of friendliness.
> For one thing, Inform's extremely high-level language may be
> more difficult to use for non-English speaking authors.
The other upside to using special symbols instead of pseudo-English is
that people who don't speak English can learn a programming language
more quickly. A non-English-speaking person can understand FORTRAN's "e
= m*c^2;" a bit easier than COBOL's "multiply m by the square of c,
giving e." The authors of COBOL recognized this problem and adopted a
syntax very similar to that using in I-F: Each statement in that
language is a verb followed by a list of direct objects and
prepositional phrases. They hoped that later versions of COBOL would
include "plug-ins" for Belgian, Italian, etc, but the idea never took off.
Six months ago, I7 seemed to be following the trail blazed by COBOL.
This leaves me a bit disappointed.
> On the other hand, to use I7 requires (in a way) giving up my cash and
> checkbook and moving my finances to Paypal. I'm allowing a system to
> take over many things that I'm used to doing for myself, and I'm still
> unsure if that's a step that I'm willing to take.
As a professional programmer, I am used to a set of tools which I use
regardless of the language in which I'm programming. I7 does not force
me to abandon those tools, but it does push me in that direction. 'Nuff
said.
John Bruce
> (SNIP)
>
> For example... purely hypothetical, I assure you... should authors with
> new game ideas hold off on starting to develop them until the details
> of Inform 7 are announced?
While this is only my own personal opinion of thse things, I would
never recommend delaying a perfectly good project in anticipiation of a
development tool that is not in your hands yet. As Andrew has pointed
out elsewhere in this thread, there is necessarily a learning curve in
encountering any new language or system. I would also add that despite
the rigorous testing I7 is undergoing, it will doubtless still have a
few bugs upon release that will need ironing out. Too, Graham himself
has said that I6 will still be maintained, in part because I7 relies on
it but also in part because I7 will not be the right language for
everybody's projects, and without knowing what I7 entails, you can't
really judge if it's right for yours. Perhaps most importantly,
however, if you have already fleshed out your idea to the state where
you would begin working, it seems a waste to let it grow stale and rot
just because you don't want to implement it in an existing language.
I could see, perhaps, justification if your idea was very "out there"
and would be difficult to implement in existing languages, and thus you
thought the alluded-to new paradigm of I7 would free you to write your
piece more easily, more cleanly, and overall better. But if the
existing systems COULD work for you, then why wait? Just to be "using
the latest thing" seems both risky and unnecessary to me. There's no
reason we should all stop making IF and hold our breath until I7 is
released.
--
With All Due Respect,
John Bruce
Kevin Venzke
> I7 is further from I6 than TADS-3 is from TADS-2.
Wow. I had not expected that.
Kevin Venzke
steve....@gmail.com
> > I7 is further from I6 than TADS-3 is from TADS-2.
>
> Wow. I had not expected that.
>From a certain point of view, Tads-3 is not very different from Tads-2.
The objects look about the same (the typical definition of a "kitchen
table" object looks the same; per-object action handling looks pretty
similar); some intrinsic operations have migrated to the library, but
they work nearly the same. Most of all, the syntax looks and works the
same. It feels like the same language.
With Inform-7, the syntax is a lot different. The programming model's
orientation is different. The programmer, like Samwyse, will see this
as a radically different creature, as will the typical game-writer.
These are all superficial observations, of course. But in their
superficiality, they show that "I7 is further from I6 than TADS-3 is
from TADS-2" is a complex idea (even if very vague).
Poster
> I could see, perhaps, justification if your idea was very "out there"
> and would be difficult to implement in existing languages, and thus you
> thought the alluded-to new paradigm of I7 would free you to write your
> piece more easily, more cleanly, and overall better. But if the
> existing systems COULD work for you, then why wait? Just to be "using
> the latest thing" seems both risky and unnecessary to me. There's no
> reason we should all stop making IF and hold our breath until I7 is
> released.
>
> --
> With All Due Respect,
> John Bruce
>
I quite agree. Hey look, if I7 is going to be here someday, that's
awesome. Folks will have put a lot of work into it and it'll be great.
In the meantime, let's make the best of the tools we have. For me,
that's I6.
It's the old upgrade joke. If you wait long enough, what you want will
cost 30 credits or so. But you'll have nothing in the meantime.
-- Poster
www.intaligo.com Building, INFORM, doom metal
Kevin Forchione
news:1141526849....@i39g2000cwa.googlegroups.com...
> These are all superficial observations, of course. But in their
> superficiality, they show that "I7 is further from I6 than TADS-3 is
> from TADS-2" is a complex idea (even if very vague).
A question to answer in this respect is whether I7 will be targeted toward
the I6 library. We know from previous posts that I7 will produce I6
compliable source code, but what is of interest is whether the underlying
parser/execution cycle/model world will be significantly different from that
of I6.
--Kevin