[MUD-Dev] Introduction

[Miroslav Silovic]

> [Miro:]
> :This is an expensive tradeoff, and one you want to think CAREFULLY about.
> :You can go for strongly-typed (i.e. all /variables/ are declared in advance,
> :and dynamically-typed (i.e. data keeps type-tags, and types are checked
> :in runtime). If you do strongly-typed language, you'll be able to compile
> :it to C without too much pain, and gain a lot of speed. Unfortunately, the
> :payoff is in the ease of programming. MUD tend to use mixed datastructures
> :a lot, and when you're able to just say 'this is a list' without worrying
> :about the types of the elements inside it (as dynamically-typed languages
> :allow), you can spew working code at blinding speed, and you'll also make
> :your hired coders much happier.
> 
> Actually, I've gone somewhat futher than that. The DB is strongly typed,
> too. Any reference to a property on a DB entity is done in such a way
> that the type of the property is known, so the type of the retrieved
> value is known. I support lists of stuff (all the same type, as you say),
> and have never noticed any difficulties. Can you give me an example of
> where you would want to have a list of different types of things, and
> how you want to go about processing the list?

Okay, a few examples: One of the situations that happens often is a function
returning either result or 'I couldn't do it'. With typed system, you need
to return two values explicitely. With untyped, you can return either a
list of (integer) 0 (assuming that result is a list).

Another example is mixing plaintext and compiled hypertext. You can use
strings for plaintext and objects for pre-parsed hypertext type. It's
nice to be able to mix them freely.

Much harder example: consider a list of contents in a room. In strong
typed system, you will have to decide on their representation in advance.
But in a dynamically typed system, you could use integers (or symbol types)
to refer to commonly used objects (say, prepackaged weapons). Or you
could use objects from some lightweight class to refer to classes of
very similar objects, and still have the option of doing heavy-weight
things.

And yes, I /know/ that some strongly typed languages can use distict
unions (ML can, for example). If you're aiming at writing a MUD in something
similar to ML, I'd certainly be very interested.

Hmmm, on a second thought, Common LISP is also strongly typed, if you
choose to declare everything. But I *want* freedom not to. It's simply
too annoying to try to figure what a variable will be used for, when
I'm trying to concentrate on the algorithm.

> Personally, I'd much rather work with code that wasn't "spewed at blinding
> speed" - it is much more likely to work properly, and to handle the
> inevitable exceptional cases. I think what it comes down to is the

You misunderstand. I refer to *FAST* development of robust code. Dynamically
typed languages, with some debugging facilities, won't let you get away
with too much, and they don't pester you with figuring declarations in
advance (again, I /know/ that ML doesn't either. But ML is also
non-trivial to implement from scratch).

> experience of the individual. Until you've tried a system that is
> strongly typed, but nevertheless has the flexibility of a MUD system,
> I doubt a proper comparison can be made. I've worked with several weakly
> typed systems, and am forever frustrated by their inability to detect
> even the most obvious of my blunders.

You're certainly right here - it depends on individual experience. I
have great experience with dynamically typed systems (I hope you mean
'dynamically typed' as opposed to 'weakly typed' - those are not the same).

> Now, I'm on the exact opposite side of the boat in the area of objects
> and properties. I don't have any fixed object formats - they are all
> just a collection of properties, either inherited (*without* copying),
> or specified explicitly. (Well, there is a small base structure for an
> object, which I call "things" since they are used for rooms, etc. as
> well.) Doing this *does* cost me performance - every property reference
> is a scan of a small array (plus possibly following inheritance pointers),
> but the flexibility is tremendous. I can add a property to the system at
> run-time, and attach it to whatever objects I chose. It will be ignored
> by old code, but it works just fine with the new code it was created for,
> is inherited like anything else, has an appropriate default based on it
> type, etc. This also saves me huge amounts of DB space compared to some
> systems I've seen or heard about. A property needs to be present on a
> thing only if it is different from the default, and different from what
> is inherited.

Oh, we agree here. Completely. :) I'd also add that I don't like having
to explicitely load the objects (a'la LP). Checkpointing is a Good Thing
(or some more dynamic version of the same).

> Hmm. I *think* I might know what you were getting at. No, I don't mean
> other ways to reference locals behind the scenes - there are no
> pointers or "reference" types. What I was trying to say was that you
> don't need the name of a local to reference it at run time - the
> interpreted code just needs the pointer to the current traceback
> record, and the offset of the variable.

Uhhh, okay, I misunderstood a bit - it's not that unsafe. But again,
why do you need it as part of the /language/ as opposed to part of the
language /implementaion/?

	Miro