[MUD-Dev] Introduction

[Dan Root]

cg at ami-cg.graysage.edmonton.ab.ca (Chris Gray) writes:

> :A small footprint in memory (under 300k for the binary, plus object
> :and attribute caches for a total on the order of 1.5M resident in a
> :medium sized database).
> 
> MUDServ 		  182888 ----rwed 03-May-97 19:41:28
> 
> That's my server, including interpreter, database code, etc. I normally
> run with a 500K database cache. There are other caches, etc. that will
> likely push it up to over a Meg. Oh yeah, there is also a shared library
> that contains the programming language parser and lots of utilities:

Just out of curiosity, what sort of system type is this?  (I don't
recognize the directory listing style)


> :A *small* codebase (ideally also under 300k) that's well documented
> :and cleanly coded such that it's easy to extend if necessary.
> 
> That might be a problem. Mine is currently:
> 
> MUD.index		   49524 ----rwed Friday    23:15:35
> MUD.data		  591194 ----rwed Friday    23:15:35
> 
> When you make your server generic, and put all the actual scenario rules,
> etc. in to the database, that can push up the size of the database a lot.
> You can aim for a small one, and it might even start that way, but I bet
> it will grow, and grow, and grow...

The 300k goal wasn't for the database itself, but for the amount of
code.  I was disgusted when I discovered that TinyMUCK was over 1.2M
of code.  300k is high itself.  I'm honestly hoping for around
175-200k.  The database itself is likely going to be huge. :)


> :At this point I've finished most of my db layer, and a good portion of
> :my networking code.  Now I just need to design and implement the
> :internal language.  (I'm leaning towards a Forth/MUF-like stack-based
> :language at this point)
> 
> You want to think about this a lot. Are you the only one who you would
> want to use the language? If so, they choose whatever fits your needs. If
> not, then think about what other people know and are used to. That's why
> the C-like languages in LP and MOO are successful. Personally I'm
> sufficiently arrogant that I just made a language like the previous
> languages I've designed, and force people to use it, even though no-one
> is familiar with it.

I've considered a bunch of different ideas, including including a
full Scheme subset.  However the implementation details of a stack
language versus a stack-frame language like C are pretty significant.
Even with tools like yacc, writing a language like C is not easy and
takes a lot more memory and processing power to 'compile'.  (I'm
currently leaning towards not compiling the language at all, since
interpreting a stack based language is very straight forward).  

I'm also not convinced that C is a good language.  I use it and like
it, but for a beginning programmer a lot of people believe that a lisp
or forth-like language is actually easier to learn.


> Might I suggest that you make your language strongly-typed? Many people
> don't like that (not me!), but it can make it run a lot faster if you
> don't have to do very many run-time checks or conversions. Similarly,
> force people to pre-declare variables, so that you can access them via
> something other than their name at run-time (e.g. an offset from a
> current scope pointer, allocated on entry to the scope).

I'm still in the air on this issue.  The few strongly typed
language/systems I've used left me rather cold to the idea.  (I'm of
the "I know put four chars there, but give me them as an integer
dammit." school of programming myself :).

I've been trying to come up with a reasonable way to implement a
slightly 'stronger' typing for Forth (numbers, strings, lists,
objects, and error types, mostly castable to other types) without
completely breaking the language design.  The other thing I'm trying
to avoid is local variables.  Right now, it's on the stack, in an
attribute on an object in the database, or it doesn't exist.
Unfortunately I might have to back off on this, since local vars. are
incredibly convenient for a lot of tasks.

	-DaR
--
Dan Root - dar at thekeep.org