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

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

"Jon A. Lambert" wrote:
> I think it's essential for bytecode modules that use the VM engine.
> As for native code modules, should one be required to edit
> the makefiles and relink the entire mud statically to effect a
> change?

Think about it.  There is no real difference, automate the process if you so
desire.  How slow is your linker?  This is clearly a minor issue for a mud
development project, and no worse than editing a config file...

> I can compile and link native modules independently.

Yeah sure, you can do that with a static approach too.  It's not like
anything will prevent you from using a shared lib during the development
phase if you so desire.

> I can distribute my native module in binary form to another DevMud
> user, who can simply add a few parameters to a configuration file
> and, viola, they're using my module.

Yes, if you assume that the commercial developers which the DevMUD
project were supposed to cater for are totally incapable of programming, but
then again, what do they need this for then. They could just run off with
diku, muq, moo, lp, cold + a wide range of startups.

This is getting worse. Now you don't even assume anything about the
developers, and Vadim ignores the lag! Great! A total lack of a problem
space!!  You'll be lucky if you eventually stumble onto something which
isn't a minor issue...

The real challenge for the team is to actually form and communicate a vision
which can act as common designgoal. It should address the potential
developers using it, of how it is going to save the day for developers etc,
on a conceptual level (not lowlevel technical level). I think this is
imperativ for a volunteer collaborative effort. 

(As an example, Both Linux and GNU can be viewed as "saving our peers from
the evil empire" by giving them the tools which already have been made
(commercially) for free. There is no evil empire in the mud community to
copy yet, so you can't skip analysis without paying a price)
 
> Yeah.  If I had to weigh the overhead of many discrete function calls
> and quite readable and understandable code versus speed and
> optimization, I'd take readable code almost every time.  But you are
> quite right, inlines give you the best of both worlds.

Actually, you'll probably get a lot of split objects, state stored multiple
places etc etc. What you really should do was to at least identify modules
that would be needed in a full mud and spec the requirements to see what the
implications are.  Not really my choice, but a lot better than discussing
bolts and nuts for "nothing".

Besides, "all" programs are optimized by the programmer, it is just a matter
of how far you are willing to go.  If you don't optimize for MUDs then you
could happily do with any dbms on the market, etc, etc.  To optimize for
MUDs you have to know something about structure and dynamics.

> > 1. there is no object model
> 
> Yes,  I know this does bother me a lot.  I think there are many
> disconnects here between those of the function/data persuasion and
> those of the object-oriented persuasion.

At least some sunlight! Not as much as I think would be appropriate for the
process but still..

I guess I should refrain from further complaints, if implementing a "cool"
feature fulfills a recreational purpose then trying to get a grip on the
process is probably a total waste. Probably tells a lot about why the
software industry does what it does though. :(  Almost as depressing as last
years drive to log everything the users say just to hold it against them...
--
Ola