Inform 7 first impressions
Lorenzo Marcantonio
DISLIKES:
- Too much verbose sintax
- 'fake' natural language sintax with a lot of clauses to remember
- Tieing the language to an ide (maybe, it seems that it can be
disconnected). I mean, can it work as a stand-alone compiler?
(especially when/if it will be released for unix platforms)
- Putting in the language stuff that can be handled by the library...
well, the traditional 'library' isn't here no more. So features can be
easier to use but difficult/impossible to modify/hack
- The chapter/section division is completely arbitrary... IT IS a
computer program after all, and under the candy sugary pseudo natural
language syntax there is a regular grammar.
- Special ad-hoc cases... like why 'most' is 50%+1 and 'almost all' is
80%? IMHO that's FAKE legibility... declarative languages are around
for more than 30 years and most of the natural language based one are
flawed. OTOH declaring stuff as horn clauses would be really bad :P
LIKES:
- Scene stuff
- All the rule based stuff (well, it seems picked from an expert
system, anyway...)
- check/perform on actions like TADS
CAN BE USEFUL:
- all that 'kind' classification stuff (like units and qualitatives)
- the autorouter
ABSOLUTELY NEEDS:
- a 'grammar reference' in the documentation
- where is foreign language support gone?
DOUBTS:
- isn't it a little heavy on the z machine or will be mostly targeted
for glulx? for example the stack size issue for the terps...
I fear inform is going toward COBOL bloating...
jameshcu...@gmail.com
Well - perhaps I'm being a jerk, but I feel compelled to point out that
the word you're looking for is "syntax". A "sin tax" is a tax levied
on goods or activities that are looked down upon socially, like
cigarettes or alcohol. A "sintax", as far as I know, is nothing at
all.
I too am interested to find out whether the compiler will be released,
extricated from its development environment. It seems to me that Mr
Nelson wishes the program to *just be* Inform 7, which is okay, but it
would seem to leave KDE/Gnome/BeOS/RISC OS users out in the cold. This
is okay for me - I do most of my computing on OS X and Windows - but of
course the very rare individual will be miffed. Allowing other
individuals to design new development environments around the natural
language Inform would be nice.
As for your "doubt", according to the SPAG interview with Nelson and Ms
Short Glulx will eventually be targetted, probably (one can only hope)
with an extension to the natural language syntax to allow for
multimedia.
Best,
James
what finals?
Stuart Moore
> I too am interested to find out whether the compiler will be released,
> extricated from its development environment. It seems to me that Mr
> Nelson wishes the program to *just be* Inform 7, which is okay, but it
> would seem to leave KDE/Gnome/BeOS/RISC OS users out in the cold. This
> is okay for me - I do most of my computing on OS X and Windows - but of
> course the very rare individual will be miffed. Allowing other
> individuals to design new development environments around the natural
> language Inform would be nice.
Inform 7's code has been released under the terms of the GPL (Inform 6,
as I understand it, has not been). In theory, it would be possible to
create a command-line version of the tool (stripping out the UI and
related functionality). Whether it'd be worth it, of course, is another
question. Alternatively, the UI could be rewritten using a
cross-platform toolkit ala WxWindows. Not as easy (relatively speaking)
as stripping the UI off, put most likely more useful.
> As for your "doubt", according to the SPAG interview with Nelson and Ms
> Short Glulx will eventually be targetted, probably (one can only hope)
> with an extension to the natural language syntax to allow for
> multimedia.
Graphics seemed a certainty, sound less so, if I understood the
interview correctly.
--
Stuart "Sslaxx" Moore
http://sslaxx.livejournal.com/
ChicagoDave
Inform 7, adhering strictly to its current design, but built using Mono
C#. The WinForms capabilities are slowly coming to completion and it's
my belief that such a project might be started sometime this summer or
fall. When Mono WinForms is viable, I will query Graham about this
again and go from there.
If you don't like Mono or believe it's somehow tainted by Microsoft
patents, I cannot help you. I believe Mono is entirely viable and safe
for cross-platform development.
David C.
James Cunningham
> I discused with Graham early on about creating a third UI project for
> Inform 7, adhering strictly to its current design, but built using Mono
> C#. The WinForms capabilities are slowly coming to completion and it's
> my belief that such a project might be started sometime this summer or
> fall. When Mono WinForms is viable, I will query Graham about this
> again and go from there.
Is there any reason why Java couldn't be used for such a project?
Swing has matured to the point where I would not hesitate to use it for
a GUI project, at least if cross-platformishness were my primary goal.
Such a project could begin immediately.
Alternatively, there are cross-platform user interface libraries that
work great (Qt) or very well (WxWidgets).
best,
James
Andrew Plotkin
>
> Inform 7's code has been released under the terms of the GPL (Inform 6,
> as I understand it, has not been).
The interface applications are out as GPL. The source code for the
actual I7 compiler has not yet been released. I'm not sure what Graham
is planning for that, but the desire of Linux geeks to play with the
new toy would militate for some kind of release under an I6-like
license.
--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.
Andrew Plotkin
>
> Is there any reason why Java couldn't be used for such a project?
> Swing has matured to the point where I would not hesitate to use it for
> a GUI project, at least if cross-platformishness were my primary goal.
> Such a project could begin immediately.
I've been working with the Java (Swing) toolkit for a while now, and I
agree -- it's usable. (Although clunky enough that I'm glad it's not
the *primary* solution for Mac and Windows platforms.)
Graham Nelson
language syntax" a chance; it has a sinewy strength which is, perhaps,
not really apparent until one begins defining new verbs to express
inter-relationships. Natural language is as optimised for talking about
human situations - the physical world, and the world of people - as C
is for low-level filtering of data in files. (I think COBOL has stood
the test of time rather well, too, within its own domain, and I note
that it is still used today.)
I have no wish to leave users of other operating systems out in the
cold, and would be very pleased to see a Linux user interface for
Inform (for instance). The task of writing this would not be a small
one - the interface has to do some pretty extraordinary things - but
I'm very open to proposals.
At some point, yes, the underlying command line tools will be
independently available and their source published. Their usefulness is
limited, but we do use them now and then at shell level, for instance
in the mechanical test which verifies that the examples in the
documentation all compile and play correctly.
But I do indeed think of Inform as the assembled whole, not as any of
the individual pieces: and - this is a more general point, though I
mean it as no attack on any other system - I feel IF needs to present
rather more integrated, rather richer tools to the general public. I
look back at Inform 6, and think that it would have sat nicely as part
of a Unix distribution in, say, 1979. (If it had been better
programmed, anyway.) Now that is a vital culture today and in no sense
one whose time has passed. I use perl, bash, gcc, sed and so forth all
the time. But a command-line tool with terse error messages - because
Silence is Golden and output exists to be mechanically read by other
programs - is unlikely to tap into the great well of creativity among
Internet users at large. Blogs, for instance, did not take off as a
result of RSS becoming available: they took off because fairly
convenient tools existed with which you could "just write".
Kevin Forchione
news:1146433563.0...@y43g2000cwc.googlegroups.com...
> Personally there are a lot of things I dislike and a lot I like:
> I fear inform is going toward COBOL bloating...
So? Run it on a mainframe.
--Kevin
ChicagoDave
probably much safer than Mono WinForms. I'm on the mailing list for
Mono WinForms and it ain't pretty. I don't think they anticipated the
enormity of copying this part of .NET. But they _are_ getting close.
Though Java+Swing would certainly be a viable cross-platform solution.
David C.
Aaron A. Reed
and playing around, are extremely positive. It's trivial, but I've been
getting a great deal of pleasure from Graham Nelson's superhuman
ability to turn expository technical writing into light, witty banter,
that still manages to be instructional. The Inform application is great
to use, as well: I like the layout of everything and tools available
are phenomenal. The index, in particular, is a great resource.
More significantly, I'm impressed by the I7 syntax. At first glance
it's reminiscent of Applescript, which has similar natural language
commands and is very readable as source code. When I first became a Mac
convert about a year ago, I was very excited by Applescript and and
tried to do some things with it, but quickly hit a dead end when I
couldn't get the syntax of scripting language correct. It reads great,
but you really have to understand a lot to get it to do anything that's
not completely trivial, and the end result is that's it's still
programming, but with more typing.
Early in Chapter 3 of the I7 documentation, a mention is made of
rideable vehicles. Curious, I typed a few sentences into the code
window without referring back to the manual, creating a Stable, a
meadow, and a rideable horse, and hit "Go." I'd misunderstood the usage
of just one word--which a verbose, friendly error message told me how
to fix without needing to refer back to the manual--and on my second
attempt, it all compiled and everything worked exactly as I had
imagined.
Computers just don't *do* that! :) Kudos again to the I7 team.
Giovanni Riccardi
> I think I'd suggest that people give the "candy sugary pseudo natural
> language syntax" a chance; it has a sinewy strength which is, perhaps,
> not really apparent until one begins defining new verbs to express
> inter-relationships. Natural language is as optimised for talking about
> human situations - the physical world, and the world of people - as C
> is for low-level filtering of data in files. (I think COBOL has stood
> the test of time rather well, too, within its own domain, and I note
> that it is still used today.)
In the discussion on the Italian Newsgroup, I suggested the same thing.
I always thought a system for creating IF should be "optimised" for a
target of writers, not programmers. I7 seems to take this path. And for
language verbosity, I think writers have no problems to write more words
to express something. I didn't examined the new language in detail, but
I noticed you hide in some way programming specific concepts (I didn't
see any variable, array, class, etc. in the documentation) and expose
algorithmic ones (rules to do something with elements of the IF).
> I have no wish to leave users of other operating systems out in the
> cold, and would be very pleased to see a Linux user interface for
> Inform (for instance). The task of writing this would not be a small
> one - the interface has to do some pretty extraordinary things - but
> I'm very open to proposals.
One could use the same interface for all three major platform (MacOS,
Linux, Windows). GTK is one solution to this problem.
For the interface itself, I didn't find anything to configure the Inform
6.31 compiler to use some switches. I believe the environment should
be user configurable.
> At some point, yes, the underlying command line tools will be
> independently available and their source published. Their usefulness is
> limited, but we do use them now and then at shell level, for instance
> in the mechanical test which verifies that the examples in the
> documentation all compile and play correctly.
A system for unit testing could be very useful for command line tools. I
believe this can be more useful than any other I7 GUI tools (at least
for programmers, not for writers).
Giovanni
Tikitu
> independently available and their source published. Their usefulness is
> limited, but we do use them now and then at shell level, for instance
> in the mechanical test which verifies that the examples in the
> documentation all compile and play correctly.
Please! For those of us tied to linux, and too impatient to wait for
the gurus to port the IDE... I *really* want to test-drive the new
syntax.
Anyone have any success with WINE, and willing to write up the hoops
they jumped through?
Oh, and: Wow.
Wow wow wow.
John Elliott
: Alternatively, there are cross-platform user interface libraries that
There's also GNUstep, which shares a common ancestor with Cocoa (the
library used by the Mac front end).
--
John Elliott
Stuart Moore
> Anyone have any success with WINE, and willing to write up the hoops
> they jumped through?
The .MSI doesn't appear to work with WINE or it's variants, currently.
Jacek Pudlo
> But a command-line tool with terse error messages - because
> Silence is Golden and output exists to be mechanically read by other
> programs - is unlikely to tap into the great well of creativity among
> Internet users at large. Blogs, for instance, did not take off as a
> result of RSS becoming available: they took off because fairly
> convenient tools existed with which you could "just write".
Here's what I think you're saying. Correct me if I'm wrong.
Inform 7 is meant to attract new talent to interactive fiction, where "new
talent" denotes humanists who are scared shitless of FOR-loops and syntactic
paraphernalia like != and <=. These people can now skip the hard groundwork
of learning a programming language and "just write."
My impression of Inform 7 is that trivial things like defining and
connecting rooms and cramming them with objects have become even easier,
while non-trivial things like designing puzzles remain non-trivial to
implement. In practical terms this means that you can map your apartment in
ten minutes, but if you want puzzles with that, you must prepare yourself
for a steep learning curve.
Inform 7 is a cute toy. It is slick as hell. Instead of learning to program,
say "just write!"
That's a false promise. If anything, it will ghettoise the medium by
attracting the wrong crowd, like ADRIFT, only worse, because Inform 7 is
*way* more cute and slick.
Bruce Stephens
[...]
> My impression of Inform 7 is that trivial things like defining and
> connecting rooms and cramming them with objects have become even easier,
> while non-trivial things like designing puzzles remain non-trivial to
> implement. In practical terms this means that you can map your apartment in
> ten minutes, but if you want puzzles with that, you must prepare yourself
> for a steep learning curve.
>
> Inform 7 is a cute toy. It is slick as hell. Instead of learning to program,
> say "just write!"
It's reasonable to fear that. The impression I get from reading some
of the documentation, and some of the articles about I7, is that they
tested exactly that, to ensure that difficult things are easier in I7
too.
[...]
Graham Nelson
"natural language for legible syntax" - which I think is the basis of
COBOL or AppleScript, for instance, though I quite admire both of those
languages as highly suited to their own domains of expertise - and
"natural language for stronger semantics".
For instance, "Instead of going through the Great Gateway when all of
the magic rings are in the wooden box", to take a simple example, looks
superficially like a paraphrase. But in fact it implicitly contains a
loop and some pattern-matching and creates a rule which depends on the
simultaneous behaviour of lots of things. The ability to do this sort
of thing concisely and cleanly makes I7 rather more powerful than I6,
in my own view: it adds something different in character, just as
regular expression matching makes Perl semantically different from C.
The idea is to save up one's programming time for what is genuinely
fresh and unusual about this particular situation.
I believe the Examples offer some evidence that highly complex puzzles
are, in fact, more accessible to I7 writers. Many would have been
pretty purgatorial to write in I6 (though certainly feasible). But
let's see how people feel after they've played around for a while.
This was a three-year project; the "cute and slick" stuff only took
about a year of that (though implementation and polishing wasn't easy).
Far more of the thinking time went into working out the ideas which
really don't paraphrase I6 at all: relations, units, scenes, and so
forth. It will be interesting to see how total newcomers to programming
get along with the documentation.
Andrew Wooldridge
it would be very interesting once the compiler, etc. is released to
have a plugin for eclipse for this -- then having to have a 3rd party
IDE might be less of an issue.
Wei-ju Wu
bread-and-butter UI framework). On Unix based systems I personally
would prefer an UI implementation based on a higher level language such
as Ruby, Python or Java (or Mono, if you like, Dave).
In this particular case, instead of Swing, it would be interesting to
consider an Inform IDE based on Eclipse. It saves a lot of work for
developing a stable IDE, because there is already a stable and neat
looking platform in place.
If I had the time, I would love to look into it (well, "if"....).
Wei-ju
James Cunningham
> In this particular case, instead of Swing, it would be interesting to
> consider an Inform IDE based on Eclipse. It saves a lot of work for
> developing a stable IDE, because there is already a stable and neat
> looking platform in place.
Eh. Interesting to *consider*, I guess. ;) But Eclipse is huge and
slow and unwieldly, and would bring a significant amount of baggage to
the party. I believe that a very large portion of the impetus behind
I7 is the attempt to snare creative persons, of the sort who would not
be comfortable with a traditional programming language. Those persons
would be manifestly uncomfortable with Eclipse.
Besides, SWT is in certain circumstances uglier and slower than Swing.
I would not encourage its use here.
I would think even that a jEdit plugin would be better, and easier, and
a smaller download.
As for other things to try: WxPython has a lot of support and is
stable, from what I understand. WxRuby not so much; but
Korundum/QtRuby perhaps. For Mono, I'd think that GTK# would be a
better idea than Windows.Forms, and would be native for Gnome and could
be made to look pretty decent in KDE.
Best,
James
Andrew Plotkin
>
> > In this particular case, instead of Swing, it would be interesting to
> > consider an Inform IDE based on Eclipse. It saves a lot of work for
> > developing a stable IDE, because there is already a stable and neat
> > looking platform in place.
>
> Eh. Interesting to *consider*, I guess. ;) But Eclipse is huge and
> slow and unwieldly, and would bring a significant amount of baggage to
> the party. I believe that a very large portion of the impetus behind
> I7 is the attempt to snare creative persons, of the sort who would not
> be comfortable with a traditional programming language. Those persons
> would be manifestly uncomfortable with Eclipse.
I have tried to use Eclipse, and it defeated me.
I am not proud of this. But it's probably indicative of something.
(That something being "Eclipse is.... problematic...?")
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
"Bush has kept America safe from terrorism since 9/11." Too bad his
job was to keep America safe *on* 9/11.
Wei-ju Wu
results and the fewest reinvented wheels, as a software developer, I
have gotten lazier with the years :-)
I have to admit, Eclipse is pretty huge (a 35 MB download, I would
expect for an Inform IDE based on Eclipse) - can't confirm the "ugly
and slow", though - but it comes with the infrastructure and is pretty
flexible. Looking at it from the authors' perspective, there would be
definitely some work to tailor it to their need, that's for sure.
That said, only a concrete implementation would tell.
Wei-ju
Bruce Stephens
> My first thought was which way probably would get me the quickest
> results and the fewest reinvented wheels, as a software developer, I
> have gotten lazier with the years :-)
>
> I have to admit, Eclipse is pretty huge (a 35 MB download, I would
> expect for an Inform IDE based on Eclipse) - can't confirm the "ugly
> and slow", though - but it comes with the infrastructure and is pretty
> flexible. Looking at it from the authors' perspective, there would be
> definitely some work to tailor it to their need, that's for sure.
It's Java, and I imagine the existing ones are Cish. Also, I get the
impression that Eclipse has its own idea of what an interface ought to
look like. Probably a good I7 interface could be put in a suitable
form, but my guess is for a first attempt it would be better to copy
the existing interfaces as slavishly as possible. I don't know what
the easiest way to do that would be (GNUstep, GNOME, KDE, or something
else).
Adam Thornton
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>(I think COBOL has stood
>the test of time rather well, too, within its own domain, and I note
>that it is still used today.)
Ah-HA!
Actually, when I have time, I'm planning on writing a little something
about my experience with I7, but one of the bits is going to be that it
has a lot of very interesting features, and a lot of features that
remind me of COBOL, and that these two sets are not entirely disjoint.
I expect that last clause to be a major bone of contention on this
newsgroup.
Adam
Adam Thornton
As soon as there's source for a Linux version, I'll build it for S/390
(which will also run on zSeries, of course).
Adam
REH
fun--I've always loved to code). My first impressions of Inform 7: It
makes me want to throw out everything I've done! It's truely
ingenious. I particularly like the generalization of relations (binary
predicates). I have them in my world model, but only for parent/child
relationships. I've programmed in many, many languages over the years.
I never thought natural languages would go anywhere. Nelson's paper
on the subject is making rethink that stance...
REH
John W. Kennedy
> (I think COBOL has stood
> the test of time rather well, too, within its own domain, and I note
> that it is still used today.)
COBOL has some horrible problems (although I hear that COBOL 2002 has
fixed the worst), but I don't really see Inform 7 and COBOL intersecting
much. The faults of COBOL have tended to be:
bad defaults (e.g., DISPLAY instead of COMPUTATIONAL),
bad software engineering (e.g., the abominable PERFORM THRU),
nonportability (intermediate-result precisions left as an
"implementation detail", God help us!),
instability (not only frequent changes of syntax, but frequent
changes in semantics of the /same/ syntax, often in subtle and
dangerous areas, such as the binding strength of NOT)
slow reaction to technological progress (disks first supported in
1968, ISAM in 1974, structured programming in 1985...),
a tendency to avoid recognized jargon only to invent new COBOL jargon
(e.g., where other languages said something like "BUFFERS(2)", which
any competent programmer understood, COBOL insisted on "RESERVE 1
ALTERNATE AREA"),
a tendency to force "English-like" syntax for concepts that are not
at all readily expressed in English, the result being neither good
English nor good notation. (I have heard that, back in 1959, the
designers of COBOL seriously considered eliminating the IF
statement, "because 'if' is not a verb.")
In general, I don't see Inform 7 as guilty of these faults.
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
Wei-ju Wu
there is no C-ish or Java-ish interface, especially from the user's
standpoint. The Java UI toolkits should be flexible enough (there is an
HTML element to view the docs, that one could embed, for example) to do
the job and Swing can be configured to look really pretty.
I agree with you that it would be nice that the interfaces resemble
each other on the different platforms - which does not look too
difficult.
What I think is pretty cool is the embedding of the interpreter with
automatic resizing (great job), the "Skein" feature is a nice idea as
well.
I really like it on the first impression, very fast roundtrips - the
syntax is a bit unusual though (but then, I am only a programmer).
Wei-ju
Graham Nelson
little COBOL. It seems to me, though, that it did have one genuine
strength: when looking at typical COBOL code written by a long-dead
programmer, it's fairly easy to tell what he was trying to do. This is
a plus in industries where code is kept in use for decades (e.g. the
financial services sector); perhaps it is also a good idea in a
long-term cultural product?
J. Robinson Wheeler
more easily than on small delights, but I wanted to
mention something that's been sticking on me. Overall,
I find the natural language syntax to be kind of catchy,
like my brain could get used to thinking in that mode.
However, as a conversation on ifMUD brought to mind, I
am having difficulty correctly reading the delineations
of [if]-[otherwise]-[end if] blocks within output strings.
The ifMUD conversation went like this:
| ____ says, "Hmm, is there a bug in this code (from
| Cloak of Darkness:
| The description of the hook is "It's just a small brass
| hook, [if something is on the hook]with [a list of things
| on the hook] hanging on it[otherwise]screwed to the
| wall[end if].""
| ____ says, "I was wondering if it would print "It's just
| a small brass hook, .""
| ++++ says, "it should either print ", with blah blah on
| it." OR ", screwed to the wall.""
| ____ says, "Oops, never mind."
It takes a lot of concentration on my part to make sure
I'm following which bits get printed in which conditions,
and where the conditions start and end, because, in a way,
all words sitting inside square brackets look like words
sitting inside square brackets. It's not enough of a
beginning and an end for my brain to pick up on at a
glance. At a casual read, I read erroneously. It sticks
out, since by and large I7 code is easy reading.
I can imagine it being logical to write when I am in the
act of writing a game. I may have trouble re-reading my
own writing later, finding myself thinking, "Wait, when
am I telling it to print which part?"
I don't know how addressable an issue it is, but it's the
main one I'm seeing so far.
--
J. Robinson Wheeler Games: http://raddial.com/if/
JRW Digital Media Movie: http://thekroneexperiment.com/dvd/
John W. Kennedy
> Perhaps I was just being a controversialist when speaking up for poor
> little COBOL.
Oh, I don't care for the easy, rather juvenile contempt of the hacker
mentality toward COBOL, myself. But I've been programming since 1965,
mostly on IBM mainframes that were mostly employed in accountancy, and
the language has always had real problems.
> It seems to me, though, that it did have one genuine
> strength: when looking at typical COBOL code written by a long-dead
> programmer, it's fairly easy to tell what he was trying to do.
...not always. As I say, the PERFORM THRU construction (which,
effectively speaking, inserts and deletes invisible GOTO's at run time)
can result it taking /days/ just to figure out a program's control flow,
the arithmetical semantics of the COMPUTE statement (roughly
corresponding to the assignment statement) were left for individual
compiler writers to determine (Cobol 2002 has finally defined a
standard, but adherence is optional), and the semantics of identical IF
statements has historically varied from one ISO version to the next.
(Every 10 years or so, IBM has been forced to create a new
COBOL-to-COBOL translator, and even with such aids, the shop I was at,
despite all my efforts, continued to make massive use of a
thirty-years-old, ten-years-obsolete compiler because upgrading was just
too difficult.)
Disciplined programmers who have been warned that certain COBOL features
should be avoided at all costs can produce long-term readable code, but,
in my decades of experience as debugger-of-last-resort, the language
invites abuse, although it is now much improved.
> This is
> a plus in industries where code is kept in use for decades (e.g. the
> financial services sector); perhaps it is also a good idea in a
> long-term cultural product?
I am considerably more sanguine about the future of "Natural Inform"
than about the past of COBOL.
Adam Thornton
John W. Kennedy <jwk...@attglobal.net> wrote:
>Graham Nelson wrote:
>> Perhaps I was just being a controversialist when speaking up for poor
>> little COBOL.
>
>Oh, I don't care for the easy, rather juvenile contempt of the hacker
>mentality toward COBOL, myself. But I've been programming since 1965,
>mostly on IBM mainframes that were mostly employed in accountancy, and
>the language has always had real problems.
>
>> It seems to me, though, that it did have one genuine
>> strength: when looking at typical COBOL code written by a long-dead
>> programmer, it's fairly easy to tell what he was trying to do.
>
>...not always. As I say, the PERFORM THRU construction (which,
>effectively speaking, inserts and deletes invisible GOTO's at run time)
>can result it taking /days/ just to figure out a program's control flow,
This is all true.
I just escaped from a nightmare of trying to update someone else's COBOL
system to do a bunch of its actual work on Linux. Now, I was--I hasten
to add--only responsible for the Linux side of the implementation, but
since *that* was done in a few days, I got drafted into the COBOL as
well.
It was quite tentacular, largely due to PERFORM--not even PERFORM
THRU--although this particular piece did indeed tend to be pretty
well-structuerd.
Nevertheless, COBOL and INFORM 7 share the following characteristics:
GOOD: The person who didn't write the code is indeed usually able to
tell, at a high level, what it's supposed to do (assuming that it's
reasonably-well-structured) just by reading it, and so probably is his
nontechnical manager. This is indeed one of COBOL's primary design
goals, and both a worthy one (modulo the question of whether it's
appropriate for your nontechnical manager to be looking at your code at
all) and one that it achieved pretty admirably.
BAD: The language wants you to believe it's English, but it really
isn't. Thus the thing that SEEMS like the obvious construction doesn't
work, and you end up resorting to stilted constructions to get your
point across to the compiler (yes, yes, also see AppleScript and its
late but--at least by me--lamented progenitor HyperCard).
Adam
John W. Kennedy
> BAD: The language wants you to believe it's English, but it really
> isn't. Thus the thing that SEEMS like the obvious construction doesn't
> work, and you end up resorting to stilted constructions to get your
> point across to the compiler (yes, yes, also see AppleScript and its
> late but--at least by me--lamented progenitor HyperCard).
So far, I have not found anything in I7's English even remotely as
tortured as, say, the COBOL INSPECT statement. We are, of course, still
a long, long way from HAL 9000.
I think one point that is being missed here is that Emily Short, well
established as an I6 master, and who has actually /used/ I7, has already
testified that I7 moves projects from the "infeasible" to the "feasible"
column. I've already found points where I7 seems easier to manage, and,
although I have never made a public release of any large I6 project, I
have 40 years of experience programming in several dozen languages,
ranging from mainframe assembler to RPG to Ruby to Java, including
considerable experience with COBOL, and I'm not seeing I7 as COBOL-like
at all, except in one essentially cosmetic area where the resemblance is
not all that strong.
kin...@nbnet.nb.ca
minutes:
- - -
"Test Project" by Sean Givan
The story genre is "'My Apartment' Games". The release number is 11.
The story headline is "The author's apartment".
Part 1 - Opening Technicalities
Use no scoring.
After going somewhere, try looking.
Part 2 - The Adventure World
When play begins, say "Hello World!"
Chapter 1 - Your Apartment And Surroundings
The player is in Your Apartment.
...
Your Apartment is a room. "This is your own apartment, where you've
lived for several years now. It's worn but comfortable, crowded but
warm, badly lit but a good place for sleeping. To the [bold
type]north[roman type] is the kitchen."
A faded red couch is in Your Apartment. "Your couch, faded and red,
sits by the side of the wall, as always."
The couch is fixed in place. Instead of taking the couch, say "The
couch is way too heavy to move. You like it where it is, anyway."
The description of the faded red couch is "You bought it two years ago
at a flea market. It was cheap but surprisingly effective at resting
your seat."
A fuzzy checkered blanket is on the faded red couch. The description
is "It's checkered red and blue, and fuzzy. It covers the bad patches
on the couch." The printed name is "blanket".
Instead of smelling the blanket, say "The blanket smells fuzzy and
slightly dusty."
A pair of pants is in Your Apartment. It is wearable. The description
is "A brown pair of slacks."
...
North of Your Apartment is Your Kitchen.
Your Kitchen is a room.
The description of Your Kitchen is "This old kitchen is in bad shape.
You think it's clean - you do wash it now and again, after all - but
the age of the linoleum and counters make it difficult to tell; it
always seems a little bit dirty."
A dirty kitchen fixture is a kind of thing. The description is "Dirty
and slightly peeling."
A dirty kitchen fixture is scenery.
Instead of taking a dirty kitchen fixture, say "They are immobile. And
dirty. So you don't want them for two different reasons."
The counters are in Your Kitchen. They are dirty kitchen fixtures.
The floor is in Your Kitchen. It is a dirty kitchen fixture.
...
Instead of listening, if the player is in Your Kitchen, play a random
outdoor sound, for sure.
...
Every turn, if the player is in Your Kitchen and the player's command
does not include "listen", play a random outdoor sound, maybe.
...
To play a random outdoor sound, maybe or for sure:
if maybe, let s be a random number from 1 to 5;
if for sure, let s be a random number from 1 to 3;
if s is 1, say "You hear the faint horns of a car driving by
outside.";
if s is 2, say "Outside, you hear birds twittering.";
if s is 3, say "You hear the breeze blowing through tree branches
outside.".
...
- - - - -
Comments:
* Those three dot symbols I put in on a hunch; I don't know if it's
documented, but you can put in content dividers like those when you
feel like it.
* The couch isn't explicitly defined as a supporter, but in the game it
is; probably because I put a blanket on top of it. I like that!
* I love what dirty kitchen fixtures can do for me :)
* And I also like that I can say 'They are dirty kitchen fixtures'
without getting any complaints.
-Sean Givan
Kevin Forchione
news:1146527334.3...@g10g2000cwb.googlegroups.com...
> I don't know how addressable an issue it is, but it's the
> main one I'm seeing so far.
It's an interesting issue, especially since elsewhere the [] delineate
comments. Obviously you'll have to think of the [] in these circumstances as
behaving much like the <<>> syntax in TADS. The difference, of course, is
that in TADS that kind of determination would be made using expressions,
method calls or other easily identifiable programming constructs, while in
I7 the brackets serve to indicate where the code is to be parsed as a
construct and where it is to be printed as a string.
--Kevin
Kevin Forchione
news:e35tnv$m0t$1...@fileserver.fsf.net...
> In article
> Ah-HA!
>
> Actually, when I have time, I'm planning on writing a little something
> about my experience with I7, but one of the bits is going to be that it
> has a lot of very interesting features, and a lot of features that
> remind me of COBOL, and that these two sets are not entirely disjoint.
>
> I expect that last clause to be a major bone of contention on this
> newsgroup.
Why be ashamed of your predilections, eh?
--Kevin
Kevin Forchione
news:qAv5g.47$N11...@fe08.lga...
Hmmm. Interestingly, the companies I've worked for didn't seem to be
effected by any of those issues:
*None of them used defaults, the picture clause was always explicitly
coded.
* ERFORM THRU companies are still using this without blinking an eye,
although it's not a requirement
* Portablility and upgrading were simply regression tested.
* The use of NOT was generally avoided, for readibility's sake.
* Slow reaction to technological changes - so are most businesses that
actually employ it.
* RESERVE... never seen it implemented, never needed.
* IF -- well, 1959, that was the year BONANZA aired on t.v., not a
stellar year for anyone's brainwaves.
And despite 20 years of talk and the best efforts of academia to squelch it,
it's still running your bank account app and processing your life insurance.
--Kevin
Adam Thornton
>at all, except in one essentially cosmetic area where the resemblance is
>not all that strong.
I don't think it's "essentially cosmetic," and that's where we differ.
I think both COBOL and Inform attempt to be readable to nontechnical
readers, that both succeed to a large extent, but--crucially--it's
actually a convenience for the reader, not for the author. The author
in either language still needs to learn a quite restrictive syntax.
I find myself writing flow control in very verbose Inform 6, basically,
when I write stuff in I7. Now much of this may be my problem, in that I
think like a programmer, and that I'm fighting the language to do
something it actually supports in much more natural syntax. Time will
tell.
Adam
P.S. Also, I too put in a plea for an "otherwise if" construction to
avoid grossly overnested conditions.
mathew
> I have tried to use Eclipse, and it defeated me.
Same here... until last week. They have clearly done major work on it
since the last version I tried. It's now actually usable.
That said, it still failed to import and build the working Ant project I
tried. But if you start your project in Eclipse, it's usable. Useful, even.
I guess you could set up the project structure and then import existing
files one by one. That also seems to work.
mathew
--
<URL:http://www.pobox.com/~meta/>
My parents went to the lost kingdom of Hyrule
and all I got was this lousy triforce.
mathew
> When I first became a Mac
> convert about a year ago, I was very excited by Applescript and and
> tried to do some things with it, but quickly hit a dead end when I
> couldn't get the syntax of scripting language correct. It reads great,
> but you really have to understand a lot to get it to do anything that's
> not completely trivial, and the end result is that's it's still
> programming, but with more typing.
That's my experience too. I've repeatedly tried and failed to get to
grips with AppleScript. In general, I can't stand syntaxy languages, and
I need consistency and lack of stuff to remember more than I need pretty.
When I saw the Inform 7 announcement on the web just now and read the
description, I have to say my first reaction was that I7 is a work of
genius. I'd been thinking that someone needed to revive the alleged
Level 9 approach to world-building, defining general properties and
relationships and then applying them to objects, rather than focusing on
the objects.
However, given my experiences with AppleScript I'm not sure Inform 7 is
something I'll be able to enjoy. But who knows, maybe it'll encourage me
to get out one of my game ideas from the notebook and turn it into an
actual game...
James Cunningham
> Andrew Plotkin wrote:
>> I have tried to use Eclipse, and it defeated me.
>
> Same here... until last week. They have clearly done major work on it
> since the last version I tried. It's now actually usable.
>
> That said, it still failed to import and build the working Ant project
> I tried. But if you start your project in Eclipse, it's usable. Useful,
> even.
>
> I guess you could set up the project structure and then import existing
> files one by one. That also seems to work.
>
>
> mathew
I've had a bit of trouble with Ant and Eclipse: It seems to want me to
hardcode paths, which is annoying, but when I bowed to its pressures I
was able to import my (small, amateurish) projects without too much
trouble. After the love affair and razzle-dazzle effect wore off,
though, I found myself much more comfortable with a text editor.
(I use TextMate now, but jEdit can be made into a very nice little Java
IDE with some work, with code completion, smart importing, refactoring,
Ant integration, and all sorts of good stuff, all while staying faster
and less cluttered than Eclipse. But only if you're using 1.4.)
Best,
James
Janus
Gene Wirchenko
>MacWorld credits I7 for IF "making a slow but steady comeback".
>
>http://www.macworld.com/news/2006/05/04/inform/index.php
Rather premature to give the credit to I7, isn't it? I think
there are a lot of factors involved.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Richard Bos
> "Lorenzo Marcantonio" <loma...@tin.it> wrote in message
> news:1146433563.0...@y43g2000cwc.googlegroups.com...
> > Personally there are a lot of things I dislike and a lot I like:
> <snip>
> > I fear inform is going toward COBOL bloating...
>
> So? Run it on a mainframe.
Well, yes, that part of the problem I have with some recent IF
developments. There was a time when I could run a ZCode game on my Revo
or on a very ancient Win98 (or even MS-DOS!) machine, and even the
compiler. This was a large part of the appeal of the ZMachine to me. No
more.
Richard
Richard Bos
> MacWorld credits I7 for IF "making a slow but steady comeback".
>
> http://www.macworld.com/news/2006/05/04/inform/index.php
What, already? Boy, they're quick!
Richard
Adam Thornton
Richard Bos <rl...@xs4all.nl> wrote:
>"Kevin Forchione" <ke...@lysseus.com> wrote:
>> So? Run it on a mainframe.
>Well, yes, that part of the problem I have with some recent IF
>developments. There was a time when I could run a ZCode game on my Revo
>or on a very ancient Win98 (or even MS-DOS!) machine, and even the
>compiler. This was a large part of the appeal of the ZMachine to me. No
>more.
Do not MAKE me use the RECENT GCCMVS port to PORT a ZCODE terp to MVS
3.8 which is FREELY AVAILABLE and which runs under Hercules, also FREELY
AVAILABLE.
Adam