[MUD-Dev] Language design

Jeff Kesselman jeffk at tenetwork.com
Mon Aug 25 15:39:41 CEST 1997


At 03:09 PM 8/25/97 PST8PDT, you wrote:
>I seem to remember that someone (Jeff Kesselman, I think) stated that when 
>designing a language, they always went via one of two routes:
>
>   1. The language is tightly-bound to the task at hand
>   2. The language is very generic in nature
>
>What are the (dis)advantages of each? I suspect that a non-generic 
>language would not be too extensible (and may cause problems if it went 

As a general rule this is ture, more or less.  I qualify because a while
back I did a multi-media authoring system with a non-generic language.  It
was nonetheless simply and  uniformly structured and there was a logical
place in the syntax tree for hanging new operations.  This DID still
require some new coding and modification of a YACC script but I purposely
designed it to be easy and more or less modular to do so.

>on to a public ftp-able release), what are your opinions on this? A 
>generic language with libraries for specific purposes seems better than 
>tying everything to the language itself, but this is pretty much 'the C/C++ 
>route'; I'm anxious to avoid making decisions solely on the basis of 
>"It's all I know."

Well I have a bias, but I think its a reasonable one.
When designing a "generic" (or probably more correctly termed "ful
lfeatured" or "complete") language, I go for simplicity and purity in the
core. 
I personally believe this tends to yield better working and faster
executing code.  My current little language Kelvin is probably the ultimate
expression of this as even the expression 2+2 ends up mapping to
int(2).plus(int(2))

This treatment of everything as an object and message ends  up yielding a
very simple core.  I then use standard library objects for all
fucntionality, even accessing the internals of the VM for stack trace and
such is done though an instance of the VMinterface class, which is
implemented a a piece of library code that calls into hooks in the VM itself.

In re application specific v. complete language... the biggest issue IMO is
the scope of the problems you are trying to solve, and the programming
skill of those who will be solving them.  Application specific languages
tend to be better for non programmers because the very high level concepts
they are dealing with are presented as part of the structure of the
language itself.  Complete languages win in flexability, which is
particularly important when your scope is not clearly and rigidly defined.

JK
Jeff Kesselman
Snr. Game Integration Engineer
TEN -- The Total Entertainment Network -- www.ten.net

-----BEGIN GEEK CODE BLOCK-----
     Version: 3.1
     GCS/CC/E/IT/MC d+(++)@ s: a C++++$ ULSC+++(++++)$ P++(+++)$ L++ 
     E--- W++$ N++$ o+ K--? w++(+++)$@>--- O+(++)>$ M+>$ !V PS++ PE+ 
     Y+ PGP- t+ 5+ X- R+(++)$>+++* tv+ b+>++ DI+++ !D G e++ h r+++ y+++
------END GEEK CODE BLOCK------ 

Speak Geek!
http://krypton.mankato.msus.edu/~hayden/geek.html



More information about the mud-dev-archive mailing list