CeeLanguage is often asserted to be better than most (or all) other languages, especially in its primary domain of systems programming. However, detractors often assert that its alleged advantages, such as compact code or faster run-time, are illusory or misleading, because it requires a greater programming effort to get a certain result than a more abstract language would, and that the resulting code is often more susceptible to serious bugs as well. This page is set up so that C partisans can assert any objective and preferably quantitative reasons why C is superior, either in a specific problem domain or in general, as well as for any counter-arguments by C detractors.
- Execution speed? CeeAlso: AsFastAsCee, FasterThanCee
- Requires only the c library, which isn't a runtime (no overhead, no other processes running) and is present on all major operating systems.
- Possesses a very simple call-interface, which made it the standard ApplicationBinaryInterface?. (abi)
- Benefits from mature, high-performance compilers, by the virtue of being relatively simple to implement.
- Not offering StrongTyping, TypeInference and other modern static typing, it stays flexible and extensible through its use of ManifestTyping and WeakTyping.
- ''Benefits from having a compiler on new EmbeddedSystem platforms. In other words, CeeLanguage is more CrossPlatform? than any other language. (Well, after I fiddle with the MovingGoalPosts so I can claim that AssemblyLanguage and ForthLanguage don't count).
- Fiddling with goalposts is not needed to elminate AssemblyLanguage; given that it isn't a single language, but a set of languages related only by the fact that they serve the same purpose--abstracting the instruction set of CPUs. Code written for x86 assembly needs to be completely rewritten for PowerPc or SPARC or ARM. As far as ForthLanguage goes, that one I don't know about--you might be correct given that many ultra-low-end CPUs may find it easier hosting Forth than C. OTOH, excluding those sorts of platforms, C certainly has more mature implementations on 32-bit and better architectures than Forth does. Plus, I like the compiler to keep track of stack frames for me, rather than having me do it manually....
- You can reasonably exclude Forth for the simple reason that some programmers (a majority? a strong plurality? I don't know) simply cannot deal with an exposed stack (two of them, actually) as their only execution model. I think it's very diagnostic to look at how many languages look like C and Algol and how very few look like Forth. (In fact, the only three Forth-like languages I know of that don't claim to be Forth dialects are PostScript, which few people write by hand, RPL, the programming language for HewlettPackard's calculators, and JoyLanguage, a functional language that is based on the composition of functions.) (JavaVirtualMachine bytecode doesn't count: I don't think Sun officially offers JVM assemblers, and it isn't portable beyond the relatively few systems that have a working JVM implementation. An assembly language for a VirtualMachine is still an assembly language.)
- Established knowledge base, and ease of finding information about it. It is much easier to find a good book on C than a good book on Common Lisp or Objective Caml.
- Established resource base. You want to use a GUI library? They're written in C or C++. You want to use a library for graphics, sound, mathematical transformations, database interface, networking, or just about anything else? The first one you find is probably going to be written in C or C++.
CategoryCee