[MUD-Dev] Languages for MUD drivers

Petri Virkkula pvirkkul at iki.fi
Thu Nov 18 09:20:30 New Zealand Daylight Time 1999

>>>>> "Laurent" == Laurent Bossavit <laurent at netdive.com> writes:

Laurent> A lot of the issues M* server designers and implementors struggle 
Laurent> with are in fact active areas of programming language research. These 
Laurent> are in approximate order of importance (for M* writers!)
Laurent>  - distributed processing support (for large worlds)
Laurent>  - concurrent processing support (for reactive worlds)
Laurent>  - object orientation (for modular worlds)
Laurent>  - object persistence (as in MOO)
Laurent>  - run-time mutability (aka dynamic recompilation, as in MOO/ColdC)
Laurent>  - reflective capabilities (so programs can modify themselves)
Laurent>  - security (to enable in-game access to world code by 'wizards')

	To me the MUD building language/server design priorities are
	the following:

	1) easy language for area builders (this means that there are
           no threads, mutexes, etc. in the language
	2) stability
	3) object oriented
	4) security
	5) distributed processing for performance

	I think Java is bad in respect my criterias. LPC is fine, but
	current dirvers do not support distributed processing. Thus
	my "dream" driver uses LPC and uses multiple CPUs/machines for
	LPC bytecode execution, shares all objects between the
	multiple interpreter threads/processes AND hides from area
	builders the fact that the driver is distributed.

	IMHO synchronization of threads or multiple processes is too
	difficult task to give access such primitives to area
	builders. The programming environment (the driver) must hide
	that kind of issues from area builders, and perhaps even from
	mudlib coders.


MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list