"Are LPMuds dead? None of the major drivers have made any real
advancements in at least two years (an eternity in the Internet world)
and it seems today even more so than in the past that new muds never
see the light of day.
... I no longer value LPC as a mud building environment. It does have
some strengths over Java that one
can get around by using a proprietary JVM, but on the whole it seems
to be overwhelmingly limiting in where it can let people take muds."
The question posed by George is an interesting one, it is unfortunately
a very open ended one and multi-barrelled
with no real criteria for comparison except citing "real advancements".
There are so many ways to approach such an open question.
I'll deal with the question from a number of perspectives:
Does one language provide technical possibilities
the other doesn't?
Does one language provide better quality support
in terms of performance, reliability, maintainability,
security or robustness?
Technical and Language Issues
Both LPC and Java are Turing complete languages. What this means for you
non computer science people is that whatever you do in one language you
can do in the other. This may not be easy and an appropriate amount of
support work would be required to emulate various features, more on that
later. George may believe Java can take us to places that LPC can't but I
see no reason they can't both take us to the same place. It is likely that
one will take us there more quickly and more efficiently than the other.
The is no compelling reason that an LPC to JVM compiler couldn't be built.
Basically the JVM would replace the custom VM(s) that LPmuds have built-in
internally. Obviously an LPmud internal function emulation library would
have to be built and the compiler would need to link to this directly. The
production of such a tool would provide a legacy path for moving LPmuds
into a Java environment. A number of other languages already compile
to the JVM (including Ada), these may provide even better languages
for mud-building. While that wasn't the question posed by George it is
certainly an issue worthy of further consideration (at another time!).
It's worth examining some of the features provided by each language
which are not well handled by the other.
Java provides in-language support for handling concurrency. LPC does not;
here Java is technically superior. Although some extensions to the LPC
language and a support library could provide concurrency support, these
aren't trivial. It should be noted that concurrency is a two-edged sword
that many wizards, who aren't programmers, would cut themselves upon.
Issues of synchronization, deadlock and debugging become major issues
that are not easily addressed. Nevertheless I regard the lack of true
concurrency support as a significant deficiency of LPC.
Flaws exist in both languages. Object-orientedness was really a tack-on to
LPC (I remember when there was no inheritance) and it really shows. Both
language type systems leave something to be desired. LPC is (very)
loosely dynamically typed with no type checking available on objects.
Java provides a more mature complex type system that has a few subtle
problems (which I won't go into, needless to say some of the method
dispatching and dynamic casting is odd). Both share the peculiarity of
passing basic types by value and objects and array by reference. Java is
a more clearly thought out language. Strong type checking is usually
preferable for the production of large systems, dynamic type checking is
(sometimes) considered an advantage in rapid-prototyping and for use by
programming novices. Given that size and quality are issues for good muds
now I think that the static type checking of Java is a desirable feature.
Using either language effectively requires an understanding of that
language's static name-space organization and their runtime support
libraries (objects, etc). LPC name-space organization is pretty simple
(with classes mapping directly to filenames). Java is more complicated
with packages (relating to directories), files and classes inside
files. Compiled code also hangs around in the directories. Both have
numerous runtime support systems, Java neatly encapsulates them into
class interfaces. Conversely LPC runtime support is usually buried away
in the driver as a bunch of efuns in a flat name-space. Basically both
require some learning overhead to really get going on larger projects.
Dynamic code replacement is an interesting issue. One of the big strengths
of LPC is that you can easily and readily replace broken code
and have new objects created from the code. Java
provides for easy loading of new code but it's not so easy to replace
existing code already linked with other code. Certainly an edge to LPmud here.
Java has a huge library of of well documented support code, but it's
mostly general programming stuff. LPmud provides extensive existing
libraries for actual
muds. Nevertheless class libraries can be developed easily in either
language. It's not really a language issue as such but it is `time to
start' issue. The most significant issue of importance in this domain is
that of strings and string handling. Strings and string handling are an
essential element of any textual mud. Java's string handling is
fundamentally irritating, requiring the use of
two classes to do any really interesting manipulations. Contrast this
to LPC which has always been aimed at convenient string handling.
Certainly an edge to LPC in this important mud-development aspect.
Quality and Software Development Issues
LPC has a strictly limited number of software development support tools
such as profilers, debuggers, CASE and metrics tools. It is unlikely to
get many either, most mud developers are more interested in actually
getting a mud up and running than developing high quality tools!.
Java is streets ahead here in the availability and quality of software
development and maintenance tools.
LPmuds are by and large reasonably stable runtime environments with
known problems. Java is still quite an unstable beast, especially the
browser implementations of JVM and the class libraries. Most JVMs have
significant garbage collection problems. An existing edge in reliability
to LPC, but it's quickly being addressed by the growing band of Java
compiler and VM developers.
LPC has been specifically tailored to perform well in the mud domain,
which is one which consists of lots of strings and smallish memory
objects and long uptimes. Java really hasn't been applied widely in
these circumstances. I haven't done any benchmarking but on similar
hardware I'd expect LPC to do a better job providing mud-service in a
similar mud domain. Having said that server performance and memory usage
are far lesser issues than they were a few years ago. If you've got a
performance problem then "throw more hardware at it". Bottlenecks are
now more likely to be network ones than server ones.
Most LPmud drivers are a maintainability burden. With Java the runtime
support and compilers are maintained by the wider software community
and cease to be issues. Standardization will also eventually occur
facilitating the re-use of code between muds.
Large code bases are easier to maintain in Java because of Java's
strict type system, the packaging system, and the availability of
development process control tools.
Many millions of lines of dedicated mud code already exists in LPC. Very
limited amounts of mud-oriented Java code exist. A lot of people would
be quite unhappy to abandon their existing muds and begin again.
This issue alone will ensure the continued existence of LPC as a language
and LPmud as a development environment.
Java is the buzz-language of the moment; it's over rated as a programming
language because of the intense marketing campaign promoting it. Plenty of
similar alternatives exist including: Inferno, Erlang, Ada (to JVM). These
languages and others provide excellent platforms on which to built a
mud. Heavy marketing and professional support means market-wide support
and development of tools and libraries for all of these languages. These tools
and libraries are either unavailable or not professionally supported in
the LPmud environment.
In years gone by LPmud was the only really flexible mud driver, this is
certainly no longer the case. Unless you're already familiar with LPC
there are not that many compelling reasons to start one up.
In conclusion I don't think LPC is dead yet, but without significant
injections of highly quality energy it is certainly on the decline. If
you have a good one running it's much easier to maintain and build on
it than it is to switch to another development environment. If you're
looking to start from scratch then Java is one of the many reasonable
December 1998 Imaginary Realities, the magazine of your mind.
© Copyright Information