I'm interested in hard problems.
Recently, I've started thinking a lot about what CP6AN might look like.
Class::MOP and the Perl 6 Metamodel make me more excited than I'd like to admit.
Also expect occasional wordy technology-related rantings.
2) Device drivers and operating systems are written exclusively in C. Now, you may never write a device driver or an operating system, but what if you are ever required to modify one?
Rare modification of device drivers aside; I think a better reason (sorta related to this) is that C was designed to write Unix in. Learning C may allow you to learn more about the internals of your OS.
4) C programs are smaller and faster then any other program created in a different language. Sometimes your program needs that speed boost that only C can give it.
False. Sorry, but this is no longer the case. Compiler research has come a long way.
For example, look at perl's highly fine-tuned regular expression engine written in C. CL-PCRE, a Perl-compatible regular expression library written in Lisp, claims to outperform perl's (when compiled with CMUCL). Yes, there are many problems whose C implementations are faster, but this does not hold true for all programs or all architectures.
5) If you have learned C, you can learn any modern programming language. The reason behind this is that all modern programming languages are based on C
Many programming languages have syntax that's kind of like C. But all? Scheme is based on Lisp. Prolog is almost nothing like C. As isn't Haskell. I have trouble believing that SQL and C share much in the way of parentage. XSL? I could go on.
Much more important than syntax is paradigm. My problem with the "learn C and you can learn anything" argument is that maybe if you learn C you can learn other procedural languages. Knowing C ain't gonna get ya very far in learning functional or logic programming. And most of the languages that are based on C have powerful language constructs that C lacks. Closures, for example.
8) C is the only language that teaches you what pointers really are. C# and Java skip the subject completely. It is pointers that give C its power.
A power we have yet to fully understand how to harness. Like goto. The indirection role is played by references in Perl and equivalents in other languages. The continguous addressable block of memory space? Arrays and iterators mostly take care of that. The fact that dynamically allocated memory is only accessible through indirection is not a feature, though.
Face it, C's pointers (and the language infrastructure they're related to) are the reason buffer overflows exist. Let's figure out how to stuff them back into Pandora's box before they become widespread. Oh wait, we didn't.
I can see the power of C's pointer implementation because it allows for all kinds of crazy Turing-machine possibilities. With those possibilities come risk.
9) C is still the most commonly required language for programming jobs.
My gut feeling is that the language of choice for PHBs these days is Java, but I have no data to back up my assertion either.
10) Anything that has a microprocessor in it has support for C. From your microwave to your cell phone, C powers technology.
I could sort of see this argument being valid if you were talking about IA32 (which seems to have a lot of C primitives as instructions), but otherwise not so much. The processor has no support for C.
If you want to argue almost every architecture has a C compiler for it, you'd be a lot closer. Some of this is because C is self-hosted, but some is also because C is good for getting close (but not too close) to hardware.
Please note that I am not trashing C. I happen to think it is also worth learning, for different reasons. I'll have to write those down later.