A handful of things I don’t like about C

Y’know what I haven’t written about in ages?  Programming! So now that I’ve accumulated a readership base that’s mostly interested in politics with a polite tolerance for my forays into motorsports, I’m going to bore most of you with a foray into computer languages.  If you really don’t give a shit about what we compiler-jockeys do for a living and want some relevant econ, have a read at this history of the Great Depression (rather more accurate than what you were spoon-fed in high school):

• The real New Deal (The American Interest)

and this chunk of seemingly-esoteric speculation (the title alone should get your attention):

• Do we need a bubble? (Worthwhile Canadian Initiative)

See you tomorrow!

…are they gone?  Okay, let’s talk about C.  Computing science students who believe what their Intro SE textbooks told them will probably inform you that C is an archaic and obsolete language, lacking the powerful and sophisticated tools (a framework for object-oriented programming, templated types, safe typecasts, &c.) needed to realize the architectures of modern software design paradigms.  I was one of those comp-sci students, and I am here to tell you that they’re full of shit.

Oh, sure, you can write abysmal C.  In fact, the language damn near double-dog dares you to shoot yourself in the foot with its void pointers, unsafe casts, and almost perversely-counterintuitve const keyword.  But you can write abysmal code in any language, and C does something truly wonderful if you’re willing to let it: it gets out of your way.  Not in the same sense as a language like Ruby; when people talk about Ruby “getting out of your way and letting you code”, what they really mean is that Ruby does tedious things for you, like resize arrays and free memory when the last reference to it goes out of scope.  Ruby is sort of like an anxious-to-please Sheltie — it’s friendly and happy and fetches the paper and your slippers and pours you a cup of coffee in the morning.  C is more like a barn cat: it kills mice and gives you reproachful and condescending looks if you ask it to do anything else.  If you want to get your own coffee in the morning, you’ll hurt Ruby’s feelings; if you want to kill a few mice yourself, C couldn’t give less of a shit.

I came to appreciate C’s true nature when I used it to write a compiler.  This is a great way to learn C: if you know how code gets lexed and parsed and folded, spindled, and mutilated into machine code, a lot of the “weird features” of C turn out to make perfect sense — the ways in which arrays-of-pointers and arrays-of-arrays differ, for example.  Compilers are also complex beasts, even compilers for toy languages like the one I was assigned as an undergrad, and believe it or not this is where C really shines.

See, most of the “enterprise-oriented” or “architecture-enabling” features of languages like C++ or Java are best used by large teams of wildly varying programmer quality, to keep the noobs and jerkoffs from fucking the whole thing up.  If you’re a solitary programmer responsible for a fiendishly complex system, you might prefer C simply because there’s less of it.  It’s convenient to have a vector template that you can use as a generic container, but in general you’ll spend more time jumping through hoops to keep your STL implementation happy than you will writing your goddamn program.  If you need to append to a list exactly once in your code, realloc is a better friend to you than a full copy-constructor implementation.

With all that said, C has a few warts where I wish it didn’t.

1. Pointer type semantics

C rewards you heavily for using value objects instead of reference objects.  C also rewards you heavily for using pointers with grace, elegance, and finesse.  You’ll find yourself declaring a lot of pointers.  That’s not a bug in the language, it’s a feature.

This is a bug:

int* foo, bar, baz; /* declares foo as a pointer-to-int and bar and baz as ints */

I know why it’s done that way, and if you don’t you should read Section 5.12 of K&R (or Appendix A if you’re feeling masochistic) until you do.  I just don’t like it.

If you’re a bit too much of a keener, you can do this instead:

typedef int* intp;
/* ... */
intp foo, bar, baz; /* declares foo, bar, and baz as pointers-to-int */

but oh my fucking god that’s ugly, especially for builtin types.

2. General operator weirdness

No rant on C would be complete without bitching about operator-precedence rules, so: C’s operator-precedence rules are fucko bazoo.  Why, for example, bit-masks are lower precedence than equality tests is beyond me.

if(x - 1 == 0) { ... } /* fine, checks to see if x is 1 */

if(x & 1 == 0) { ... } /* bitwise-ands x with the result of 1==0 */

For that matter, why the hell are bitwise operators single-character, while logical operators are two characters long?  Okay, by now I’ve long internalized that && means “logical and” and (binary) & is something I never use, but come the fuck on… let’s Huffman code operators, shall we?

And of course this nonsense has largely infected other languages, which need to cater to folks who know C (or, more recently, C++ and Java) to bootstrap themselves into relevance.

3. No lambdas

While I tend to write most of my code in C or Ruby, I’ve developed an enduring affection for Lisp and Haskell.  Lambdas — anonymous (really “literal”) functions, with or without stack context to make them closures — come from Lisp, and they’re the only thing preventing me from making C the perfect language.  For example, if you have lambdas, you can rather trivially implement currying, and that gets you most of the day-to-day advantages of Haskell without going so far as strong type inference.

If you have lambdas, you can also implement higher-order functions like map and filter, which will literally save you days of typing out for loops over the course of your life.  Higher-order functions will also make you smarter, taller, and more attractive.

But look over here! Apple are proposing to add “blocks” to the C language standard, and have already implemented them in their own version of gcc.  Oh happy day!

A. Things I’m not complaining about

Just to be clear….

• malloc/realloc/free.  They are not that fucking hard.
• printf syntax.  Also not that fucking hard. Ruby’s string interpolation is a clear improvement, but printf and friends are perfectly serviceable.
• gets — but only because it’s too damn obvious.
• void pointers.  There is a place for just giving me a goddamn address and letting me get back to work.
• setjmp/longjmp.  Decidedly user-hostile, but as transparent in execution as exception-handling is ever likely to get.
• Lack of literal structs.  C99 has ’em.
• Index declarations in for loops.  C99 has those, too.
• C strings.  Sure, they’re a hack.  But if you need a more powerful implementation than string.h gives you, that’s your design telling you to write your own.

The internet being what it is, I suspect I’ll get more flames for this post than anything political I’ll ever write.