[MUD-Dev] Language design
cg at ami-cg.GraySage.Edmonton.AB.CA
Mon Aug 25 22:47:47 New Zealand Standard Time 1997
: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
: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."
I have a hard time thinking of any disadvantages of using a more general
purpose language, combined with a number of built-in functions to
efficiently support the things that are used a lot by the expected code.
I don't think its any harder to make a general language - in fact it is
probably easier than having to add in a bunch of extra constructs for
the special stuff you want. It might be a slight bit less "convenient"
for users, if they have to use function call syntax instead of some
custom syntax, but its probably a lot easier to remember and get right!
I also don't think it is less efficient to use a general language. There
is more lost to things like unneccessary run-time checks than I can
imagine being gained by restricting the language in some way. The basic
implementation technique is far more important for speed concerns.
So, the only constructs I put in my language, other than fairly vanilla
generic stuff are things like the '@' operator to access attributes
on objects, and using subscripting to access list elements. Oh, and
the '--' operator for deleting attributes from objects (its all dynamic
in my system).
Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
More information about the MUD-Dev