[MUD-Dev] Languages for MUD drivers

[Laurent Bossavit]

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
> evaluation.  

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 
Library...)

> Assembling something in Java based on various
> off-the-shelf subsystems (Voyager &tc) is another alternative
> you presumably evaluated?

Yup. As one paper [1] 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 
them. :)

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 [2] or languages [3] 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).

References
[1] - http://lsewww.epfl.ch/~rachid/conferences/oowg/Guerraoui.html
[2] - http://pauillac.inria.fr/~xleroy/researchers.html
[3] - 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 
world construction.)


+-                        ---+
' 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
http://www.kanga.nu/lists/listinfo/mud-dev