[MUD-Dev] Re: Why modules? (Was: Inheritable modules)

[Thandor]

On Sat, Oct 31, 1998 at 02:41:30PM +0100, Ola Fosheim Gr=F8stad wrote:
> Can someone please explain WHY dynamic loading is desired?  I haven't s=
een
> one good argument yet for why it should be dynamic.  People won't repla=
ce
> their magic module twice a day. Probably not once a month either, a reb=
oot
> once a month is quite good!

Ah, this is something I meant to say earlier, but it got messed up in my
attempt to put my jumble of thoughts into words. I think I got my points
messed up and pointed to the mud language instead of the whole system, wh=
en
asking why is being so modifiable on the fly such a great thing?

It does raise the question - people are saying you'll probably never need
to touch the underlying code, and be able to do everything in the mud
language. If that's the case, then Ola is right. There is zero benefit of
having dynamic loading.

> Maybe a 20% speed up isn't all that much, but have 4 levels of 20% spee=
d ups
> and you'll have a 100% speed up!

I think a 20% speedup is a lot. ;) Especially if the thing used to speed
the mud up also has the benefit of making the mud simpler.=20

> A MUD is not exactly an OS, an OS caters for many _ independent _
> applications, running on a wide variety of hardware with different
> functionality.  Implementing the OS metaphor is a mistake in my opinion=
.=20
> Can somebody please explain what MUD related advantages these modules h=
ave
> over regular libraries?

Well, I guess someone will say that a single copy of DevMUD could be
running multiple different muds at once. I agree, it could. But you have =
to
ask yourself - why? What advantage does it have? In practice, DevMUD is
probably going to be used to run a single mud at once. In operating syste=
m
terms, it's really only going to be operating on the level of MSDOS. ;)

> One should really try to separate analysis, design and implementation..=
.=20
> You don't need a 1-to-1 correspondence between the conceptual design an=
d the
> implementation.  You can do OO in C as well as in assembly!

True, OO isn't language specific, although the choice of language can
certainly help. I'm a little surprised so much debate has gone into the
choice of language at this stage actually. Isn't it better to come up wit=
h
a design and then pick the best language for implementing that design
(modifying it where necessary since a perfect language is unlikely to
exist)? Why build around the limitations of (for example) C at this stage=
?
I certainly haven't seen enough design to know for sure what language wil=
l
be the most appropriate for DevMUD. It seems a shame to throw things away
just because they can't be done in one particular language, before enough
is known to even say that language will be the best one to use.

> I'm not questioning that there will eventually be DevMUD, I am question=
ing
> the analysis/design strategy which have been "selected". So far, the de=
sign
> strategy seems to be "assume nothing" and "design nothing" and "select =
tools
> before analysis"... It think it would help a lot if the team forgot abo=
ut
> computers for a while and spent some time working on the vision (the
> philosophy) and made sure it is related to the end product, MUDs.

Ah, this is exactly what I was trying to get at. You just summed it up so
much more elegantly than I could hope to with my verbose writing style.

- Shane King.