[MUD-Dev] Mud Languages

[Chris Gray]

[Of course I'm going to reply to this thread! :-)]

:I'm thinking that designing a language blindly would be a Bad Thing.
:Since subscribers to this list would probably have wide-reaching
:experiences in many languages, I'd be interested in, say, a list of the
:top five best and worst features of a language (features specific to a 
:certain language, in addition to generic attributes).

Some traditional languages have been specifically designed, mostly in
the Algol/Pascal/Ada line. Others have "grown", such as the C/C++ line.
Most research languages have also been more design than evolution. Both
approaches have good and bad points. Designed languages can often show
the bias of their designers (whether an individual or a committee).
Grown languages often end up with misfeatures and too many ways to do
the same thing. It is interesting that the languages that have made it
to the "mainstream" have mostly been "grown" languages: Cobol, Fortran,
C, C++. I'll guess and say that this is because most programmers don't
care what the language they use is like - they just want something that
lets them do what they want to do, and is widely available.

:Most contributors to my project have not much more experience than C/C++,
:Pascal, et al. I'm more interested in features of 'older' languages,
:those that are now seldom used (principally because although the language
:may be old and no-longer used, this does not mean that it is bad, or that
:certain of its features are bad - for example, I believe that C++ took 
:features from C, BCPL and Algol...), mainly because those features *may*
:be less familiar and/or forgotten.

I've used quite a few (as, I suspect, have a few of the other older
members of this list), including APL, AlgolW, Algol68, Pascal, Lisp,
Basic, Fortran, Forth, several assemblers, and a few languages of my
own design. Designing a language of your own is a great liberator, in
a way - it lets you see what is wrong with existing languages, and
makes you think about how to fix those problems.

:Contributors are mainly going for either the LPC approach (code something
:close to what we understand (i.e. C), but with some enhancements), or the
:Java approach (code something close to what we understand (i.e. C),
:removing some of (what we consider to be) its bad points, such as
:pointers). There seems to be no 'design the language for its intended
:users/function/application', which is something I feel that needs to be
:part of the equation, somewhat.

Its a difficult, but very important, decision. First we have to clarify
things a bit, however. You started talking about a MUD language that would
be provided by your server, and used to implement some portion of your
MUD scenario. Now you have brought up existing languages like C and
Java. If you are going to implement a language, you do not want to say
that you are going to implement, say, C - it is far too much work to do
that as part of a MUD system. You can choose to implement a small C-like
language, which perhaps uses the standard C pre-processor, but you don't
want to make any committment to the full language. C++ in particular is
an immense amount of work to implement the full thing. It may be possible
to use Java from inside another program system, much like Tcl is used,
but I'm not knowledgeable enough to answer that question. If it can be
done, it makes a good option.

If the language you create/use is familiar to a lot of your workers, then
it is easier to get them to work in it, since there is less learning
curve, and there is the "instant gratification" that can be so important
in getting people motivated. I essentially did that with my system, but
since I knew that I was going to be the only user for a while, I chose
to make my language like other languages I had designed, and not like
any mainstream languages. My dislike for many mainstream languages, and
the simplicity of parsing my own languages influenced this a lot, too.

:What are the tradeoffs involved between implementing the entire mud in a
:custom-designed language (a la LP/Cold), or only implementing part of it
:in that language (cf Tiny et al, I guess)?

I'd guess that Nathan would have some good input here, since his system
is much nearer the "completely in traditional language" end of the scale
than many of the others. Here are some factors I can think of:

    - if you have your own in-MUD language, you can make it not require
	traditional recompilation, so quick changes and fixes can be
	done without recompiling the whole scenario, and likely without
	even bringing the server down.

    - if you have no in-MUD language, you only have one language to deal
	with, and won't suffer from problems as you rapidly switch
	between the two - perhaps even on the scale of having bits of
	each in different editor buffers in the same editor session.

    - traditional languages fully compile to machine code, which runs
	at machine code speeds. An in-MUD language will typically be
	interpreted or use threaded code or bytecode, and thus will be
	quite a bit slower - likely 10 times slower or more. This can
	make a difference. You can lessen the impact of this by
	providing general utility routines in the server framework, so
	that code in the MUD language can call out to get compiled
	performance on those common jobs.

    - if you have an in-MUD language, you can provide facilities where
	running code can create new code, or replace existing code, while
	the server is actively running. This provides capabilities that
	are difficult or messy to obtain with straight compiled code.

    - and, as you mentioned at the beginning, if you have an in-MUD
	language you can modify it so that it has features that are
	very useful in MUDs, but are not present, or are present in
	different ways, in the mainstream compiled language. For example,
	you will almost certainly want a true "string" type, but will
	not want any true pointer types. Another useful type is the
	associative array.

    - with an in-MUD language, it may be easier to have everything stored
	in an on-disk database. The conversion of in-memory structures to
	on-disk structures can be done by the language core and support
	code, rather than having to be done explicitly. For example, if
	your objects are all persistent, then simply assigning to an
	attribute is enough to persistently change that attribute so that
	it is changed across reboots - you don't have to setup any code
	to explicitly save the object or its attributes.

:Is C++ actually a worthwhile language to implement a mud in? I'd be
:interested in anyone trying to write a mud in standard language other
:than C/C++ or Java. Also, in people's experiences with full-on OOPLs - 
:could a custom-designed language similar to, say, Eiffel, be used to
:effectively implement a mud?

Personally, I don't think C++ is a worthwhile language to write anything
in, but that's diving deeply into the "religious wars" you mentioned. My
MUD is written in a language called "Draco", which is one I designed for
CP/M and later ported to the Amiga. That choice was an obvious one at
the time, since I was only planning on spending a month or two on a quick
MUD system as a fun project. Six years later, the choice wasn't so good,
since now I'll have to translate to C in order to port to other systems.
(Which isn't really hard, since the semantics of the two languages are
fairly similar.)

:The model I am thinking of is an extra layer added onto the standard 6-layer
:VM. This would involve a driver/lib combination like LP/Cold, yes?

Sorry, I don't grok a "standard 6-layer VM".

:Note: when I joined this list at the back end of March, it had a dying 
:thread called 'MUD Languages'. Would that be of interest to me, do
:you think? If so, is it in any way possible to get a copy of just that 
:particular thread?

It probably would - there were some examples of various languages used
by folks in the list, as well as a fair amount of discussion. Some got
a bit religious, however. I believe Chris L has recently said that he
can't readily extract threads from the archives, however.

:Another note: I seem to remember quite a long 'Languages' thread around
:April/May too. I also remember it caused a number of religious "My 
:language is better than your language" battles. I hope this post doesn't 
:start them up again :) (Particularly considering that any potential replies
:will me mainly subjective...)

There have been threads about spoken languages within game contexts - those
aren't likely of interest here.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA