[MUD-Dev] Re: Fallacy Watch and DevMUD Vision (was Re: ... CoolComponentCore)

[Jon Leonard]

On Tue, Nov 03, 1998 at 12:50:19PM +0100, Ola Fosheim Gr=F8stad wrote:
> Hal Black wrote:
> > On Sun, Nov 01, 1998 at 01:54:13PM +0100, Ola Fosheim Gr=F8stad wrote=
:
> > > On the technical decisions "made":
> > >
> > > - DevMUD will have dynamic loadable modules because it is cool (and=
 because
> > > it is used in mainframes, it looks like Java, it is used in Windows=
 as a
> > > replacement for a sucking memory model, because it is used for OS d=
evice
> > > drivers, plug'n'play and that makes it a good idea)
> >=20
> > A nice straw man, but you neglected to mention any of the reasons tha=
t people
> > have posted that they want dynamically loaded modules.  Please allow =
me to
> > reiterate.
>=20
> I didn't list the negative sides either. I basically tried to see the
> underlying reasons for decisions being "made" ad-hoc. (but yeah there w=
as a
> nasty twist to it)

Like any other feature, dynamic loading is subject to a cost/benefit
analysis.  The implementation cost is obviously low:  I converted my IPC
example to use dynamic loading in a matter of hours.  I think we've seen
more effort spent on explaining why it's hard than it took to implement.

There isn't much of an efficiency penalty either.  In a more static syste=
m,
loads are a one-time event, and fairly fast from a user perspective.  The
run-time cost of calling from one module to another is on par with C++
virtual method calls.

We haven't yet seen how much of a burden it is on module definitions.
I expect that it doesn't impose any more overhead than well defined
reusable modules have anyway.  We'll see.

Given the costs, I think that "It's cool" might be reason enough.  The
fact that there are more substantive benefits makes it clear to me that
it's the right choice.  I still want an option to compile without it,
though.

> > > - DevMUD will have a Virtual Machinelanguage because it is cool (ev=
erybody
> > > does it)
> >=20
> > If there's going to be some in-game programming language (which a lot=
 of
> > people seem to think would be a good thing to have), there is going t=
o be
> > something like a virtual machine, even if it's a simple interpreter.
>=20
> Or a statemachine/graph (abstract syntax three). Another problem is wit=
h
> making the virtual machine the portable mechanism (as opposed to select=
ing
> an existing language syntax), you have to do it right the first time. V=
M
> efficiency is clearly dependant on language-semantics and hardware...  =
The
> main VM advantage is exchanging objectcode between different hardware
> platforms, not a major issue to my projects. ( I don't know enough abou=
t
> this, but I assume that a graph is less platform sensitive in terms of
> efficiency (all objects and references))

Enough MUD designs use in-game languages that DevMUD needs to support the=
m.
A bytecoded virtual machine has both memory and speed advantages over oth=
er
kinds of interpreters, so I consider it obvious that we'll eventually wri=
te
one.  I consider it equally obvious that not everyone will use it.

> > > - DevMUD will use 16 bit chars because it is cool (it is an interna=
tional
> > > effort as well)
> >=20
> > I guess I can't disagree with that assesment.  Some people think it i=
s cool
> > to have slashes and dots through and around their vowels.
>=20
> You can do'em with 8bits too. Actually I think UNICODE is a good idea, =
but
> the extra problems has not been discussed.  One problem is bandwidth an=
d
> storage (could be solved by increasing complexity), another problem is
> look-up-tables, yet another problem is reuse of libraries (regexp and l=
ex
> for instance).

DevMUD as I see it has 4 levels of support for a feature:

Required in all modules
Supported by some modules
Not yet implemented
Forbidden

You think putting Unicode in one of the middle two categories is a proble=
m?

I think these are significant decisions, but I don't think they're nearly
as problematic as you seem to think they are.

Jon Leonard