[MUD-Dev] Languages for MUD drivers
laurent at netdive.com
Thu Nov 18 00:13:56 New Zealand Daylight Time 1999
Cynbe sez :
> That's pretty close to the set of design goals I've used in the
> Muq design and implementation.
Hullo Jeff. IIRC I think Muq lacks the distributed aspect ? It's no
accident that's at the top of my list; what I envision is Internet -
scale virtual realities - or perhaps more realistically IRC-scale.
> - multi-user (This is -not- the same as "security" above)
See E for a definition of 'security' (capabilities) which is exactly
what it's supposed to be in a MUD context - other users can only
access what you want them to access. (Provably, too.)
I liked Muq a lot at any rate, though the source code turned out to
be a bit too syntactically remote from my Java/C++ experience for
comfort. Are you still actively working on Muq btw ? Or doing
something else now ?
> I think "language" is the wrong concept here. The above
> constraints all really apply to the underlying virtual machine and
> runtimes, and have virtually nothing to do with surface syntax.
I don't quite agree - the feeling I get from my recent overview of
languages with support for distributed programming is that given a
language with proper structures one can 'think about' distributed
processes more clearly than otherwise. IOW, languages are about
semantics as well as syntax.
> | The underlying (implementation) and visible (world-
> | building) languages - ideally both being the same.
> I do not find this obvious. Unless I am clearly the dumbest
> person on the list, it might be worth expanding on this.
Definitely not obvious, possibly not true literally - I migh be able
to express this better if I work at it. Of course the implementation
of a distributed, persistent, mutable, reflective, secure system with
a programming language which makes these features available (and
coherent) is not likely to be written in that language. (E.g. E is
written in Java.)
What I was getting at is more that if you have a language that
provides access to enough of the system-level requirements you don't
need two languages to build a M*, just that one. In the same vein one
no longer needs to know C or C++ to write a (simpler) network server
such as a httpd, as the Java language provides enough support for the
required abstractions (sockets at the library level, concurrency at
the language level).
> E is an interesting effort, certainly one of the few real attempts
> to innovate of late. I'm a bit skeptical of how well some of their
> design ideas will fare in the real world, but that's pretty normal
> with real innovation -- time will tell!
I know from experience that dynamic compilation to Java bytecode
(hence to native code) of a 'scripting' language is workable. I'm
waiting to see how integrating persistence works out. The security
aspect I'm quite convinced is sound - and exactly what a M* needs.
> Given the amount of effort you've put into evaluation, it would be
> a service to the list if you'd sketch concisely the weaknesses and
> strengths of the systems you've looked at, and why E tops your
Not that I did all that much - call it a couple days' worth of
surfing various parts of the Web (including the very valuable Kanga
> Assembling something in Java based on various
> off-the-shelf subsystems (Voyager &tc) is another alternative
> you presumably evaluated?
Yup. As one paper  I skimmed put it, there are different
approaches to distributed programming : the one I favor is the
reflective approach, possibly because I'm lazy enough that I prefer
to let brighter minds than mine do the work of finding grand unifying
theories of distributed processing and embodying them in a language -
leaving me the lesser work of constructing practical systems with
The Oz language is interesting - JClaw in fact recently posted a
reference to a 'MUD in Oz', although little data seems to be
available - but is (to my tastes) too focused on "serious" flavors of
programming - functional and constraint-based. The same goes for
Erlang. IMHO a scripting language should be mostly imperative, as
that is a more 'intuitive' way to write short, often exploratory bits
of code such as I expect M* to be largely made of.
I barely looked at Phantom and Obliq except to trace the genealogy of
more recent languages - I prefer to exclude "dead" projects from my
initial explorations. I collected a lot of indices (lists of
researchers  or languages  for instance) and have begun sifting
through them for other promising projects. Haven't actually *run*
most of the systems yet; I did verify that E and Oz do work as
advertised (i.e. had objects on separate servers call the other
object's methods as a test of distributed operation support).
 - http://lsewww.epfl.ch/~rachid/conferences/oowg/Guerraoui.html
 - http://pauillac.inria.fr/~xleroy/researchers.html
 - http://www.luca.demon.co.uk/Ambit/Ambit.html
A few random P.S.'s - odd thoughts I had after writing the above and
which I'm including to take advantage of a delay in sending my post
to the list :
I've just had a quick look at Rebol, which has some interesting
aspects particularly regarding reflection and mutability - it's an
interpreted language and arbitrary data can be evaluated as code; the
syntactic flavor actually promotes such evaluation; the network
orientation sounds like it might permit an easy implementation of
'message passing' type distributed processing. Doesn't appear to have
any concurrent (multithread) facilities though, which kills it dead
as far as network servers are concerned.
I'm a bit frustrated at how many M* "projects" there are out there
which seem to have gone dead at various points between the design
stage and half-hearted prototype implementations, or on which there
exists so little recent information that they might as well be dead.
To name a few, Lithium (never got past design), Doug Orlean's unnamed
thesis project (see http://www.ccs.neu.edu/home/dougo/mud/), or in
the 'no info' category Matrix, Neverworld or Mu (see previous URL for
links). I'm wondering why that should be - especially as M* servers
should by nature be more visible on the Internet than other kinds of
programming projects. Or is it that there is no tenable middle ground
between IRC and Quake and that text-based social virtual realites, as
a class of software, are doomed to fail ?
On a related note, one reason I believe there is a place right now
for a "modern M*" is the recent slew of movies and other media
products related to "reality as a virtual construct", e.g. ExistenZ
or Matrix (the movie, that is). Some people are starting to catch on
as to what the Internet really is all about. :) So when are we going
to see new M* technology that really pushes the envelope a step
further toward the sort of things we see in these movies ? (Yes, I
know 3D environments are getting better all the time, witness Quake,
but that is one side of the 'virtual reality' coin - the other being
' Laurent Bossavit '
' & Sophie Jamet
' 4, impasse Morlet
' 75011 Paris
01 43 67 83 02 .
. morendil at micronet.fr .
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev