TADS vs Inform: Which supports more Platforms?
Al
Does Inform support more platforms than TADS or
is it vice versa?
Wildman, the Cuberstalker
wrote:
>Okay boys and girls this is the 2nd time I've asked this:
>
>Does Inform support more platforms than TADS or
>is it vice versa?
>
Yes, Inform will run on everything but an abacus. This is because Inform
limits the size of the game - TADS allows bigger games.
So, if you want a big game, use TADS. If you want it to run on a fancy
calculator, use Inform.
--
Wildman, the Cuberstalker
Thank you, Microsoft, and please get out of the way.
Fight spam - http://www.cauce.org/
DO NOT SPAM THIS ADDRESS
HarryH
>Okay boys and girls this is the 2nd time I've asked this:
>
>Does Inform support more platforms than TADS or
>is it vice versa?
You should choose a platform that lets you shine the brightest, not gets you
spread the widest. :)
-------------------------------------------------------
IFC1.0 --C --A R++ -P++ -I++ --T+
Pete
>
> Yes, Inform will run on everything but an abacus. This is because Inform
> limits the size of the game - TADS allows bigger games.
> So, if you want a big game, use TADS. If you want it to run on a fancy
> calculator, use Inform.
>
> --
> Wildman, the Cuberstalker
> Thank you, Microsoft, and please get out of the way.
> Fight spam - http://www.cauce.org/
> DO NOT SPAM THIS ADDRESS
OUCH! Big Dis on Inform! More manners, Tadder! ;-)
Pete "can't we all just get along" Savage
David Glasser
> On Sun, 20 Dec 1998 13:16:17 -0700, Al <rad...@qadas.com>
> wrote:
> >Okay boys and girls this is the 2nd time I've asked this:
> >
> >Does Inform support more platforms than TADS or
> >is it vice versa?
> >
>
> Yes, Inform will run on everything but an abacus. This is because Inform
> limits the size of the game - TADS allows bigger games.
> So, if you want a big game, use TADS. If you want it to run on a fancy
> calculator, use Inform.
Actually, you're talking about ZMachine interpreters vs. TADS
interpreters. I'm pretty sure that the range of computers that Inform
(the compiler) runs on vs. TADS compiler is just about the same.
--
David Glasser gla...@NOSPAMuscom.com http://onramp.uscom.com/~glasser
DGlasser @ ifMUD : fovea.retina.net:4001 | r.a.i-f FAQ: come.to/raiffaq
Sadie Hawkins, official band of David Glasser: http://www.port4000.com/
Mary K. Kuhner
>Actually, you're talking about ZMachine interpreters vs. TADS
>interpreters. I'm pretty sure that the range of computers that Inform
>(the compiler) runs on vs. TADS compiler is just about the same.
I'd be really happy if we could make this one step truer by figuring
out how to run TADS on a Dec Alpha running Digital Unix. Has anyone
managed to do this? Last time I asked, I got some encouraging
hints (which I wasn't technically competant enough to use) but no
actual solution.
The Alpha is a great machine, very fast, very stable, but Digital
Unix is a bit cranky. Inform runs, but I haven't found a single
interpreter that runs perfectly without some odd behavior or other.
(I haven't tested the X windows versions, since I can't run X from
home.) If anyone has a pet Alpha-aware interpreter, I'd love to hear
about that too.
Details of what goes wrong in each case available on request.
Mary Kuhner mkku...@genetics.washington.edu
Wildman, the Cuberstalker
wrote:
>"Wildman, the Cuberstalker" wrote:
>>
>> Yes, Inform will run on everything but an abacus. This is because Inform
>> limits the size of the game - TADS allows bigger games.
>> So, if you want a big game, use TADS. If you want it to run on a fancy
>> calculator, use Inform.
>>
>> Wildman, the Cuberstalker
>> Thank you, Microsoft, and please get out of the way.
>> Fight spam - http://www.cauce.org/
>> DO NOT SPAM THIS ADDRESS
>
>
>OUCH! Big Dis on Inform! More manners, Tadder! ;-)
>
>Pete "can't we all just get along" Savage
>
But it's true - Inform's *strength* is that it has interpreters for the more
esoteric platforms. This is at the cost of limiting the size of games. TADS
lets you make bigger games, but at the cost of limiting portability - but
only about as much as Inform limits size.
If it'll make you happy, I'll add a third sentence:
If you aren't making a big game but you don't care about supporting the
rarer platforms - Palm Pilots, C64s, TRS-80, etc. - then you'll have to make
your choice based on the language and how it all fits together.
Wildman, the Cuberstalker
wrote:
>Actually, you're talking about ZMachine interpreters vs. TADS
>interpreters. I'm pretty sure that the range of computers that Inform
>(the compiler) runs on vs. TADS compiler is just about the same.
Yes, indeed. I suppose I wasn't too clear. Thanks.
L. Ross Raszewski
the Cuberstalker wrote:
>Yes, Inform will run on everything but an abacus. This is because Inform
>limits the size of the game - TADS allows bigger games.
>So, if you want a big game, use TADS. If you want it to run on a fancy
>calculator, use Inform.
That's misleading. (but then so is most propaganda. My own response will
probnably be a little misleading) If you want a big game, you can use inform
it you want a "really tremendously huge" gam, you may have to use tads or hugo
Of all the games I've played, only Once and Future and The Legend Lives
look to be too big for inform, though I'm not _entirely_ sure; once and future
is almost 1 meg, but tads gamefiles do not compress text the way that inform
game files do. I once had the length (in pages) of the transcript of O&F
quoted to me, and it wasn't signifigantly greater than the amount of
text that I know for a fact you can fit in an inform z8 file with
room to spare.
Admittedly, you may have to do some skullduger t get around the 65k barrier,
but I'm working on that.
Now, it is a fact that tads has no upward limit and inform does, but since
it's impossible to write an infinately large game, this is something of a moot
point.
So, if you want to write a HUGE game that vcan be played on practically any
platform, use inform. If you want to write aMIND-NUMMBINGLY HUMONGOUS game
that can be played on a fair number of platforms, but (most notably) few
or no handheld systems, use tads.
And if you want to know the difference, ask me. So far, I have been hard
pressd to find a single thing thta I have wanted to do and been unable
to implement in inform (not that such things may not exist)
Gareth Rees
> I have been hard pressd to find a single thing that I have wanted to
> do and been unable to implement in Inform (not that such things may
> not exist)
Run-time memory allocation and automatic memory management are extremely
convenient tools for implementing lots of algorithms. Of course,
there's always an analogous algorithm for the Z-machine, but convenience
is worth a lot (remember that laziness is a virtue in a programmer).
For example, suppose you're writing a game with reasonably sophisticated
NPCs. Here are some things you might want to represent:
* for each NPC, some measure of how favourably they view the other
NPCs (that they've met)
* for each NPC, which rooms they've been to and how they connect with
each other
* for each NPC, where they last saw each object
* for each NPC and for each door, whether they believe the door to be
locked, and which key fits it (for route planning)
* for each NPC, a stack of unachieved goals in some representation
Sure, you can do all this in Inform, but it's very hard (especially
since there are 64-byte limits on property arrays).
--
Gareth Rees
Ethan Dicks
>wrote:
>>Actually, you're talking about ZMachine interpreters vs. TADS
>>interpreters. I'm pretty sure that the range of computers that Inform
>>(the compiler) runs on vs. TADS compiler is just about the same.
>
>Yes, indeed. I suppose I wasn't too clear. Thanks.
There is a genuine Infocom Z-machine for RT-11, one for CP/M, a Z-machine
in Java (Zplet), and I have ported the C-64 Z-machine to the Comodore PET!
I have played Z-machine games on VMS and obscure versions of UNIX (Ultrix).
But if you want a development environment to compile games in, the list
shrinks down to DOS/Windows, AmigaDOS, UNIX, Mac, Acorn and maybe one
or two others.
-ethan
--
Ethan Dicks http://www.infinet.com/~erd/
(dicks) at (math) . (ohio-state) . (edu) sellto: postmaster@[127.0.0.1]
harvestbot fodder: pres...@whitehouse.gov fcc...@fcc.gov root@[127.0.0.1]
Ricardo Dague
> . . .
> you want a "really tremendously huge" gam . . .
HAHAHAHAHAHAHAHAHAHAHA!!!!
Keep your mind on the game, and off the gams!!!
-- Ricardo
Graham Nelson
<URL:mailto:rad...@qadas.com> wrote:
> Okay boys and girls this is the 2nd time I've asked this:
>
> Does Inform support more platforms than TADS or
> is it vice versa?
Must these discussions always be "versus"?
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
David Glasser
> So, if you want to write a HUGE game that vcan be played on practically
> any platform, use inform. If you want to write a MIND-NUMMBINGLY
> HUMONGOUS game that can be played on a fair number of platforms, but (most
> notably) few or no handheld systems, use tads.
>
> And if you want to know the difference, ask me. So far, I have been hard
> pressd to find a single thing thta I have wanted to do and been unable to
> implement in inform (not that such things may not exist)
(No advocacy from me, really; I like TADS and Inform equally, have
written in both, etc., though I don't know Hugo at all.)
A good analogy to be made is C : Perl :: Inform : TADS. You can write
excellent programs in C and Perl; C is available on just about anything;
as the compilers are by all sorts of people, it can't be extended
easily, but Larry Wall + co can add features to Perl whenever they want;
C allows you to do complicated stuff with memory and such that you don't
do in Perl; Perl lets you do stuff with strings, lists, arrays, and
other such things at a higher and easier level than C; etc.
You can write excellent games in Inform and TADS; you can play an Inform
game on just about any computer; as ZMachine interpreters are written by
all sorts of people (and not Graham Nelson), it is harder to extend
Inform's *capabilities* (eg, Blorb) (syntax-extending is a different
thing); MJR can add features to TADS whenever he wants, as he controls
his porters; Inform lets you do complicated things like write Tetris,
Befunged, and LISP (which would be difficultin TADS); TADS has far
superior list and string handling than Inform; etc.
Of course, this isn't trying to imply that it is harder to program in
Inform than in TADS; in fact, unless you are trying to do very advanced
things, they are about the same. But, all the same, TADS has better and
easier list and string handling, and is more OO. Inform, on the other
hand, is still an excellent language.
I'd recommend that anyone learn *both*. At the least, it lets you make
rants like this one.
Oh, and there is no real equivalent for HTML-TADS. I'd like to see
somebody write Arrival in Inform.
Jesse McGrew
[snip]
: Inform lets you do complicated things like write Tetris, Befunged, and
: LISP (which would be difficultin TADS); TADS has far superior list and
: string handling than Inform; etc.
Actually, wouldn't a Lisp interpreter probably be easier to do in TADS?
Looking over Andrew Plotkin's code I see that a large amount of it is for
managing memory, which is basically a non-issue in TADS. And Lisp relies on
lists a lot, which TADS is great at.
Not that Lisp interpreters are often written, of course.
(ObPlug: Everything you said about TADS applies to Snack also. New Snack
version yesterday: http://frink.ml.org/~jmcgrew/snack.html. Still no library.)
--
/ Jesse "Monolith" McGrew \ Intel inside. Screwdriver inside.
\ Mr2001 on IRC / Intel outside. AMD inside!
Jesse McGrew
[snip]
: Regarding OO, Inform (except the inner workings of the parser, but most
: games leave that as-is) is about 90% OO. I understand TADS is more like
: 99%?
I'm no Inform jockey, but AFAIK the Z-machine's only object-orientation is
that the actual in-game objects have various properties, and they can be
used interchangeably. That's encapsulation and polymorphism, but inheritance
still needs to be done by the compiler.
The Inform library, again AFAIK, has very little object-orientation in the
inheritance sense. Objects rarely provide any behavior of their own
(instead, other routines look at the object's properties and decide how to
behave), whereas in TADS the differences between an item and a container are
all in the container class (the parser says "here, deal with this 'put x on
y' action" and the classes deal with it differently).
--
/ Jesse "Monolith" McGrew \ PhongNet: IRC by youth, for youth.
| jmcgrew at cris dot com | /server toldyouso.com 6667
\ Mr2001 on IRC / http://toldyouso.com/~mrircd
Jesse McGrew
:> Actually, wouldn't a Lisp interpreter probably be easier to do in TADS?
: It was my impression that just enough was hardwired in TADS to make
: anything other than a text adventure (setting HTML aside for the moment)
: impossible.
As long as you can enter a loop where you read lines of text without giving
control back to the parser, it should be easy enough to implement something
like Lists of Lists. However, I don't think TADS has the console or timing
control needed to do something like Freefall.
: Maybe I'm wrong, but that was my impression. Maybe just nobody's ever
: bothered to do any TADS "abuses"?
I think that's probably it.
--
/ Jesse "Monolith" McGrew \ :) -> TMBG, UCB/TDS, AMD, ROTT/Sin
| Most quotable man on the Internet | :( -> CW/R&B/rap/alt, WWF/WCW/etc,
\ Mr2001 on IRC / Intel/Cyrix/PPC, Q2
Jonadab the Unsightly One
> Yes, Inform will run on everything but an abacus. This is because Inform
> limits the size of the game - TADS allows bigger games.
It's also because the VM was specifically designed to run on
anything -- 30 years ago.
> So, if you want a big game, use TADS. If you want it to run on a fancy
> calculator, use Inform.
That's pretty much it, although it's worthwhile to note
that a "medium-sized" Inform game can in fact contain
quite a fair amount of stuff. Curses absolutely blew
my mind in terms of size when I first played it.
- jonadab
Jonadab the Unsightly One
> A good analogy to be made is C : Perl :: Inform : TADS.
[Snip]
That's a beautiful analogy.
It doesn't deal with OO, but it's beautiful anyway.
Regarding OO, Inform (except the inner workings
of the parser, but most games leave that as-is)
is about 90% OO. I understand TADS is more
like 99%?
[IMO Inform is as OO as it needs to be, but
that's a matter of preference.]
> Oh, and there is no real equivalent for HTML-TADS. I'd like to see
> somebody write Arrival in Inform.
The same could be said, however, for Freefall in TADS.
- jonadab
Jonadab the Unsightly One
> Actually, wouldn't a Lisp interpreter probably be easier to do in TADS?
It was my impression that just enough was hardwired
in TADS to make anything other than a text adventure
(setting HTML aside for the moment) impossible.
Maybe I'm wrong, but that was my impression.
Maybe just nobody's ever bothered to do any
TADS "abuses"?
- jonadab
Jonadab the Unsightly One
> But it's true - Inform's *strength* is that it has interpreters for the more
> esoteric platforms.
I would have said Inform's strength was grammar.
Portability is another major strength, though.
- jonadab
Jonadab the Unsightly One
> > Does Inform support more platforms than TADS or
> > is it vice versa?
>
> Must these discussions always be "versus"?
Actually, I'd like to see some new games
released simultaneously for both platforms...
- jonadab
Admiral Jota
> Yes, Inform will run on everything but an abacus. This is because Inform
> limits the size of the game - TADS allows bigger games.
> So, if you want a big game, use TADS. If you want it to run on a fancy
> calculator, use Inform.
Actually, I've been working on porting Frotz to the abacus. So far, I only
have it working for the Roman style, but I think I've figured out what
caused most of the bugs on the Chinese ones. The real problem I'm facing
is how to download z5 files correctly -- about half the time, the beads on
the third wire get shifted by one bit. Any suggestions?
--
/<-= Admiral Jota =->\
-< <-= jo...@tiac.net =-> >-
\<-=- -= -=- =- -=->/
Magnus Olsson
>of the parser, but most games leave that as-is)
>is about 90% OO. I understand TADS is more
>like 99%?
I don't think percentage figures like that are very meaningful.
In some ways, Inform is more OO than TADS (Inform has private
members, TADS hasn't), while in other ways it's less. Both languages
are, as you say, as OO as they need to be:
>[IMO Inform is as OO as it needs to be, but
>that's a matter of preference.]
The big difference is in the libraries; the Inform library has a
non-OO heritage, hence it still does some things in a less than
ideally OO way, while the TADS library was OO from the start. The
basic paradigm in the Inform library is that almost all objects are of
the same class, attributes are used to distinguish, say, a chair from
a door, and the library code contains lots of tests on these
attributes. The TADS library is built from the ground up on multiple
inheritance and overridden methods (so there's never any need to
explicitly test if an object is a door or a chair, say while trying to
sit on it; the object is just passed the "sit on" message and reacts
accordingly. To be fair, the Inform library does this as well in many
cases, but far from always; IMHO too often it has to do things like
"Hmm, the player wants to sit on this object. I'll have to check if
it's a chair, in which case I'll do this, or if it's not I'll have to
do something different").
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Magnus Olsson
Jesse McGrew <jmcgrew-at-...@guess.org> wrote:
>Jonadab the Unsightly One <jon...@zerospam.com> wrote:
>: Regarding OO, Inform (except the inner workings of the parser, but most
>: games leave that as-is) is about 90% OO. I understand TADS is more like
>: 99%?
>
>that the actual in-game objects have various properties, and they can be
>used interchangeably. That's encapsulation and polymorphism, but inheritance
>still needs to be done by the compiler.
There's no reason the Z-machine would have to support OO, any more
than the Pentium II that runs my C++ programs has to. You might argue
that it might be nice if it did, but all this is invisible to the
programmer.
Magnus Olsson
>
>> Yes, Inform will run on everything but an abacus. This is because Inform
>> limits the size of the game - TADS allows bigger games.
>
>anything -- 30 years ago.
More like 20 years ago, actually; 30 years ago, there weren't even any
adventure games ("Colossal Cave" is from 1972 IIRC, and Zork is a couple
of years younger).
Gareth Rees
> A good analogy to be made is C : Perl :: Inform : TADS.
Perl is written in C. TADS is not written in Inform (at least not the
last time I looked).
--
Gareth Rees
Wildman, the Cuberstalker
wrote:
>in Java (Zplet), and I have ported the C-64 Z-machine to the Comodore PET!
You're a masochist, aren't you. ;)
Andrew Plotkin
> In rec.arts.int-fiction David Glasser <gla...@DELETEuscom.com> wrote:
> [snip]
> : Inform lets you do complicated things like write Tetris, Befunged, and
> : LISP (which would be difficultin TADS); TADS has far superior list and
> : string handling than Inform; etc.
> Actually, wouldn't a Lisp interpreter probably be easier to do in TADS?
> Looking over Andrew Plotkin's code I see that a large amount of it is for
> managing memory, which is basically a non-issue in TADS. And Lisp relies on
> lists a lot, which TADS is great at.
I don't know enough TADS to say for sure, but I don't think it would be
particularly easier. Lisp lists have some slightly wacky semantics, based
on the fact that they're *really* binary trees, which just usually slant
to the right. So, for example, finding the tail of a list (the same list
minus its first element) is a constant-time operation, and doesn't involve
allocating anything new -- you just return a reference to the right
subtree. Are TADS lists organized this way?
Could you have to implement Lisp cons cells (objects) as TADS objects, or
as memory in the TADS user heap, or either? I can see possible tradeoffs
either way. The user heap is limited to 64K (sound familiar? :-); TADS
native objects are pretty complicated beasts.
The other trick is parsing. In the Lisp part of Lists, I pitched the
Inform library parser entirely, and wrote my own code to deal with the raw
characters.
(Sorry to spend all this verbiage on a system I don't even know. Heh.
You've got my source code, which says everything I have to say about Lisp
in Inform.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Ethan Dicks
>wrote:
>>in Java (Zplet), and I have ported the C-64 Z-machine to the Comodore PET!
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>You're a masochist, aren't you. ;)
I suppose. I just always wanted to play Zork on my first computer. As an
aside, I got the same source to compile for the VIC-20 (w/32K). There are
a couple of minor problems: you have to load the game at $A000, in ROM space
no problem under VICE) and the status line is a bit fubared because it's so
short (the score overwrites the end of the room name). Other than that,
it plays fine. The text gets hard to read sometimes.
Pete
Wow. You still have your VIC-20? Wish I did. I gave away the VIC and the
C-64 years ago, along with original Scott Adams cassettes and Infocom
disks/packages. Now I'm kicking myself.
Sigh,
Pete
Alan Trewartha
<URL:mailto:jo...@shell2.tiac.net> wrote:
> In rec.arts.int-fiction Wildman, the Cuberstalker <wil...@microserve.net> wrote:
> Actually, I've been working on porting Frotz to the abacus. So far, I only
> have it working for the Roman style, but I think I've figured out what
> caused most of the bugs on the Chinese ones. The real problem I'm facing
> is how to download z5 files correctly -- about half the time, the beads on
> the third wire get shifted by one bit. Any suggestions?
Is that because you have C++ set to 102?
--
Mail to alant instead of no.spam
David Glasser
I'm sorry. I really should have said "a somewhat passable analogy".
My point was basically that they are different in some ways and similar
in others, and that it's silly to say that one is always better than the
other.
Jesse McGrew
: Jesse McGrew (jmcgrew-at-...@guess.org) wrote:
[snip]
:> Actually, wouldn't a Lisp interpreter probably be easier to do in TADS?
:> Looking over Andrew Plotkin's code I see that a large amount of it is for
:> managing memory, which is basically a non-issue in TADS. And Lisp relies on
:> lists a lot, which TADS is great at.
: I don't know enough TADS to say for sure, but I don't think it would be
: particularly easier. Lisp lists have some slightly wacky semantics, based
: on the fact that they're *really* binary trees, which just usually slant
: to the right. So, for example, finding the tail of a list (the same list
: minus its first element) is a constant-time operation, and doesn't involve
: allocating anything new -- you just return a reference to the right
: subtree. Are TADS lists organized this way?
Not typically, but you could do it.. instead of a list like this:
[a b c d e]
You could have this:
[a [b [c [d [e nil]]]]]
Although that probably isn't any easier to deal with than the equivalent
structures in Inform, except for the memory management. Considering the
structure of Lisp lists, and the way they are accessed (by cdr and car,
instead of by element number), I will concede that a Lisp interpreter
wouldn't really be much easier to do in TADS.
[snip]
: The other trick is parsing. In the Lisp part of Lists, I pitched the
: Inform library parser entirely, and wrote my own code to deal with the raw
: characters.
I think you can read a line of text from the user, and as long as you can
have a loop that reads text and doesn't give control back to the TADS parser
until it's ready, I think parsing wouldn't be a problem.
--
Jesse McGrew
: In article <75nf0p$g...@journal.concentric.net>,
: Jesse McGrew <jmcgrew-at-...@guess.org> wrote:
[snip]
:>I'm no Inform jockey, but AFAIK the Z-machine's only object-orientation is
:>that the actual in-game objects have various properties, and they can be
:>used interchangeably. That's encapsulation and polymorphism, but inheritance
:>still needs to be done by the compiler.
: There's no reason the Z-machine would have to support OO, any more
: than the Pentium II that runs my C++ programs has to. You might argue
: that it might be nice if it did, but all this is invisible to the
: programmer.
True, but in a system that runs on TRS-80s and Psions, you might want to
have that functionality in the interpreter to make your zcode smaller and
faster.
--
Darin Johnson
> I'm no Inform jockey, but AFAIK the Z-machine's only object-orientation is
> that the actual in-game objects have various properties, and they can be
> used interchangeably. That's encapsulation and polymorphism, but inheritance
> still needs to be done by the compiler.
Actually, even less support is in the Z-machine. There's no huge
difference, per se, than in a normal machine language. What you
really have is just a lack of type checking (maybe not a complete
lack). It's still up to Inform to lay things out correctly so that
polymorphism works. (yeah, there's a *little* support for objects,
but not a lot)
--
Darin Johnson
"Look here. There's a crop circle in my ficus!" -- The Tick
Darin Johnson
> (Inform has private members, TADS hasn't)
Smalltalk doesn't have private methods. The presence of lack of this
feature is orthagonal to OO, IMHO. Of course, the drawback in TADS is
that you don't have private instance variables either, as methods and
instance variables are merged into the same concept. That's probably
what you're referring to.
In the long run "OO" is defined differently by everyone, and everyone
will always argue about what it really means, and what 3 or 4 or 5
properties have to be there before you can call something OO.
Personally, OO is an adjective like "red" or "big", and thus should be
more loosely defined.
(ie, object-oriented is a programming style that corresponds to
procedure oriented, function oriented, data oriented, imperative
oriented, etc.)
> The big difference is in the libraries; the Inform library has a
> non-OO heritage, hence it still does some things in a less than
> ideally OO way, while the TADS library was OO from the start.
This is important. Language support for OO is a *convenience* which
promotes OO style. You can do OO without any language support at all.
To have really good OO it should be used throughout, so that it is
available to be used everywhere. So in the IF programming case, it's
important to have the OO in the library so that it's ready to be
exploited. The quicker you can modify behavior with inheritance, the
more likely you'll end up with a game that feels different from other
games.
A good comparison is Smalltalk vs. C++.
--
Darin Johnson
My shoes are too tight, and I have forgotten how to dance -- Babylon 5
Jonadab the Unsightly One
> True, but in a system that runs on TRS-80s and Psions, you might want to
> have that functionality in the interpreter to make your zcode smaller and
> faster.
Smaller and faster than z-code?
I don't think that's possible cross-platform;
you'd probably have to program on bare metal,
separately for every CPU and OS.
- jonadab
Jesse McGrew
:> True, but in a system that runs on TRS-80s and Psions, you might want to
:> have that functionality in the interpreter to make your zcode smaller and
:> faster.
: Smaller and faster than z-code?
No.. smaller and faster than the code Inform 6 generates. The methods used
to implement Inform's object orientation (most notably individual
properties) take up space in the zcode file and execution time.
Of course, a single individual property lookup probably wouldn't take any
noticable time on a TRS-80, but I wouldn't want to use them for everything.
--
Andrew Plotkin
> Jonadab the Unsightly One <jon...@zerospam.com> wrote:
> : jmcgrew-at-...@guess.org (Jesse McGrew) wrote:
> :> True, but in a system that runs on TRS-80s and Psions, you might want to
> :> have that functionality in the interpreter to make your zcode smaller and
> :> faster.
> : Smaller and faster than z-code?
> No.. smaller and faster than the code Inform 6 generates. The methods used
> to implement Inform's object orientation (most notably individual
> properties) take up space in the zcode file and execution time.
Well, faster and a *little* smaller. Those individual-property accesses
are implemented by a function call, so the code is only generated once,
not every time you access a property. The function call itself is 7 bytes
instead of 5 for a common-property lookup, which isn't that bad.
I tend to think that the machine should implement a level of functionality
lower than full OO but higher than the Z-machine does now. There are as
many, no, more styles of OO than there are languages, and you don't want
the VM to be locked into one language. Or, to look at it a different way,
*consider* the individual-property thing in Inform: it has nothing to do
with OO; it's a hack to get around the limited number of hardware
properties.
Trevor Barrie
>: Jesse McGrew (jmcgrew-at-...@guess.org) wrote:
>[snip]
>:> Actually, wouldn't a Lisp interpreter probably be easier to do in TADS?
>:> Looking over Andrew Plotkin's code I see that a large amount of it is for
>:> managing memory, which is basically a non-issue in TADS. And Lisp relies on
>:> lists a lot, which TADS is great at.
>
>: I don't know enough TADS to say for sure, but I don't think it would be
>: particularly easier. Lisp lists have some slightly wacky semantics, based
>: on the fact that they're *really* binary trees, which just usually slant
>: to the right. So, for example, finding the tail of a list (the same list
>: minus its first element) is a constant-time operation, and doesn't involve
>: allocating anything new -- you just return a reference to the right
>: subtree. Are TADS lists organized this way?
Don't know, but I do recall that TADS has built-in functions car and cdr
which you can apply to its lists, so it wouldn't surprise me to learn
that they are.
Darin Johnson
> I don't think that's possible cross-platform;
> you'd probably have to program on bare metal,
> separately for every CPU and OS.
And you'd still possible end up larger (but not faster).
--
Darin Johnson
I'm not a well adjusted person, but I play one on the net.
Neil K.
> As long as you can enter a loop where you read lines of text without giving
> control back to the parser, it should be easy enough to implement something
> like Lists of Lists. However, I don't think TADS has the console or timing
> control needed to do something like Freefall.
The most recent version of TADS has some realtime functionality. The
problem is that TADS doesn't have the fixed-grid-based cursor-control
capability of the Z-machine. TADS assumes stream-based text output. You
can sort of fake stuff in HTML TADS using banners, but it's real fakery -
you have to redraw the banner every time something changes.
Different models with different strengths and weaknesses, basically. TADS
works well with modern resizeable GUI windows, whereas Inform lets you do
more textual animation stuff.
- Neil K.
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
Zimri
>EEw. who'd want to play IF in amodern resizeable GUI window?
::waving hand:: I would. I play IF with WinFrotz (even WinTADS on
occasion :^)
When developing a game, I like to have an instance of the game open in
one window, and the source text in another. Sometimes I find it
helpful to open two instances of the same game. Or maybe I just
decide, on a whim, to give Spellbreaker another crack while I'm doing
e-mail. Or maybe I've found a bug, and want to copy-paste it into an
e-mail to the author.
I agree that playing IF in console form is more immersive and
(arguably) more fun, but playing it in GUI form won't give you
cooties.
-- Zimri'el
Michael Gentry
Zimri wrote in message <75sbta$re4$1...@holly.prod.itd.earthlink.net>...
>L. Ross Raszewski wrote :
>>EEw. who'd want to play IF in amodern resizeable GUI window?
>
>::waving hand:: I would. I play IF with WinFrotz (even WinTADS on
>occasion :^)
>
>When developing a game, I like to have an instance of the game open in
>one window, and the source text in another. Sometimes I find it
>helpful to open two instances of the same game. Or maybe I just
>decide, on a whim, to give Spellbreaker another crack while I'm doing
>e-mail. Or maybe I've found a bug, and want to copy-paste it into an
>e-mail to the author.
Also: fonts. It's pretty nifty playing "Muse" in Cotillion, for example.
I've been going through Anchorhead using this delicious font called Chiller;
it's so damn atmospheric, I'm considering bundling a copy of the font in
with the second release for the benefit of Windows users.
-M.
================================================
"If you don't eat your meat, you can't have any pudding.
How can you have any pudding if you don't eat your meat?"
L. Ross Raszewski
> Different models with different strengths and weaknesses, basically. TADS
>works well with modern resizeable GUI windows, whereas Inform lets you do
>more textual animation stuff.
>
> - Neil K.
Jeremy A.Smith
<slrn77t9lm....@foobar.net>...
> If you aren't making a big game but you don't care about supporting the
> rarer platforms - Palm Pilots, C64s, TRS-80, etc. - then you'll have to
make
> your choice based on the language and how it all fits together.
I'd hardly call Pilots rare!! They're a huge-selling palmtop (maybe the
biggest selling).
C64s - I see your point. ;-)
Jeremy
--
Replace 'X' in e-mail with 'J' if you wish to e-mail me
John Francis
I would, most of the time. There's nothing special about 24 lines, or 80
characters, or whatever your full-console mode gets you.
If I wanted an authentic experience I'd have to find an old teletype, and
see if anybody still makes a 20ma current-loop controller card. No thanks!
(Although I wouldn't need a "script" command. Scrolling is automatic, too).
Even full-screen mode looks just plain silly on a 17" or 19" display - it's
so obviously not the same as the (40-column) screen on my first CRT.
I'm happy to take advantage of a modern high-resolution display where I can
see sixty or more lines of text on screen, and modern processor speeds where
response time is not even a consideration.
I remember the days when compilation was a multi-pass operation involving
cassette tapes, etc. I don't yearn for them. Life was *not* better then.
--
John "Cassette tapes? You was *lucky*! We had to make do with ..." Francis
TenthStone
08:56:14 GMT:
>Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>
>> > Does Inform support more platforms than TADS or
>> > is it vice versa?
>>
>> Must these discussions always be "versus"?
>
>Actually, I'd like to see some new games
>released simultaneously for both platforms...
Fine. When I've finished writing my game, you can have the TADS source
code to port.
-----------
The imperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us
Jonadab the Unsightly One
> EEw. who'd want to play IF in amodern resizeable GUI window?
My sentiments exactly.
- jonadab
Jonadab the Unsightly One
> I'd hardly call Pilots rare!!
It depends what you compare them to.
I've seen Macintoshes multiple times and places.
We have several PCs in my house.
I've never seen a palmtop.
- jonadab
Jonadab the Unsightly One
> : Smaller and faster than z-code?
>
> No.. smaller and faster than the code Inform 6 generates. The methods used
> to implement Inform's object orientation (most notably individual
> properties) take up space in the zcode file and execution time.
>
> Of course, a single individual property lookup probably wouldn't take any
> noticable time on a TRS-80, but I wouldn't want to use them for everything.
Ah. I avoid individual properties like the plague.
If the library didn't use them these days my game
wouldn't have any at all.
- jonadab
Magnus Olsson
I would.
Not because the window is resizable, perhaps (though that can be
convenient if you want to fit other windows on the screen).
But because with a "modern" GUI I can
* cut and paste text from the game to, say, a review.
* cut and paste commands (sometimes, the command line editing of
modern interpreters isn't quite sufficient)
* have an editor open in a "parallel" window for notes.
* (most important) choose the font that I find most readable.
Of course, under Unix most of this can be done by running a
terminal-based interpreter in an xterm window.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Magnus Olsson
Darin Johnson <da...@usa.net.nospam> wrote:
>m...@bartlet.df.lth.se (Magnus Olsson) writes:
>
>> (Inform has private members, TADS hasn't)
>
>Smalltalk doesn't have private methods. The presence of lack of this
>feature is orthagonal to OO, IMHO. Of course, the drawback in TADS is
>that you don't have private instance variables either, as methods and
>instance variables are merged into the same concept. That's probably
>what you're referring to.
Primarily, yes. Data hiding is part of (my) definition of OO. The most
important feature for this is of course private member
variables/instance variables/data members or whatever you call them.
Private methods is more a matter of convenience, although you could
argue that Smalltalk's lack of such is a misfeature.
>In the long run "OO" is defined differently by everyone, and everyone
>will always argue about what it really means, and what 3 or 4 or 5
>properties have to be there before you can call something OO.
That was more or less my point. The discussion of which language is
most OO is largely meaningless, since OO means different things to
different people, and, more importantly, which language features are
*important* depends on the context.
>Personally, OO is an adjective like "red" or "big", and thus should be
>more loosely defined.
"Should be"? I'd say it *is* loosely defined (because everybody
has their own opinion of what's OO) and it would be nice if we
could agree on a narrower definition.
>> The big difference is in the libraries; the Inform library has a
>> non-OO heritage, hence it still does some things in a less than
>> ideally OO way, while the TADS library was OO from the start.
>
>This is important. Language support for OO is a *convenience* which
>promotes OO style. You can do OO without any language support at all.
>To have really good OO it should be used throughout, so that it is
>available to be used everywhere. So in the IF programming case, it's
>important to have the OO in the library so that it's ready to be
>exploited. The quicker you can modify behavior with inheritance, the
>more likely you'll end up with a game that feels different from other
>games.
The important thing here is the extendability and modifiability of the library. IMHO,
the OO structure of the TADS library makes some modifications easy,
while the corresponding modifications to the Inform library require
you to go far "under the hood" and replace large chunks of code that
should be internal to the library. I've encountered situations where
I've had to replace a 100-line function in the Inform library with a
nearly identical copy, that just tests for one more flag in the
innermost layer of a loop. In the TADS library, the same modification
would be done by subclassing and replacing a single method.
Of course, the TADS library is far from perfect, and there are other
areas where the Inform library is much simpler to work with.
>A good comparison is Smalltalk vs. C++.
No, I don't think that's a very good comparison at all, but perhaps
you could elaborate a little so we can see what you mean?
Jonadab the Unsightly One
> But because with a "modern" GUI I can
>
> * cut and paste text from the game to, say, a review.
I use a transcript for that.
> * cut and paste commands (sometimes, the command line editing of
> modern interpreters isn't quite sufficient)
Hmmm... I've never been bothered by any insufficiencies there.
> * have an editor open in a "parallel" window for notes.
Actually, you can do that out of DOS with a task swapper
such as DOSEDIT. Granted, both can't be on the screen at
the same time, but that's how I finally finished Curses.
Or you can do it out of Windows running a DOS interpreter
and a DOS editor, which I also do. Call me odd.
> * (most important) choose the font that I find most readable.
I agree this is very important.
Maybe you can choose the font *you* find most readable in a
GUI. The font I find most readable isn't available in a
modern GUI; it's built in to text mode of PC monitor cards,
which is the biggest reason I prefer console software;
it doesn't strain my eyes.
- jonadab
Darin Johnson
> Private methods is more a matter of convenience, although you could
> argue that Smalltalk's lack of such is a misfeature.
It's a difference between "enforce privacy rules" and "privacy is by
convention". Would Smalltalk have been a better language if it
enforced privacy? I don't know, I do think that if it did it would
have raised the ugly spectre of just what private means (ie, C++'s
protected vs private, and private vs public inheritance, etc). But
convention works well enough, and few reasonable people would claim
that Smalltalk isn't OO.
> >Personally, OO is an adjective like "red" or "big", and thus should be
> >more loosely defined.
>
> "Should be"? I'd say it *is* loosely defined (because everybody
> has their own opinion of what's OO) and it would be nice if we
> could agree on a narrower definition.
But many people have very rigid definitions. Things like it must have
inheritance, or it must have enforceable encapsulation, etc. The
human animal has this apparent need to create rules and categories.
> >A good comparison is Smalltalk vs. C++.
>
> No, I don't think that's a very good comparison at all, but perhaps
> you could elaborate a little so we can see what you mean?
Smalltalk has OO throughout conceptually; everything is an object, and
there is a full fledged object oriented class library that comes with
it; it tends to be larger and slower than many languages. This is
like TADS; most things are objects, even the vocabulary words, and the
default library is OO based. C++ supports OO, but doesn't come with
much OO built in to the standard, and the standard library is not very
OO at all; it is usually pretty fast and a good author can write
pretty small programs. Inform is similar in that out of the box
there's not a whole lotta OO going on, though one can add plenty; and
it's usually smaller/faster than TADS.
Just a quick assessment, though I doubt it will hold up to scrutiny.
--
Darin Johnson
"Particle Man, Particle Man, doing the things a particle can"
Magnus Olsson
>> >more loosely defined.
>>
>> "Should be"? I'd say it *is* loosely defined (because everybody
>> has their own opinion of what's OO) and it would be nice if we
>> could agree on a narrower definition.
>
>But many people have very rigid definitions. Things like it must have
>inheritance, or it must have enforceable encapsulation, etc. The
>human animal has this apparent need to create rules and categories.
I think the human race would benefit from a more stringent definition of
what constitutes an OO language. This would eliminate a lot of contention
and misunderstanding.
Mind you, the definitions shouldn't be too narrow. (I think you're really
talking about narrow vs. broad definitions, rather than loose vs. rigid
ones. Oh, and yes, I spotted my own misuse of "narrow" above).
The issue is further complicated by the fact that we must separate OOA,
OOD, OOP and OOL (OO Analysis, Design, Programming, and Languages).
To me, an OOL is a language that has native constructs for OOP, such
as inheritance. You can do OOP in a language without inheritance, such
as C, but that doesn't make C an OOL.
>Smalltalk has OO throughout conceptually; everything is an object, and
>there is a full fledged object oriented class library that comes with
>it; it tends to be larger and slower than many languages. This is
>like TADS; most things are objects, even the vocabulary words, and the
>default library is OO based. C++ supports OO, but doesn't come with
>much OO built in to the standard, and the standard library is not very
>OO at all; it is usually pretty fast and a good author can write
>pretty small programs. Inform is similar in that out of the box
>there's not a whole lotta OO going on, though one can add plenty; and
>it's usually smaller/faster than TADS.
>
>Just a quick assessment, though I doubt it will hold up to scrutiny.
For example, the analogy breaks down when you look at the string data
types of Inform and TADS: in Inform, strings are objects with methods
and belong to the class String, whereas TADS' string datatype is much
more like the simple datatypes of C++ (though not like the string
datatype in ISO C++, which is a class).