[MUD-Dev] Languages for MUD drivers

[Cynbe ru Taren]

"Laurent Bossavit" <laurent at netdive.com> commented:

|  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 ?

Well, it wasn't in the original 1991 design specs, but it has
crept in over time.  One has to check back every 3-4 years to
see what is new. :)  (Also, I should update the docs thoroughly
soon:  I've been concentrating on getting the code solid in
recent years.)

The current level of distributed support falls considerably short
of what I would ideally like to offer, but I believe the current
Muq Micronesia worldkit demonstrates by construction that the
current level of Muq server support for distributed operation
is sufficient to achieve interesting and useful levels of
distributed operation.

I expect some performance issues will need appear and need to be
resolved as Micronesia moves from theory to practice.  For example,
Diffie-Hellman shared secrets are transparently computed and stored
for each local-user/remote-user pair which wind up communicating and
this sort of public-key stuff is CPU intensive (and my big-int stuff
probably half as fast as it could be) so there may be some start-up
lag when encountering a large batch of new users.

There are also as-yet-unresolved issues in Muq at the intersection
of OOP and distribution, such as how to handle a local instance of
a remote class, or class definition objects replicated on multiple
servers (standard library classes, for example):  The current Muq
Micronesia worldkit codes around these issues in order to get
something usable out the door in the same millenium the project
started. :)


|  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 ?

Well, I just accepted a job, so I'll be doing less on Muq next
year than I did this year. :)

But I'm focussed on a version 0.0 first-beta 99Dec29, and we should
start getting actual experience with it after that.

I've also added OpenGL bindings and a C-ish syntax softcode
language of late.



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

I was merely suggesting that most of the value-added in your
requirement set is unrelated to syntax issues.

E.g., by limiting yourself to "languages", you might be overlooking
a distributed operating system or computation project which in fact
meets your needs nicely, except for needing to have your choice of
Python or Scheme or whatever bolted to it -- a relatively trivial
task these days.



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

Having just come off spending a year of my professional programming
life working in Java, this is one of the things that makes me a
bit skeptical of E   :-/



|  I know from experience that dynamic compilation to Java bytecode 
|  (hence to native code) of a 'scripting' language is workable.

Yes, one of the things the Java (Oak) design crew did very nicely
(imho) was design to promote this sort of ease of compilation --
definitely a Java strength.

Which makes sense, Oak was intended for embedded programming --
making toaster ovens sit up and talk &tc -- where CPU efficiency
is critical.


| I'm waiting to see how integrating persistence works out.

Activerse tried doing virtual world persistence in Java shortly before
I arrived and finally gave the entire thing up in disgust as a bad
job.

Java was -not- designed to be a persistent, distributed or
multi-user (or text-oriented) language, and it shows.  It is
also a big enough juggernaut that changing its direction and
structure at this point is pretty iffy.

My own experience with Muq design and implementation has been that
doing a good job on persistence has easily been the hardest part of
the design and implementation effort to date, with the hardest
efficiency issues and most pervasive effects through the rest of the
system: This inclines me to be skeptical of efforts to retro-fit
persistence after-the-fact to a design and implementation.

But we shall see -- perhaps Java will pleasantly surprise me. :)



|  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 ?

I've wondered similar things myself:  When I started Muq seven years
ago, my main reference competitors were MOO and Cold, and that is
still pretty much it now, give or take Java-based possibilities.

To my mind, probably contributing factors are:

(1) The current crop of servers were basically all hacked up by an
    undergrad or two while in college.  I think we've reached the
    limit of what can be achieved in that mode:  Writing a new server
    from scratch in that mode and producing something noticably
    -better- than existing servers is not really practical.

(2) Doing a quantum-leap-better next-generation virtual world server
    from scratch now requires prohibitively broad expertise: TinyMUCK
    was built from a quick-and-dirty ("lousy") db, compiler, bytecode
    interpreter &tc &tc.  Implementing all of those things -well-
    (i.e., enough better than the existing crop of servers) is getting
    to be a task well beyond the abilities of the first-time undergrad
    hacker crowd who have traditionally provided new hackers.

(3) Current server implementations have reached their design limits:
    The easy hacks have been done, and significant progress really
    depends on starting with a fresh design -- which is a major
    barrier from both a compatibility and a coding viewpoint.

If Muq succeeds, it may wind up being seen as the last harrah of the
lone-hacker school of new server development: Seven years in alpha and
a quarter million lines of code is clearly stretching the limits of
this development model.  Even if it fails completely, it might wind up
looking like the reductio ad absurdum of that line of development. :)

It looks to me as though future quantum leaps forward will require
some different model of development.

Assembling systems out of parts such as Java class libraries is
attractive, but seems to work better in theory than in practice, so
far: Aside from Java's fading immaturity problems, it turns out to be
difficult to just add a class library that makes everything nicely
persistent.  Possibly this will prove true only for a couple of
critical things like persistence?  If so, once they are resolved,
this might be the model of the future:  One person can grab a
few million lines of code and assemble something dramatically
better in an afternoon.  We can dream. :)

Massively multi-programmer projects like GNOME are another possible
way to break through to a new level.  Unfortunatly, the winning new
designs of the past all seem to be done by one or two person teams:
The Chinese Army approach so far seems limited to problems where the
design is essentially already done (as POSIX did for the Linux kernel)
or "embarassingly parallel", consisting of a host of fairly obvious
small parts -- GNOME seems to satisfy both requirements, in that it
is largely a clone of an existing model made of many small parts.

Figuring out how to get a new design right -- and then excite a
critical mass of programmers to implement it mass-hacking style --
remains I think an unsolved problem, if not perhaps an insoluable one.



|  So when are we going to see new M* technology that really pushes
|  the envelope?

99Dec29  :)  ;)  :)

 Cynbe





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