[lmud-devel] re-inventing past mistakes

[Heow Eide-Goodman]

James,

Your reasoning for LMUD sounds very much why I love using eshell for
Emacs.  Having shell operations implemented in Emacs allows you to swim
in a 'soup' of elisp functions as if they were shell-scripts/commands.
It's a very powerful paradigm and takes absolutely no time even for
newbie non-lispers to 'get it'.  Amazing.  

This really brings up questions regarding the complexity of interacting
with a MUD.  I mean with today's machines, who really MUDs on a VT100
anymore?  I personally use tkmoo simply because it allows me programatic
control over the windowing operations in that I can break up the stream
of chatter/interaction into well defined "channels" each in their own
window.  Rolling all of this in CL would be a dream-come-true, heck I'll
make it my login shell.  :-)

And yes, although Mooix does allow multi-language objects, it aspires to
be no more complex than LambdaMoo, which is an "interesting" language
lacking in many features which are the strength of CL.  However, it does
work and seems to be relatively little effort to port without
re-implementing systems functionality within CL.

So I'm actually giving Mooix a go and am quite impressed with acl-compat
for the networking layer.  I've successfully read a website over socket
connectinos using both CLisp and LispWorks (on Debian) so I expect that
it's claims of near-universal Lisp communication are not unfounded.

Hope all goes well with your studies and I'd like to see something in
the CVS repo ASAP, if anything just for the pure joy of playing with a
broken CL MUD.  I'd also like to [eventualy] include this in the Lisp
Resource Kit when it gets into a stable state.

Cheers,

- Heow


On Tue, 2004-09-28 at 23:59, James Crippen wrote:
> On 24 Sep 2004 15:57:40 -0400, Heow Eide-Goodman
> <lists at alphageeksinc.com> wrote:
> > I've always been interested in writing a MUD in Lisp as I feel it is a
> > very, very good implementation language.  Especially since the
> > programming aspect of most MUDs are often an afterthought.
> 
> Indeed. That's one reason why I came up with the idea of interacting
> with the Lisp REPL through something like SLIME, rather than making
> programmers load files or program by MUD client. That same system may
> provide an inter-MUD object-sharing protocol as well, by basically
> serializing objects and spitting them at a REPL on the other end.
> 
> > Anyway, I thought you'd be interested in this paper on the exact
> > subject:
> > http://web.archive.org/web/20031227104716/http://www.ccs.neu.edu/home/dougo/thesis/000824/proposal/
> 
> That's an interesting paper. Thanks for bringing it to my attention.
> 
> > Which although is implemented in Perl, attempts to create a
> > cross-language platform so that objects can be implemented in something
> > like say Scheme.
> 
> I really don't think that there's much call for making a multilingual
> MUD, particularly one like LMUD. In the end LMUD should be a fairly
> complex system that will make a lot of assumptions based on using
> Common Lisp as the language, just for example the heavy use of generic
> function dispatch and the separation of objects from their methods.
> Also, multiple inheritance is rarely available in other languages and
> LMUD is going to (already does, in fact) make extremely extensive use
> of it. So making it multilingual would be in my mind an inconceivable
> cramp on the implementation of the system. Perhaps after the basic
> object API has settled somewhat, it might be possible, but figuring
> that people will be constantly adding objects in a working system and
> creating new interactions for them, the likelihood that a multilingual
> system might have much future seems limited.
> 
> One of the reasons why I wanted a MUD in Common Lisp was for the
> reason that so many MUDs are developed in scripting languages which
> lack a lot of descriptive power. I don't like the idea of taking a
> step backwards to make the MUD compatible with such crippled
> languages.
> 
> In any case, LMUD is really nowhere near far enough to reasonably
> consider such issues anyway. Once the TELNET service is working and
> the basic command interpreter is tested then I'll think about it more.
> And this semester for me is extremely busy with 18 credit hours per
> week at university, so I'm not getting much done anyway.
> 
> James