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

[Ola Fosheim Grøstad <olag#ifi,uio.no>]

Hal Black wrote:
> On Sun, Nov 01, 1998 at 01:54:13PM +0100, Ola Fosheim Grøstad 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 device
> > drivers, plug'n'play and that makes it a good idea)
> 
> A nice straw man, but you neglected to mention any of the reasons that people
> have posted that they want dynamically loaded modules.  Please allow me to
> 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 was a
nasty twist to it)

> 1. Dynamically loading a module is one way to avoid a huge cache miss (both
> writing and reading) for all the state in all other modules which would be
> caused by shutting down and restarting the whole mud (unless you have some hack
> to make your data stay there while you reload).  This could cost a substantial
> amount of time depending on the mud (not all muds have a small memory footprint
> and loading time) and the frequency at which it is used (some coders will
> reload modules in their test server more than once a month - maybe 20 times an
> hour if they were changing a lot of different modules).  Maybe none of this is
> worth dynamic loading to YOU.  That doesn't mean that it isn't valuable to ME.
> Or that it is a viewpoint worth scorn as a "cool feature".

There are lots of other problems. For instance, what are you going to do if
invariants change.  Meaning: you have to either limit yourself or write two
versions in the update.  Meaning: yet more room for human error and
nondeterminism.  This won't be a likely problem if you go for something a
human gamemaster could calculate, but if you go for a more complex
system...  I think one should list the extra problem one buys oneself.  If
for no other reason, they have to be adressed at some point.  I usually try
to minimize the situations I have to consider and put that load on the
development system. (I don't really jump at massive multithreading for the
same reason)

> 2. If a suitably large toolkit of modules existed, people less of the computer
> geeky and more of the creative variety would be able to download modules and
> put them together without a compiler (linker).

I agree, but then the focus is not really to make a commercial foundation.
Which I assumed it was.  And it assumes (even binary) interoperability which
is hard to do.  Example if your fighting module assumes hitpoints and my
avatar has health and energy instead, then you need some kind of adapter.
This is the type of issues one has to address when discussing resuable
modules...  If you try to analyze existing muds within the plugin framework
then I am sure you can identify a number of such issues which one would be
better off knowing about before the designed foundation is frozen.

> Now, dynamic loading might not be the only way to do these things, but it seems
> to me to be a straightforward way, and that is at least worth consideration.

I think Chris Gray pretty much said it.  To rephrase in my own words:
volunteers needs a carrot and whether it is rational or not is perhaps not
the issue...  I've realized that if you remove dynamic modules then there
will probably not be a DevCore, but that doesn't mean that one shouldn't
specify the problems involved...
 
> > - DevMUD will have a Virtual Machinelanguage because it is cool (everybody
> > does it)
> 
> 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 to be
> something like a virtual machine, even if it's a simple interpreter.

Or a statemachine/graph (abstract syntax three). Another problem is with
making the virtual machine the portable mechanism (as opposed to selecting
an existing language syntax), you have to do it right the first time. VM
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 about
this, but I assume that a graph is less platform sensitive in terms of
efficiency (all objects and references))

> > - DevMUD will use the eventmodel because it is cool (scalability is
> > paramount)
> 
> I'd like to use an event-based execution model, because it maps well to MUD
> execution (as opposed to that of, say linear algebra or bovine cracking)

I didn't say it was a bad idea?  But the extra cost has not been discussed. 
If one wants to use reusable (third party) modules then it probably is a
good idea (because you avoid some of the technical interfacing issues)

> > - DevMUD will use 16 bit chars because it is cool (it is an international
> > effort as well)
> 
> I guess I can't disagree with that assesment.  Some people think it is cool
> 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, but
the extra problems has not been discussed.  One problem is bandwidth and
storage (could be solved by increasing complexity), another problem is
look-up-tables, yet another problem is reuse of libraries (regexp and lex
for instance).

> > Maybe you should consider renaming the project CoolComponentCore?  (or
> > GeekCore?)  Ah well, I think I'll stick to PhotonCore (fast'n'light ;-)
> 
> Hmm, name calling, and a slightly veiled ad hominem.

Actually, I think one should be honest about ones motives.  Cool and Geek
seems to play a rather important role in general on mud-dev, and I have no
problems with cool features and geek culture in their own right.  If that is
to be the context, then so be it. Just make sure you say so...
 
> Additionally, we have an underlying contradiction here.  On one hand, you argue
> that one can't design the core without first having a plan for what the mud
> should do, and on the other, you say that static is better than dynamic.

I've basically argued for commercial/efficient as the bottomline, and in
this context I haven't yet found the advantages of dynamic that could
outweigh what I see as disadvantages.  Basically because I can do everything
that can be done with dynamic, with static, as seen from the players point
of view.  Then again, I haven't said that you shouldn't go for dynamic. 
Just that you won't get it for free and that you need something better than
cool features to guide design.

> > I am honestly not sure if the generic approach is worth it. Perhaps a good
> > shiny surface which slight modifications on would look good and have a real
> > impact on the world is better for the muddingcommunity... *shrug*
> 
> What generic issues would you remove?  Bind it to text-only clients?
> Room-based only?  No virtual machine?  (not rhetorical, I'd really like to
> know)

I can't answer that as I am not the one to drive the DevCore project.  I
think the actual vision and goals is something those _involved_ with the
project should work with.  Not only to guide design, but also to make it
more likely that cooperation will work out.  (I don't agree with those that
say that talking is bad, depends on what you are talking about. One really
need someone to collect statments, ideas and write readable summaries
though.)

You might want to try IPA for the most important aspects, a rather verbose
notation technique in which you record the design rationale (state issues,
positions and arguments). I believe it roughly follows this pattern:

Issue 1: main mechanism for supporting collaboration/reuse
    *Position 1: using dynamic loadable modules (*=selected position)
           +argument 1:
           +argument 2:
           -argument 3:
           Issue 1.1: interfacing
             etc...
    Position 2: templates and libraries

(I wouldn't use it for minor issues though)
 
[... a vision ...]

> Hopefully
> I have made this specific enough so that Ola won't say I am asking for
> "everything"  (I was careful not to mention world peace in the vision
> statement).

Bravo, jolly good start. (I'd like to see more on the context it is going to
operate in, but...) Now, if just someone would volunteer to go through the
threads and collect statements and wishes and proposals and integrate these,
point at conflicts etc... That's the "trying" part.
--
Ola