DM Compared to Other Languages

DM, like many modern programming languages, is an evolved form of C. Additional derivatives include C++, Java, Awk, and a host of others. Since these all share a common ancestor, they have many similarities in structure and syntax. A programmer familiar with one of them can adapt to the others with little difficulty.

Beginners often ask questions like which of two languages is more powerful. However, that is not really the right question. Programming languages evolve to fit a niche just like biological organisms specialize and adapt to their environment. To ask whether a hawk or a bear is better adapted to survival is in many ways nonsensical. The right question is: which one is better suited for a given task or situation? The same is true of programming languages.

Byte Code

Suitability of a programming language depends on a number of factors. At the lowest level is efficiency of the byte code in terms of system resources: CPU time, memory, network bandwidth, and so on. Languages like C and C++ will generally produce more efficient byte code because they generate machine code which is directly executed by the CPU. DM, like Java, produces virtual byte code. Instead of being directly executed by the hardware CPU, it is handled by a software emulated CPU, also known as a virtual machine. In this case, the virtual machine is the server.

The extra overhead of running a virtual processor makes each byte code instruction take a little longer than if it were directly executed by the hardware. The advantage, on the other hand, is that the same byte code can be run on any computer, because differences in the hardware (and almost all differences in operating system too) do not matter.

Another advantage of virtual byte code is security. The virtual machine has complete control over any action taken by the program. It would be very difficult, for example, for a mistake in a DM program to do any lasting harm. And if one is worried about intentional damage being done by some malicious programmer, the server can be put in safe mode to disable any potentially dangerous features altogether.

Related to security is stability. When something goes wrong in a machine code program, chances are the whole thing will crash. A DM program, on the other hand, will normally only crash the procedure in which the fault took place. The rest of the program will continue to run without interruption.

Finally, while it is true that each virtual instruction requires additional CPU overhead, that is not the full story, because the instruction sets may be entirely different. For example, DM has some byte code instructions tailored specifically to the types of things that DM programs tend to do (like computing a list of visible objects). That is a very high-level operation which would correspond to thousands of machine code instructions. The extra overhead of a virtual machine in cases like that is entirely negligible. In fact, it may even be faster in practice, because the algorithms employed by the server have been highly optimized.

Source Code

As modern computers become increasingly powerful, efficiency of the byte code has become less and less of an issue. Of greater importance is efficiency of the source code. In other words: how much work must the programmer do to accomplish a given task? This is where the real difference between programming languages is apparent.

C and C++ are general purpose low-level languages, and can therefore be used to do almost anything from writing operating systems and compilers to web browsers and word processors. However, this high degree of manual control and lack of specialty comes at a price. Compared to a language specifically tailored for a purpose or one that has a higher level of automation, it is usually more work to accomplish the same thing in C or C++. The programmer often has to attend to many extra details rather than focusing on issues directly related to the task at hand. Occasionally it is fun to be totally in charge. Sometimes it is downright annoying.

The principal aspect of DM that makes it a specialized language is the networked user interface. DM programs (also known as worlds) are automatically designed to be accessed simultaneously by multiple people over a network. The addition of a single-user mode was an afterthought (though it has some potentially interesting uses).

Since DM is essentially a language for writing networked multi-user programs, it provides many convenient and powerful features for this purpose. The ease with which realtime and other sleeping operations can be mixed in the code is one example. In most other languages, such situations would have to be handled with "call-back" routines, which chop the source code up and otherwise interfere with the programmer's ability to structure it.

The player key system is another convenient component of the network interface. It provides a uniform and secure login identity for players, allowing for continuity between worlds. This opens the door for linking worlds together over the network--nicely side-stepping the traditional single-server bottleneck.

Another essential component of networked software is a client--the user interface. As part of the BYOND package, DM programs come with a ready-made, yet adaptable, client. The advantage of this cannot be overstressed. The user need only install one client to access any DM program. All special resources needed for a particular world (like graphics or sounds) are automatically transferred to the client (and efficiently cached) without any pre-configuration or installation by the user.

The client also provides many built-in interface components commonly needed to interact with DM programs, such as an intelligent command line, graphical menus, formatted terminal output, and sound control. By making the user interface somewhat standardized, players are provided with a familiar environment, and the programmer is freed from designing one from scratch every time.

Another very specialized feature of the DM language is the world map. The map editor is a highly integrated tool, allowing easy access to and adaptation of source code objects. The network algorithms are also fully optimized to transmit the user's view of the map as efficiently as possible--all without any effort from the designer. No other graphical world building software exists having such a full-featured language closely integrated with a powerful point-and-click map editor. It is the jewel of the BYOND system.


Another point of comparison between programming languages often goes unmentioned, but is perhaps just as important as any other. It is elegance. There are ugly languages and there are neat and tidy ones. Of course such judgments have an element of subjectivity, but often esthetic considerations have a deeper practical root.

Like many of the modern derivatives of C, DM treats the newline as a semicolon rather than as a space. While this may seem like a superficial difference, it is not. Almost every statement in a well-formatted program is on a line by itself. The eye of the programmer therefore sees the end of line as the end of a statement--even though in C and C++ it is actually the semicolon which serves this purpose. When the eye of the programmer and the eye of the compiler are looking at things differently, needless confusion is the likely result. Besides, the semicolon is ugly.

DM takes the principle one step further by equating indentation of a block of code with braces around the block. By convention, all C programmers format code by indenting each block. They do this in order to easily see where the braces start and end. But who needs the braces then? It is not only simpler but safer if the compiler looks at the code the same way the programmer does: by paying attention to indentation.

( It is also interesting that the brace-less code style eliminates one of the long-standing sources of division in the programming community. The two sides of the debate are known as Danism and Tomism. The Danists put their left brace at the end of a line of text. The Tomists put their left brace on the next line all by itself. I could tell you which method is correct, but this would involve a lengthy theological discussion that would be mostly unintelligible to the neophyte. As it often turns out, however, the argument is entirely unnecessary. If you have not been indoctrinated into the Danist or Tomist cult, I suggest adopting the nudist style and avoiding the whole left brace issue. Do it for lasting peace and love among programmers... )

Another unique feature of DM syntax is a hierarchical object tree, using the path as a familiar and flexible notation for naming and navigating between nodes in the tree. The programmer can use paths to independently position source code in the tree and in the source files, providing both logical and organizational structure.

DM is also consistent in allowing variables to be initialized when they are defined. It works at any level--global, procedure, and object variables may be initialized. C and C++ do not allow initialization of object variables in the definition but require it to be done in a separate procedure, which can be a bit of a nuisance when changing the object definition.

Formatted text output containing variable expressions is an important part of any language. There are two common approaches in use--the C method and the C++ method. The first inserts special markers in the text to be replaced by expressions which follow as separate arguments. The latter method introduces a special operator which can be used to effectively add together text strings and other expressions. The advantage of the C method is the main text string doesn't get messed up by complicated expressions and extra operators; the advantage of the C++ method is you can read the whole conglomeration from left to right.

DM supports both methods in a nice compact notation. When the expressions to be inserted are simple they can be directly embedded; otherwise they may trail behind.

Text Expressions in C, C++, Java, and DM
C printf("%f is the mean of %f and %f.\n",(x+y)/2,x,y);
C++ cout << (x+y)/2 << " is the mean of " << x << " and " << y << ".\n";
Java System.out.println((x+y)/2 + " is the mean of " + x + " and " + y + ".")
DM world << "[(x+y)/2] is the mean of [x] and [y]."

Since text is such a basic element of most programs, it is worth noting that DM, like Java, automatically handles memory allocation and deallocation (also known as garbage collection) for text strings, as well as any other value. C and C++ leave it up to the programmer, which can become a tedious chore at times. For instance, in the previous example, the final text string to be displayed could instead be used as a value in DM (and stored in a variable or something). In both C and C++ this would require (among other things) allocating memory for a new text string and then remembering to deallocate it later when finished. (Being a primitivist, I personally consider life without garbage collection fun. It also happens to be ugly--an unfortunate combination.)

The Universe BYOND

Finally there is the issue of fellowship. Creating a world is an inherently social undertaking. It is not shaped in a vacuum by the designer but continues to evolve for the very reason that players become a part of it and participate in making it a reality.

Not only that, but designers, though elusive and antisocial by nature, stand to gain a great deal by bumping into each other and exchanging the occasional magic lantern for an incantation or two. That is a "feature" the DM language has to offer in abundance--a community rich in talent, imagination, and diverse interests.

This is something for which the authors of BYOND can claim little credit, nor would they wish to, preferring as a rule to operate in remote secluded regions of cyberspace. The BYOND community is very much its own creature, inhabiting a universe of its own making. Perhaps Dantom, stumbling upon the initial seed, provided a drop of water and a warm patch of ground. But having taken root, the sapling grows to its own design. The story shifts now to new characters, and creation continues...