<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] Mud Languages -->
<!--X-From-R13: ptNnzv-pt.UenlEntr.Sqzbagba.OP.QO (Quevf Uenl) -->
<!--X-Date: Thu, 07 Aug 1997 17:19:40 +0000 -->
<!--X-Message-Id: 9708071550.8at7@ami-cg.GraySage.Edmonton.AB.CA -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] Mud Languages</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00423.html">Previous</a>
| <a href="msg00425.html">Next</a>
]
Thread:
[ <a href="msg00527.html">Previous</a>
| <a href="msg00427.html">Next</a>
]
Index:
[ <A HREF="author.html#00424">Author</A>
| <A HREF="#00424">Date</A>
| <A HREF="thread.html#00424">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] Mud Languages</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] Mud Languages</LI>
<LI><em>From</em>: <A HREF="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</A> (Chris Gray)</LI>
<LI><em>Date</em>: Thu, 7 Aug 97 08:50:28 MST</LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
[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#ami-cg,GraySage.Edmonton.AB.CA
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00433" HREF="msg00433.html">Re: [MUD-Dev] Mud Languages</A></strong>
<ul compact><li><em>From:</em> Greg Munt <greg#uni-corn,demon.co.uk></li></ul>
<li><strong><A NAME="00427" HREF="msg00427.html">Re: [MUD-Dev] Mud Languages</A></strong>
<ul compact><li><em>From:</em> Nathan Yospe <yospe#hawaii,edu></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00423.html">Re: [MUD-Dev] Spellcaster, or Waving Hands</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00425.html">Re: [MUD-Dev] Graphic MUDS/Ultima Online</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00527.html">Re: [MUD-Dev] Introduction</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00427.html">Re: [MUD-Dev] Mud Languages</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00424"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00424"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] Re: Mud Languages (Introesque)</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<LI><strong><A NAME="00440" HREF="msg00440.html">Re: [MUD-Dev] Re: Mud Languages (Introesque)</A></strong>,
Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Sat 09 Aug 1997, 01:35 GMT
</LI>
</ul>
</ul>
</LI>
<LI><strong><A NAME="00426" HREF="msg00426.html">Introduction</A></strong>,
Dan Armstrong <a href="mailto:orion#pixi,com">orion#pixi,com</a>, Fri 08 Aug 1997, 02:43 GMT
<UL>
<LI><strong><A NAME="00429" HREF="msg00429.html">Re: [MUD-Dev] Quad-trees/Oct-trees</A></strong>,
Michael Hohensee <a href="mailto:michael#sparta,mainstream.net">michael#sparta,mainstream.net</a>, Fri 08 Aug 1997, 14:41 GMT
</LI>
<LI><strong><A NAME="00527" HREF="msg00527.html">Re: [MUD-Dev] Introduction</A></strong>,
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Thu 14 Aug 1997, 00:00 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00424" HREF="msg00424.html">Re: [MUD-Dev] Mud Languages</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Thu 07 Aug 1997, 17:19 GMT
<UL>
<LI><strong><A NAME="00427" HREF="msg00427.html">Re: [MUD-Dev] Mud Languages</A></strong>,
Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Fri 08 Aug 1997, 04:24 GMT
</LI>
<LI><strong><A NAME="00433" HREF="msg00433.html">Re: [MUD-Dev] Mud Languages</A></strong>,
Greg Munt <a href="mailto:greg#uni-corn,demon.co.uk">greg#uni-corn,demon.co.uk</a>, Fri 08 Aug 1997, 19:18 GMT
<UL>
<LI><strong><A NAME="00436" HREF="msg00436.html">Re: [MUD-Dev] Mud Languages</A></strong>,
Captain Burrito <a href="mailto:burrito#darklock,com">burrito#darklock,com</a>, Sat 09 Aug 1997, 01:02 GMT
</LI>
<LI><strong><A NAME="00441" HREF="msg00441.html">Re: [MUD-Dev] Mud Languages</A></strong>,
Miroslav Silovic <a href="mailto:silovic#petra,zesoi.fer.hr">silovic#petra,zesoi.fer.hr</a>, Sat 09 Aug 1997, 02:58 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>