[MUD-Dev] Re: Bruce Sterling on Virtual Community goals

[Jon Leonard]

On Mon, Oct 19, 1998 at 07:49:44PM -0700, J C Lawrence wrote:
> On Mon, 19 Oct 1998 18:33:45 -0700 
> Jon Leonard<jleonard at divcom.slimy.com> wrote:
> > On Mon, Oct 19, 1998 at 05:02:56PM -0700, J C Lawrence wrote:

> >> I'd be much more tempted to go with one of the several readily
> >> available embeddable languages that is already out there (and
> >> hopefully reasonably well tuned).  Python comes to mind as one
> >> example -- just add in a coule default modules to handle your data
> >> model and such trivia and you're away.

[snip good reasons to do that]

> > Assuming there's any interest in playing with such a server, I'll
> > probably tweak Perl so that it works as an internal language.  (More
> > because I can get help from my local Perl hacker than anything
> > else.)
> 
> <<I am really getting to dislike perl, but that's a personal
> preference stylistic matter>>

This sort of thing is exactly why I think we need multiple language
modules.  Using Python would drive me nuts, because I can't stand
whitespace sensitivity.  Some Perl characteristics bug me too.  I chose
it above because I have documentation, and Perl annoys me less than
TCL, Python and Java do.  I already know I wouldn't get many takers
for lisp-like languages...

> Perl, like LPC and Pike (?) has the advantage there there are
> compile-to-C to compile-to-machine (?) code tools available.  Java of
> course, given a JIT, has similar advantages without necessarily losing
> the CASE/RAD advantages of a scripting language per se.  IIRC there
> was some development of one of the JVM vendors releasing its JVM code
> to the Linux community some time back (vague recollection of Slashdot
> article)? 

Compile to machine code is a feature we don't want to design out, but it's
not very high on my priority list.  I'm more interested in rapid development
and new features than I am in squeezing the last ounce out of performance
out of a machine.  (The joys of a mostly idle 600MHz Alpha, which is,
incidentally, available for running experimental MUD servers.)

I'll note that compile to machine code can also be accomplished by
compiling to C, forking off GCC, and dynamic linking in the result.
It's even somewhat portable.  (More so than a code generator.)

> NB  Python's pickle storage format on first glance would seem to lend
> it self to DB back-end storage.  

Persistence and storage in general definitely need to be available.
The AberMUD and LPMud models should be available too, though.

> > This means that there'd be modules with different licenses, but
> > that's not necessarily a problem.
> 
> True.

We should probably work out some idea of what the default license is
before there's much code.  (Saves trouble later.)  I want it to be
something that allows incorporation into commercial projects.  Any
of the commercially affiliated list members care to give some idea
what a license would have to look like before you'd consider using
outside code?

I'd go as far as a "steal this code" public domain release, but
something a little less extreme might be better.

> I haven't touched a line of code on Murkle for some months now
> alas. Given the rather sweeping architectual changes that are going
> into the current codebase I'm starting to get pretty eager to roll
> either Python or CINT in as the soft code language de jour (CINT
> license is a concern).  Python is particularly attractive in this
> regard for its clean and elegant OO model.
> 
> That said I'm NOT looking forward to reworking my security model...

The lack of a security model is probably the biggest downside to this
approach.  It's extremely difficult to design security in as an
afterthought, but mix and match modules don't allow much of anything
else.  The best we might be able to do is put a chapter into the
documentation, along with an analysis of specific combinations of
modules.

Jon Leonard