[MUD-Dev] Mud Languages

[Chris Gray]

[Suggestion to most readers: skip this letter - I am answering Greg's
questions, but this is straying pretty close to the language wars that
our esteemed moderator has wisely forbidden.]

[Greg M:]
: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?

Sorry, I haven't actually used either of those. Read some on them, that's all.

: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?

One of the things that C does that is different from nearly all other
languages, including Pascal, is let you use something without having seen a
full declaration for it. This has been retained in ANSI-C, and lead to the
funny syntax for function prototypes (indirectly). C also has the feature
of allowing a reference to the name of an array to automatically mean the
address of the first element of that array. That's an example of a feature
that should never have been present (IMHO).

Those are examples of where C's typing can be thought of as being "weak",
but that kind of thing isn't what I consider to be the difference between
strong and weak typing. In weak typing, you don't have to declare your
variables - they take on a type at run time, based on what you assign
to them, or how you otherwise use them. See my ToyMUD system for an
example of how to do that. In a strongly typed language you have to
correctly declare all variables before using them, and once declared,
you have to always use them based on that declaration.

Many scripting languages are weakly typed, on the supposed theory that
it is more convenient to the user. Most normal compiled languages are
strongly typed, since that makes it possible to produce much more efficient
run-time code (no type checking at run time). My AmigaMUD system isn't
a true compiler, but it is strongly typed - I prefer strongly typed
languages, since they find many programmer errors at "compile" time,
rather than haphazardly at run time.

:> 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?

Well, my answers aren't going to make a lot of sense unless you know the
languages in question, but I'll give it a try, just to give you a feeling
for the kinds of things someone might not like.

    APL - write-only code. Fun to play around with, and has been used for
	some quite complex commercial systems, but I can't imagine stuff
	in it being long-term maintainable. Requires special keyboard and
	character set, or uses multi-character replacements for operators.
	Has *no* operator precedence - everything is evaluated right-to-
	left. Operators can be combined into more powerful operators. Has
	*no* keywords at all. Can do very complex and large things with
	an extremely small number of characters. Picking an example that
	I can sort of type in ASCII,

	    A <- B +.x C

	assigns the multidimensional matrix product of B and C to A.
	The operator "+.x" is composed from the '+' operator and the
	'x' operator to do this.

    AlgolW - designed by Niklaus Wirth before he did Pascal. I learned
	to program at university with this language. OK, but very
	limited. No pointer operator - "records" could be allocated and
	were pointers in truth, but the language only allows them as
	pointers - you can only use the equivalent of C's '->' on them.
	Somewhat wordy. No separate compilation. My memory is hazy!

    Algol68 - one of the few languages in the world that has actually
	been formally defined. Much more used in Europe than in North
	America. Quite powerful and uniform, but somewhat difficult to
	understand (IMHO), due to its automatic type conversions, which
	could do function calling, pointer dereferencing, normal
	conversions, etc., all without any source indications. A fairly
	steep learning curve, which I never really got over.

    Pascal - poor I/O system, not quite powerful enough to be a full
	systems language (to be expected, since Wirth designed it to be
	a teaching language only). No in-language separate compilation.
	Lots of 'begin' and 'end', like in AlgolW and Algol68.

    Lisp - you have to have the right kind of mind to like Lisp. I don't.
	I find the code unreadable, and needlessly constrained. I never
	have fully grokked some of the more powerful features. Their
	macro facility is neat, however. E.g. (approximate):

	    (defun newfunc lambda(x y)
	     (progn (print x) (print y)
	      (setq x (cons (cadr x) (cdr y)))))

    Basic - as I mentioned above, I prefer strongly typed, compiled
	languages. I've never used a newer BASIC, however, so my opinion
	here is very outdated. The language was designed to be interpreted,
	and I think it shows. It's not very well defined, and doesn't
	have the features needed for systems programming.

    Fortran - (FORmula TRANslator) - shows its great age. Original language
	had lots of bad features - automatic declarations, fixed format
	statements, no scope at all, no tokenization rules, hacks like
	EQUIVALENCE, no proper conditional statements, etc. etc. Newer
	versions like Fortran-77 are better. Even newer ones like Fortran
	90 are immense, bloated languages that no-one is going to use much.
	Original Fortran didn't even have subroutines - you had to use
	state variables and goto's, much like in some very early BASIC's.

    Forth - even foreigner than LISP. No checking of types, etc. at all.
	A neat toy, but I can't imagine using it for anything serious.
	Everything is reverse Polish (operator after both operands).
	No meaningful syntax to speak of. E.g. (approximate):
	
	    : newword dup @ dup * + ;

Puff! Pant!

Basic summary is that there is a lot out there other than C and C++, and
many of them have lots of neat features, and useful features. C became
popular because it really allowed low-level programming, but offered
significant improvements in programming ease and reliability over
assembler. It also was widely available, and initially, freely available.
No other language had those advantages. Unfortunately, C was created
and grown, not designed, so its full of warts, oddities, and misfeatures.

:Is it possible to say, in general terms, what makes a bad programming
:language? And what makes a good one?

No. It will vary too much from person to person. For every language out
there, there will be reasonable, intelligent people who think it is the
greatest language ever. And others who think it is silly and pointless.
It will also vary widely on the use to which the language is put.

:I know someone who is looking into dynamic linking of object files into a
:running executable. Has anyone here done anything like this?

Nope. Look into libdl - it is the most widely available, at least on
UNIX systems.

:What is it that you dislike about mainstream languages? Why?

C has too many misfeatures, mainly in its syntax, but some elsewhere. C++
has carried most of those over, and added a bunch more. I won't even
mention Cobol, and Fortran I covered above. Are there any other languages
that are today considered to be "mainstream"?

I think the main thing that bothers me about C++, is that it could have
been done so much better, but now the opportunity has been lost forever.

:> 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.

I'm not going to comment much here. But I think that thinking of those
as actual levels in a system is going to mislead you badly.

:Is anyone aware of any sort of comparison between languages, showing
:levels of suitability for various tasks?

It's not something I've tried to keep track of, but if you go to your
local university library and look through back issues of the ACM
SIGPLAN Notices (look for 20 feet of light blue covers), you will find
more stuff (some of very questionable merit!) on programming languages
than you ever wanted to see. :-/ There have been textbooks that compared
languages, but its been a while for me, so I don't know of the recent
ones. One used in my class was "A Comparative Study of Programming
Languages" by Bryan Higman. Published in 1967, it doesn't even mention
C, let alone C++. (Hey, you asked!)

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA