August 1997
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features Jon A. Lambert
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features Jon A. Lambert
- New Topic: Butthead features Matt Chatterley
- New Topic: Butthead features Jon A. Lambert
- New Topic: Butthead features Matt Chatterley
- New Topic: Butthead features clawrenc@cup.hp.com
- New Topic: Butthead features Matt Chatterley
- New Topic: Butthead features clawrenc@cup.hp.com
- New Topic: Butthead features Matt Chatterley
- New Topic: Butthead features clawrenc@cup.hp.com
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features clawrenc@cup.hp.com
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features clawrenc@cup.hp.com
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features clawrenc@cup.hp.com
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features Koster, Raph
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features Jon A. Lambert
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features Jon A. Lambert
- New Topic: Butthead features Martin Keegan
- New Topic: Butthead features clawrenc@cup.hp.com
- New Topic: Butthead features Richard Woolcock
- New Topic: Butthead features Martin Keegan
- New Topic: Butthead features coder@ibm.net
- New Topic: Butthead features Matt Chatterley
- New Topic: Butthead features Brandon Cline
- New Topic: Butthead features Matt Chatterley
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features Matt Chatterley
- New Topic: Butthead features Koster, Raph
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features Matt Chatterley
- New Topic: Butthead features clawrenc@cup.hp.com
- New Topic: Butthead features clawrenc@cup.hp.com
- New Topic: Butthead features Martin Keegan
- New Topic: Butthead features Jeff Kesselman
- New Topic: Butthead features Adam Wiggins
- New Topic: Butthead features clawrenc@cup.hp.com
- PirateMUD and CSL Niklas Elmqvist
- PirateMUD and CSL Chris Gray
- PirateMUD and CSL Koster, Raph
- PirateMUD and CSL clawrenc@cup.hp.com
- PirateMUD and CSL Jon A. Lambert
- PirateMUD and CSL clawrenc@cup.hp.com
- PirateMUD and CSL clawrenc@cup.hp.com
- Sparse Arrays and co-ordinate based worlds Michael Hohensee
- Sparse Arrays and co-ordinate based worlds Cynbe ru Taren
- Sparse Arrays and co-ordinate based worlds Michael Hohensee
- Sparse Arrays and co-ordinate based worlds Shawn Halpenny
- Sparse Arrays and co-ordinate based worlds clawrenc@cup.hp.com
- Graphic MUDS/perspectives Koster, Raph
- Ultima Online/Generalized AI Koster, Raph
- Reputation, was butthead features Koster, Raph
- Reputation, was butthead features Jeff Kesselman
- Reputation, was butthead features Koster, Kristen
- Reputation, was butthead features Jeff Kesselman
- Reputation, was butthead features Adam Wiggins
- Graphic MUDS/perspectives Jeff Kesselman
- Generalized AI Resend Koster, Raph
- Generalized AI Resend clawrenc@cup.hp.com
- Interview with Richard Bartle clawrenc@cup.hp.com
- Generalized AI last try! Koster, Raph
- Spellcaster, or Waving Hands clawrenc@cup.hp.com
- Spellcaster, or Waving Hands Chris Gray
- Spellcaster, or Waving Hands Michael Hohensee
- Spellcaster, or Waving Hands clawrenc@cup.hp.com
- Spellcaster, or Waving Hands Michael Hohensee
- Spellcaster, or Waving Hands clawrenc@cup.hp.com
- Spellcaster, or Waving Hands Jon Leonard
- Spellcaster, or Waving Hands clawrenc@cup.hp.com
- Spellcaster, or Waving Hands Jeff Kesselman
- Spellcaster, or Waving Hands Chris Gray
- Spellcaster, or Waving Hands Michael Hohensee
- Spellcaster, or Waving Hands clawrenc@cup.hp.com
- Spellcaster, or Waving Hands Cynbe ru Taren
- Spellcaster, or Waving Hands clawrenc@cup.hp.com
- Spellcaster, or Waving Hands Richard Woolcock
- Spellcaster, or Waving Hands clawrenc@cup.hp.com
- Spellcaster, or Waving Hands Nathan Yospe
- Mud Languages Greg Munt
- MUD languages Chris Gray
- MUD languages clawrenc@cup.hp.com
- Mud Languages Chris Gray
- Mud Languages Nathan Yospe
- Mud Languages Chris Gray
- Mud Languages Greg Munt
- Mud Languages Captain Burrito
- Mud Languages Miroslav Silovic
>
> One of my contributors mentioned how much they liked the 'scoping' of
> Pascal a week or two ago. Things like strongly typed, weakly typed - what
> does this actually *mean*? Is it simply that the types of function params
> are specified in advance? Or am I thinking along the wrong lines? Or is
> it that there is a bit more to it than I am aware of?
Err, okay. Strong and weak typing are actually wrong terms, in my
opinion. The correct terms are static vs dynamic typing. In static
typing, /all/ the types are know at compile time. This is usually
implemented by requiring that all the variables be declared - one
of the exceptions is ML, which requires only enough declarations that
the rest of the types can be deduced (and the compiler is amazingly
good at deducing things for you). With dynamic typing, types are
known at runtime. Efficient compilers are often able to deduce
a /lot/ about your code, and optimize it by converting to static
typing. On the other hand, a freedom to use dynamic typing is,
IMHO, very important for rapid code design (people who never tried
it seriously will probably disagree).
> Are there any specific things that I should be aware of, when designing a
> language? (I am not interested in implementation issues atm.)
Design is far more important, because if you take your time to look
at the articles on the compiler theory on the net, you'll find out
that pretty much /every/ design can be implemented within 1/3 speed
of C (except tcl, but now they're compiling even /that/).
There are many issues. Many people think that design is tradeoff
between efficiency and ease of use. Actually design is a tradeoff
between compiler complexity and the ease of use. :) I'll come to the
issues in a bit.
> > I've used quite a few (as, I suspect, have a few of the other older
> > members of this list), including APL, AlgolW, Algol68, Pascal, Lisp,
> > Basic, Fortran, Forth, several assemblers, and a few languages of my
> > own design.
>
> Of these languages, which features do you like? Which don't you like? Why?
>
> Is it possible to say, in general terms, what makes a bad programming
> language? And what makes a good one?
At the risk of starting a flamewar, there are very few languages which are bad
in general. I'd say that the /really/ bad feature is failure
to check the types of function arguments (either at compile time or
at runtime). This is my major gripe with FORTRAN and K&R C (thankfully,
they fixed this in ANSI C).
Another think that I hate is high sensitivity to the error of the programmer.
C++ is particularily affected by this - just try to play with templates
a bit and watch the code-size explode. Error tolerance is probably the
single most important issue to deal with. This means that errors, when
they occur, should be meaningfully reported. But it also means that
logical errors should be relatively rare.
> I know someone who is looking into dynamic linking of object files into a
> running executable. Has anyone here done anything like this?
Cold people consider doing this. There is another possibility: There is
a reasonably portable code generator that spews machine code directly
into RAM. See http://www.pdos.lcs.mit.edu/~engler/pldi96-abstract.html
> > If the language you create/use is familiar to a lot of your workers, then
> > it is easier to get them to work in it, since there is less learning
> > curve, and there is the "instant gratification" that can be so important
> > in getting people motivated. I essentially did that with my system, but
> > since I knew that I was going to be the only user for a while, I chose
> > to make my language like other languages I had designed, and not like
> > any mainstream languages. My dislike for many mainstream languages, and
> > the simplicity of parsing my own languages influenced this a lot, too.
>
> What is it that you dislike about mainstream languages? Why?
Okay, here's the main design point: There are MANY issues you have to
think about when designing a MUD language. VERY few mainstream languages
satisfy these in a sensible manner. Here's a quick breakdown:
1) object orientation
MUDs are usually simulations of the kind that renderes EXTREMELY well
to object-oriented design. So, the language should have clean and
well-designed object system. This kills C, FORTRAN, and Pascal at the
start.
2) memory management
This is the single, most insidious bug source in all the programming
projects I dealt with. MUD environment is extremely dynamic in nature.
You /really/ don't want holes in your memory management. You really
don't want to /think/ about memory management, either. I think this
kills C++. Although Nathan wrote very elaborate refcounting allocator
for his MUD, he is still plagued by occasional glitch. I think that
a MUD language, to be at all usable, must either be garbage-collected,
or otherwise support only a sufficiently limited set of data structures
so that reference counting can be done automatically and still work
reliably (read: No pointers!).
3) team support
You should think /really/ carefully about this issue, since it
encompasses pretty much all other issues I'll mention. The problem
is some systems are geared toward supporting teams of programmers,
while some are almost unusable if more than one person does the
coding. Team support means that you have to think about it from
the very start. Here is an example from Cold: all datatypes are
immutable. In effect, if you have a list, the only way to change
it is to construct a new list (the driver will recognize the
cases when this can be short-circuited without copying the data
around). This is efficiency problem, but it's terribly important
because with this, you can freely return a list that is also
stored on an object's property, without fear that method you
return the list to will overwrite an element of this list.
Java, in particular, doesn't have this feature, meaning that you
have to /think/ about copying all the data you don't want to
/ever/ see modified. Then there is problem of dynamism: If you
never ever have to call the external compiler, then the team of
programmers can modify the system through their telnet connections.
VERY few mainstream languages can support this. I'll touch some of
the points here in more detail...
4) static vs dynamic typing
This is a sticky issue. If you decide to go with team support,
they you're better off with dynamic typing. In my experience,
it's MUCH easier to get used to (even if it has its own pitfalls,
such as the problem that you'll only know that types are wrong
at runtime). Also, you need VERY advanced static typing if you
ever hope to compete with dynamic (again, look at how ML does it).
Finally, dynamic typing makes automatic memory management easier,
as data must be tagged so that the types are immediately deducible
at runtime - this means you can actually write a good garbage
collector.
Still, I would agree that this point depends on personal taste.
If you will be the only coder, choose what suits you best.
5) persistance
Some MUDs have persistance implemented on the language level.
This means that some data (world objects, most usually) automatically
survive crashes/reboots/shutdowns. This, if you can afford its price,
is extremely useful. The price is database management, which can
become VERY complex if you want to make is sufficiently general.
In addition to that, you will also have to give thought to
backups, checkpointing, integrity, and many other things - basically,
you'll have to read a few VERY thick books on the topic.
The gains are tremendous: you will be able to modify the database
in a permanent way on the object level, without even soiling
your hands with I/O. If you have a team of programmers, this is
even more important.
6) interpretation/dynamic compilation/static compilation.
Interpreters are relatively easy to write, but can be slow. Static compilation
means that you parst the language offline (while the server is shut down)
and turn it into object files (possible by using, for example, C and C++
as intermediate steps), then link and reboot. Dynamic compilation is
VERY hard to do right, and means that code is compiled at runtime and
dynamically linked. As I said above, I'm looking at the possiblity of
dynamic compilation without linking and without disk access - again,
look at VCODE.
In my experience, interpreters are sufficient for almost anything, if
you write them well.
7) frozen world versus softcoded world
This issue deals with the following decision: You have to choose
whether you'll design your core objects externally to the admin-visible
systems, or show the internals to all the coders. The former is,
without doubt, more efficient, and you can do certain things that'd
be fordibbingly slow in the latter model. However, I suspect that
with a dynamic compilation in place, this issue becomes meaningless.
8) security
In team approach, programmers' code should run in a sandbox - it
wouldn't do if each programmer could crash the entire system just
by debugging a new version of the 'score' command. :) This encompasses
a lot of things: object access, database access (if you don't go
for automatic persistance), datatype opaqueness, and large number
of other issues. Most mainstream languages don't even begin to
deal with this issue. So, IMHO, mainstream language is not an
option for a MUD done by more than a single programmer.
9) dynamic objects/inheritance
This issue is VERY problematic. The idea is that if you go for
a dynamic object system, gain is that you're able to dynamically
reparent objects, change the methods and properties on the fly,
and do all of this through your telnet connection. The downside
is that this slows down message passing, both in interpreters and
compilers. It can still be made /suffciently/ efficient, actually.
Common LISP has full dynamic inheritance supported by its native
object system, and it's not too slow. The secret is caching - if
you don't /repeat/ method lookups when they're not needed, you'll
be well off.
I think that full dynamism is important if you're working on very
creative setting with lots of custom code, and you want this code
done QUICKLY - the programming speed in dynamic languages is so
much greater than in static object systems that it's not even fun.
It also gives great freedom in experimenting.
--------------------------
With the mainstream languages, Common LISP satisfies most of these
features. Scheme comes close, in some implementations (as Scheme
standard is pretty minimal). Neither can very well support a team
of telnetted programmers developing the world, though. Some MUDs
discussed here do.
> Maybe I used incorrect terminology.
>
> 5 [ PROBLEM-ORIENTATED LANGUAGE LEVEL ]
> 4 [ ASSEMBLY LANGUAGE LEVEL ]
> 3 [ OPERATING SYSTEM MACHINE LEVEL ]
> 2 [ CONVENTIONAL MACHINE LEVEL ]
> 1 [ MICROPROGRAMMING LEVEL ]
> 0 [ DIGITAL LOGIC LEVEL ]
>
> These are the 6 layers to which I was referring. To move from one level
> to another, compilation/interpretation is required. Adding another level
> on top is what I *think* something like LPC does. Maybe, maybe not.
>
> Is anyone aware of any sort of comparison between languages, showing
> levels of suitability for various tasks?
The problem is that MUD design means that you've already decided on the
particular task. Out of a LARGE number of general-purpose languages, I
have yet to find *one* that supports persistance, dynamic object system
and automatic memory management in a satisfying manner. Rschem (the
implementation) comes close, but it still has a long way to go.
Miro - Mud Languages Cynbe ru Taren
- Mud Languages Jeff Kesselman
- Mud Languages Chris Gray
- Mud Languages clawrenc@cup.hp.com
- Mud Languages coder@ibm.net
- Mud Languages Jeff Kesselman
- Mud Languages clawrenc@cup.hp.com
- sorry, cut off, was PirateMUD and CSL Koster, Raph
- Introduction Dan Armstrong
- Introduction clawrenc@cup.hp.com
- Introduction John G.
- Introduction clawrenc@cup.hp.com
- Introduction Dan Armstrong
- Introduction clawrenc@cup.hp.com
- Introduction Michael Hohensee
- Mud Languages (Introesque) ##Make Nylander
- Mud Languages (Introesque) ##Make Nylander
- Mud Languages (Introesque) Nathan Yospe
- Quad-trees/Oct-trees Michael Hohensee
- Quad-trees/Oct-trees Dan Armstrong
- node-based 3D coord systems Nathan Yospe
- Signing off... Brandon Van Every
- The 'Socialiser' problem Greg Munt
- The 'Socialiser' problem Nathan Yospe
- The 'Socialiser' problem Greg Munt
- The 'Socialiser' problem Nathan Yospe
- The 'Socialiser' problem Greg Munt
- The 'Socialiser' problem Nathan Yospe
- The 'Socialiser' problem Matt Chatterley
- The 'Socialiser' problem Chris Gray
- The 'Socialiser' problem Jeff Kesselman
- The 'Socialiser' problem Miroslav Silovic
- The 'Socialiser' problem Martin Keegan
- The 'Socialiser' problem Matt Chatterley
- The 'Socialiser' problem clawrenc@cup.hp.com
- Release out! Chris Gray
- Dots in a name? Martin Keegan
- Dots in a name? Chris Gray
- Dots in a name? Matt Chatterley
- Dots in a name? Martin Keegan
- Dots in a name? Matt Chatterley
- Dots in a name? clawrenc@cup.hp.com
- Languages: "strong" vs "weak" Chris Gray
- porting question Chris Gray
- New to this mailing list Richard Woolcock
- New to this mailing list Chris Gray
- New to this mailing list Matt Chatterley
- New to this mailing list Richard Woolcock
- New to this mailing list Chris Gray
- New to this mailing list Marian Griffith
- New to this mailing list Martin Keegan
- New to this mailing list Caliban Tiresias Darklock
- New to this mailing list Jeff Kesselman
- New to this mailing list Caliban Tiresias Darklock
- New to this mailing list Jon A. Lambert
- New to this mailing list Jeff Kesselman
- New to this mailing list Jon A. Lambert
- NPC Ecologies [was 'New to this mailing list'] Greg Munt
- DemonScape clawrenc@cup.hp.com
- Evolution of The Mud Tree Greg Munt
- OT: Invite Batzing? clawrenc@cup.hp.com
- New Topic: ButtheadS and Jurisprudance Jeff Kesselman
- New Topic: ButtheadS and Jurisprudance clawrenc@cup.hp.com
- New Topic: ButtheadS and Jurisprudance Jeff Kesselman
- New Topic: ButtheadS and Jurisprudance clawrenc@cup.hp.com
- Finding Space Michael Hohensee
- Finding Space Shawn Halpenny
- Finding Space Nathan Yospe
- Finding Space Chris Gray
- Finding Space Ned Lovely
- Finding Space Ned Lovely
- Finding Space Chris Gray
- Finding Space Nathan Yospe
- Finding Space Michael Hohensee
- Finding Space clawrenc@cup.hp.com
- OT: test Odysseus Laertes
- Fuzion - RPG game system Jon Lambert
- Character evolution Richard Woolcock
- Character evolution Dan Shiovitz
- Character evolution Matt Chatterley
- Character evolution Richard Woolcock
- Character evolution Matt Chatterley
- Character evolution clawrenc@cup.hp.com
- Character evolution Matt Chatterley
- Character evolution clawrenc@cup.hp.com
- Character evolution Adam Wiggins
- Character evolution Caliban Tiresias Darklock
- Character evolution Richard Woolcock
- Character evolution clawrenc@cup.hp.com
- Character evolution Caliban Tiresias Darklock
- Character evolution clawrenc@cup.hp.com
- Character evolution Matt Chatterley
- Character evolution Caliban Tiresias Darklock
- Character evolution Matt Chatterley
- Character evolution Richard Woolcock
- Character evolution Caliban Tiresias Darklock
- Character evolution Adam Wiggins
- Character evolution Brandon J. Rickman
- Character evolution Marian Griffith
- Character evolution Jeff Kesselman
- Character evolution Matt Chatterley
- Character evolution clawrenc@cup.hp.com
- Character evolution clawrenc@cup.hp.com
- Character evolution Jeff Kesselman
- Character evolution Matt Chatterley
- Character evolution clawrenc@cup.hp.com
- Character evolution Jeff Kesselman
- Character evolution Koster, Raph
- Character evolution Jeff Kesselman
- Character evolution Jon A. Lambert
- Character evolution coder@ibm.net
- Character evolution Jon A. Lambert
- Character evolution clawrenc@cup.hp.com
- Character evolution S001GMU@nova.wright.edu
- Character evolution clawrenc@cup.hp.com
- Character evolution Adam Wiggins
- Character evolution Jon A. Lambert
- Character evolution Matt Chatterley
- Character evolution Marian Griffith
- Character evolution clawrenc@cup.hp.com
- Character evolution Jon A. Lambert
- Character evolution clawrenc@cup.hp.com
- Character evolution Caliban Tiresias Darklock
- Character evolution Jon A. Lambert
- Character evolution coder@ibm.net
- Character evolution Brandon J. Rickman
- Character evolution Richard Woolcock
- Character evolution clawrenc@cup.hp.com
- Character evolution Ola Fosheim Grøstad
- Character evolution Jon A. Lambert
- Character evolution clawrenc@cup.hp.com
- Character evolution Jon A. Lambert
- Character evolution coder@ibm.net
- Character evolution Jon A. Lambert
- Character evolution Jon A. Lambert
- Character evolution Jeff Kesselman
- Character evolution Jeff Kesselman
- Character evolution Jeff Kesselman
- OT: test Jon A. Lambert
- Fuzion Jon A. Lambert
- (subject missing) Maddog Worlds
- Fuzion - Game System Jon A. Lambert
- Fuzion - Game System Frank Crowell
- Fuzion - Game System Jeff Kesselman
- Fuzion - Game System Jeff Kesselman
- Fuzion - Game System Jon A. Lambert
- Fuzion - Game System Jeff Kesselman
- legal mumbo jumbo Jeff Kesselman
- Bladder Control Jeff Kesselman
- Bladder Control Caliban Tiresias Darklock
- Collision Detection Cynbe ru Taren
- Looking for books... Greg Munt
- Looking for books... Jeff Kesselman
- Looking for books... Cynbe ru Taren
- Looking for books... Caliban Tiresias Darklock
- Looking for books... Jeff Kesselman
- Looking for books... Caliban Tiresias Darklock
- Looking for books... Jeff Kesselman
- Looking for books... clawrenc@cup.hp.com
- Looking for books... clawrenc@cup.hp.com
- Looking for books... coder@ibm.net
- Looking for books... Ola Fosheim Grøstad
- Looking for books... coder@ibm.net
- Looking for books... Jon A. Lambert
- Looking for books... clawrenc@cup.hp.com
- Re: Caliban Tiresias Darklock
- Character evolution Jon A. Lambert
- Character evolution Marian Griffith
- Character evolution Nathan Yospe
- Character evolution Jon A. Lambert
- Character evolution Jeff Kesselman
- Character evolution Jeff Kesselman
- Character evolution clawrenc@cup.hp.com
- Character evolution Jeff Kesselman
- Character evolution coder@ibm.net
- Character evolution Jeff Kesselman
- Character evolution Jon A. Lambert
- Character evolution Jeff Kesselman
- Character evolution Jon A. Lambert
- Character evolution Jeff Kesselman
- Character evolution clawrenc@cup.hp.com
- Character evolution Jeff Kesselman
- Character evolution coder@ibm.net
- Character evolution Jeff Kesselman
- Character evolution Felix A. Croes
- Character evolution Jeff Kesselman
- Character evolution Marian Griffith
- Character evolution Jeff Kesselman
- Character evolution Adam Wiggins
- Character evolution Jeff Kesselman
- Character evolution Adam Wiggins
- Character evolution Jeff Kesselman
- Character evolution Adam Wiggins
- Character evolution Chris Gray
- Character evolution Caliban Tiresias Darklock
- Character evolution ##Make Nylander
- Character evolution Brandon J. Rickman
- Character evolution Chris Gray
- Character evolution Nathan Yospe
- Character evolution Jeff Kesselman
- Character evolution Maddy
- Character evolution clawrenc@cup.hp.com
- Character evolution Marian Griffith
- Character evolution Marian Griffith
- Character evolution Matt Chatterley
- Character evolution Ned Lovely
- Character evolution coder@ibm.net
- Character evolution clawrenc@cup.hp.com
- Character evolution Travis Casey
- Character evolution Jeff Kesselman
- Character evolution Chris Gray
- Character evolution coder@ibm.net
- Character evolution coder@ibm.net
- Character evolution Travis Casey
- Character evolution Jeff Kesselman
- Character evolution clawrenc@cup.hp.com
- Character evolution Travis Casey
- Character evolution clawrenc@cup.hp.com
- Character evolution The Eternal City
- Character evolution clawrenc@cup.hp.com
- Character evolution The Eternal City
- Character evolution Jon A. Lambert
- Character evolution Jeff Kesselman
- Character evolution Brian Price
- Character evolution Travis Casey
- Character evolution Jeff Kesselman
- Character evolution Nathan Yospe
- Character evolution clawrenc@cup.hp.com
- Character evolution Shawn Halpenny
- Character evolution Jeff Kesselman
- Character evolution clawrenc@cup.hp.com
- Character evolution Adam Wiggins
- Alignment Jon A. Lambert
- Alignment Richard Woolcock
- Alignment Jeff Kesselman
- Alignment Jeff Kesselman
- Alignment Jon A. Lambert
- Alignment Caliban Tiresias Darklock
- Alignment Ling
- Alignment Hans-Henrik Staerfeldt
- Alignment adam@treyarch.com
- Alignment Spin
- DESIGN: R-Trees (fwd) Greg Munt
- DESIGN: R-Trees (fwd) clawrenc@cup.hp.com
- Alignment & Introductions lapsos
- Alignment & Introductions Travis Casey
- Alignment & Introductions Matt Chatterley
- Alignment & Introductions clawrenc@cup.hp.com
- Foods (was Character evolution) Marian Griffith
- Foods (was Character evolution) Matt Chatterley
- Foods (was Character evolution) clawrenc@cup.hp.com
- Foods (was Character evolution) Matt Chatterley
- Comments on MUDs from Shadists clawrenc@cup.hp.com
- Inebriation Jon A. Lambert
- Language design Greg Munt
- Language design Jeff Kesselman
- Language design Chris Gray
- Language design clawrenc@cup.hp.com
- Language design Chris Gray
- {rape] lets drop it Jeff Kesselman
- {rape] lets drop it Alex Oren
- {rape] lets drop it Caliban Tiresias Darklock
- Invitations coder@ibm.net
- Invitations coder@ibm.net
- Poisons (was Foods) Koster, Kristen
- Poisons (was Foods) Travis Casey
- Poisons (was Foods) Matt Chatterley
- Poisons (was Foods) Jon A. Lambert
- META: Attributions and Eudora clawrenc@cup.hp.com
- META: Attributions and Eudora Jon A. Lambert
- Free DB list coder@ibm.net
- New topic: AI and NPCs Caliban Tiresias Darklock
- New topic: AI and NPCs Travis Casey
- New topic: AI and NPCs Jeff Kesselman
- New topic: AI and NPCs Travis Casey
- New topic: AI and NPCs Adam Wiggins
- New topic: AI and NPCs Jeff Kesselman
- New topic: AI and NPCs Travis Casey
- New topic: AI and NPCs Adam Wiggins
- New topic: AI and NPCs Jeff Kesselman
- New topic: AI and NPCs Adam Wiggins
- New topic: AI and NPCs Jeff Kesselman
- New topic: AI and NPCs clawrenc@cup.hp.com
- New topic: AI and NPCs Jeff Kesselman
- New topic: AI and NPCs clawrenc@cup.hp.com
- New topic: AI and NPCs Matt Chatterley
- New topic: AI and NPCs Jon A. Lambert
- New topic: AI and NPCs Matt Chatterley
- New topic: AI and NPCs clawrenc@cup.hp.com
- New topic: AI and NPCs Matt Chatterley
- New topic: AI and NPCs Ola Fosheim Grøstad
- New topic: AI and NPCs Jeff Kesselman
- New topic: AI and NPCs Ola Fosheim Grøstad
- New topic: AI and NPCs Matt Chatterley
- New topic: AI and NPCs Ola Fosheim Grøstad
- New topic: AI and NPCs Jeff Kesselman
- New topic: AI and NPCs Ned Lovely
- New topic: AI and NPCs Caliban Tiresias Darklock
- New topic: AI and NPCs Nathan Yospe
- New topic: AI and NPCs Jeff Kesselman
- New topic: AI and NPCs Jon A. Lambert
- New topic: AI and NPCs Adam Wiggins
- New topic: AI and NPCs Nathan Yospe
- New topic: AI and NPCs Jon A. Lambert
- New topic: AI and NPCs Nathan Yospe
- New topic: AI and NPCs Alex Oren
- New topic: AI and NPCs Caliban Tiresias Darklock
- New topic: AI and NPCs Jon A. Lambert
- New topic: AI and NPCs coder@ibm.net
- New topic: AI and NPCs clawrenc@cup.hp.com
- New topic: AI and NPCs coder@ibm.net
- New topic: AI and NPCs Jeff Kesselman
- Re: clawrenc@cup.hp.com
- Rape Threads Nathan Yospe
- Rape Threads Jon A. Lambert
- Rape Threads Nathan Yospe
- Rape Threads Robin Carey
- Rape Threads Caliban Tiresias Darklock
- "Social control", was butthead features Koster, Raph
- "Social control", was butthead features Jeff Kesselman
- "Social control", was butthead features clawrenc@cup.hp.com
- "Social control", was butthead features Jeff Kesselman
- Character evolution [off topic] Alex Oren
- (fwd) NEW: multi-user VRML world clawrenc@cup.hp.com
- (fwd) NEW: multi-user VRML world Brandon Gillespie
- (fwd) NEW: multi-user VRML world Caliban Tiresias Darklock
- (fwd) NEW: multi-user VRML world coder@ibm.net
- MUD universe Felix A. Croes
- MUD universe Chris Gray
- MUD universe clawrenc@cup.hp.com
- MUD universe S001GMU@nova.wright.edu
- MUD universe Nathan Yospe
- MUD Universe S001GMU@nova.wright.edu
- MUD Universe Nathan Yospe
- MUD Universe S001GMU@nova.wright.edu
- MUD Universe clawrenc@cup.hp.com
- MUD universe coder@ibm.net
- MUD universe Felix A. Croes
- MUD Universe Caliban Tiresias Darklock
- MUD universe clawrenc@cup.hp.com
- MUD universe Felix A. Croes
- MUD universe Maddy
- MUD universe clawrenc@cup.hp.com
- MUD universe Felix A. Croes
- MUD universe clawrenc@cup.hp.com
- MUD universe clawrenc@cup.hp.com
- MUD Design Fundamentals (Was: Looking for books...) Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for books...) Jeff Kesselman
- MUD Design Fundamentals (Was: Looking for books...) Caliban Tiresias Darklock
- MUD Design Fundamentals (Was: Looking for books...) Jeff Kesselman
- MUD Design Fundamentals (Was: Looking for books...) Chris Gray
- MUD Design Fundamentals (Was: Looking for books...) Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for books...) coder@ibm.net
- MUD Design Fundamentals (Was: Looking for books...) Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for books...) Adam Wiggins
- MUD Design Fundamentals (Was: Looking for books...) Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for books...) Adam Wiggins
- MUD Design Fundamentals (Was: Looking for books...) Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for books...) coder@ibm.net
- MUD Design Fundamentals (Was: Looking for books...) coder@ibm.net
- MUD Design Fundamentals (Was: Looking for books...) Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for Jeff Kesselman
- MUD Design Fundamentals (Was: Looking for Brian Price
- MUD Design Fundamentals (Was: Looking for Jeff Kesselman
- MUD Design Fundamentals (Was: Looking for Jeff Kesselman
- MUD Design Fundamentals (Was: Looking for Jon A. Lambert
- MUD Design Fundamentals (Was: Looking for Chris Gray
- MUD Design Fundamentals (Was: Looking for coder@ibm.net
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for Jeff Kesselman
- MUD Design Fundamentals (Was: Looking for Jeff Kesselman
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for Chris Gray
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for Chris Gray
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for Chris Gray
- MUD Design Fundamentals (Was: Looking for Jon A. Lambert
- MUD Design Fundamentals(Was: Looking for Jeff Kesselman
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for Jon A. Lambert
- MUD Design Fundamentals(Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals(Was: Looking for Jon A. Lambert
- MUD Design Fundamentals (Was: Looking for Jon A. Lambert
- MUD Design Fundamentals (Was: Looking for Jon A. Lambert
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for Miroslav Silovic
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for Jeff Kesselman
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for coder@ibm.net
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for coder@ibm.net
- MUD Design Fundamentals (Was: Looking for Ola Fosheim Grøstad
- MUD Design Fundamentals (Was: Looking for Jeff Kesselman
- Re: Adam Wiggins
- Re: Marian Griffith
- Users want sexy muds, not rape... (Re:) Ola Fosheim Grøstad
- OT: Mortality coder@ibm.net
- Re:) Adam Wiggins
- Character evolution [off topic] coder@ibm.net
- Character evolution [off topic] Miroslav Silovic
- **sigh** OOP wars and defining RDBMS Jeff Kesselman
- **sigh** OOP wars and defining RDBMS Ola Fosheim Grøstad
- **sigh** OOP wars and defining RDBMS Jeff Kesselman
- **sigh** OOP wars and defining RDBMS Ola Fosheim Grøstad
- **sigh** OOP wars and defining RDBMS Jeff Kesselman
- **sigh** OOP wars and defining RDBMS Ola Fosheim Grøstad
- Re:) Ola Fosheim Grøstad
- World full of heros Jeff Kesselman
- World full of heros Marian Griffith
- MUD Design Fundamentals (Was: Looking for books. Jon A. Lambert
- MUD Design Fundamentals (Was: Looking for books. Ola Fosheim Grøstad
- OT: Re:) Jon A. Lambert
- Hard Sci-fi muds was Character evolution Brian Price
- Hard Sci-fi muds was Character evolution Jeff Kesselman
- Hard Sci-fi muds was Character evolution Brian Price
- Hard Sci-fi muds was Character evolution Jeff Kesselman
- Hard Sci-fi muds was Character evolution Nathan Yospe
- Hard Sci-fi muds was Character evolution Brian Price
- Hard Sci-fi muds was Character evolution Miroslav Silovic
- Hard Sci-fi Muds was Character Evolution Brian Price
- Hard Sci-fi Muds was Character Evolution Travis Casey
- Hard Sci-fi Muds was Character Evolution Brian Price
- Hard Sci-fi Muds was Character Evolution Travis Casey
- Hard Sci-fi Muds was Character Evolution Brian Price
- Hard Sci-fi Muds was Character Evolution Adam Wiggins
- Hard Sci-fi Muds was Character Evolution Brian Price
- Hard Sci-fi Muds was Character Evolution Adam Wiggins
- Hard Sci-fi Muds was Character Evolution Nathan Yospe
- Hard Sci-fi muds was Character evolution Shawn Halpenny
- Hard Sci-fi muds was Character evolution Brian Price
- Hard Sci-fi muds was Character evolution Brandon J. Rickman
- Hard Sci-fi muds was Character evolution Chris Gray
- Hard Sci-fi muds was Character evolution Brandon J. Rickman
- Hard Sci-fi muds was Character evolution Nathan Yospe
- Hard Sci-fi muds was Character evolution Brandon J. Rickman
- Hard Sci-fi muds was Character evolution clawrenc@cup.hp.com
- Hard Sci-fi muds was Character evolution Brandon J. Rickman
- Hard Sci-fi muds was Character evolution Chris Gray
- Hard Sci-fi muds was Character evolution Brandon J. Rickman
- Hard Sci-fi muds was Character evolution Jon A. Lambert
- Hard Sci-fi muds was Character evolution Adam Wiggins
- Hard Sci-fi muds was Character evolution clawrenc@cup.hp.com
- Hard Sci-fi muds was Character evolution Brandon J. Rickman
- Hard Sci-fi muds was Character evolution Adam Wiggins
- Hard Sci-fi muds was Character evolution clawrenc@cup.hp.com
- Hard Sci-fi muds was Character evolution Matt Chatterley
- Hard Sci-fi muds was Character evolution Chris Gray
- Hard Sci-fi muds was Character evolution Brian Price
- Hard Sci-fi muds was Character evolution Chris Gray
- Modeling spells/skills as collections of affects Brian Price
- Modeling spells/skills as collections of affects Travis Casey
- Modeling spells/skills as collections of affects Jeff Kesselman
- Modeling spells/skills as collections of affects Brian Price
- Modeling spells/skills as collections of affects Jeff Kesselman
- Modeling spells/skills as collections of affects Travis Casey
- Modeling spells/skills as collections of affects Jeff Kesselman
- Modeling spells/skills as collections of affects Travis Casey
- Modeling spells/skills as collections of affects Jeff Kesselman
- Modeling spells/skills as collections of affects Brian Price
- Modeling spells/skills as collections of affects Jeff Kesselman
- Modeling spells/skills as collections of affects Travis Casey
- Modeling spells/skills as collections of affects Jeff Kesselman
- Modeling spells/skills as collections of affects clawrenc@cup.hp.com
- Modeling spells/skills as collections of affects Caliban Tiresias Darklock
- Modeling spells/skills as collections of affects Michael Hohensee
- Modeling spells/skills as collections of affects Jeff Kesselman
- Modeling spells/skills as collections of affects Jeff Kesselman
- Modeling spells/skills as collections of affects Matt Chatterley
- Modeling spells/skills as collections of affects clawrenc@cup.hp.com
- Modeling spells/skills as collections of affects Dan Shiovitz
- Modeling spells/skills as collections of affects Jon A. Lambert
- Modeling spells/skills as collections of affects Shawn Halpenny
- Modeling spells/skills as collections of affects Maddy
- Modeling spells/skills as collections of affects Shawn Halpenny
- Modeling spells/skills as collections of affects Adam Wiggins
- Modeling spells/skills as collections of affects Travis S. Casey
- Modeling spells/skills as collections of affects Travis S. Casey
- Modeling spells/skills as collections of affects Caliban Tiresias Darklock
- Modeling spells/skills as collections of affects Nathan Yospe
- Modeling spells/skills as collections of affects Jon A. Lambert
- Modeling spells/skills as collections of affects clawrenc@cup.hp.com
- Modeling spells/skills as collections of affects clawrenc@cup.hp.com
- Modeling spells/skills as collections of affects Dan Shiovitz
- Modeling spells/skills as collections of affects clawrenc@cup.hp.com