[MUD-Dev] Mud Languages
greg at uni-corn.demon.co.uk
Fri Aug 8 20:12:51 New Zealand Standard Time 1997
On Thu, 7 Aug 1997, Chris Gray wrote:
> 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.
What I am specifically after are good and bad features of languages. I am
only really aware of 'generic' languages such as C++, not languages
geared towards a specific purpose. Examples of certain language features,
and why they are a part of that language, are what I am after, really.
Is anyone familiar with OOPLs such as Eiffel or Smalltalk? Are there any
features that they have, that would be particularly useful to programming
a mud, specifically?
One of my contributors mentioned how much they liked the 'scoping' of
Pascal a week or two ago. Things like strongly typed, weakly typed - what
does this actually *mean*? Is it simply that the types of function params
are specified in advance? Or am I thinking along the wrong lines? Or is
it that there is a bit more to it than I am aware of?
Are there any specific things that I should be aware of, when designing a
language? (I am not interested in implementation issues atm.)
> 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.
Of these languages, which features do you like? Which don't you like? Why?
Is it possible to say, in general terms, what makes a bad programming
language? And what makes a good one?
I know someone who is looking into dynamic linking of object files into a
running executable. Has anyone here done anything like this?
> 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 is it that you dislike about mainstream languages? Why?
> :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".
Maybe I used incorrect terminology.
5 [ PROBLEM-ORIENTATED LANGUAGE LEVEL ]
4 [ ASSEMBLY LANGUAGE LEVEL ]
3 [ OPERATING SYSTEM MACHINE LEVEL ]
2 [ CONVENTIONAL MACHINE LEVEL ]
1 [ MICROPROGRAMMING LEVEL ]
0 [ DIGITAL LOGIC LEVEL ]
These are the 6 layers to which I was referring. To move from one level
to another, compilation/interpretation is required. Adding another level
on top is what I *think* something like LPC does. Maybe, maybe not.
Is anyone aware of any sort of comparison between languages, showing
levels of suitability for various tasks?
"Scratch muds can only ever be leaves of The Mud Tree."
Discuss, using obscure references.
More information about the MUD-Dev