26 Feb, 2008, exeter wrote in the 1st comment:
Votes: 0
Prompted by a similar discussion in a game programming newsgroup, I've been wondering: why aren't there more MUDs (specifically new MUDs) coded in high-level languages like Ruby, Python, or Perl? Conversely, why do most MUD codebases seem to be written in C or C++?

For purposes of this topic, I'll call C and C++ "low-level" and languages like Perl, Python, Ruby, etc. "high-level." To qualify as a "high-level" language, for purposes of MUD programming, a language should have excellent text-handling capabilities; easy object serialization; and high-level, built-in data types like lists, hashes, tuples, etc. Perhaps there are other or better distinguishing characteristics of a high-level language, but these will do as a first approximation.

My first guess as to why there aren't more MUDs in high-level languages is that these languages intentionally disregard certain low-level efficiencies in exchange for these high-level abstractions, thus leading to increased resource usage. However, LPMUD servers have, for 15+ years, implemented a high-level language, variants of which have been wildly successful in the MUD world.

That argument may have held water 15 years ago, but, in the days of giga-everything, even on shared hosting, this doesn't seem to be much of an issue in 2008. Instead, I suspect two forces are at work:

1. Some MUDs originate as variants of older codebases which, naturally, tend to be in C or C++.
2. Because "most" MUDs are written in C or C++, the newbie coder is automatically advised by the masses to code his or her MUD in C or C++.

For the moment, let us disregard #1 and focus on the coders of new codebases. Of the higher-level languages I mentioned (Perl, Python, Ruby), I know of only a handful of MUD codebases in each of these languages. (In fact, for Perl and Ruby, I only know one each.) Given that a MUD is just a server program that listens on a socket and does lots of text manipulation, why should this be so?

Please, in your replies, try to avoid "language wars," and other such non-constructive bickering. As someone considering coding a MUD server (in Python) I'm genuinely interested in the answer to this.

Thanks
26 Feb, 2008, Zeno wrote in the 2nd comment:
Votes: 0
By "most codebases", can you give some examples? Preferably anything released in the last few years.
26 Feb, 2008, Conner wrote in the 3rd comment:
Votes: 0
I would be inclined to think that new coders might be encouraged to use C or C++ for their code base simply because it's much easier to find other mud coders who know those languages than most others should that new coder find they need help resolving an issue.
26 Feb, 2008, exeter wrote in the 4th comment:
Votes: 0
Examples? Sure.

Of the top 10 results (including only projects that have files) on sourceforge.net for "mud server," two are in C#, one in O'Caml, three are in C or C++, and three in Java.

I don't really know enough about C# to comment, but I consider Java to be a low-level language in this context. Even if you include C# as a high-level language, that leaves 3 for high-level and 7 low-level. The trend continues, broadly, as you go down the list.
26 Feb, 2008, Kayle wrote in the 5th comment:
Votes: 0
I think the main reason most codebases are done in C/C++ is the ease of learning the language. You don't necessarily need to spend days or weeks pouring over books or other instructions to learn C/C++. A lot of times you can learn C/C++ simply through trial and error. I know several people who started out this way.

Another reason is C/C++ is more widely used in the industry. I believe, most platform games are written in C++. Of course I could be wrong here. However, most applications that everyone uses daily are written in C/C++ and it's more common to find GCC or G++ installed on Web servers catering to MU*s. Because these things are typically needed in any *nix installation for compiling in new features for your system.

But, These are just my opinions, I could be way off-base in most of them, and I can't really complain that I was able to form coherent thoughts at 1:40 in the morning..
26 Feb, 2008, Brinson wrote in the 6th comment:
Votes: 0
Because changing coding languages would require you to more than reinvent the wheel, you'd have to reinvent the entire car. People know how to write muds in C/C++, they can find examples, snippets, code, ideas, ect, for C/C++ programming of muds everywhere they turn.
26 Feb, 2008, KaVir wrote in the 7th comment:
Votes: 0
exeter said:
Conversely, why do most MUD codebases seem to be written in C or C++?


My three main reasons for creating a mud from scratch in C++:

1. All of the development team were already experienced C developers, four of us having previously (and independantly from each other) written muds from scratch in C. Most of us were also proficient in C++, and as the latter is (almost) a superset of the former, the others were able to pick it up very quickly.

2. I was able to reuse some of the (codebase-independant) C snippets I'd written in the past, as well as sections of my previously scratch-written mud (which had also been written in C).

3. C and C++ are pretty efficient in terms of CPU and RAM usage when compared to many other languages, and this helped keep the hosting costs down. If you're paying based on CPU and memory usage, as is the case with many mud hosting services, this is indeed an issue.


As for why I didn't use LPC, see here: http://groups.google.com/group/rec.games...
26 Feb, 2008, kiasyn wrote in the 8th comment:
Votes: 0
because people are lazy and developing a codebase from scratch takes time =(
26 Feb, 2008, drrck wrote in the 9th comment:
Votes: 0
As KaVir pointed out, I think one of the main reasons for the prevalence of low-level languages in the MUD community is that C/C++/Java are compiled languages that produce very fast machine code which uses very little resources (relative to high-level, interpreted languages). Given that 99% of MUDs are not run as corporate ventures and make little to no money, minimizing the need for expensive hardware/bandwidth is pretty key for most administrators.

That said, one of the other reasons is undoubtedly the fact that most beginning programmers learn one of these three languages as their first (and usually strongest) language. Simply put: it's easier.
26 Feb, 2008, shasarak wrote in the 10th comment:
Votes: 0
Quote
As KaVir pointed out, I think one of the main reasons for the prevalence of low-level languages in the MUD community is that C/C++/Java are compiled languages that produce very fast machine code which uses very little resources (relative to high-level, interpreted languages).

Many high-level languages are not interpreted these days, they're JIT-compiled; the performance deficit between pre-compiled C and a JIT-compiled language is typically negligible (unless you're writing something like Crysis).
26 Feb, 2008, David Haley wrote in the 11th comment:
Votes: 0
Re: efficiency: it is a very common perception that dynamic languages will suffer greatly from increased CPU/memory usage. A lot of this is spoken (frankly) out of ignorance; people make the claim without really knowing dynamic languages, and most importantly without really having benchmarked the alternatives.

Somebody once told me that they did not want a C++ codebase because it would be slower and more memory intensive than C. :stare:

Kayle said:
I think the main reason most codebases are done in C/C++ is the ease of learning the language. You don't necessarily need to spend days or weeks pouring over books or other instructions to learn C/C++. A lot of times you can learn C/C++ simply through trial and error. I know several people who started out this way.

Err… I'm afraid that I have to rather strongly disagree with this statement. C/C++ are notoriously hard to learn compared to some dynamic languages. As evidence I need only submit pointers and the mystery they represent to far too many programmers. Nearly every single bug in MUDs is caused by a lack of understanding of pointers, be it for null checking, aliasing, memory management, or even simple string handling. So, this language is simple and easy?

Contrast with dynamic languages where, for the most part, you don't have to deal with issues like that and can get to business doing whatever it is you need to do.

Furthermore, there's no reason why one should be able to learn C/C++ by trial and error and not another language, nor why you should be able to learn them without books whereas others require books. (And frankly, many programmers who learn without ever touching some form of book or class are likely to have gaping holes in their understanding. Been there, done that.)

Finally, the educational community, for whatever it's worth, has also come to the conclusion that C/C++ are not the best introduction to programming because there are too many superfluous concepts that get in the way of learning the concepts of programming. Of course, some people come back and say "no, you should learn C first"; what reason do they give? They want people to understand pointers… :wink: The problem is that many people go through C/C++ and still don't really understand pointers…

Kayle said:
Another reason is C/C++ is more widely used in the industry. I believe, most platform games are written in C++. Of course I could be wrong here. However, most applications that everyone uses daily are written in C/C++ and it's more common to find GCC or G++ installed on Web servers catering to MU*s. Because these things are typically needed in any *nix installation for compiling in new features for your system.

Well, availability is a weaker and weaker argument these days due to how often languages such as Perl and Python appear on *nix distributions. Lua can be installed in a snap.

The "industry" (which industry? games? enterprise software? …) usually does require C/C++ (and/or Java) knowledge. But it might be interesting to know that many extremely high-profile companies also want experience in higher-level languages. Google (a small, local company around here; you might have heard of it) does huge portions of its development in Python, for example.

drrck said:
That said, one of the other reasons is undoubtedly the fact that most beginning programmers learn one of these three languages as their first (and usually strongest) language. Simply put: it's easier.

I think this is one of the strongest reasons why most development is in C – not even C++. (I think it's interesting to see how many people actually write C++ over C.) People do it because it's what they know how to do…

shasarak said:
Many high-level languages are not interpreted these days, they're JIT-compiled; the performance deficit between pre-compiled C and a JIT-compiled language is typically negligible (unless you're writing something like Crysis).

Even the speed difference for an interpreted language will usually be unimportant for MUDs. It's not as if MUDs have inner loops that need to render thousands and thousands of polygons. MUDs have rather simple loops with rather little to do; it's usually much more important to help the programmer than to help the CPU.

Besides, most CPU-intensive operations on MUDs are caused by inefficient data structures or algorithms, like iterating over the entire list of objects in the game searching for something, instead of keeping some kind of indexed list.
26 Feb, 2008, drrck wrote in the 12th comment:
Votes: 0
shasarak said:
Many high-level languages are not interpreted these days, they're JIT-compiled; the performance deficit between pre-compiled C and a JIT-compiled language is typically negligible (unless you're writing something like Crysis).


I don't know of any popular high-level languages that are JIT-compiled by default, except Java. I know Ruby has a JIT implementation somewhere out there, and Perl/Python probably do as well, but they're all going to be interpreted for the vast majority of users without reimplementation.

DavidHaley said:
Somebody once told me that they did not want a C++ codebase because it would be slower and more memory intensive than C.


I guess the truth of that would depend on whether they were referring to managed C++ or not, as well as what exactly they were making (I'm sure whoever suggested this didn't know as much, though). It's rather hard to get rid of such an ingrained fallacy in programming culture, though. Just look at how many people still debate over whether i++ or ++i is "faster" (despite modern compilers making that trick obsolete ages ago).

DavidHaley said:
Even the speed difference for an interpreted language will usually be unimportant for MUDs. It's not as if MUDs have inner loops that need to render thousands and thousands of polygons. MUDs have rather simple loops with rather little to do; it's usually much more important to help the programmer than to help the CPU.

Besides, most CPU-intensive operations on MUDs are caused by inefficient data structures or algorithms, like iterating over the entire list of objects in the game searching for something, instead of keeping some kind of indexed list.


Depending on the MUD, you're absolutely right; though, if you know C++ pretty well, and you know Ruby pretty well, I think the consensus among MUD developers is pretty much: why not opt for performance improvements (as relatively minor as they may be)?
26 Feb, 2008, David Haley wrote in the 13th comment:
Votes: 0
drrck said:
I guess the truth of that would depend on whether they were referring to managed C++ or not, as well as what exactly they were making (I'm sure whoever suggested this didn't know as much, though). It's rather hard to get rid of such an ingrained fallacy in programming culture, though. Just look at how many people still debate over whether i++ or ++i is "faster" (despite modern compilers making that trick obsolete ages ago).

Indeed, I'm pretty sure the person in question was not referring to managed C++ or anything of the sort… I had proposed converting code to plain C++ to be able to use string/map/set/etc. and was told it was a bad idea due to performance concerns. Needless to say I didn't really stay involved in the project after that…

And regarding ++i vs. i++, it's one thing to believe in the compile-time difference (but as you say, not anymore), but people who think there's a runtime difference… well… sigh.

drrck said:
Depending on the MUD, you're absolutely right; though, if you know C++ pretty well, and you know Ruby pretty well, I think the consensus among MUD developers is pretty much: why not opt for performance improvements (as relatively minor as they may be)?

Well, there are a few things here… I can give personal examples for whatever they are worth. I believe that I know C/C++ pretty well, and I also am quite familiar with several dynamic languages. Some tasks are nonetheless much more quickly accomplished in a dynamic language. In fact, most tasks are easier in the dynamic language. I use C/C++ when it really does matter for efficiency purposes, and I try to avoid making that decision until actually benchmarking/profiling code. So e.g. I'd start out in the dynamic language of my choice and only later move things to C++ if I find that there's a bottleneck.

The tradeoff involved is speed of execution vs. speed of development. Yes, the compiled language will (almost always, but not always, interestingly enough!) have better execution time. But for a given amount of time writing code, it is likely that you will get more done in a dynamic language.

An interesting example is Nick's task code. (It's spread out over a few threads over here.) Sure, everything he did would be possible to do in C/C++. But it would be a whole lot more annoying…

Another example is resumable commands. Compare the ease of using coroutines in Lua to stop/resume commands vs. what you would have to do to stop C commands at arbitrary points and resume them arbitrarily. (It turns out, of course, that you can emulate cooperative multi-threading with threads in C, but that can be a dangerous game to play. And you're just reinventing the wheel, too.)
26 Feb, 2008, KaVir wrote in the 14th comment:
Votes: 0
DavidHaley said:
Re: efficiency: it is a very common perception that dynamic languages will suffer greatly from increased CPU/memory usage. A lot of this is spoken (frankly) out of ignorance; people make the claim without really knowing dynamic languages, and most importantly without really having benchmarked the alternatives.


Muds written in such languages usually do suffer increased CPU and memory usage, although many dynamic languages perform exceptionally well in certain situations (as you'll often see in benchmarks which try to defend them). Of course there's no absolutely reason why you can't write a mud in something like Python or Ruby, and in some cases they may well be the preferred choice - but when you're paying an extra $1.50 per month for each +1% CPU usage and $1 per month for every +5MB of RAM, you might start to reconsider the view that CPU and memory usage don't matter.

DavidHaley said:
Somebody once told me that they did not want a C++ codebase because it would be slower and more memory intensive than C.


Assuming it actually used C++ features, it probably would be. Even just using polymorphism will add an extra memory overhead of one pointer per object (plus the per-class overhead of a vtable), and virtual function calls are slower than direct calls (particularly if you've converted them from what was previously an inline function).

Of course the difference is negligible, and almost certainly irrelevant for a mud, but that doesn't mean it doesn't exist; back when I was developing real-time embedded software, if someone had asked me why I programmed in C instead of C++, I would have truthfully listed speed and memory as two of the main reasons.

DavidHaley said:
And regarding ++i vs. i++, it's one thing to believe in the compile-time difference (but as you say, not anymore), but people who think there's a runtime difference… well… sigh.


As long as you're not using the value of the expression, you're right that there shouldn't be a difference - but that only applies to standard data types. If you've overloaded the prefix and postfix increment operators of an object, there will be a performance hit. Once again it'll likely be negligible, but it's still considered good practice in C++ to use the prefix operators.
26 Feb, 2008, David Haley wrote in the 15th comment:
Votes: 0
KaVir said:
Muds written in such languages usually do suffer increased CPU and memory usage

Well, perhaps this wasn't clear, but I chose the word 'suffer' rather specifically: yes, there may be an increase in CPU and memory, but it usually doesn't cause the MUD to suffer from it (especially when it comes to CPU). It depends on where the CPU-intensive operations are; besides, for the really intensive stuff, it's easy enough to have a C module that takes care of it for you, and you still do the bulk of the work in your dynamic language…

KaVir said:
Of course the difference is negligible

Of course it is negligible. Your reaction is the of the sort that encourages less informed people to think that C++ incurs this terrible performance hit over C. I'd have been happier if you had said up front that the difference exists but is negligible. So forgive me if I take the time to attack this issue of C++ being slower than C…

For instance, saying that virtual function calls are slower sounds a whole lot worse than saying what actually happens and noting that a virtual function call incurs simply one dereference and in some cases an addition more than a normal function call. (Oh no! A dereference and an addition! The MUD is doomed! Run for the hills!)

Real-time embedded systems are a completely different beast than MUDs. And also, just because you thought you were gaining speed and memory doesn't mean you actually were; you might have been, you might not have been. (Note that people use Lua in embedded systems and are content – clearly Lua is slower than C!) You might have also been able to use C++ to organize the code without actually incurring the hits associated with e.g. vtables – thereby increasing readability without losing performance.

OGRE was a very interesting case study of C++ vs. C. Despite all the naysayers who say that you need C to write a fast graphics engine, theirs is right up there in terms of performance despite being written in the "slow" C++…

KaVir said:
As long as you're not using the value of the expression, you're right that there shouldn't be a difference - but that only applies to standard data types. If you've overloaded the prefix and postfix increment operators of an object, there will be a performance hit.

Yes, and if you overload the addition operator, maybe ++i won't actually add anything at all! I take your point but I'm just not sure why it's relevant, especially considering that the intention of "i" is pretty clearly to talk about integers… as soon as you talk about overloading you've opened a whole new door. (And of course if you're using the value of the expression it makes a difference…)

By the way, what kind of performance hit are you talking about – compile-time or runtime? The only justification I ever heard for prefix operators was compile-time, but you made it sound like it was a runtime gain…

KaVir said:
Once again it'll be negligible, but it's still considered good practice in C++ to use the prefix operators.

I'm curious to hear who establishes this "good practice" and why. I've heard from many (more, actually) people that it doesn't matter and is a question of habit. :shrug:




EDIT:
It is interesting when people take so much time to point out "negligible" differences, when (by definition) if they are negligible they aren't worth considering. :wink:
26 Feb, 2008, Fizban wrote in the 16th comment:
Votes: 0
Quote
Finally, the educational community, for whatever it's worth, has also come to the conclusion that C/C++ are not the best introduction to programming because there are too many superfluous concepts that get in the way of learning the concepts of programming. Of course, some people come back and say "no, you should learn C first"; what reason do they give? They want people to understand pointers… The problem is that many people go through C/C++ and still don't really understand pointers…


On what basis do you consider the educational community to have decided C was not a good first language? I'm not saying you're wrong, so much as that it really isn't always the case. In my high school the only two programming classes they even had were C and a AP level C++ class. In college on the other hand I have indeed found that they STRONGLY suggest learning Java before C.
26 Feb, 2008, David Haley wrote in the 17th comment:
Votes: 0
I didn't say that every single educational institution has made the switch. And yes, I was referring more to college-level courses than to high-school level courses, even though I forgot to say that. :smile:

As for what basis I have, it is a sampling of several school websites, in addition to "big names" in the CS education community such as Eric Roberts. Also, articles such as Joel Spolsky's "Java Schools" (or whatever the title is), where he decries the fact that so many schools are switching to languages other than C/C++ (in particular for him, Java).
26 Feb, 2008, drrck wrote in the 18th comment:
Votes: 0
DavidHaley said:
Well, there are a few things here… I can give personal examples for whatever they are worth. I believe that I know C/C++ pretty well, and I also am quite familiar with several dynamic languages. Some tasks are nonetheless much more quickly accomplished in a dynamic language. In fact, most tasks are easier in the dynamic language. I use C/C++ when it really does matter for efficiency purposes, and I try to avoid making that decision until actually benchmarking/profiling code. So e.g. I'd start out in the dynamic language of my choice and only later move things to C++ if I find that there's a bottleneck.


That's a good point, although you'll find that there's a lot of people who don't mind putting extra time/effort into programming now just so they can squeeze a little better performance out of the code later. Interestingly enough, it really comes down to psychology (even players have the same mentality about now vs. then rewards). But then, you could always code the core game in a low-level language for performance, and extend the functionality through a higher-level language interfaced with it; then you'd be getting the best of both worlds.

DavidHaley said:
I'm curious to hear who establishes this "good practice" and why. I've heard from many (more, actually) people that it doesn't matter and is a question of habit. :shrug:


I, personally, think it's good practice and use prefix operators simply because they make more sense to me when reading code. Just as a + b = c is read "a plus b equals c" and is represented in the code in the order that it's read, ++i more logically represents what it means: "increment i". Of course, this is purely aesthetic, not functional.
26 Feb, 2008, drrck wrote in the 19th comment:
Votes: 0
Fizban said:
On what basis do you consider the educational community to have decided C was not a good first language? I'm not saying you're wrong, so much as that it really isn't always the case. In my high school the only two programming classes they even had were C and a AP level C++ class. In college on the other hand I have indeed found that they STRONGLY suggest learning Java before C.


By definition, low-level languages are going to be more complicated and harder to learn simply because they don't restrict the programming scope. It tends to overwhelm newcomers when they can clearly see all these things that are going on, but aren't told why because explaining them all is way beyond entry-level information. Compare this to high-level languages, where a lot more of these things are either straight-forward or omitted. A good example is the concept of passing arguments by reference. C/C++ both use this concept freely, while Java omits it (or… hides it, anyway). Another good example is pointers.
26 Feb, 2008, David Haley wrote in the 20th comment:
Votes: 0
drrck said:
That's a good point, although you'll find that there's a lot of people who don't mind putting extra time/effort into programming now just so they can squeeze a little better performance out of the code later.

The problem with this argument is that it's not just time/effort for programming now, it's time/effort for programming now and later…

drrck said:
But then, you could always code the core game in a low-level language for performance, and extend the functionality through a higher-level language interfaced with it; then you'd be getting the best of both worlds.

That's my plan, in any case. :smile:

drrck said:
Another good example is pointers.

I would say this more strongly: pointers are basically the bane of new C/C++ programmers. Other languages hide them, to some extent, and understanding pointers always helps you be a better programmer, but in C/C++ you need at least a basic understanding before being able to do even basic tasks such as string manipulation, whereas in other languages you can get away with not knowing about them for a lot longer.
0.0/51