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.

[KaVir]

Originally Posted by Is anyone here using anything besides C/C++ to create a MUD in?

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.

Originally Posted by 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?

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.

Originally Posted by 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.

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.

[Yazracor]

Well, I was not the one who decided to use Java for our MUD because I wasn't part of the development team then (actually, at that time I wasn't even mudding yet ). Nevertheless, from my experience Java has quite a few points which make it superior to "older" languages (especially C) for the task of creating a MUD engine from scratch (admittedly, my experience with C++ is *nil*).

First off, error handling is as easy as catching an exception. So, instead of the MUD crashing because some pointer points into nirvana, we get a NullPointerException right in the bugs immo-channel with a line in the sourcecode where it occured. This benefits stability and makes debugging a lot easier in most cases.
Code-reloading is another nice feature as most classes can easily be (re-)loaded while the MUD is running and only extensive conceptual changes require an acutal reboot. Platform independence allows our developers to use their favorite OS to write and test their code and areas on. People on the team use Mac, several Windoze flavors and Linux for development while the server runs on Linux.
The nicely abstracted collection classes in Java are another plus, allowing us to focus on development for the MUD instead of having to implement (and debug) things such as hashmaps or lists.
In addition, bytecode running with sun's newest version of the HotSpot engine is nearly as quick now as native code.
Oh, as a last point, with SKIJ and Kawa there exist nice implementations of the scheme-language that can be used for dynamic contents in areas.

As I came to the team when the engine was already very advanced (running stably for years), I can only refer you to our head-imp for more information about "Why Java?"

With a bit (very small bit) more penalty in performance, even more dynamic "code-reloading", stability against errors and ease of abstraction could be achived by using LISP, which I admit exists little support in the community for. Especially the ability to perform symbolic computations should make LISP (or one of its dialects) a rather ideal tool for MUD development if you think of such features as AI or automatic area creation.

[enigma@zebedee]

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.

Originally Posted by 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.

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.

Originally Posted by 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.

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.

Originally Posted by Nevertheless, from my experience Java has quite a few points which make it superior to "older" languages (especially C) for the task of creating a MUD engine from scratch (admittedly, my experience with C++ is *nil*).

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.

Originally Posted by With a bit (very small bit) more penalty in performance, even more dynamic "code-reloading", stability against errors and ease of abstraction could be achived by using LISP, which I admit exists little support in the community for.

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.

Originally Posted by 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.

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. =)

[KaVir]

Originally Posted by 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 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?

[angelbob]

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.

[karlan]

I was wondering if anyone uses libraries from other languages. I have just started work as a programmer with a civil engineering software company (thus devestating the amount of time I can spend on my MUD coding ), and alot of the original calculations and transforms we use were written in fortran, which is how the boss wants it to stay. I was wondering if people have considered using imported modules like this (ie LISP for AI stuff) in other languages.

Please note: I am not involved in that side of things yet, so I do not know how to do it ( Yet! )

Karlan
"There are 10 types of people in the world, Those who understand binary, and those that don't"

[Spazmatic]

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

Objective-C is yummy.

Originally Posted by 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.

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.

Originally Posted by First off, error handling is as easy as catching an exception. So, instead of the MUD crashing because some pointer points into nirvana, we get a NullPointerException right in the bugs immo-channel with a line in the sourcecode where it occured. This benefits stability and makes debugging a lot easier in most cases.

C++ has exceptions.

Originally Posted by The nicely abstracted collection classes in Java are another plus, allowing us to focus on development for the MUD instead of having to implement (and debug) things such as hashmaps or lists.

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.

Originally Posted by 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.

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.

Originally Posted by 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.

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*

[Kastagaar]

Originally Posted by 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.

That's a very good saying and all, but I can't honestly remember ever saying it

But to add some humour value, maybe the OP should try implementing a mud codebase in one of the languages on or linked from this page:

http://www.dangermouse.net/esoteric/

My favourite language of that lot is definitely "Ook!", although "Chef" comes a close second.

Kas.

[shadowfyr]

lol I actually considered combining Haifu and Chef to make a spell system, but concluded that it would be far to complicated (like on the scale of building a mud lib from scratch) to impliment and would be fatally flawed unless the mud included sufficiant interfaces and real time physical effects to make it work. As a spell system a graphical representation that could be built into a real physic/magic sim would be better.

As an alchemy system though Chef by itself would be interesting, but you have the same problem, "how do you make sure that each new item added to the game, especially stuff like birds feathers or sea shells, adds to the mechanics of the alchemy without having to hard code the results?" The only way of course is to give each new item a set of alchemical characteristics, but that has to pretty much be done from day one.

Yeah, Esoterics are very interesting. Try looking up Java2K some time.

[Tamsyn@zebedee.org]

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.

[Yazracor]

Originally Posted by 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.

Well, just recovering from my failure to put WordNet to good use in some kind of text understanding/RP recognition system, I can tell you that there are quite a few things especially in the AI field that just swallow processing power of even fast CPUs - and were prohibitively memory-intensive running on my home machine with 1 user.
It all depends on what you want to do in your code - just displaying rooms and mobiles and items and make fights won't draw much in terms of resources, of course.
As to using some libraries of other languages:
I tried to use a LISP-interface to wordnet via sockets so i didn't have to code my own one for java. Its performance was so poor, though, that I wound up writing it anyway. This was due to the fact that it was meant for a different purpose than I used it, and not a performance issue of clisp. The pattern-matching and part-of-speech-tagging was done in LISP until I found an article describing in detail why my approach was futile

[karlan]

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"

Originally Posted by It may be just my ignorance, but is LP used for anything other than MUDS

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 Pike. 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.