What's To Love About C? 793
First time accepted submitter edA-qa writes "Antiquated, clunky, and unsafe. Though beloved to some, C is a language that many choose to hate. The mass opinion is indeed so negative it's hard to believe that anybody would program anything in C. Yet they do. In fact a lot of things, even new things, are programmed in C. The standard was recently updated and the tools continue to evolve. While many are quick to dismiss the language it is in no danger of disappearing."
Shorthand for Assembler (Score:5, Interesting)
Where'd the Unix go? (Score:4, Interesting)
Because its fun (Score:2, Interesting)
I'm writing a game in C. I spent a lot of time trying to decide what language to use for the game: Java, C#, Python, C++. Ultimately I decided that I wanted to write the whole thing myself so I didn't have to rely on any releases of virtual machines.
I find it fun. I write in C++ for my job and that is where I spent most of my education. C is an interesting challenge where I don't get all of my comforts. But, it works. I tried writing the game in C++ and I kept getting lost in infrastructure: Objects or get-it-done function? I had to decide all the time. C drops that for a simple set of rules (to me, but I "grew-up" in C++ so I'm used to managing memory) that helps me get the job done. I'm still learning, and I work on infrastructure some to reduce complexity, but its fun.
Re:Good habits (Score:5, Interesting)
Problem is the diligence that is required. A C developer is a really good coder when they do their work in an other language. However for large projects, C doesn't make too much sense, because you need to expect your developers to be on their A Game in the course of the project. A developer is porting their proof of concept code into production, right near lunch time, and he is starving, and some of the other guys are waiting on him to finish up, because they are starving too, might mean some code got copied in, and put into the production set, without full though. Because the Proof of Concept code worked, it may pass many layers of Quality Check (and we all know most software development firms have very poor QA teams) Once it leaves and goes to the customer, it could be wide open to a security problem.
Every Developer thinks they are the best developer on earth about 50% of them are actually below average. C is a great teaching tool, I wish most colleges still used it, and didn't switch to .Net and Java. However once you go into production, unless you really need the C performance (and you can code highly optimized C) going with other Languages that are a little more protected is a safer bet.
Hire a C developer... Give him a higher level language, and you will probably get really good code.
Hire a C developer have him program C, you are setting up a time bomb, where once they miss a beat you are screwed.
Re:One good reason... (Score:5, Interesting)
I like C++, but I can think of a few. Lets ignore for the moment things like macros that are outdated in C++ and kept for C compatibility. We can easily get rid of:
*Value templates.
*Diamond inheritance (just make it illegal)
*The entire algorithms part of the STL. Nobody uses it and it makes for unreadable code (keep the container classes, of course)
*Kill either structs or classes. We don 't need both, with one being syntactic sugar to change the default visibility on the other
*The iostream libraries. I don't think I've ever seen code that didn't say fuck that and just use C style stdio. They're clunky.
That's off the top of my head, without going into things we could do better. And I like C++, it's my preferred language. The real argument here is even though C++ is bloated, it's far from the worst that way. Perl takes that crown, with it's 500 special variables. And the people who complain about C++'s bloat generally like Python or Ruby, which are both just as bloated as C++, without the bonus of it's simplicity.
Because it WORKS (Score:5, Interesting)
C and C++ (I consider them essentially the same, if only because I write them essentially the same) have a few advantages:
They work. A language update doesn't break your actual programs. It may break your ability to compile them, but you still have a working binary compiled with the old version, which gives you time to make the code work with the new version. You never have to run around like a chicken with it's head cut off because some automatic Java or Python or PHP or __LANGUAGE__ update broke __BIG_CRITICAL_APP__.
The tools work. You have IDEs that actually work. You have debuggers that actually debug. You've got static analysis tools that actually analyze (I've seen some PHP "static analyzers" that actually just make sure you use a particular code style!). If you want, you can grab the intermediate assembly files and debug *those*.
The coders work. Sure, C[++] has some really awful language features, but the programmers know about them, know how to use them properly (which, often times, is "never"). It's a language known by any decent programmer. Maybe not used, or liked, but pretty much everyone can read C.
It does things many other languages can't. You cannot (last I checked) embed assembly snippets in any other major language. There are many libraries that only have C APIs.
It's fast. Game developers, serious ones, use C++, because even Java is still too slow. And when you have 20,000,000 vertices you need to render every 16ms, speed *matters*. That's why web servers are written in C. That's why operating systems are written in C. That's why other programming languages are written in C. Because sometimes, processor time actually *is* more expensive than programmer time.
I *like* C. That game I program in my free time? It's C++, but it acts like "C with objects and strings". Sure, I could have done it "faster" in another language, but I know C and like C, for all the reasons enumerated above.
Portability (Score:2, Interesting)
Among the many benefits of C overlooked by some apparent `mass opinion' is portability. C compilers are easy to create. Things written in C can be compiled on platforms that provides a C compiler. C has been the lingua franca of mature system software for over 40 years; it's the first thing you write after you have a working assembler.
This situation won't change until someone makes a real alternative. Lots of things purport to offer an alternative but are actually not; they are complex and require sophisticated compilers and memory management schemes. C is simple. Any alternative must be at least as simple to be considered.
It isn't hard to imagine an alternative. C is not perfect. The problem, in my opinion, is that no one has really tried; language designers seem to be interested in only higher level problems and are happy to muddle along ignoring the flaws of C.
Re:One good reason... (Score:5, Interesting)
Compare C++ to Objective-C. You might dislike the syntax of Objective-C some, but it has clear advantages:
We can all supply better languages for a purpose; Objective-C and C++ have the same purpose (an object oriented general purpose native compiled mid-level programming language), and so this comparison is relevant. Comparing to Java or Python or C#.NET would be irrelevant.
A loose argument can be made that Objective-C is better because of its much better polymorphism features--the main point of an object oriented language. Objective-C does indeed supply much more flexible, more useful polymorphism; C++ class inheritance is pretty rigid because of its rigid ABI. Objective-C's run time resolution enables this, and I would admit that run time resolution of class objects is a bit slower ... if it wasn't optimized by cache (i.e. resolve the first time on demand and build the PLT) AND if C++ class member mangling didn't make actually building the PLT at load time so god damn slow. Two points to Objective-C.
Objective-C doesn't have operator overloading. Operator overloading is often claimed as a negative feature because it makes code hard to read. The effective argument AGAINST operator overloading is is that everyone is used to the 'cout >>' and 'cin
The biggest argument for operator overloading is really that nobody uses it, so we're all familiar with the corner case syntax in the standard library. Think about that: the biggest argument for it is that it never gets used.
Also, Objective C has reference counting with cycle detectors and all. Garbage collection is a limited feature (you can create garbage collected objects intentionally).
It's actually relatively easy to argue that C++ is an abomination. It's not unexpected either: it's an old language, and an OOP shim hacked on top of a well-designed mid-level language. That C is so well designed is surprising; but then it is the legacy of assembly, PASCAL, FORTRAN, and BASIC. COBAL is circa 1959, BASIC circa 1964, C circa 1972, C++ circa 1984. C++ had only Smalltalk to learn from, really, and was trying to be C with Classes.
Re:One good reason... (Score:4, Interesting)
what features you could therefore remove without detracting from the effectiveness of the language.
Exceptions -- I personally like exceptions, but exceptions in C++ are terrible and not necessary. C++ exceptions have the following problems:
Incidentally, the problem here is the order in which things happen. Exceptions should be caught before the stack unwinding process, which guarantees that the handler will execute before another exception is called. This also allows for "restarts" i.e. the ability to resume execution from the point where an exception was thrown, which might make sense (e.g. for exceptions that indicate some non-critical function could not be performed, which should not prevent a critical function from completing).
I have also seen quite a few large C++ projects that simply ban exceptions, because they wind up creating more problems than they solve.
Re:Control (Score:4, Interesting)
C, predictable? Would you mind taking this http://blog.regehr.org/archives/721 [regehr.org] quiz? It's about the predictability of integers in C.
Re:because (Score:4, Interesting)
Re:One good reason... (Score:5, Interesting)
* It is a strict superset of C: C compiles as Objective-C (C++ doesn't, since structs have a different syntax, among other things)
I've never had trouble pulling C headers into a C++ compiler. Problems can exist, I suppose, but are very rare and easy to work around.
* More importantly, it is runtime-resolved.
Or, if you prefer, that's a huge disadvantage. It makes things very, very slow since all sorts of useful optimizations are not possible. If C++ used nothing but dynamic binding, I'd have to stick to C.
in C++ you can't add members to classes, at all.
That is a wart with C++. If you pimplify your classes properly, you don't break the ABI. Since it's such a common idiom, it would be really nice if there was compiler support to make it trivially easy.
* The mangling in C++ is a serious pain and makes loading C++ libraries and programs retardedly slow.
How so? The mangling gives functions funny long names, but they appear to the linker as just functions with long names, and behave the same way as C programs. I don't recall ever being bitten by this...
* Swizzling (you can replace members of classes at runtime--not just inherit, but actually overload class members) makes the language quite a bit more flexible.
That's a potentially useful flecibility.
* Operator overloading and templates are an abomination, and don't exist in Objective-C.
You made coherent arguments up to this point, where you basically revert to saying it's bad because you say so. If you use + to add ints and + to add floats in ObjC, then you aren't completely against overloading. Templates and overloading are two of the best features of C++.
I really don't see how compile time hackery (templates) is inferior to run-time swizzling in ObjC.
Without templates, there can be no good container libraries.
Without operator overloading, writing intuitive mathematics libraries (for example) would be impossible.
A loose argument can be made that Objective-C is better because of its much better polymorphism features--the main point of an object oriented language.
C++ isn't a objected-oriented language. It's a multi-paradigm language where object-orientation is one of the paradigms supported. You're ignoring all other facets of C++.
The biggest argument for operator overloading is really that nobody uses it, so we're all familiar with the corner case syntax in the standard library. Think about that: the biggest argument for it is that it never gets used.
On what grounds is that the biggest argument for it? I use it all the time. I use olperator> on streams. I use + to concatenate strings. I, personally use + to add all sorts of things (like ints, floats, Vectors, Matrices, automatic differentiation types, an occasionally complex numbers). I use operator= all the time to assign one container to another.
So, your point is basically wrong. I and many others use operator overloading all the time to do useful things, and make stuff clearer and simpler.
Also, Objective C has reference counting with cycle detectors and all. Garbage collection is a limited feature (you can create garbage collected objects intentionally).
C++ as they say doesn't need garbage collection as it produces very little garbage. Garbage collection is very nice when you have long lived mutable cyclic datastructures. For all other cases, the arguments for and against are much more subtle.
Personally, I fund deterministic destruction useful. I find it much easier to run out of memory in Java compared to C++ when dealing with large datasets.
It's actually relatively easy to argue that C++ is an abomination.
I beg to differ: you have been unable to argue that so far.
Re:Maybe because it compiles down to the metal... (Score:4, Interesting)
These days Java runtime bugs and security issues take up a significant portion of my time. There's no real advantage to "knowinf what the code really does" to be found in a modern hugh level language, because the VM isn't perfect, and anything short of perfect means you have to care aout that layer. And you don't have soruce for that layer, or an easy way to inspect it. Whenever I was a bit uncertain what the compiler would do with oddball corner-case code in C or C++, I could fire up the debugger and check the generated object code, achieving absolute certainty what was really happening.
Wait till you have to debug your first memory leak in Java or C# - you'll be singing a different tune after that. At least in C, when a third-party API leaks memory you have all sorts of object-level tools available to get to the bottom of the problem, even without source. Bump into a JVM or CLR leak? Sucks to be you.
Re:One good reason... (Score:4, Interesting)
Value templates- yes, templating on the value, rather than the type. It's an extremely niche use case that causes difficult to read code and provides little in the way of benefits. I doubt even 5% of the user base knows it exists. Kill it.
I think you are underestimating the number of people who use it indirectly.
I'm in the 5% who use it directly, and it is an invaluable tool which gives C++ a massive advantage over other languages. Otherwise, it is very useful inside metaprogramming, which is the key to making easy to use (not easy to write) libraries.
Besides how is it hard to read?
STL algorithms- sorry, totally disagree. The entire thing is a horrible hack based on using constructors to make quasi-first order functions.
I'm not entirely sure I follow. How do constructors enter into it?
I bounce any code review I see using them.
What do you use to sort data? What do you do when you want a heap, or want to perform a set difference or some such operation?
Yup, I stand by my original opinion- all of these could be cut with no real loss to the language. Then again, if I were writing my own language I'd take C, add constructors, destructors, and C++ style syntax for member functions, add container classes, and call it perfect.
So, you would have (presumably) type generic container classes?
Re:One good reason... (Score:4, Interesting)
I used to work with a team that produced a professional C/C++ compiler. We used to joke:
There are two problems with C++
1. it's design
2. it's implementation
As a programming I've come to love the sweet spot 1/2 between C and C++.
C leads to overly terse code
C++ leads to over-engineered solutions
Its too bad the preprocessor is still stuck in the '70s :-( Every year C++ is slowly turning into a clusterfuck LISP implementation by people who don't understand how to write a safe macro meta-language.
Re:One good reason... (Score:2, Interesting)
There needs to be a Godwin's Law corollary for MS Bob.
Re:One good reason... (Score:4, Interesting)
When it comes to STL algorithms, you may have been right before C++11/C++0x. Now, with lambda functions, the standard algorithms are genuinely brilliant. Modern IDEs should support debugging the lambdas as well.
I honestly don't care if you disagree. There are enough people around that use them extensively and they are not going away. I would most likely bounce your code your code for NOT using STL algorithms if they were the quickest solution.
I completely agree on struct/class and diamond inheritance though.
Re:because - (Score:4, Interesting)
I think C's originators (or at least the still living one) changed his mind about some of them. From looking at the go language which targets the same programming niche some of these things have been addressed.
The semicolons are implied in most places now (as a side effect it enforces a brace style many people dislike, but happens to be my preference -- so even though I'm happy with C's semicolons this is a borderline positive change for me).
Declaration syntax has been made "more sane", which isn't surprising, and by the time K&R wrote the C book they had already started regretting it (one of the assignments was to parse C declarations into "english", look at what the authors wrote about it).
Go revamped switch (and a lot of the control flow operators).
Some of those changes might just be because computers have gotten a wee bit faster in the last 25 years or so, what constituted a great tradeoff on a computer with a 64K (split I+D) address space and maybe 512K max RAM a clock cycles measured in a few Mhz (oh, and these were multi user computers) is a wee bit different from what makes a good tradeoff now. (semicolons I think wind up here)
Some are likely to be a change they would still have made on the original system. (most of the control flow changes wind up here, likely variable decl too)
Re:because - (Score:5, Interesting)
When writing business software for Windows desktop platforms you don't want to mess around with pointers, memory addresses or other relatively low level stuff like that. High level languages like Java, C#, heck, even Delphi are far more useful for that and allow for far greater productivity.
Sure, there are situations where C is the better choice, just like even lower level languages are sometimes a better choice, but claiming that people choose Java, C# or Python over C because they're ignorant is ignorant in itself. If, these days, you choose to build your windows forms application in C, then you're just getting yourself in a world of hurt that could easily be avoided by choosing a different tool (programming language).