The Unreasonable Effectiveness of C

It also has a few downsides:

- The build system is broken.

vs. make. qmake. cmake. autotools. scons. 'modern' makefiles (>_> what does that even mean? Yes, I'm looking at you Google) There's a whole ecosystem of tools out there to solve this.

- There are a few rubbish IDEs, most of which support c as a second class candidate.

VS has officially abandoned C; xcode grudgingly supports it. The CDT is mediocre. There's little or no support for refactoring or doing other things on large code bases, and the majority of the time the work has to be done manually.

- Because the build system is broken, dependency management is hell

Got one library that uses scons, another using autoconf, and what to build a local dev instance of a library without installing it into the system path? Goooood luck.

This is made even worse by arcane things like rpath, which mean that dynamic libraries only work when they are in specific paths relative to the application binary (I'm looking at you OSX).

- Its a terrible collaboration platform.

Why? Because the barrier to entry is high. To submit a patch that works and doesn't break other things, doesn't introduce serious security holes or memory leaks is hard.

Astonishingly, some successful projects like SDL are actually written in C, but most C projects are not collaboration friendly.

- There are no frameworks for doing common high productivity tasks in C, only low level system operations, or vastly complicated frameworks with terrible apis (>_> GTK).

I'll just whip up a C REST service that talks to mysql and point nginx at it. Um... yeah. I'm sure there's an easy way to do that. ...perhaps...?

How about a quick UI application? We'll just use GTK, that's portable and easy. ...Or, not very easy, and vastly complicated to setup and build.

These issues aren't unique to C, but they're certainly issues.

I'm not really sure I'd happily wonder around telling people how amazing C is at everything.

It's a tool for some jobs; definitely not all.

"But amazingly it's proven much more predictable when we'll hit issues and how to debug and fix them. In the long run, it's more productive."

That's nothing to do with C. It's because Damien worked on CouchDB first, and learned a lot from that. If I were to go and rewrite our current system in Java or Scala, I'd also be able to predict where performance, and other, issues would crop up, simply because I've already encountered a number of them before.

At the risk of sounding like that guy, isn't this property of all Smalltalk descended languages?

And I mean on the basic language level, not "using a library to run a hot swap VM for my language" level like Eclipse and IntelliJ IDEA do.

Having strings, containers, etc, not built into the language itself means that you can't practically use them. Libraries will all have their own incarnations, and as a result you get stuck dealing with the lowest common denominator of C arrays.

The author doesn't claim it's perfect or that there's no way to improve on it, but I think he has a very salient point, which is that most of the OO buzzwords and programming fads that come and go in "higher-level languages" simply end up making a bigger mess of things as a project grows. Basically, the author loves C because it is simple, straightforward, and restrictive -- it forces you to write [relatively] simple, straightforward code too, instead of concocting a terrible Frankenstein of custom classes and types intertangled into a grotesque, intractable mass of dependencies and subdependencies. If something is in C, you know it is going to be built from the basics, and in many cases, this simplicity is a life saver as a project matures.

There are definitely annoyances and issues, but they are known and can be taken into account with much less hassle than attempting to grok a Java project that requires you to traverse into the basest-level of classes like BusinessObject2013SingletonDispatcherFactoryFactory every time something needs to be debugged or fixed.

It doesn't mean you should use C for your Web 2.0 startup, but his point is well taken. I heard someone 'round these parts once acknowledge that the modern equivalent of spaghetti code (i.e., code that intractably descends through hundreds of code paths with gotos, etc.) is OO hell, i.e., code with huge dependency stacks and equally intractable and unjustifiable inheritance models, where you have to descend into all kinds of classes and special cases to make a meaningful change.

>I'm pretty sure the author hasn't written a line of ANSI-C compliant code in his life, otherwise he'd never write something like this.

Damien Katz is actually fairly accomplished, and it definitely sounds like he's written multiple lines of C to me.