"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?
Legacy issues.
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.
Legacy Issues
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.
Concluding Thoughts
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 alternatives available.
December 1998 Imaginary Realities, the magazine of your mind.
© Copyright Information