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

[James Wilson]

On Sat, 31 Oct 1998, Thandor wrote:
>I've heard several posts saying "I think the core should be done in C" or
>words to that effect. Not just it should use C calling conventions, but
>that it should be done in C. Deciding on C calling conventions now doesn't
>really bother me because I stuggle to see the list come up with a better
>alternative. However, as for the actual language of implementation - I
>certainly don't know enough about how the system is intended to work to be
>able to say at this stage that C is the best language for the job.

You're right, they're a bit different. C bindings could be the glue, but 
the core itself could be in C++ (or in Perl, for that matter). 

>I'm not convinced that giving people enough rope to hang themselves (ie
>allowing them to write modules in any language) is the greatest idea
>anyway. I thought the idea is you only had to do the very low level stuff
>in native code, the rest could be handled by some sort of game code? In
>which case, keeping things simple by deciding on a single language to use
>for the implementation of the native code section might not be such a big
>tradeoff. I certainly find things easier to understand when everything is
>writen in the same language, rather than every other module choosing the
>author's pet language.

yeah, but the language I want to use isn't the language you want to use isn't
the language Chris wants to use. Imposing a single language on all DevMud
modules would miss the point.

>So, does anyone mind telling me what exactly are we really hoping to gain
>from allowing any language at all to be used? Confusion is what I see being
>gained. Then again, I just can't get my mind around the idea of the
>infinitely flexible design that people seem to want. Maybe someone needs to
>spell it out in simple english how that allows me to make a better mud so I
>can understand it.

first off let me say that I think true language agnosticism is a pipe
dream. What IS realistic, however, is a straightforward and simple mechanism
for module abstractions, such that integrating said modules with other systems
is made easier. Not necessarily trivial, and not necessarily always
possible, but as straightforward as we can make it. One of the hopes is that the
module interface will also be easy to glue together with languages of peoples'
choice, so if I run a Python-based mud I can still glom in a DevMud module with
a minimum of fuss.

Writing modules in various languages does raise a lot of issues which I don't
have an answer for. Can we really integrate a module written in Python with a
module written in COBOL by having the kernel link up various extern "C"
function pointers? Maybe. There may be some heavy lifting that has to be done
for each language that is to interoperate; that is, perhaps C and C++ are the
easiest to make interoperate, so we start with modules written in those. Then
we look at Python interoperation, figure out how to make Python's memory
management work with DevMud's, and distribute the proper magic to do so.
Someone else looks at Perl, and James takes COBOL. I'm not sure this is
feasible. We'd need to look at a lot of specific issues in great detail and
design the kernel/modules appropriately.