[MUD-Dev] Languages for MUD drivers

[Ian Macintosh]

    > Laurent Bossavit
    >
    > As my quest for the perfect M* server design continues
    > (I've been a
    > deep lurker on the list for over one year, though some
    > of you might
    > remember my interest at one time in porting LambdaMOO
    > to Java (done,
    > but not the panacea I hoped)) I am more and more
    > convinced that the
    > crucial parts are the underlying (implementation) and
    > visible (world-
    > building) languages - ideally both being the same.
    >
    > A lot of the issues M* server designers and
    > implementors struggle
    > with are in fact active areas of programming language
    > research. These
    > are in approximate order of importance (for M* writers!)
    >  - distributed processing support (for large worlds)
    >  - concurrent processing support (for reactive worlds)
    >  - object orientation (for modular worlds)
    >  - object persistence (as in MOO)
    >  - run-time mutability (aka dynamic recompilation, as
    > in MOO/ColdC)
    >  - reflective capabilities (so programs can modify themselves)
    >  - security (to enable in-game access to world code by
    > 'wizards')


Hi Laurent.

I know LambdaMOO very well, and from your comment re Java conversion,
I presume you do to.  What about it doesn't fit your list?

Distributed processing support can be handled by running multiple
processes and interconnecting them.  I've always thought that this is
a better way of handling large systems and a large number of users.
ie, segment areas (zones) onto different servers and link them.

I'm not sure of what you are refering to when you say concurrent
processing support?  I understand the term, but I don't understand the
context re reactive worlds?

Perhaps you could also elaborate reflective capabilities?

Regards,

Ian Macintosh.




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev