[MUD-Dev] Mud Languages

[Nathan Yospe]

On Thu, 7 Aug 1997, Chris Gray wrote:

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

AOL! AOL! (Sorry)

::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.

Pretty much. There are languages individuals prefer, of course. Me, I
actually like C++, provided I have my library of custom classes handy.

In any case... the question here is, what do you want to do with your
language? Does it only have to design objects and features for muds?
Particular styles of muds? Behavior of things in a mud? (A guy I knew,
Newt, aka Markku Nylander, wrote a very advanced version of mobprogs, a
language used by some diku derivatives to control mob behavior.
Interpreted, of course.) Do you want to have to use the language for
writing the low level functions of the mud? Do you want to be able to use
it that way? Is speed a major issue? Are you using a database server?

::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.

There are features, there are styles... some languages are better for
specific tasks. My own internal language is so-so for most things, useless
for many... it has only single inheritance, because it uses hardcoded
objects as bases... I stole Java's interfaces, and null references. I
don't allow access to the processor, of course. Objects are incapable of
compiling if they violate the physical model, behaviors are limited to
systematic modifications (it is possible to add two massive objects and
construct a new object with compound mass, but there is no way to "create"
mass in the internal language, save the instantiation system, which
actually logs usage of the components... remember that bit about unique
weapons made of material X? Trivially easy for me.), and have access to a
library of advanced physical transforms. It also has the advantage of a
MATLAB+ level approach to tensor algebra. I did not, on the other hand,
bother with most of the things people DO do for most mud languages. String
is an unmodifiable class. The language parser is hardcoded, as are many
other "high level" features... most of them things I consider "static" in
the normal runtime of a mud. I follow the "World changes, but the skeleton
better be done" school. I think most of the significant features of a mud,
the global features, should never be changed trivially. I consider the
need for a recompile and relaunch after changing, say, the combat system
to be a good thing(tm).

: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.

I've never counted the languages I know. Dozens, certainly. But as far as
that goes, well... I think anything I need that I've known from another
language, I've been able to simplify to a class, black box form, in C++.
Works well enough for me. (I do sometimes wish I could use nonstandard
operators in operator overloading... I would appreciate a power symbol.)

::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.

As far as that goes, there is no such thing as a natural language for a
new programmer, nor an experienced programmer who is not, to some degree,
biased by their previoused languages.

: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.

Java is fairly simple, but has some real problems with regard to
implementation. The socket and thread code, for example, are major
endeavors. I recommend a language that uses familiar syntax, to some
degree, but only where function is identical. The use of a familiar
keyword for slightly different behavior is damned confusing. Also, don't
pull stunts like the addition sign in a string in Java. Its annoying, to
say the least, to have operator overloading in a single special case, and
not anywhere else in the language.

: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.

True... personal preference has always been a factor in language design.
My use of a stylisticly unique syntax is reflective of this. (I reserve
the '|' key, for example, for text operators, which can be created. I may
scrap this, eventually... its been a bitch to implement... eg: |pow| is a
power operator (not true, as '**' got that designation), |eq| could be a
comparison operator...

::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)?

Not all Tinymud derivatives really do this, though most seem to have a
fixed room concept, and a bit of a crude one at that.

: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:

Its a relative thing. Not like I'm programming a diku here...

:    - 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.

True. Of course, an intermediate solution can handle quick changes (though
not fixes... but that's analogous to fixing the database server... not
possible there, either) pretty well too.

:    - 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.

My intermediate solution makes this even worse... ah, well, can't win them
all.

:    - 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.

Or you can ultimately commit code that is ready for permanency to an
internal-to-native translater. This, of course, has the effect of making
it impossible to change the commited code... 

:    - 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.

The first is possible with a hybrid. The latter (replacing existing code)
is generally impossible...

:    - 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.

The in-MUD language in a hybrid also has the advantage of providing a
layer of concealment for the guts of the engine. This allows a simplified
concept of the mud's operation to suffice for extending it.

:    - 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.

This is more a result of using a database style server/driver/engine. It
does, for me, provide some degree of difficulty. I'm still playing with
it.

::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.)

While I don't want to get into the religious wars (I am a C++ user) I will
say this: Don't, whatever you do, try to implement even a subset of C++
yourself. Its not worth the stress.

::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".

Neither do I. Care to clarify?

--

"You? We can't take you," said the Dean, glaring at the Librarian.
"You don't know a thing about guerilla warfare." - Reaper Man,
Nathan F. Yospe  Registered Looney                   by Terry Pratchett
yospe at hawaii.edu   http://www2.hawaii.edu/~yospe           Meow