Compared to other
programming languages used today, MUSH code is a tremendous
step backwards:
- Everything is a function. There are no operators (+, -, *, /), only functions (add, sub, mul, div). Thus, 2+2 would be add(2,2).
- No variables. MUSHcode supports ten registers to store values in (helpfully labelled 0 through 9), but that's it. These registers are also global; there's no concept of a private value.
- No data types. Everything is a string, and any function will take any value. If the function doesn't like the value, it may return an error string, or it may return a default value, depending upon the implementation. As an example, add("two","two") may return 0, or it may return "#-1 NOT A NUMBER".
- Errors are returned as strings. The most common error in MUSHcode is to be missing one or more parenthesis or brackets. The parser will happily assume that some part of the code is meant to be taken as literal text, feed it to a function, and continue on its way. Thus, the missing parenthesis thirteen functions deep isn't reported to you as a syntax error; it just causes your code to behave in strange ways.
- Lack of whitespace. In most programming languages, it is considered good practice to have whitespace (in this case, blank lines) separate logical blocks of code. In MUSHcode, since everything has to be entered on one line, this is not possible. (Thanks, vilk)
- Limited comments. In most programming languages, you should comment frequently and extensively. MUSHcode suffers from two problems with this. First, you can only comment between commands (with the @@ command), not between functions...and since the great majority of MUSHcode is a single command, it renders that moot. Secondly, MUSHcode has a size restriction imposed on it; any one piece of code cannot be longer than 1024 characters by default, and comments are counted against this. (Thanks, vilk)
None of this is helped by the fact that MUSHcode is near impossible to read without special
formatting, and that it's only
debugging tool,
@trace, feeds you the results of each and every
function call -- which can get into the hundreds or thousands.
Despite this, MUSHcode is a good learning exercise, and a good first step towards
LISP. It forces you to program in a
functional (as opposed to
procedural) manner, to be careful about your spelling, to
double check your punctuation, and to think about your structure. MUSHcode lends itself to
modularity incredibly well (it almost requires it), so it also does a good job of forcing
object oriented practices.