[MUD-Dev] Re: Fallacy Watch and DevMUD Vision (was Re: ... CoolComponentCore)
jleonard at divcom.slimy.com
Tue Nov 3 12:38:01 New Zealand Daylight Time 1998
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=
> > > it is used in mainframes, it looks like Java, it is used in Windows=
> > > replacement for a sucking memory model, because it is used for OS d=
> > > drivers, plug'n'play and that makes it a good idea)
> > A nice straw man, but you neglected to mention any of the reasons tha=
> > have posted that they want dynamically loaded modules. Please allow =
> > reiterate.
> 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=
> 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=
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,
> > > - DevMUD will have a Virtual Machinelanguage because it is cool (ev=
> > > does it)
> > If there's going to be some in-game programming language (which a lot=
> > people seem to think would be a good thing to have), there is going t=
> > something like a virtual machine, even if it's a simple interpreter.
> Or a statemachine/graph (abstract syntax three). Another problem is wit=
> making the virtual machine the portable mechanism (as opposed to select=
> an existing language syntax), you have to do it right the first time. V=
> efficiency is clearly dependant on language-semantics and hardware... =
> main VM advantage is exchanging objectcode between different hardware
> platforms, not a major issue to my projects. ( I don't know enough abou=
> 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=
A bytecoded virtual machine has both memory and speed advantages over oth=
kinds of interpreters, so I consider it obvious that we'll eventually wri=
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=
> > > effort as well)
> > I guess I can't disagree with that assesment. Some people think it i=
> > to have slashes and dots through and around their vowels.
> You can do'em with 8bits too. Actually I think UNICODE is a good idea, =
> the extra problems has not been discussed. One problem is bandwidth an=
> storage (could be solved by increasing complexity), another problem is
> look-up-tables, yet another problem is reuse of libraries (regexp and l=
> 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
You think putting Unicode in one of the middle two categories is a proble=
I think these are significant decisions, but I don't think they're nearly
as problematic as you seem to think they are.
More information about the MUD-Dev