Comments on: Joel Spolsky: You cannot program parallel in C, period

By: Andras

Andras — Thu, 15 Oct 2009 00:49:47 +0000

Well, consider Cilk. Simple elegant and even an average programmer (and Joel ) can understand.
At Ericsson, we write parallel and concurrect programs in C all the time. While it’s not the simplest thing to do, it’s done by average programmers and the very reason you are able to make a mobile phone call is that it works

By: Lars

Lars — Tue, 13 Oct 2009 09:44:30 +0000

Hey, maybe Joel is not to stupid for this:

http://macresearch.org/cocoa-scientists-xxxi-all-aboard-grand-central
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12

By: Charlie Martin

Charlie Martin — Mon, 12 Oct 2009 17:34:48 +0000

Oh, come on, Joel, that’s just dumb. Or, at least, it’s reducible to “parallel programming cannot be done at all”, because if it were possible to parallel program at all, it would then be possible to reduce the components in the magical Parallel Programming Language to C fragments (proof via Turing equivalence.)

Of course, what you really mean is “conventional programmers, trained in a conventional manner with no special training in dealing with concurrency, find it extremely difficult to write parallel programs that are correct.”

To which the knowledgeable response is “well, duh.”

By: Tim Berglund

Tim Berglund — Mon, 12 Oct 2009 17:34:44 +0000

Joel is, per his usual enjoyable style, making an overly generalized, contrarian statement in support of a valid point: C is the wrong choice for almost all concurrent programming. No one writing concurrent code at the application level on a general-purpose server is going to sit down with a diverse toolset and a blank sheet of paper and pick C as his language. They just aren’t.

That said, his statement is, on its face, false. I know this because I *do not* think of myself “hot shit”—I’ve taken far too many blows on my developer’s back for that!—and I have, in fact, written complex concurrent code in C. It’s some of the most difficult code I’ve ever written, but it can be done. Firmware developers do it all the time. Would it be cool if we could give them tools to work at a higher, safer level of abstraction while maintaining C’s time and space advantages? Yeah! We can afford those trade-offs at the application level on the server, so C is always the wrong choice there. But that’s not because the alternative is impossible; it’s because the alternative is prohibitively expensive in development time and quality.

Another important point: I enjoy making fine distinctions and elaborating on them at length. Joel likes making bombastic, sweeping generalizations. Lots of people read Joel. Not quite as many read me. Something to think about as we consider this debate.

By: henk

henk — Mon, 12 Oct 2009 17:23:08 +0000

It of course depends on the libraries and tools you use. Using the low-level C primitives, which are somewhat associated with native C (even though technically even those low-level primitives aren’t a part of C itself), like Pthreads and fork/join, it is indeed barely possible for mere humans to code parallel.

Now some higher beings (like kernel coders) might put these to good use, but for the rest of us it’s pretty much a no-go.

Now move up the concurrency ladder and take a look a higher level frameworks like map/reduce, GCD (grand central dispatch) and the kind of stuff that you find in e.g. Java’s concurrent package. Armed with these tools, concurrent and parallel programming suddenly comes within the reach of use groups of mere mortals.

By: Jakob

Jakob — Mon, 12 Oct 2009 14:46:21 +0000

Looks like this post caught fire.

I think that the truth, if there is such a thing, is not as bad as Joel is making it out to be: C in general is hard to use for parallel programming, but it does seem to be successfully applied in some critical code, by good programmers.

But as a general programming language for general parallel software, I think there are many better choices than plain C with a low-level API. OpenMP does count to low-level in my book. You want at least a gc, and preferably asynchronous message-passing or similar crash cushions to make it comfortable.

One size does not fit all, but “size C” does fit some.

By: f055

f055 — Mon, 12 Oct 2009 13:14:18 +0000

Some programmers are not human, thus this does not comply. Also, concurrency is one of the last areas where your code can be 100% correct and still produce an error in 0.01% situations, and this obviously will appear during the most important moment of the user. Murphy is evil, I tell you.

By: Chauncy

Chauncy — Mon, 12 Oct 2009 11:30:46 +0000

Aren’t the UNIX-like kernels (E.g., Linux, BSD) written in C, aren’t they multi-threaded, and aren’t they very reliable?

By: Paul Betts

Paul Betts — Mon, 12 Oct 2009 02:59:57 +0000

Every modern production operating system kernel is written in C, and an OS kernel is the most concurrent environment you could ever program in.

By: Machielo

Machielo — Mon, 12 Oct 2009 00:43:13 +0000

MPI is parallel, and works with C flawlessly. Joel usually goes to the extreme to make his point, but this time he failed.

By: herp derp

herp derp — Sun, 11 Oct 2009 21:54:30 +0000

i leave a coment on der paeg.

By: Astro

Astro — Sun, 11 Oct 2009 21:22:16 +0000

You’re confusing parallel & concurrent programming. While parallel programming is very easy with OpenMP and still easy with threads, concurrent programming is the nightmare you are talking about. Asynchronous programming to the rescue, it’s still concurrent.

By: Kevin Bowling

Kevin Bowling — Sun, 11 Oct 2009 21:13:59 +0000

Joel,

You are an idiot.

OpenMP much?

By: Evan Carroll

Evan Carroll — Sun, 11 Oct 2009 20:48:16 +0000

Thanks for succinctly summing this up! People are too stupid to write multi-threaded code in C. This argument by fiat is the most sound, logical, and rational argument by fiat that I’ve seen yet. I’m delighted to finally understood these vivid points you hit on — hopefully someone can do something really great with this constructive advice and revise the C language!!! Thanks Joel!!! U ROX.