Talk:C

That such statements like "C is fast" or "C is highly portable" are misleading should be obvious to most programmers. I can write highly unportable and very slow C code - don't dare me! ;)

And then there was this statement:

• Lack of classes makes it hard to do an object-oriented design, limiting project flexibility (so you have to plan ahead)

The author claims that OOD automatically makes a project "flexible" and that non-OOD based projects have to "plan ahead". I see no proof for this statement. I use C and I never had to rewrite, unlike many developers who use OOP languages and I didn't "plan ahead" for sure. The often claimed superiority of OOP is unproven, especially as far as roguelikes are concerned because not one of the major RLs is based on real OOP. I don't want to say that procedural programming is superior, in fact maybe OOP is indeed superiour but please don't write such stuff here until its proven.

In general I ask everyone to avoid "language wars" in these articles. If editors claim that "lack of OOP support" is a "Con" some functional programming zealots might start adding "lack of real FP" to all languages. Know what I mean? --Copx 17:26, 8 Oct 2005 (CEST)

I wrote the original article. Most of your edits are fine, but I think some of them are obfustication. "C is fast" is a good take-away point. You replaced that with several sentences that amount to the same thing. In general I agree that more information is better than less - but it's good to boil things down to talking points the Pro/Con bullet list, is it not?

Your changes also de-emphasize some rather critical points I made about C, namely the lack of native GC. This is an important point for practical RL dev, IMHO.

OOP vs. procedural programming is a side issue and perhaps is best addressed in a separate article.

I think some of my points regarding C's lack of modern language features are valid and of practical concern for RL devs and should be re-instated.

I approached this article as writing a practical guide for RL devs. Anyone interesting in C as a language in and of itself will always be better served by wikipedia, where a lot of the concerns you raise are answered.

[[User:Shedletsky|???John Shedletsky^Talk ]] 00:26, 9 Oct 2005 (CEST)

Sorry, but statements like "C is fast" or "C is portable" are simply incorrect. C can't copy bytes from one memory area to another faster than other languages for example. It's just that typical C code does different things than similar code in higher level languages. For example another language might do bounds checking by the default in such cases so the operation is slower but that doesn't mean that "C is faster". I could write/use a C routine that does bounds checking, and such a routine would have the same performance characteristicts as the functinon used by the higher level language.

As far as the other stuff is concerned: You wrote "IMHO" and that's the point. It's just your opinion, not a fact. You mentioned wikipedia so you probably know what NPOV (Neutral Point of View) means, you can write that C has no garabage collection by default and mention the issues of manual memory management but you can't write that C is an inferiour choice for roguelike development. Community-based wikis are no place for "A is better than B" statements 'cause I ensure you that people won't agree.

If you want to write some "Why OOP is a superiour choice for RL development" article do it on your own homepage and post a link. Or do it here and clearly mark at as your personal opinion, not as some unquestionable fact. --Copx 10:20, 9 Oct 2005 (CEST)

I think that John's point was that something like "C is fast" would imply not that C itself is fast (though it really is - a language like Java will be slower if we're comparing the ideal same C program to the ideal Java program), it would imply that usually a game written in C will be faster. C allows the programmer to write a program that runs faster than one written in another language. Java allows the programmer to use OO to better organize the code. These sorts of statements shouldn't be excluded on the basis that someone may say "hmmph, well I program in C and my code is well organized!", because they do describe what is typically true of a language and what makes it distinct in practice. Then again, saying "C is fast" without explaining what is meant probably isn't desirable either. [[User:M|–M^T]] 00:50, 10 Oct 2005 (CEST)

"you can't write that C is an inferiour choice for roguelike development". I don't think I wrote that. Geez. Get off my case. I don't have any patience for language demogoguery. Given two languages, A and B, that are otherwise identical, if A has garbage collection and B doesn't, then most people will agree A is better. This doesn't reflect on C as a language itself, but lack of garbage collection is definitely a minus and that was my original point.

Furthermore, C is fast. You are complicating the issue. Like M says, when you get down to it, C is just faster than anything except possibly assembly.

As far as wikipedia goes, I only mentioned it because it's a good source for people who want more details about the C language itself, as opposed to info that might help them decide whether to write a RL in C. For instance, wikipedia will supply you with the details supporting the claim "C is fast".

[[User:Shedletsky|???John Shedletsky^Talk ]] 04:05, 10 Oct 2005 (CEST)

I agree with both of you. You can't give a blanket statement like "C is fast" without then describing what that entails and how that's relevant to the development of a roguelike. C is and isn't faster - "C allows a programmer to write programs that run faster than they would in most languages because...". You also have to say things like that, that a language is better organized, or that it can do this or that better, regardless of how well it can be done in another language. You may be able to organize your code very well in C, but if you were using Java, you'd do an even better job - that sort of thing. Take visual basic dot net. I think I can safely say (since I've used it professionally for a period of time) that it's slow, non-portable (despite windows emulators on *nix), has a terrible editor (even if you can get a nice one elsewhere), that the API is poorly documented and occasionally buggy, that the exception handling is... odd, and that the code looks silly, but also that it integrates with ms software quite well and that it's comparatively easy for a non-programmer to do something in. But I think I went off on a tangent there. Instead of arguing about this stuff, propose some changes, and don't let things get too personal. We're all trying to make the articles here better, not worse. [[User:M|–M^T]] 07:23, 10 Oct 2005 (CEST)

The lack of garbage collection is a non-issue for me. It takes about a two minutes to write a allocation/deallaction combo and typical C code won't need much of those. Detecting possible memory leaks is also no problem because you can just link your code against checked versions of malloc or run it through valgrind to find those. If you don't want to handle manual memory management you can easily link your code against a garabage collector library. Nothing stops you from using one with C. And "C is fast" still isn't correct. Other languages are slow by design, they force overhead on you but that doesn't meant that you couldn't add that overhead to your C program. C only makes faster code possible. --Copx 09:24, 10 Oct 2005 (CEST)

I could easily argue that the lack of garbage collection is a language feature. Garbage collection leads to programmers becoming lazy about tracking ownership semantics for objects. This then leads to them getting hopelessly confused when they have to marshal said objects onto disk. --JeffLait 18:27, 11 Oct 2005 (CEST)

Forced memory management should not be used to teach programmers proper OOD. And from what I recall, Java and other GC languages will not force programmers to marshal objects onto disk, since they implement serialization, which marshals the objects for them. The problem that you describe with persisting objects is cycles in your object model, correct? This is as it should be. Object models can, and in many (or most) cases should, have looping referances. We shouldn't force an object model into a tree just for the sake of making our own home-grown persistance mechanism easier to implement. GC is a feature in any programming language, thouh it may be a detrimental feature if you'd like to implement a real-time system, or if you're the type of programmer (and this isn't directed at you, since you look like you know what you're talking about) that needs manual object management to remind you to create a good object model. [[User:M|–M^T]] 20:41, 11 Oct 2005 (CEST)

Just as a side note to people posting about C. Speed in a programming language only makes sense if it is a comparative measurement. It is true that C doesn't access memory faster than any other language. When people say "C is fast" compared to say, Java, for example, what they usually mean is this: Java uses bytecode and a virtual machine, whereas C is compiled down to machine code.

To execute a command, Java must interpret the command through the bytecode, and then through the virtual machine, and finally to the machine level. More translations (steps) equals more time, irregardless of programming language. Additionally, Java is a language built (from the bottom up) in an OOP manner. As with any language that uses the OOP paradigm, many times there are various object translations and calls that need to happen before the command can execute, thus adding more time.

C doesn't have to worry about any of that -- no bytecode, no virtual machine, no OOP calls, no nothing that adds extra steps to execution time. It interfaces directly with the machine. In this sense (and only this comparative sense) can we start sensibly talking about the run-time efficiency of various programming languages.

But, as stated before by someone else, I don't think run-time efficiency is essential information to a roguelike game developer. I agree that this article should be tailored to practical concerns. I personally don't see an issue with writing outside that bound, but I think that those things should be written with context in mind.

Sorry, I think that a mis-communication/misinterpretation was happening regarding both C and the intention of some contributors.

--Sean Brown Oct 14th 2010, 5:17PM (PST)