LPMOO was originally motivated by the observation that MOO is extremely successful at what it does, yet is still limited by the idiosyncrasies and constraints of the MOO server. Although the MOO environment is useful, many assumptions are made by the server, and a particular structure for interaction is forced (from "wizard" bits to command parsing.)

DGD was designed from the start to make as few assumptions as possible. The traditional design for an LPmud-derived server involves having programmers write their code in LPC and manipulate objects in an on-line filesystem. However, nothing forces this particular structure. LPMOO is an example of a design in which the entire LPC interface is hidden from programmers. Instead, LPC is generated automatically from MOO code.

To its credit, MOO is slowly evolving to avoid many of the assumptions it currently makes. LPMOO isn't intended to replace all existing MOO servers; it is primarily presented as an example of the flexibility of DGD, and will hopefully inspire future designs for on-line interactive environments.

LPMOO and LambdaMOO

LPMOO does have a number of interesting advantages when compared to the LambdaMOO server, making it inviting to particular situations. For example, DGD automatically makes LPMOO disk-based. It also becomes a simple matter to extend the MOO interface by adding new built-in functions or modifying existing behavior, all by programming in a high-level language, LPC.

With all these advantages, there are still disadvantages. LPMOO is not quite as fast as the pure-C, optimized LambdaMOO. DGD is fast, but the simulation adds some overhead. The speed difference is difficult to measure quantitatively. However, the performance of LPMOO is generally quite acceptable, especially if also measured in terms of efficient memory usage. The speed issue is greatly helped by DGD's ability to "precompile" LPC into C (to link directly into the server executable itself), giving what would otherwise be interpreted execution optimal performance.