[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=F8stad wrote:
> > On the technical decisions "made":
> >
> > - DevMUD will have dynamic loadable modules because it is cool (and b=
ecause
> > it is used in mainframes, it looks like Java, it is used in Windows a=
s a
> > replacement for a sucking memory model, because it is used for OS dev=
ice
> > 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 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 s=
ome hack
> to make your data stay there while you reload).  This could cost a subs=
tantial
> amount of time depending on the mud (not all muds have a small memory f=
ootprint
> and loading time) and the frequency at which it is used (some coders wi=
ll
> reload modules in their test server more than once a month - maybe 20 t=
imes 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 t=
wo
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.  I=
f
for no other reason, they have to be adressed at some point.  I usually t=
ry
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 th=
e
same reason)

> 2. If a suitably large toolkit of modules existed, people less of the c=
omputer
> geeky and more of the creative variety would be able to download module=
s 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 wh=
ich
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 framewo=
rk
then I am sure you can identify a number of such issues which one would b=
e
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 considera=
tion.

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 no=
t
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...
=20
> > - DevMUD will have a Virtual Machinelanguage because it is cool (ever=
ybody
> > does it)
>=20
> If there's going to be some in-game programming language (which a lot o=
f
> 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 selectin=
g
an existing language syntax), you have to do it right the first time. VM
efficiency is clearly dependant on language-semantics and hardware...  Th=
e
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)
>=20
> 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 discusse=
d.=20
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 internati=
onal
> > effort as well)
>=20
> 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, bu=
t
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?  (o=
r
> > GeekCore?)  Ah well, I think I'll stick to PhotonCore (fast'n'light ;=
-)
>=20
> 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 n=
o
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...
=20
> Additionally, we have an underlying contradiction here.  On one hand, y=
ou 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 everyth=
ing
that can be done with dynamic, with static, as seen from the players poin=
t
of view.  Then again, I haven't said that you shouldn't go for dynamic.=20
Just that you won't get it for free and that you need something better th=
an
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*
>=20
> 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 th=
at
say that talking is bad, depends on what you are talking about. One reall=
y
need someone to collect statments, ideas and write readable summaries
though.)

You might want to try IPA for the most important aspects, a rather verbos=
e
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 (*=3Dselected 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)
=20
[... 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 th=
e
threads and collect statements and wishes and proposals and integrate the=
se,
point at conflicts etc... That's the "trying" part.
--
Ola