[MUD-Dev] Mud Languages

[Greg Munt]

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.