After browsing through the which is preferred thread, I decided to throw out some questions. Is anyone here using anything besides C/C++ to create a MUD in? If so, are there any specific reasons you chose that language to program a MUD in? If not, what are the extreme benefits of C/C++ over using, for example, a so-called "interpreted" language instead?

When asking this question in a more general scope I usually receive a "for speed" response; but we are talking about relatively simple programs, where the speed difference (in most scenarios, imo) is negligible.

There are people developing muds in many different languages. Take away all the derivatives (which are generally bound to using the same language as their parent codebase) and you'll probably find a fairly even distribution between languages.

It depends what you're trying to do. A programming language is just a tool - and a good tool for one problem may be a poor choice for another. The trick is to first identify exactly what you're trying to achieve, and then decide which language is best suited - because as Kastagaar is fond of saying, when the only tool you've got is a hammer, every problem starts to look like a nail.

When you're talking about muds using scripted languages (such as LPC), you'll find that speed can indeed become an issue, as can memory usage. If you're paying a monthly hosting fee, such a difference is often not negligible. However that is only one point - when chosing which language to use, you should consider all aspects of development. For example:

* What programming languages do the development team already know (or are interested in learning).

* What crossover is there with non-mud-related stuff (for example, if you developed a mud in Java, would it aid your professional career - and would skills gained in your professional career make it easier for you to develop the mud?).

* What sort of books and online documentation are available for the language.

* What beneficial tools and utilities are available for developing with the language.

* What quality and quantity of mud-related software is already available in that language - and what sort of license restrictions does it have.

* What specific benefits does the language offer, and how well do these fit with what you're trying to achieve. For example, if you're using an OO design (as many of the newer scratch-written muds seem to be), you're going to find it more difficult to use a language without support for OO features.

There is no "ideal" language for mud development, so don't believe anyone who tries to tell you there is.

Hmm, well Zeb is an LP Mud - so running on an LPC driver which is basically an interpretted language (compiled to bytecode I believe similar to Java). It is sort of quasi-OO and designed specifically for writing muds.

A lot of the benefits just listed for Java it also provides (bugs in mud code do not crash the whole mud for example) and has the advantages that coders can actually code and make changes online without needing access to anytihng other than the code for the files they are modifying and documentation for the mudlib. This lets us keep the mudlib private - so only the highest level coders can change it - while letting newer coders have complete freedom when working on their areas.

I have to admit I have never coded on anything other than an LP Mud (although I have coded on three of those to varying degrees) so I am not sure how things like dynamic code changes while the mud is running operate in the other languages.

Like fork(), eh? Anyways, quite a fair response to the question; although the main purpose of my question wasn’t to ask everyone what the was best language to code a mud in, it was more of asking the individuals that use these “other” languages why they chose it and what benefits they believe it brings to creation of MUD development. On the other side I wanted to be fair and see if the people that chose C/C++ did so for reasons other than familiarity, i.e. Why they decided it was the best language suited.

I have noticed speed issues when dealing with some heavy LP code, I also believe that it all goes back to size of the MUD itself as well, so inability of the server to operate in such a limited resource environment would be a good reason to shy away from those “interpreted” languages.

The rest of your post lists good pointers that people should follow when choosing the language, though I think that many people do so for just one or two of the reasons on the list (I am not excluded from this comment).

As to there being no “ideal” language for mud programming, I agree, but so often do I see people scoffing at users of odd languages. One such is someone most of us know, whom I am not going to name. If you put the idiocy of the person’s attitude aside, as well as the surrounding debate of the licensing of his code, the code itself is actually quite a wonderful example of the programming language being just a tool.

Your post basically sums up my opinion on why I use the language I use, in fact those are some of the biggest plusses of using an “interpreted” language. While I admit to having very little Java experience, I do know that speed wise it rocks compared to some of the other “interpreted” languages.

I agree, the virtues of using a language such as LISP could be worth the penalty that it takes, even that penalty may not be so profound. Correct me if I am wrong but some newer LISPs (and SCHEME) languages are usually compiled to native code and if written carefully can be quite comparable to other native-compiled languages. The fact that there isn’t much support is a downer, but seems like it would make for quite a fun adventure.

Usually most “interpreted” languages have the ability to do such things. I myself started programming  on an LP Mud. (If you don’t count Qbasic , Pascal for BBS Door games and small shell scripting.) That may be one of the largest influences on why I chose the language that I have coded my mud in.

I use Pike, which has some of the same virtues as other such languages (albeit not as fast as something like Java) and has a lower learning curve for someone coming from an LPC or C background.

The other day though, I was browsing across the net and came across the Ruby web page (I had heard of Ruby, just not explored it), so decided to read the manual and play with it for a little bit. I absolutely loved some of the features and the syntax. I think when I finish this server in Pike I will do it in Ruby as well. I am a sad person, an obvious glutton for punishment, that cannot help but torture himself by learning languages by coding a mud server. Pity Me. =)

I would say that most people do not choose their language - they choose their codebase, and then just use whichever language it is written in (generally C).

However C is a very powerful and flexible language.  All seven team members of the mud I'm working on have used it before, with five having done so professionally.  Four of the team members have also previously written their own codebases from scratch, in C, so there was very little learning curve there.

Only three of the team members know how to program in C++ - but have used it professionally, and it's not very difficult to understand for someone already familiar with C.  It also allows us to encapsulate and use previously written C code (such as some of the standalone snippets I've written in the past), which saves some time.

The primary reason we chose C++ over C was because we required inheritence and polymorphism, which isn't very clean to implement in C.

Only one team member knows how to program in Java, having used it for hobby programming.  I'm not sure about other languages, but my own are very rusty, as I've not used anything other than C and C++ for a very long time.

As well as familiarity with the language itself, we have knowledge of various tools which make development in C and C++ easier.  We also have the usual collection of books which developers tend to gather over time.  In the case of mud-specific languages such as LPC and ColdC, as far as I know there aren't any books, nor is there much support in general.

In addition, as I pointed out before, five of us develop software professionally (using a mixture of C and C++).  Developing a mud is a learning process, and experimentation is probably one of the best ways to learn the ins and outs of a language.  Having a programming language on your CV/resume is always useful, but most companies aren't interested unless you've used it professionally - however, if you do use it professionally, they're still going to test your skills before offering you a job.  When I applied for my second job (back in 1999) I had "C" on my CV, but I doubt I would have got through the technical interview without the knowledge I'd gained from four and a half years of mud development.

So in summary:

* There is very little learning curve for us.

* There is no need for us to purchase new books.

* There is no need for us to download and learn new tools.

* We can easily reuse some of our existing code.

* We gain valuable directly-relevent "real world" skills.

* Less of a resource hog means cheaper mud hosting.

* No licensing restrictions.

But most importantly of all:

* C++ provides exactly what we need in the way of features.

So, taking the other points into consideration, why use something else?

You can also choose a driver -- for instance, DGD supplies some features not found elsewhere. But if you use DGD, you have to use LPC so your language choice is made as well.

The main compelling feature for me was the rlimits() construct, which will cleanly cut off a thread of execution after a given amount of time. Other unique features of DGD include atomic functions -- a given function is guaranteed to fully execute or else leave no trace, including any global variables writes that it may have done. In DGD, any function may be declared atomic and the only operations it can't perform are network read/write and file read/write.

As a result, DGD can't really do callout to other languages since other languages can't manage either the "cleanly interruptable" functionality or the "atomic" functionality. You can precompile LPC and you can use C to extend the driver, but mainly you just have to use LPC.

Objective-C is yummy.

Large-scale LISP projects are not for the timid. While very possible, they do require a certain degree of organization not common in mud dev teams. Further, I'd argue, despite the fact that LISP (Common Lisp with CLOS, in fact) is my primary language, that it is not really oriented towards state-heavy code. The more functional, the better.

Also, you can't compile LISP (not completely, parts can be) since it is symbolic... It would be nearly impossible to manage (I guess it could be done, but you wouldn't get much of a speed increase). I think, more importantly, is that the speed difference between good LISP interpreters and, say, Java, is not so high that that alone would cripple it.

C++ has exceptions.

On the other hand, muds are a fairly unique system data structure wise, and specially designed algorithms and data structures will get MUCH better performance.

I'd aruge that C/C++ definitely leads in total codebases, even avoiding derivatives, as it was the so dominant for so long. Whether new projects are fairly diverse is beyond me.

Speed is negligible if you're recoding Circle. If you're using hardcore AI with NP-approximation algorithms for path finding and planning, throwing around needs and decision trees for mobs, etc, that speed is going to matter. All the moreso for most muds, which run on shared hosting.

That said, I use C#. *shrugs*

I'm a little surprised about the speed & memory problems allegedly associated with LPMUDs (and any other mud drivers taking the 'byte code' approach).

Sure, 10 years ago when Zeb started, we used to use a max of about 20 megs after a few days up and running, and we used to use a high percent of CPU, say 40%. And things could get slow, especially when backup processes ran. But that was 10 years on, running on a Sun 386 or a Sparc 1 or 2 with 32MB memory or even less.

These days, memory is dirt cheap, and processors speeds are light years ahead. Even with a MUD with 50k rooms and 500 people online I imagine the memory and CPU issues are manageable.

Of course it depends whether you have a co-hosting agreement i.e. supplying your own machine with whatever CPU/memory you require, or whether you are hiring space. The latter is always going to be restrictive to some extent.

It may be just my ignorance, but is LP used for anything other than MUDS, most of my coding is in C/C++ since I use it at work, and so I chose codebases based around that, mainly laziness to avoid learning a new language (NOTE: I have not looked at LP so I do not know how different it is, OR how similar)

Is familiarity with the language a factor for others when choosing a codebase?

"There are 10 type of people in the world, those who understand binary, and those who don't"

Yes it is. The original LPC language and interpreters were written by Lars Pensjo. Various derivatives occured and were used for such things as web servers, chat servers. Since they were all derivatives and based on the non-commercial license, Frank Hubinette created a new one from scratch called uLPC which eventually morphed into the scripting language . Many things can be written in this, I have seen: media players, games, etc... It is currently what I am writing my codebase in.

As to LPC similarities to C, I would say it shares alot in common.. from what I know, which is little as I have never really USED C\C++ for much more than simple tasks like writing modules for Pike.