[MUD-Dev] Mud Languages

[Cynbe ru Taren]

Miroslav Silovic <silovic at petra.zesoi.fer.hr> notes...

| 1) object orientation
| 2) memory management
| 3) team support
| 4) static vs dynamic typing
| 5) persistance
| 6) interpretation/dynamic compilation/static compilation.
| 7) frozen world versus softcoded world
| 8) security
| 9) dynamic objects/inheritance
| 
| With the mainstream languages, Common LISP satisfies most of these
| features. Scheme comes close, in some implementations (as Scheme
| standard is pretty minimal). Neither can very well support a team
| of telnetted programmers developing the world, though. Some MUDs
| discussed here do.
| 
| The problem is that MUD design means that you've already decided on the
| particular task. Out of a LARGE number of general-purpose languages, I
| have yet to find *one* that supports persistance, dynamic object system
| and automatic memory management in a satisfying manner. Rschem (the
| implementation) comes close, but it still has a long way to go.

Tooting my own horn for once:  Pretty much the design
concerns that have driven my implementation of Muq.
(http://muq.org/~cynbe/muq/muq.html)

I tried basing Muq on Scheme but ran out of standard before I ran out
of issues, so I switched to CommonLisp.  (Although the current surface
syntax is Forthish. A Muq Lisp syntax compiler is about half written,
but on backburner, since Forthish is at least as suitable for
interactive hacking.)

At this point Muq consists essentially of a bytecoded multiuser,
multithreaded commonlisp with all objects living in a persistent db
with garbage collection and demand-paging from the disk db.  Much
(most) of CLOS (CommonLisp Object System) is implemented at this
point, with some minor extensions to handle multiuser stuff (CLOS
doesn't define read/write privs relative to other users, since it
has neither multiple threads nor multiple users).

Recently I've been adding some transparent networking support so
threads in one server can communicate with threads in another Muq
server without having to explicitly be aware that they are remote, and
writing a first-order mudlayer worldkit implementing something looking
vaguely like a traditional mud.  (Actually, really recently I've been
too busy with a startup to do much on Muq. :(  )

Design is logically microkernel in that just about everything you'd
want to customize is softcoded (e.g., the production compiler, the
user shell, the exception handlers, the user daemons, the inter-server
networking daemon...  if you don't like the double-round-robin
pre-emptive tasker I provided, sufficient hooks are there to write a
higher level job scheduler inserver on top of it...)  The "micro"
kernel is still nearly as big as fuzzball, however.

I've developed a relatively large regression suite hand-in-hand with
Muq, something I -strongly- recommend to anyone developing a server on
this scale.  Muq probably isn't as stable as gcc yet, say, but it's
been a year or two since anyone managed to coredump a production
release(*), and its certainly a hell of a lot more stable than, say,
Netscape or NT or VisualCafe or... *wrygrin*.

For what it's worth, that's come to about 4 years of coding and
120,000 lines of code so far:  If you're gonna try something a
-whole- lot more ambitious from scratch, you might wanna think
about either having a second person participate :) or leveraging
something existing like Java.  (A hacked Kaffe might allow you to
add multi-user &tc stuff while still taking advantage of the
existing base of compilers and libraries.)

 Cynbe

(*) Well, one person had Muq coredump this year, but after some
investigation, a botched Linux installation got the credit.