INTRO:
http://en.wikipedia.org/wiki/MUD
"In computer gaming, a MUD (Multi-User Dungeon, Domain or Dimension) is
a multi-player computer game that combines elements of role-playing
games, hack and slash style computer games and social chat rooms.
Typically running on an Internet server or bulletin board system, the
game is usually text-driven, where players read descriptions of rooms,
objects, events, other characters, and computer-controlled creatures or
non-player characters (NPCs) in a virtual world. Players usually
interact with each other and the surroundings by typing commands that
resemble a natural language, usually English. ....
In 1989, TinyMUD began to allow players to easily participate in
creating the online environment, as well as playing in it. The TinyMUD
code spawned a number of descendants, including TinyMUCK and TinyMUSH,
which added more sophisticated programmability. (TinyMUCK versions 2 and
higher contain a full programming language named MUF, or Multi-User
Forth...."
http://linnaean.org/~lpb/muddex/tinymuck.txt
An inventor reminiscing:
"I was a college sophomore, knew next to
nothing about parsers, compilers, or interpreters other than that
magical
introductory class "Structure and Interpretation of Computer Programs",
and
decided it was time I bit off more than I could chew. ....
I picked a language that was easy to parse and write a compiler to:
"forth". I then mutated it beyond recognition, and wrote a compiler for
it,
then a stack-based interpreter. Everything was done op****tunistically,
for
instance, other objects could be called because it was convenient to
code
that into the interpreter. The security system was a mess until Jon
Blow of
Berkeley wrote down the rules and I coded them. Jon also helped by
developing a macro system for MUF (MUCK Forth). ....
It was also beginning
to gain attention because of one im****tant thing: it was backwards
compatible and painless to switch to MUCK from an already preexisting
TinyMUD or TinyMUCK. That probably had more to do with TinyMUCK's
popularity than the programmnig language, the stability of it, or the
popularity of Atlantis."
WHAT HAPPENED?
http://everything2.com/title/TinyMUCK
"TinyMUCK
A multiplayer MUD-like networked game that came about in the early
nineties. It is more socially oriented than most MUDs, and has a
programming language called MUF that drives all but the most patient
people insane.
Derivatives of TinyMUCK, including FuzzBall, GlowMUCK, and NeonMUCK have
also appeared on the scene. They have various enhancements, such as the
LISPlike MPI language."
MUF got the reputation for being Forth, and was widely despised. Kind of
like "I say it's spinach and I say the hell with it."
http://www.mud.co.uk/richard/imucg5.htm
From a 1999 review:
"The big difference between TinyMUCK and TinyMUD is programmability.
TinyMUD provides users with very basic creation facilities, but TinyMUCK
has its own interpreted programming language, TinyMUF ("Multi-User
Forth"). This is flexible and powerful, but has a reputation of being
difficult to use.
TinyMUF (or just MUF) is basically the same as Forth, with a few new
library routines. .... MUF has a limited "if-then" construct, but no
"if-then-else". ....
To make programming easier, there is an on-line, line-oriented editor
built in. Source code is stored, which means tried-and-tested creations
can be moved easily to other TinyMUCKs. MUF programs tend to be longer
than in most MUAs - a simple slot machine (gambling pennies) is, for
example, around 150 lines long. TinyMUCK can read TinyMUD databases, but
not vice-versa.
TinyMUCK comes with plenty of do***entation, and compared to other
building-oriented MUAs on InterNet looks rather attractive. It works,
and it can perform many powerful tricks. Its problem is that the people
doing the building have little experience of a thorough, well-written
MUA ...."
http://en.wikipedia.org/wiki/MUF_(programming_language)
Basic description of Forth, essentially no mention of MUF specifics.
"Limitations
* The MUF editor is quite primitive and resembles a
feature-deficient version of Unix's ED editor. Most MUF programmers
write their code in a text editor on their local machine, and upload the
code to the server.
* It is quite easy to write entirely unreadable code in MUF.
* MUF's implementation of variable scoping is rudimentary at best.
In addition, MUF includes no mechanism for examining data type at
compile time though it may be examined at run time and easily typecast
as needed. Given the design of the language that allows a function to
legitimately accept many different types of arguments, compile-time
typing would be difficult to implement and the usefulness is
questionable.
Despite these limitations, MUF has proven to be a very successful and
appropriate tool for its intended purposes."
Still, very quickly they came up with MPI, an alternative language that
fit people's preconceptions better. It ran slower.
http://schnee.livejournal.com/384981.html
People reminiscing about MUCKs:
"And of course, MUF sucks. It may be nice from the server coder's POV,
since Forth variants are easy to implement (and, for that matter,
implement correctly), but... well, it just isn't great when you want to
do stuff. MPI is nicer, of course, but not really well-suited for larger
things, so at a certain point, you pretty much will have to use MUF."
"I like MUF. c.c Coded quite a few things in it. I find it easier than
MPI, too."
"And MUF... no. It probably was OK back when when TinyMUCK (or whatever
it was originally based on, if anything) was originally written, but
nowadays, it's an anachronism of the worst kind, especially since
there's so many alternatives."
http://w2.eff.org/Censor****p/Academic_edu/CAF/batch/?f=1991_12_15.txt
1991 discussion:
"MOO: A C-like object-oriented language based on the concept of
verbs attached to objects. The language is highly integrated into
the structure of the server, which is essentially just an
interpreter, and is perhaps the most advanced and elegant designs
among modern MUDs.
MUF (for TinyMuck): A stack-based Forth language with no backwards
jumps; all looping is done with recursion. It's interesting to
develop theory about how to do large loops, since there is an
imposing 512-object data stack and call stack ceiling. (Writing
programs to handle lots of iterations isn't difficult, but it
requires a bit of thought.) I learned a lot about stack handling
using this language. MUF is unstructured and difficult to read,
and is grafted onto the server rather than integrated into it (it
plays the role of a complicated command language), but it's an
interesting study. It's probably the most commonly-used MUD
language today for Tiny-derived MUDs"
One of a list of 5 or so languages. C-like OO languages mostly.
"> Yes, you can learn a lot from MUF, such as basic coding, a stack
based
> language, and if you're hot recursion, and other neat stuff. But it
> sounds like what you are saying is that muf programmers are real hot
> shots. Most aren't. And the examples you give aren't that advanced.
I agree, most MUF programmers aren't that hot ... but how many
professional
programmers have ever been happy with FORTH ? All you ever get from
computer
scientists is funny looks and questions about how it compares to C on
speed. To
be honest, I don't think very many programmers at all are hot, and I
include
myself. The point is, anyone can say 'sure, that's easy' when they've
been
doing it for a while, but most of the people who write MUF code are
unlikely to
have come in contact with FORTH before, and it can be a right pain
trying to
write large programs in a stack-based language for the first time -
heck, at
any time !
As the message was addressed to non-MUDers, think of what most of them
were
thinking at the mention of approaching a multi-user task ... then image
that
person wasn't into programming at all. If you can honestly say it
wouldn't
daunt you if you were in their shoes, then you must have been born to
hack ...
no doubt about it !"
http://www.cyberconf.org/~cynbe/muq/mufhack_15.html
As usual with Forth, somebody decides that MUF should be rewritten
correctly.
"Some reasons I stuck with RPN notation for Muq's first programming
syntax:
* A surprising number of my tinyMuck hacker friends re****ted that
they actually liked tinyMuck MUF. To my surprise! (Before I surveyed
them, I'd figured they all used it under protest.)
* Forth was developed for interactive at-the-keyboard hacking -- I
can't think offhand of any other major language that was so designed.
(Excepting tcsh & kith!) There is room for a syntax which works well in
realtime mode.
* I've never seen anyone seriously try to drag a Forthlike language
into the modern programming era: I found it fascinating to explore how
much it could be improved with modern facilities without losing its
essential character.
* I've always been distressed by how very bad tinyMuck MUF was -- in
many ways it combines the worst aspects of the Algolic tradition (for
example, explicit compile-edit-debug cycles, black-box compilers) with
the worst aspects of the Forth tradition (for example, unreadable code,
obscure bugs). That the original author of tinyMuck MUF was completely
ignorant of Forth, compilers and interpreters is an explanation but not
a justification... Why not a MUF that combined the best of those
traditions?
.....
In the Muq manual set, 'MUF' when not otherwise qualified should always
be understood as referring to Muq MUF, not tinyMuck MUF.
MUF attempts to maximize the traditional strengths of Forth family
languages, such a simple, transparent, highly customizable compilers,
while fixing many of its traditional weaknesses, such as lack of local
variables and frequent use of the RESET button during debugging.
MUF has somewhat C-style control structures, C-style printf formatting,
modern datastructures including Lisp-style lists and objects with
multiple inheritance, internal pre-emptive multitasking, a limited infix
path notation that overcomes some of the worst verbosity problems of
traditional Forths, and a sophisticated exception handling facility.
Among many other things!
MUF is particularly appropriate for interactive throwaway hacking, since
it is concise, evaluates expressions right-to-left exactly in the order
you type them, and publishes intermediate states visibly on the stack as
you go.
MUF is less appropriate (but usable) for programming of large projects.
It is less readable than C-style infix notation for such archival code,
and the lack of strong type checking means you wind up having to hunt
down at runtime bugs which a language like Java would have re****ted at
compiletime."
CONCLUSIONS:
A Forth compiler apparently written by somebody who didn't know much
about Forth or about compilers, for a special purpose that fit Forth
very very well.
Complaints that the code was unreadable, by people who didn't like it
and didn't want to learn to read it.
Alternatives with all the latest bells and whistles.
Many users liked it although experts thought they shouldn't.
Now increasingly losing ground to competing OO C-like languages. MUDs
are not that popular now anyway.
No particular studies done about whether users (who often have no CS
experience) can code better with C-style control structures, printf,
multiple inheritance and general OO etc. People who design systems just
know that modern techniques are better.
EXTRA CONCLUSION: There are an unknown but probably large number of
people who have been exposed to Forth from MUDs, who could probably do
some Forth programming if they had any reason to.
|
