09 Mar, 2011, Chris Bailey wrote in the 41st comment:
Votes: 0
Moh-Rahn said:
Starting with a language that is not C is fine as long as you don't plan on learning C later in the future. In other words, if you learn some crap like Python, you might never be able to learn programming in C properly.


..What?

I think if your interests lie primarily in mud related programming you should consider languages more suited to it. Perhaps some crap like Python, or better yet, Ruby. That being said, dead-souls does seem like a good option for you.
09 Mar, 2011, Kalinash wrote in the 42nd comment:
Votes: 0
Rarva.Riendf said:
Totally wrong, learning with C first is totally mad, you should start with assembler (and I mean that) at least some basic notion of it.


Heh, I said just that (about assembler) not more than an hour ago. Most people think I'm totally mad at that point :)
09 Mar, 2011, Runter wrote in the 43rd comment:
Votes: 0
There is no shortcut. Research books before you buy them. Then you'll be much less likely to pick up ones that don't fit your taste.

There are a lot of good books in print that are available in previous editions full and freely on the internet. Those aren't bad places to start.

Some books I have in my shelf pertaining to Ruby include The Pragmatic Programmer, The Ruby Way, Programming Ruby.

Keep in mind, most of the time books are written for learning languages & intro to programming at the same time. The quest of learning to program and learning a specific language just happen to be two destinations you may get to about the same time. So figure out which tool you plan to want to learn first and do that. But don't listen to nonsense about how you have to learn a specific tool first or ruin your opportunity to ever learn it.
09 Mar, 2011, quixadhal wrote in the 44th comment:
Votes: 0
Just to toss my pure opinion in here…

C (and thus C++) is a *HORRIBLE* choice of a language to write a text game with, because C (and C++, even with STL and boost) doesn't deal with strings as a native data type… and when you're writing a text game, you are going to be spending 90% of your time writing code to manipulate strings.

Most of the arguments people have used for C/C++ don't apply to text MUD's these days. In 1990, a popular MUD would use up the WHOLE 16 Megabytes of memory that a server had, and the poor little i486 CPU might well be pegged at 90% with only 30 players running around. Nowadays, your cell phone can run that MUD.

I would also suggest working with something like an LpMUD or perhaps a ruby codebase like CoralMUD, for the simple reason that in both cases, they already handle all the technical nonsense of sockets/command parsing/etc, which is probably NOT what you really want to spend your time on. If you're learning, you'd probably rather learn how to make things happen. Once you become more comfortable with coding in general, you can always delve deeper into the inner workings of either system and go write your own, if you like.

Also, ignore foolish things like what Moh-Rahn said about C. The young are often silly. I learned BASIC first, then assembly, then Pascal, before I really did anything with C. C is still my strongest language, and it's still my LAST choice for doing anything involving text. Any decent programmer can learn any new language. The smart coder learns to use the right tool for the right job.
09 Mar, 2011, Vigud wrote in the 45th comment:
Votes: 0
I often hear people saying "gee, I'm writing something in C and it's a pain… Python/Ruby/Scheme/whatever is so spoiling…". Just saying.
09 Mar, 2011, Runter wrote in the 46th comment:
Votes: 0
Vigud said:
I often hear people saying "gee, I'm writing something in C and it's a pain… Python/Ruby/Scheme/whatever is so spoiling…". Just saying.


That's cause writing something in C is indeed such a pain.

Your claim might have more to it if people were saying "Omg, I learned Python and now I've lost all ability to learn anything lower level than Python. It's unbelievable, because it's like magic and doesn't make any sense." But people probably haven't said that.
09 Mar, 2011, Vigud wrote in the 47th comment:
Votes: 0
Quote
I learned Python and now I've lost all ability to learn anything lower level than Python.
If you replace "ability" with "motivation" then that's also what I hear frequently.
09 Mar, 2011, Rarva.Riendf wrote in the 48th comment:
Votes: 0
Conclusion for the first poster:avoid C or C++ in the codebase of your choice at all cost unless the real goal is to learn those langages.
Or resurect an old game you were found of that happens to be in C.
Not worth the time, especially for a text game. It will only frustrate you at how hard it is just to make a stupid string duplication/trim/concatenation without memory leak when every other langages that has a garbage collection make it easy. (not bullet proof but better than going around naked like in C)
09 Mar, 2011, David Haley wrote in the 49th comment:
Votes: 0
Although learning from existing code is a good idea and how many if not all people here started (one way or the other), you should take it with a grain of salt. The code won't always be terribly good and sometimes has downright bad practices. It's hard to keep that in mind when you're only just learning, but just don't always take everything you see as "gospel code".
09 Mar, 2011, quixadhal wrote in the 50th comment:
Votes: 0
Here's a great example of some really BAD C code. Don't do things like this. This is in the ever-popular ROM codebase, and probably in most derivatives of it as well. Consider finding WHY this code is so horrible a learning exercise.

PS: It's not important what number_mm() actually does, but it returns a (hopefully) 32-bit number with 26 bits of randomness. I say hopefully, because it assumes that both an int and a long are 32-bit.

/*
* Generate a random number.
*/
int number_range( int from, int to )
{
int power;
int number;

if (from == 0 && to == 0)
return 0;

if ( ( to = to - from + 1 ) <= 1 )
return from;

for ( power = 2; power < to; power <<= 1 )
;

while ( ( number = number_mm() & (power -1 ) ) >= to )
;

return from + number;
}
09 Mar, 2011, Rarva.Riendf wrote in the 51st comment:
Votes: 0
quixadhal said:
PS: It's not important what number_mm() actually does

Snicker, but it is equally bad (if not worse)
09 Mar, 2011, Vigud wrote in the 52nd comment:
Votes: 0
That function is sub-optimal and not portable but how is it "really BAD"? What am I missing?
09 Mar, 2011, David Haley wrote in the 53rd comment:
Votes: 0
As random number generators go, it's pretty bad… it's reimplementing functionality it shouldn't… it doesn't explain the magic steps in the generation process with comments… what if the number needs more than 26 bits of randomness… etc.

Depending on just how "sub-optimal" you think it is, that alone could be reason enough to be "really bad"…
09 Mar, 2011, Tyche wrote in the 54th comment:
Votes: 0
Vigud said:
That function is sub-optimal and not portable but how is it "really BAD"? What am I missing?


Like you, I'm awaiting my education.
10 Mar, 2011, Tyche wrote in the 55th comment:
Votes: 0
Oten said:
The thing that drew me to the minimalist/barebones servers is that I can be fully aware of how everything works, but the disadvantage is that I guess that I have to write a lot of the systems myself, theres no support for the areas to be written in a format that is familliar, etc.


Exactly.

Oten said:
I'll look through some ROM code today, see how things operate, and then maybe i can get a grasp on how to implement some things. Being new to coding (i know roughly how to declare and use if/then/else statements), this should help greatly.


C is remarkably easy to pick up because it's a simple language, and there are hundreds of well-written tutorials on the net. One of the problems with C is it's not made to be safe amd you can walk all over memory and create some hard to find errors. Typically I see in mud posts, that someone learning C introduces an error and is unable to debug the error. And usually they can't roll back their code to where they introduced the error, so they start all over again. ;-)

My best advice would be to make sure whatever code or language you are using is to make sure you use some form of source version control.
That could be as simple as creating a daily backup or learning to use something more flexible like subversion or git.
10 Mar, 2011, Vigud wrote in the 56th comment:
Votes: 0
Well, git is not that easy as one would think, I think you should try Mercurial. http://hginit.com/
If you decide to write in C, one good way of finding bugs is using a debugger. http://www.gammon.com.au/forum/?id=3653
Another good way of finding bugs is not trusting GCC, because it's more tolerant to bugs than other compilers. Either don't use it or use it along other compilers.
10 Mar, 2011, David Haley wrote in the 57th comment:
Votes: 0
Do you have an example of a 'bug' that gcc would be tolerant of that another compiler would report as a bug? What is a 'bug' in this context?
10 Mar, 2011, quixadhal wrote in the 58th comment:
Votes: 0
You guys really didn't notice this???

while ( ( number = number_mm() & (power -1 ) ) >= to )
;


A while loop that only terminates when a random number happens to fall within the range requested? Which, in theory, could be never?

Best case scenario, it spins a handful of times through the process of generating a new random number, throwing away results that were deemed unacceptable. Worst case, it spins through thousands (or millions) of them, pegging the CPU at 100% while doing work that will be discarded.

Well, I guess absolute worst case… the random number gods hate you, and you NEVER get the result to fall within the range you wanted, and so your mud hangs.
10 Mar, 2011, Vigud wrote in the 59th comment:
Votes: 0
David Haley said:
Do you have an example of a 'bug' that gcc would be tolerant of that another compiler would report as a bug? What is a 'bug' in this context?
I meant that GCC turns undefined behavior into ok behavior most of the time, so a program compiled with GCC can work flawlessly, but doesn't have to work as expected (or at all) if compiled with another compiler. But I happen to be aware of both kinds of GCC's tolerance - it doesn't warn you when others do and produces safer code to hide your mistakes, so you never have a chance to correct them.

As for examples, I just need to think of a good, short testcase, because I have a real-life example from a MUD I've been co-developing at hand, but it would be unclear without the context.

quixadhal said:
You guys really didn't notice this???
while ( ( number = number_mm() & (power -1 ) ) >= to )
;
A while loop that only terminates when a random number happens to fall within the range requested? Which, in theory, could be never?

Best case scenario, it spins a handful of times through the process of generating a new random number, throwing away results that were deemed unacceptable. Worst case, it spins through thousands (or millions) of them, pegging the CPU at 100% while doing work that will be discarded.

Well, I guess absolute worst case… the random number gods hate you, and you NEVER get the result to fall within the range you wanted, and so your mud hangs.
But that's bad algorithm, not bad C code (apart from being non-portable). Design doesn't know programming languages.
10 Mar, 2011, Runter wrote in the 60th comment:
Votes: 0
Yeah, I agree with Vigud. That's good C code, but this is best C code.
while(1)
;
40.0/86