07 Jan, 2009, Baiou wrote in the 1st comment:
Votes: 0
I'm kind of working on a mud from scratch in my free time and I was wondering your opinions on whether anyone would actually use a new codebase written from c++.
07 Jan, 2009, Kayle wrote in the 2nd comment:
Votes: 0
If I wasn't already converting Smaug to C++ I'd use it. but alas. I'm converting Smaug. :P
07 Jan, 2009, elanthis wrote in the 3rd comment:
Votes: 0
Short answer: Yes. So long as the codebase actually offers something noteworthy over Diku/etc.

Long answer: There will not be a huge influx of users scrambling to get at your MUD. You will have trouble getting adoption because your MUD is from-scratch and unknown and not a Diku-derivative clone, not because it's C++. All of the snippets and tutorials and HOWTOs and the like are for the classic codebases, and most all the existing popular MUDs are using one of those classic codebases, so when newbies come looking for a codebase for his new MUD he's going to immediately look for Diku/ROM/Circle/whatever instead of looking for a clean newbie-friendly codebase. You're going to have to build a reputation and a following. You're going to need an actual MUD using your codebase to really drive up demand for it, which means you either need to think about a full MUD in addition to just a code base, or you're going to need to find a "champion" for your codebase who's willing to run a MUD on top of it without demanding that you be his full-time personal coder. It's going to be hard to create a compelling codebase if you don't have a real MUD in mind when making it, btw, unless you are just planning on implementing a bare-bones, easy-to-extend codebase a la SocketMUD.
07 Jan, 2009, Baiou wrote in the 4th comment:
Votes: 0
You are absolutely right Elanthis. My original plan was to make a backbone mud language for people who wanted to make a mud from scratch. It would've been the "DirectX" for muds, but now I've pretty much decided that it'll be best to just build a full fledged mud and pass off the code the way it is at that time or hopefully bring in a team that will help the development. What do you think the chances of gaining some attention are if I provide help files such as building manuals/programming manuals?

Oh and Kayle, I thought i saw a Smaug C++ around somewhere… I could be mistaken.
07 Jan, 2009, Zeno wrote in the 5th comment:
Votes: 0
No.

C++ sucks.

Oh Linus. :P
07 Jan, 2009, elanthis wrote in the 6th comment:
Votes: 0
Baiou said:
What do you think the chances of gaining some attention are if I provide help files such as building manuals/programming manuals?


AweMUD got quite a bit of attention back in the day, without any manuals and without even being a complete game. Nobody to my knowledge ever built a real MUD off of it. Sad fact of the MUDing community is that there's like 30 of us who know how to code and 100,000 of us who want to run a MUD (and about 20,000 of us who actually play the damn things). :/

Zeno said:
C++ sucks.

Oh Linus. :P


Linus is a moron sometimes. :) By his own logic, C is a truly shitty language because of how much horrific kernel code there has been submitted to lkml. ;) Seriously, his sole argument is "really stupid programmers have written a lot of code in C++." In fact, by that logic, I can prove that C is the worst language ever invented: just look at any classic MUD codebase or derivative. ^__^
07 Jan, 2009, Grimble wrote in the 7th comment:
Votes: 0
Kayle said:
If I wasn't already converting Smaug to C++ I'd use it. but alas. I'm converting Smaug. :P


I see this so often and have to ask… what's the point?

C++ enables an object-oriented design and taking advantage of encapsulation, modularity, polymorphism, and inheritance (and more). Unless you're overhauling the entire design of Smaug into something object-oriented (which is more trouble than starting from scratch), you're wasting your time.

For the original poster… Invest your effort in the design, and then decide whether you want to implement it in C++, Java, Python, Ruby, VB.NET, C#, etc (you get the picture).
07 Jan, 2009, Baiou wrote in the 8th comment:
Votes: 0
Seems like it might be worth it to take a stab at making one. I'll just have to take into account said things.
07 Jan, 2009, Chris Bailey wrote in the 9th comment:
Votes: 0
Why convert Smaug to C++? Maybe for the same reason some of us design muds that we know won't be played. For fun! =)
08 Jan, 2009, Sandi wrote in the 10th comment:
Votes: 0
My guess is, they're not teaching C in school anymore.
08 Jan, 2009, elanthis wrote in the 11th comment:
Votes: 0
Sandi said:
My guess is, they're not teaching C in school anymore.


They're not teaching C++, either. Good luck finding a school outside of the special few that teaches anything other than Java (and maybe a little VB for diversity). It's pathetic.

So far as I'm concerned, any school that doesn't teach a wide variety of languages (which is necessary to _really_ understand computer science, as opposed to just understanding a syntax a cookie-cutter design patterns) isn't worth the damn tuition.
08 Jan, 2009, Hades_Kane wrote in the 12th comment:
Votes: 0
Sandi said:
My guess is, they're not teaching C in school anymore.


When I was attending College, I was trying to find a C course, but alas I could not.

I was hoping for some real training on the language to maximize what I could do with my game, but I finally just went about it in the "let's make a backup, change this, and see what happens" method.
08 Jan, 2009, Kelvin wrote in the 13th comment:
Votes: 0
elanthis said:
Sandi said:
My guess is, they're not teaching C in school anymore.


They're not teaching C++, either. Good luck finding a school outside of the special few that teaches anything other than Java (and maybe a little VB for diversity).

Nah, they still teach it. There are C and C++ (along with Linux and Unix) courses here at Clemson. It just really depends on your focus and the school.
08 Jan, 2009, Kayle wrote in the 14th comment:
Votes: 0
Grimble said:
Kayle said:
If I wasn't already converting Smaug to C++ I'd use it. but alas. I'm converting Smaug. :P


I see this so often and have to ask… what's the point?

C++ enables an object-oriented design and taking advantage of encapsulation, modularity, polymorphism, and inheritance (and more). Unless you're overhauling the entire design of Smaug into something object-oriented (which is more trouble than starting from scratch), you're wasting your time.

For the original poster… Invest your effort in the design, and then decide whether you want to implement it in C++, Java, Python, Ruby, VB.NET, C#, etc (you get the picture).



Chris Bailey said:
Why convert Smaug to C++? Maybe for the same reason some of us design muds that we know won't be played. For fun! =)


CB half nailed it. For fun, and to offer a modernized version of Smaug sometime down the road. It probably would have been easier to start over. But it wouldn't have made a difference to me one way or the other. I'm still doing it to do it, and I figured the road with more challenges would teach me more than just writing my own base from scratch. After all, isn't the point of programming to challenge yourself and the code and push limits? If I can take Smaug, Convert it to C++ and then apply an Object oriented design to it (I've already established encapsulation on char_data…), and then someone else uses it, applies their own modifications to it, and makes it better, Why not?
08 Jan, 2009, David Haley wrote in the 15th comment:
Votes: 0
To answer the earlier question, I agree that you will have many other problems for adoption than just the programming language you choose. In fact, you might have less trouble with C++ than with e.g. Lua, Python or Ruby given that most people who can read C can more or less read C++ (or at least the more straightforward features).

Grimble said:
I see this so often and have to ask… what's the point?

C++ enables an object-oriented design and taking advantage of encapsulation, modularity, polymorphism, and inheritance (and more). Unless you're overhauling the entire design of Smaug into something object-oriented (which is more trouble than starting from scratch), you're wasting your time.

Well, you've sort of answered your own question here. Either he's not doing much of anything, in which case the process is very quick and not time is wasted. Or, he's taking advantage of those features he deems valuable, and he isn't wasting his time. :smile:

Remember that you don't have to convert the whole shebang in order to get value added…

Sandi said:
My guess is, they're not teaching C in school anymore.

Where I went to school, C had just recently been phased out in favor of Java and C++. But frankly, teaching C++ is more or less the same as teaching C, so I wouldn't be worried about that. Anyhow, we had to use C for various systems classes like Operating Systems or Networking. But it's true that many schools are moving away from C++, for reasons that would take too long to get into now.

It's worth noting that knowing how to very properly program in any language should help you write better code in any other language. People tend to get kind of unnecessarily hung up about syntax. I guess the only real complication that C/C++ present that you don't find in many other languages is having to deallocate memory when you're done with it.
08 Jan, 2009, Igabod wrote in the 16th comment:
Votes: 0
I'd be interested in knowing the reasons many schools are moving away from C++. We should probably create a new thread for that but I'm very interested in your opinion on this matter david.

At my school they taught only one programming course, basic. The other computer related classes were keyboarding, networking and some crap dealing with spreadsheet analysis that I never really cared enough about to find out anything more. I took the keyboarding class and basic and even had a blast using basic to make games on my TI-82 calculator.

Now I don't know of any real use for basic but it was fun learning it at the time. I just wish I still had that old calculator, I had a bunch of really cool mini-games on it that me and my best friend at the time made.
08 Jan, 2009, Mister wrote in the 17th comment:
Votes: 0
Zeno said:
No.

C++ sucks.

Oh Linus. :P

Linus is right, but only because he is talking about programming at a low-level, closer to the machine, without big abstractions, as in kernel development. In that thread, he is referring to the use of C++ in Git, a revision control system created for Linux kernel development. Besides this reason, it would be necessary to recode the whole thing to start with.

However, many of his points are true: C++ is ugly and complex, mainly due to its backward compatibility with C. It's complexity gives compilers a hard time on the obscures corners of the language (the same can be said on many languages.) And it's lack of some high-level features (such as garbage collection) are because the designers of C++ didn't want to force users to adopt a particular design.

An interesting, C/C++-like language is D. It would be interesting to see a mud codebase in that language. I tried once, but the inmaturity of the language, and the lack of a compiler on hosting servers, made me quit the attempt.
08 Jan, 2009, Baiou wrote in the 18th comment:
Votes: 0
hrm D. Is that the official D language?
08 Jan, 2009, elanthis wrote in the 19th comment:
Votes: 0
Mister said:
Linus is right, but only because he is talking about programming at a low-level, closer to the machine, without big abstractions, as in kernel development.


No, he isn't. C++ was designed for – and has been quite successfully used in – kernel development. Do NOT make Linus' stupid mistake of assuming that C++ forces you to code like a retard. After all, any kind of overly abstracted mess of crap that you can do in C++ you can also write in C – I've seen it done more than a few times. C++ makes it easier to do certain stupid things, sure, but it also makes it easier to do quite a few smart things.

Linus is wrong on this one. Plain as that. Just because schools spit out programmers whose sole curriculum was "design patterns" and were never introduced to low-level programming (or other forms of programming besides OOP) does not mean that C++ is only good for those kinds of coders. That is wrong wrong wrong.

Quote
However, many of his points are true: C++ is ugly and complex, mainly due to its backward compatibility with C.


There are maybe three ugly parts of C++ that I can think of which are really because of C, and those parts are absolutely every bit as ugly in C. Not a strong argument for preferring C over C++ for any use case. Heck, one of those ugly bits won't even exist until C++0x is released (although it might win the title of "ugliest of all" :) ).

Quote
It's complexity gives compilers a hard time on the obscures corners of the language (the same can be said on many languages.)


Most of those "obscure corners" are actually bugs in the specification – areas where the specification is ambiguous or missing. Those are addressed as new versions of the standard are released.

Personally, I don't know why people consistently claim that C++ is "too complex" to understand. I believe it comes off as complex to most people because they simply don't know what the hell they're doing, don't know how to read a technical standard, and don't have any experience with languages lower-level than Java. When people do learn C++, they usually learn it by example rather than by formal grammar and specification. If you actually try to understand C++ it's really quite easy. The only big complexity at all is the fact that C++ needs to know what an identifier is the moment the tokenizer encounters it, which I would rather it didn't require, but if you remember that fact, C++ is pretty easy to grok.

Compiler complexity comes in more from the code generation than the C++ parsing or semantic analysis. Templates in particular require a lot of extra code generation support, but oh man are they ever worth it. :)

Quote
And it's lack of some high-level features (such as garbage collection) are because the designers of C++ didn't want to force users to adopt a particular design.


Not exactly. The lack of mandatory GC is because C++ is designed for systems level programming, e.g. use in a kernel. GC is a no-go in those arenas. GC has however been possible in C++ for just about always, so long as you didn't mind using a low-level add-on library. Compilers have never added integrated support for those, but nothing has really stopped them from doingso. C++0x adds some preliminary official support for garbage collection primitives which will finally prompt compilers to integrate those libraries and then make application developers much happier. (Essentially, C++0x defines a memory model in order to support official threading and GC, adds rules for when GC is legal and when it isn't, and defines a means for C++ translation units to declare whether they require/support/break GC.)

Quote
An interesting, C/C++-like language is D. It would be interesting to see a mud codebase in that language. I tried once, but the inmaturity of the language, and the lack of a compiler on hosting servers, made me quit the attempt.


D suffers from a number of problems, foremost of which being that it is a moving spec written by a single guy with no clear public design process or goals in place. On top of that, its standard library is total crap – and the community's replacement standard library is just bad.

There are few libraries and few tools for D users. There really isn't any good reason to use D over something like C# if you're looking for that high-level of a C++-like language. The D features matrix can make it look compelling next to C#, but then that matrix leaves off a vast number of C# features (especially from C# 2 and C# 3) that make C# way more attractive than D. D advertises "native compiled code" as a compelling advantage, but I disagree that it really is one. D is no easier to integrate with other native-compiled languages than C# is (both require you to define C module maps, and neither can easily be used with a C library that relies heavily on macros for its API), so there goes half the advantage of native compilation.

The remaining supposed advantage is performance, and this one is certainly a clear winner for D. That said, picking D over C# for performance in your average application makes as much sense as picking Assembler over C or picking C over Python. Plus I'm not convinced that native compiled code is going to hold the performance crown for much longer. The techniques being used in modern high-level languages run times are already able to give C a run for its money, and these are first- and second-generation implementations of those techniques. Once those techniques mature and begin finding their way into production VMs for languages like C# or Java, native-compiled code could easily lose its performance crown. The only way languages like C and C++ would be able to keep up would be if they were used with a compiler like Clang that could compile the code to run on an enhanced LLVM.

Essentially, high level languages today have the same advantage over C/C++/D that C has over assembler: the guy writing the code can't possibly write it in the most efficient way for the complexities of current computer architectures. Truly optimized code has to do a lot of things that are very illogical at a glance to work around the performance peculiarities of deep-pipeline CPUs, high-speed DRAM, multi-core designs, high-bandwidth/high-latency buses, and so on. It used to be (relatively) easy to write assembler that out-performed most equivalent C code, but these days C/C++ compilers pull off a lot of tricks behind the programmer's back to get decent performance. To get the best performance, though, coders generally have to resort to profiler-guided-optimization, which is where the compiler takes statistics from actual runs of the program in order to recompile it to run faster. This is where the new techniques in language runtimes/VMs come into play – they can essentially perform those optimizations on the fly, and thus take into account far more variables and local criteria that even profiler-guided-optimization can't hope to achieve. Combine that with on-disk caching of the JIT-compiled code to avoid large startup delays for applications (Microsoft's .NET implementation does this, iirc) and it should be possible for VMs to pull off even better performance than any native-compiled code.

We're also likely to start seeing hardware designs that take into account the peculiarities of garbage collection, JIT-compiling runtimes, and so on. Right now CPU designs have a lot of circuitry designed to optimize traditional native-compiled code but almost nothing that helps with managed runtimes or VMs. Given that the industry as a whole is slowly moving to using languages like Java, C#, JavaScript, Python, and so on for pretty much everything, it makes a lot of sense for hardware designs to start optimizing for those runtimes.
08 Jan, 2009, Fizban wrote in the 20th comment:
Votes: 0
My high school taught C and C++ as their only two languages. Considering I only graduated in 2007 I'm not sure I can say I've seen any affects of schools pulling away from C/C++. I can though say that in college the first classes they tried making you take were Java and not C or C++. I don't care for Java, at all, and learned it just well enough to test out of the class and not be bothered by it. There are several newer languages which I do care for, but they're all interpreted, something Java isn't. As far as compilable languages are concerned I really don't see C++ being replaced as the standard for quite some time.
0.0/35