Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Visual Inform

9 views
Skip to first unread message

Giovanni Riccardi

unread,
Feb 3, 1997, 3:00:00 AM2/3/97
to

Reading messages to the newsgroup I've noticed discussions about an editor for
Inform. Even if I didn't read last 20 days messages until today, last week I've
started to work on something like "Visual Inform". I'm programming this in
Visual Basic for Win95/NT platforms. It won't be simply an editor, but a
complete development enviroment.
It includes a "project window" where you may specify relations between objects
(it is something like the directory window in Win95 Explorer) and an "object
window" where you "write" code for the object selected in the project window.
You may specify what attributes an object 'has' by selecting them from a list
(this contains both library and declared attributes) and write code for
properties that the object 'provides'.
I'm trying to simplify as much as possible designers' work. For example,
suppose that you have a bottle with some water inside it:

Object Water_In_Bottle
with name "water",
description "Water, H2O...",
after
[; Drink: "It's extremely cold.";],
has edible


In "Visual Inform" you
1. Create a new object,
2. Check edible in the attribute list
3. Select name in the property list and add all the names you want
4. Select Description in the property list and write the text
5. Select After, then select drink and write the code for drink

Probably Visual Inform will include some extra tools like a menu editor and a
library of the most used (and useful) routines in text adventures (For this I
ask your help: "Send me all the code you have and want to include in Visual
Inform").

Send me comments and suggestion..

-------------------------------
Giovanni Riccardi
g.ric...@speednet.it
Terracina ITALY
-------------------------------


Robert Fisher

unread,
Feb 4, 1997, 3:00:00 AM2/4/97
to

Giovanni Riccardi wrote:

> Object Water_In_Bottle
> with name "water",
> description "Water, H2O...",
> after
> [; Drink: "It's extremely cold.";],
> has edible
>
> In "Visual Inform" you
> 1. Create a new object,
> 2. Check edible in the attribute list
> 3. Select name in the property list and add all the names you want
> 4. Select Description in the property list and write the text
> 5. Select After, then select drink and write the code for drink

I don't wish to discourage Giovanni, but I can't really see the point of a front-end
like this. My own game is, I think, fairly rich in text, and the objects often are
quite precisely described and have many synonyms. Given the amount of keystrokes
involved in putting in a lengthy description, it seems to me to be less trouble to
type "Object" whilst I'm at the keyboard than to mess about with clicking things with
the mouse, moving back to the keyboard, clicking again etc. For basic operations like
creating objects one soon learns all the necessary commands, and they're all short and
easy to use. For more complicated code, for example daemons, special parsing rules and
general routines which are not embeddedd in objects, I'm not even sure how the system
would work.

I've never used Visual BASIC, (I'm an Amiga user) so I don't really understand the
concept of such a development environment, but it does seem to me that people are
falling over themselves to have a showy point and click interface for no reason other
than that they can. Inform is a well desgined, easy to use language with all its
functions easily accessible. All this would do is slow things down, I think. (It may
help complete beginners though, which is good.)

I hope I haven't sounded to harsh; this is not a flame, and not directed at Giovanni
Riccardi, it's just my opinion on what seems to have been a popular thread lately.

Rob

John Wood

unread,
Feb 4, 1997, 3:00:00 AM2/4/97
to

Giovanni Riccardi <g.ric...@speednet.it> writes:
>Reading messages to the newsgroup I've noticed discussions about an
>editor for Inform. Even if I didn't read last 20 days messages until
>today, last week I've started to work on something like "Visual
>Inform". I'm programming this in Visual Basic for Win95/NT platforms.
>It won't be simply an editor, but a complete development enviroment.
[snip]

>Send me comments and suggestion..

Hi - thanks for trying to do this!
Curiously enough, I was just composing a message that I was going to
post as "Visual IF", discussing this very issue. I haven't got a lot of
time, so rather than rewriting it as an answer to your request I'll just
post what I've done so far - be warned it's incomplete. Happily, much
of it seems to be along the same lines as your thoughts.

Here it is:

-8<---------------------------------------------------------------------

Recently there was a discussion of what was wanted in a visual editor
for IF authors, beyond simple map editing. There seemed to be a variety
of ideas, many of which required changes to the compiler (such as
incremental compilation), but very little about the actual "visual
editing" itself. I was too busy to get involved at the time, but here
are some of my ideas on the subject. I'm going to use Inform as my
example language (because it's the only modern IF language I know), but
I hope that most of the ideas are more generally applicable.

Note: I see a visual editor as a programming aid, not a means for non-
programmers to create IF.

0) Givens
------
The first requirement is decent text editing, preferably including
syntax highlighting. You should also be able to launch the compiler
and interpreter from the editor. If you can't do this much, you're
in trouble...

1) Browser
-------
This is *the* most useful thing for developing code IMO. Being able
to jump to the definition of an object/class/routine/verb (or run
through all references to it) saves hours of time - only a few
seconds each jump, but it rapidly adds up. A window with a
(filterable) list of objects/etc is also very useful. Filters should
allow for skipping library objects, listing only objects with animate
and female, listing all objects of a certain class, etc.

A tree-list is useful for many of these things.

2) Form-style Editing
------------------
Certain things are ideally suited to filling in via forms. An object
form, for example, could have a text box for program name, check
boxes for attributes, text list for (game) name, drop-down list for
location, and a list of other properties with an associated box for
entering details.

Similarly, verbs could be presented with a text list for name, then a
two-column list of grammar lines (format on the left, sub on the
right). Lines could be rearranged as required, and the editor could
sort out whether to replace the library version or merely extend it.

Note this would be an alternative to direct editing of the source
files, not a replacement.

3) Box-and-Line Diagrams
---------------------
Obviously, maps come into this category, but you can also have class
diagrams, object trees, and plot graphs.

4) Planner
-------
Why just help with editing code, if you can integrate some of the
analysis and design work too? Plot graphs and maps can be useful, as
can transcripts and random notes. These last don't need much extra
support, but can perhaps be integrated smoothly.

5) Project Management
------------------
This is more "excise" that keeps the author away from writing the
game. It should be made as painless as possible. [TBD]
If adaptive hints become standard, they should be managed too.

6) Online Help
-----------
Context-sensitive online help for the language - an HTMLified version
of the Designer's Manual.

As you can see, most of these features are concerned with keeping track
of where things are. There's not much to help with the actual coding
(which is why I say it's a programmer's aid, rather than a replacement
for programming ability), but it could help tame many of the "overhead"
tasks.

There are other things I'd like to see (such as incremental compilation,
debugging aids, etc) but mostly they've already been mentioned by other
people.

OK - now I've listed these ideas, one of you can go and program it. ;-)

-8<---------------------------------------------------------------------

Heh, I didn't expect anyone to answer my final challenge - particularly
before I posted the message! ;-)

Some more comments and questions:


>It includes a "project window" where you may specify relations between
>objects (it is something like the directory window in Win95 Explorer)
>and an "object window" where you "write" code for the object selected
>in the project window. You may specify what attributes an object 'has'
>by selecting them from a list (this contains both library and declared
>attributes) and write code for properties that the object 'provides'.

This is good. [Although I snipped it, I like your handling of Before /
After / Life style properties, BTW; it's not something I'd thought of.]

1) What do you intend doing about aliased attributes? You could have
them separately in the checklist, "locking" their states together,
but it would probably be best to indicate that they are aliased
somehow (so the user doesn't have any "surprises").

2) See how it goes, but consider some of my suggestions - in particular,
the browsing for definitions/references. You've sort of got that for
object definitions, but a right-mouse menu option for "go to
definition" / "go to [next/previous] reference" when the cursor's on
the name of a object/class/routine would be wonderful. And a lot of
work to implement, of course. ;-)

Some of the other suggestions (plot graphs, maps, etc) are relatively
unimportant. Don't try and implement all of them, or you probably
won't get anywhere. OTOH, try to design with future expansion of
features in mind where possible.

3) Make sure that the user can't absent-mindedly edit library files.
The dreaded "Are you sure?" would do it, so long as it is reserved
for this sort of thing and doesn't pop up willy-nilly.

4) Whatever you do, keep the usual source file(s). It doesn't matter if
you add a "project" file, but I'd want the ability to mess about with
the code directly for when I don't have access to NT/95 (for example,
when I'm at home ;-).

5) How are you thinking of releasing this? Shareware? Freeware?

6) Have you read _About Face_, by Alan Cooper? he's got a lot of good
and/or interesting ideas about user interface design, though he does
introduce a lot of jargon. If you can get it from the library, it's
worth reading before you get too far into the coding. [This led me
pretty directly to point 3, above.] If you need the info, it's by
IDG Books Worldwide, Inc., ISBN 1-56884-322-4.

I would offer to help, but I know I'm not going to have the time - and I
don't speak VB anyway. I'll happily deliver (constructive) criticism on
what you do, though. ;-)

Cheers,

John

Zaphod1342

unread,
Feb 4, 1997, 3:00:00 AM2/4/97
to

Actually, I recently started work on the same type of thing. However, if
GIovanni's going to do this, I don't think I'll bother. I'm not very
experienced at writing dev. environments...

Carl Muckenhoupt

unread,
Feb 5, 1997, 3:00:00 AM2/5/97
to

Robert Fisher <COP9...@shef.ac.uk> writes:

>I've never used Visual BASIC, (I'm an Amiga user) so I don't really understand the
>concept of such a development environment, but it does seem to me that people are
>falling over themselves to have a showy point and click interface for no reason other
>than that they can. Inform is a well desgined, easy to use language with all its
>functions easily accessible. All this would do is slow things down, I think. (It may
>help complete beginners though, which is good.)

Well, the concept of Visual Basic is primarily that it's used for creating GUI
applications. Using your mouse to place a button exactly where you want it in
a window is a lot easier than figuring out the coordinates you want it at and
typing them in. This is obviously useless for Inform.

However, I do see some merit to what has been proposed, ie, a code
generator for Inform that uses a GUI. Certainly it would be an aid to the
beginner. And if it had a visual map generator, with rooms that you could
drag and drop items into, it would be a positive boon during the design
phase.

--
Carl Muckenhoupt | Text Adventures are not dead!
b...@tiac.net | Read rec.[arts|games].int-fiction to see
http://www.tiac.net/users/baf | what you're missing!

Stephen van Egmond

unread,
Feb 6, 1997, 3:00:00 AM2/6/97
to

Robert Fisher <COP9...@shef.ac.uk> wrote:

>I've never used Visual BASIC, (I'm an Amiga user) so I don't really
>understand the concept of such a development environment, but it does seem

>to me that people are falling over themselves to have a showy point and.


>click interface for no reason other than that they can. Inform is a well
>desgined, easy to use language with all its functions easily accessible.
>All this would do is slow things down, I think. (It may help complete
>beginners though, which is good.)

That is entirely the point. Through the years (check the archives at
www.truespectra.com/~svanegmo/raif), people who have been good at writing
have commented that they love the medium, but just can't figure out the
programming end of it.

Even I get confused, and I'm at the premier CS undergraduate school in
Canada. Which of these is it?

with edible;
has edible;
with edible,
has edible,

To the writer, whether it's 'has' or 'with' or if they are separated with
a , or a ; doesn't matter. I realize there's good language- and
compiler-design reasons for it.

A visual checkbox is far more effective. That you're an Amiga user
immediately betrays why you feel this is useless: you're used to hacking
with ARexx and the CLI. You're right, sitting in a text editor typing
away probably is faster, but think of the unlucky non-technical user
enumerating the above 4 possibilities.

The trick for Giovanni (?) is to design an interface that non-technical
users. Giovanni - I suggest you find some of the people who are likely
to use your program and involve them early in your design process. You
might get some excellent ideas!

Good luck!

/Steve


Twist

unread,
Feb 7, 1997, 3:00:00 AM2/7/97
to

In article <32F737...@shef.ac.uk>,

Robert Fisher <COP9...@shef.ac.uk> wrote:
>
>I don't wish to discourage Giovanni, but I can't really see the point of a front-end
>like this. My own game is, I think, fairly rich in text, and the objects often are
>quite precisely described and have many synonyms. Given the amount of keystrokes

I can. Perhaps not the specific presentation that Giovanni had in mind,
but in reading through the Inform and TADS manuals, I think we are sorely
lacking a truly object-centered design language (with a visual
representation). Text adventures are inherently object oriented. To me,
creating one on a modern machine with a GUI should go like this:

1) Fire up GUInform 19/22
2) Select "File/New"
3) From the object palette to the right, select and drag a room icon onto
the display. A dialog appears asking you if this is a single part or multi
part room, it's default description, state variables that can affect that
description, and other relationship operators for it.
4) Drag a game object from the palette and drop it. Dialog box appears,
you name it "lantern", create relationship operators, establish a unique
characteristic flag (potential light), bring up an enumerated list of
objects it can be contained in, etc etc.

There's no reason such a system couldn't be built over top of a full
featured library system such as Inform or TADS. It's just a lot of work,
initially. But it would make IF much more of an authoring job and much
less of a programming one, which is how it should be IMHO. Programmers
could always look at the resultant source code and modify it, or add their
own modules, whatever.

It's interesting that I am put in the position of defending a much more
abstracted object level; as I am generally considered to have a grudge
against C++ by my fellow programmers (I work at a game company, and C++ is
widely misused here because it is the Next Shiny Thing, when in fact for
MOST of what we do C is more efficient and appropriate).

Anyway, having a visual object system to build the base of a work of
interactive fiction would drastically reduce the barrier to entry a
potential author sees. We'd see a lot more literature from the computer
illiterate :-).

-Rich

Andrew Plotkin

unread,
Feb 7, 1997, 3:00:00 AM2/7/97
to

Twist (Tw...@cris.com) wrote:
> I can. Perhaps not the specific presentation that Giovanni had in mind,
> but in reading through the Inform and TADS manuals, I think we are sorely
> lacking a truly object-centered design language (with a visual
> representation). Text adventures are inherently object oriented. To me,
> creating one on a modern machine with a GUI should go like this:
> [...]

> There's no reason such a system couldn't be built over top of a full
> featured library system such as Inform or TADS. It's just a lot of work,
> initially. But it would make IF much more of an authoring job and much
> less of a programming one, which is how it should be IMHO. Programmers
> could always look at the resultant source code and modify it, or add their
> own modules, whatever.

I think it would be worthwhile to scrodge through dejanews and read the
great quantity of discussion on this subject we've had over the years.

I have argued extensively that 1) for non-programmers, this system would
not really be any easier to learn; and 2) for programmers, this system
would not really make game-creation any easier.

But I don't feel like repeating myself. The short form is, "This idea
makes 5% of the job easier, which is not useful."

Of course, don't let me argue you out of proving me wrong. :)

--Z

--

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

David

unread,
Feb 8, 1997, 3:00:00 AM2/8/97
to

On Fri, 7 Feb 1997 21:05:52 GMT, erky...@netcom.com (Andrew Plotkin)
wrote:

Surely one of the strengths of Inform is that it is so easily ported
to other computers - everything from a PC to a Amiga, Atari,
Archimedes etc. All you need on these machines is decent text editor.
My guess that GUIInform would be PC based...what would happen to the
other machines. Remember, Inform started out on a Archimedes machine,
so don't forget the minority machines.

John Wood

unread,
Feb 8, 1997, 3:00:00 AM2/8/97
to

erky...@netcom.com (Andrew Plotkin) writes:

> Twist (Tw...@cris.com) wrote:
> [...]
> > There's no reason such a system couldn't be built over top of a full
> > featured library system such as Inform or TADS. It's just a lot of work,
> > initially. But it would make IF much more of an authoring job and much
> > less of a programming one, which is how it should be IMHO. Programmers
> > could always look at the resultant source code and modify it, or add their
> > own modules, whatever.
>
> I think it would be worthwhile to scrodge through dejanews and read the
> great quantity of discussion on this subject we've had over the years.
>
> I have argued extensively that 1) for non-programmers, this system would
> not really be any easier to learn; and 2) for programmers, this system
> would not really make game-creation any easier.
>
> But I don't feel like repeating myself. The short form is, "This idea
> makes 5% of the job easier, which is not useful."
>
> Of course, don't let me argue you out of proving me wrong. :)

Well, in some ways I agree and disagree with both of you. ;-)

I agree with Andrew that the particular method outlined doesn't help
very much (at least on its own). I also agree that this sort of thing
would not open up the field to non-programmers.

*However*, I agree with Rich that there are opportunities for visual
aids to make IF authorship easier - it's just that these are only likely
to help programmers write IF.

I posted some of my ideas in a reply to the original Visual Inform
thread. I do wonder if Andrew's definition of "visual programming" is
narrower than mine? To take things to an extreme, syntax highlighting
is a visual aid, although I must admit even I don't *really* think of
this when talking about this subject.

To flesh out one example: it would be nice to have a list of verbs.
Click on a verb to see the grammar lines (opening as a tree control, not
in a separate window). Use various mouse commands or keys to rearrange
lines or enter new ones (I probably wouldn't use the editor without
keyboard shortcuts, BTW). Click on the verbsub to go to the source for
that routine, or use other commands to browse through all 'before'
routines handling the verb. Call up a list of objects, select one and
add an 'after' handler for the verb, editing the code. And so on.

I've deliberately picked this example to be very different from the
descriptions usually given of visual systems - often map-based. I think
there *is* a place for mapping tools (no matter how limited in
application) and form-based object entry, but this should be accompanied
by the sort of support I am describing above. Most of what I describe
in the example (viewing and editing grammar lines and the verbsub) would
happen very rarely, but I would make frequent use the browsing aspects.
And if you can make 50 things that happen rarely twice as easy, you've
still significantly improved the programmer's lot.

If I can turn to an example from outside IF: consider a CASE tool with
code generator. [For those who don't know (and do care), CASE tools are
intended to help with the analysis and design of software systems. Some
generate a "shell" of code (in C++, or whatever) with class definitions,
empty routines, etc.] Does a CASE tool help you write lines of code?
Hardly. Does it ease your job as a software author? You bet!

A lot of what we do as programmers is what Alan Cooper calls "excise" -
scrolling or searching through files to find a particular definition, or
typing "Object ... with name ... description ...", for example. If you
can reduce the above to a few keystrokes, that's more time to work on
the *real* code.

Well, I've waffled on enough. Hopefully there's some food for thought
in there.

John

Bill Hoggett

unread,
Feb 8, 1997, 3:00:00 AM2/8/97
to

On 08-Feb-96 David wrote:

>Surely one of the strengths of Inform is that it is so easily ported
>to other computers - everything from a PC to a Amiga, Atari,
>Archimedes etc. All you need on these machines is decent text editor.
>My guess that GUIInform would be PC based...what would happen to the
>other machines. Remember, Inform started out on a Archimedes machine,
>so don't forget the minority machines.

No one will be able to do a portable GUI for all these machines, but
I don't see why that should stop the development of individual GUIs
for each platform, purely as an optional add-on. Anything that helps
reduce the tedium involved in coding the games has to be a good thing,
as long as everyone realises that you will still have to fire up your
trusty text editor to add the polish to the structure you've created
through the GUI.

---
Bill Hoggett (aka BeeJay) <mas.su...@easynet.co.uk>

IF GOD IS LIFE'S SERVICE PROVIDER WHY HAVEN'T I GOT HIS I.P. NUMBER ?


Dirk Coppelmans

unread,
Feb 9, 1997, 3:00:00 AM2/9/97
to

Robert Fisher <COP9...@shef.ac.uk> wrote:

>I've never used Visual BASIC, (I'm an Amiga user) so I don't really understand the
>concept of such a development environment, but it does seem to me that people are

>falling over themselves to have a showy point and click interface for no reason other

>than that they can. Inform is a well desgined, easy to use language with all its
>functions easily accessible. All this would do is slow things down, I think. (It may
>help complete beginners though, which is good.)

>I hope I haven't sounded to harsh; this is not a flame, and not directed at Giovanni

>Riccardi, it's just my opinion on what seems to have been a popular thread lately.

>Rob


There are a number of very interesting reasons why a visual tool
for IF development can be useful. Look at the commerically
available products on the market today. They are not just a
frontend to a programming language. They add specific tools that
provide the programmer with powerfull means that support him/her
in performing his/her complicated task.

Why should this be different for a visual tool for IF development?
I'd like to summarize a number of examples:

- The model
The user interface of a visual tool determines how users look
at the IF implementation problem. A visual tool enables you to
provide a design and implementation model that differs from the
actual language (and library) that you support.

- Combine design and implementation
A visual tool can cover more than just the language it supports.
It can include (part of) the IF design traject too and integrate
the two.

- True object orientation
In the example of 'Visual Inform', true object orientation can
be implemented. This is not (entirely) supported by Inform, but
can be implemented in a visual tool for the sake of development.
For instance inheritance and overloading are powerfull means to
create a lot of different objects that are all based on the same
base. You are able to create a more detailed and dynamic game
world with just minor effort. And if there is a bug in one of
the base objects, solve it, and all dependent objects are cured
as well.

- Class and object trees
Once OO is implemented, one can make a class and object tree
overview. You can even think of overviews by selection: all
objects that have certain attributes and/or properties or
objects that are affected by certain actions.

- Location Map
The ever required visual view of the game world: all locations,
their hierarchy (a room in a hous, a house in a street, a street
in a city, etc) and their interconnections. The map might show
the contents of the locations and provide access to this contents.

- Framework
There are a lot of specific design and implementation issues
discussed in the past that are suitable to be integrated in this
visual tool. Frameworks (a library of classes) can provide
ready-to-use (or adapt) implementations of common design challenges
(NPC's, moving vehicles, etc.). Look at the newsgroup frequently
to obtain a general idea on the contents of such framework.

Like any other software development process, IF design and
implementation is complicated. Any developer can be assisted by means
of methods and techniques. Tools that implement these methods and
techniques can help make life easier. The tools of today go much
further: they add functionality in order to give all applications
the same look & feel or provide not only a frontend to the programming
language in question, but to additional libraries as well.

These developments might be an example of what visual tools could mean
for the IF community.

Dirk Coppelmans - di...@iaehv.nl


Magnus Olsson

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to

In article <978.6978T...@easynet.co.uk>,

Bill Hoggett <mas.su...@easynet.co.uk> wrote:
>Anything that helps
>reduce the tedium involved in coding the games has to be a good thing,
>as long as everyone realises that you will still have to fire up your
>trusty text editor to add the polish to the structure you've created
>through the GUI.

And as long as everyone realizes that that "polish" will constitute
about 90% of the work, at least when the underlying language is one
like Inform or TADS.


--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)

Rich Lawrence

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to

On Fri, 7 Feb 1997 21:05:52 GMT, erky...@netcom.com (Andrew Plotkin)
wrote:

>Twist (Tw...@cris.com) wrote:
>
>I think it would be worthwhile to scrodge through dejanews and read the
>great quantity of discussion on this subject we've had over the years.

Oh I'm aware there are two sides, trust me. This will be my one
substantial post on the issue; if nobody sees any merit in my points
I'll assume it's a religious thing (right or wrong, I can assume what
I want :-) ) and ignore it henceforth.

>I have argued extensively that 1) for non-programmers, this system would
>not really be any easier to learn; and 2) for programmers, this system
>would not really make game-creation any easier.

I don't agree with either, actually. Not simply to be adversarial -
it's my opinion that most people don't trust visual object systems
because there are so few visual object systems on the market worth a
damn (to wit, VisC and Visual Basic, both of which are extremely un
"Visual").

Saying that visual/object systems are BOTH unbeneficial to non
programmers and programmers alike is basically saying that Stroustrup
was full of crap (and if you are saying that, hell I might agree with
you just on general principle) But even the most serious detractors of
C++ (me, for instance) and it's visual environments (me) can agree
that are circumstances where it and the point-and-drag environment
provides enormous benefit to both programmer and non programmer. And
the programmers can always ignore the situations where they feel
constrained and go back to the real language.

As a case in point, dialog box creation under Windows. This can be
done entirely in C, I did it that way for years. It can also be a
total pain in the ass. You'd have to be delusional to argue creating
basic dialog objects is better in simple C than in C++ under Visual C.
Whether Windows makes something difficult that shouldn't be is
immaterial (it does), the simple fact remains that it is demonstrably
easier to do the same task in a proper visual object environment,
regardless of the programmers experience.

Not to put too fine a point on it, but Inform (and yes, I think this
of TADS too) are very obtuse programming systems. This is not to
detract from the respective authors - I think they've done a fine job,
and I would never do it (too much work), but it is just FAR too
complicated to a neophyte, presumably non-programmer, to sit down at
either system and write even the most basic of works. Constructing two
connected rooms requires intimate knowledge of programming principles
we take for granted but my sister, a fine writer and intelligent
woman, would nevertheless find completely foreign.

Combine this with the questionable written literacy of many
programmers, and what you end up with a system that has insurmountable
entry barriers to all the wrong people. It's painfully obvious that
90% of IF is written from what boils down to a very basic set of
objects, and yet we still see people having to uniquely program them
(i.e., pockets, a recent discussion here - if that isn't a derived
container, I don't know what is).

>But I don't feel like repeating myself. The short form is, "This idea
>makes 5% of the job easier, which is not useful."

Even if that were so, work done once to improve 5% of many tasks is
well spent.

And no, I am not volunteering to do this. I'm under no illusions about
how complicated such a program would be, if done right. I'm also aware
that in twenty years of programming I've seen maybe a handful of
object oriented design systems I considered viable. Given that, I
wouldn't have the time, although I might pitch in if some other sucker
- er dedicated soul were to start the work.

-Rich

Bill Hoggett

unread,
Feb 11, 1997, 3:00:00 AM2/11/97
to

Alas, this is all too true. :)

Adam Dawes

unread,
Feb 12, 1997, 3:00:00 AM2/12/97
to

Hi David!

D> Surely one of the strengths of Inform is that it is so easily ported to
D> other computers - everything from a PC to a Amiga, Atari, Archimedes
D> etc. All you need on these machines is decent text editor. My guess that
D> GUIInform would be PC based...what would happen to the other machines.

The other machines would miss out. :(

If the author wrote GUInform well, it would use standard Inform source code for
its project files, and nothing else. So a game written with GUInform would
still be pure Inform source code, compilable on any platform with the Inform
compiler.

The GUI element would be all the is missing from the other platforms.

.\dam. [Team AMIGA] //\ Ad...@darkside.demon.co.uk \//
> Homepage at http://www.geocities.com/TimesSquare/1225/


Adam Dawes

unread,
Feb 12, 1997, 3:00:00 AM2/12/97
to

James Cole

unread,
Feb 14, 1997, 3:00:00 AM2/14/97
to

To those who don't like the idea, but have never used one: In an environment,
such as that proposed, the whole is greater than the sum of the parts. That
is, each of it's components considered seperately might seem only a bit of a
convenience or timesaver, but, used together over the course of a project,
have a much larger benefit.


---------------
James Cole
jrc...@ozemail.com.au

Rhodri James

unread,
Feb 18, 1997, 3:00:00 AM2/18/97
to

jrc...@ozemail.com.au (James Cole) wrote:

> To those who don't like the idea, but have never used one: In an
> environment, such as that proposed, the whole is greater than the sum of
> the parts.

Having used one, albeit only for a short time, I have to disagree with you.
The "visual" tools work best in dealing with visual objects, i.e. window
furniture, because being able to just click on an button to edit its
handler routines is very convenient. When you don't have that visual cue,
you are just hunting through a list of objects (however prettily
presented), and frankly I can do that faster with a text editor. Also I
don't like the mess these approaches invariably make of the actual (hidden)
source files, nor do I like the amount of information hiding that goes on.

Mind you, my opinions are somewhat coloured by the fact that I had to use
Visual BASIC, and I found the fragility of that allegedly professional tool
very depressing.

--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them

... Set phasors to debug!

Matthew Crosby

unread,
Feb 20, 1997, 3:00:00 AM2/20/97
to

In article <n5E2...@wildebst.demon.co.uk>,

Rhodri James <rho...@wildebst.demon.co.uk> wrote:
>jrc...@ozemail.com.au (James Cole) wrote:
>
>> To those who don't like the idea, but have never used one: In an
>> environment, such as that proposed, the whole is greater than the sum of
>> the parts.
>
>Having used one, albeit only for a short time, I have to disagree with you.
>The "visual" tools work best in dealing with visual objects, i.e. window
>furniture, because being able to just click on an button to edit its
>handler routines is very convenient. When you don't have that visual cue,
>you are just hunting through a list of objects (however prettily
>presented), and frankly I can do that faster with a text editor. Also I
>don't like the mess these approaches invariably make of the actual (hidden)
>source files, nor do I like the amount of information hiding that goes on.

I am still unclear about just exactly we are talking in this thread.

It sounds like you are talking about the likes of "Microsoft Visual foo",
none of which are visual tools. They are just IDEs. Unfortuantely,
Microsoft being Microsoft and the PC using masses being the sheep they are,
this has somewhat muddied the waters, but until Microsoft chose to
steal the term, visual had a specific meaning. If all you mean is
some sort of slick IDE, then go for it (though personally it will
be a cold day in hell before I use an IDE)

A "visual" tool is one such as LabVIEW where you can specify progam
graphically, or at least multi-dimensionally.
Inform being the language it is, it is still very textually based,
and it would imho be pretty hard to turn inform into a visual language.

It might be an interesting exercise to see if we could come up with some
sort of visual paradigm for IF, but this would be radically different
from todays text development languages

>Mind you, my opinions are somewhat coloured by the fact that I had to use
>Visual BASIC, and I found the fragility of that allegedly professional tool
>very depressing.

Last time I used VC++ was in one of the ACM programming contests. It
crashed in the middle. About what I expected from a Microsoft product,
of course, but I am still a little sore.

--
Matthew Crosby cro...@cs.colorado.edu
Disclaimer: It was in another country, and besides, the wench is dead.

Magnus Olsson

unread,
Feb 20, 1997, 3:00:00 AM2/20/97
to

In article <5ei802$4...@lace.colorado.edu>,

Matthew Crosby <cro...@nordsieck.cs.colorado.edu> wrote:
>I am still unclear about just exactly we are talking in this thread.
>
>It sounds like you are talking about the likes of "Microsoft Visual foo",
>none of which are visual tools. They are just IDEs.
(...)

>A "visual" tool is one such as LabVIEW where you can specify progam
>graphically, or at least multi-dimensionally.

Ahem. That's _visual programming_. I think it's justified to call
Visual Basic (or rather some aspects of it) a "visual tool", as long
as we keep in mind that it's not visual programming. IMHO VB is more
than "Just an IDE", because you have the visual interface to UI design
(constructing dialogs by dragging controls onto a window, and so
on). But the programming part is as non-visual as it can get.

0 new messages