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

[Bruce]

Good morning!

A bit late on the reply, but ..

On Wednesday, Oct 21, 1998, Chris Gray wrote:
>[Bruce Mitchener, Jr.:]
>
>[Info on how the Cold core addresses many of our needs snipped.]


That'd be the Cold driver... the core is the stuff written in the DB
language. (just being picky)

> >I have a number of topics relating to some of this that I want to bring
up
> >on here in the future, but I really need to finish digging myself out
from
> >underneath a big pile at work.
>
>Please do, if you can. Input from someone that has been working at the
>heart of these things for a while should be quite valuable.


As I read more in these threads, I'm not sure that we are all aiming for the
same thing.  Most people seem to be aiming for some type of server specific
to muds.  I view the Cold effort at least as one that is producing an
application server.  The very basic concerns for the core-engine are the
same.  Handle network connections, do stuff.  Everything on top of that is
just to make things more powerful, more useful, and easier to work with.  A
big focus for us also is the requirement that any one can be given access to
the programming utilities and shouldn't be able to crash the server or
interfere with someone else's programming.  This is why our system provides
builtin support for security, garbage collection (through refcounting
currently), full-blown persistence, etc.  Having a builtin parser
immediately limits you in what your system can handle.  I look at the DB as
providing all of the business logic for the system, with the driver being a
generic tool to help you implement your business logic in a fast, safe
manner.

An example would be that I've used Cold to implement web-based discussion
systems that had no mud-type component.  Brandon Gillespie has done
web-based catalogs and other things with Cold.  Sure, these aren't mud-type
applications, but who knows what the mud of tomorrow will look like
internally?

>The Cold language is Lisp-like, isn't it? (It's been a while since I
>looked!)

The syntax is similar to C with exceptions.  The object model is close to
that of Self.  Objects live in a global namespace and must have unique
names.

>How hard would it be to add another style of language?

Another language syntax?  or a full new language with differing semantics?
The compiler generates a syntax tree currently and then converts that to
bytecode.  Adding bytecodes isn't too hard, so if the existing bytecodes
didn't offer the functionality needed by the new language, it could be
added.  No one has done this though (I'm happy enough with ColdC).

>How efficient is the inner interpreter? Is it byte-code?

It is bytecode.  How do you judge efficiency?  It has been fast enough for
anything that I've wanted to do.  I'll be getting Quantify at work soon, and
we'll see how things need to be changed.  We've done load tests on a Cyrix
p150+ running FreeBSD previously with a bit over 200 test users connected
and chatting with each other (really, they were acting out plays from
Shakespeare).  Any particular method that is seen to have an efficiency
problem can be converted into a native method and linked into the driver.
Currently, there are 2 problems with that.  1)  Must recompile the driver,
since this modifies the opcode set.  I'd like to see that change and start
dynamically loading code in. 2) Can't currently call back into the
interpreter.  I expect to see this get fixed also.

>Is it strongly or weakly typed, or somewhere in the middle?

Dynamic typing.  We have distinct types, but don't require you to declare
the type in advance.

public method $user_bruce.test() {
    var foo;

    foo = 1;
    foo = "lala";

    return foo;
};

That is valid and would return "lala".

>Can strings be parsed and compiled at run-time to produce new code?


The whole system of code in the DB is fully modifiable at runtime.  This is
just about everything.  To add a new method, you call add_method() (usually
bound for security purposes to the root object and called via the wrapper
there).

>I know, I should just go read the docs, but having some of the answers
>here will likely help the stream of discussion in MUD-Dev be easier to
>follow. And yes, I'm lazy!


Understood.

- Bruce