
"Writing Multithreaded Programs Can't Be Done In C" - Spolsky - fogus
http://my.opera.com/Vorlath/blog/2009/10/11/writing-multithreaded-programs-cant-be-done-in-c-spolsky
======
niyazpk
We may want to move discussions about the daily rantings of Joel Spolsky out
of Hacker News.

Joel has his opinions about a lot of programming matters (TDD for example) and
combined with his witty way of presenting stuff those opinions should not be
given any seriousness than it deserves.

I personally like Joel as a writer and I do listen to his StackOverflow
podcasts and I think he is being misunderstood as having strong feelings
against multi-threaded programming or TDD while the fact is that he adds these
superlatives for an added effect in his talks and writing. Just ignore those
and you will be fine.

~~~
j_baker
+1

In particular, I think Joel does have a point here. Yeah, so maybe he's
exaggerating by saying it's impossible. But I would imagine that multi-
threading in C (like most things in C) is really difficult. Especially
compared to more modern languages that make it much easier.

~~~
axod
If programming was easy, everyone would do it.

------
jgrahamc
Bollocks. I made good money selling my anti-spam library polymail that is
written entirely in C, tiny, fast and multi-threaded.

~~~
RiderOfGiraffes
Your work, however, suggests that you are not actually human. Seeing some of
the things you have produced makes me think that you are inhumanly competent,
and hence Joel's remarks do not apply to you.

I think Joel is using a limited form of the word "impossible" and a limited
form of the word "human", in a similar way that 2+2=5 for sufficiently large
values of 2 and sufficiently small values of 5.

~~~
jgrahamc
My response to this post: <http://news.ycombinator.com/item?id=878919>

------
rjurney
I think Joel's point is that for the following two statements:

1) You can do multithreaded programs in C

2) You cannot do multithreaded programs in C

the common belief is 1, and it leads to much suffering. If everyone believed
what Joel is saying, 2, most everyone would be much happier.

He's trying to reset the center point of the thread folklore. And I praise
him. Doing concurrent systems in C should sound as absurd as building web apps
in assembly - there's probably a case for it, but its almost certainly not the
one you're looking at.

------
JulianMorrison
In C, parallelize with OpenMP, do large scale concurrent work in processes and
small scale concurrent work in event loops.

------
shin_lao
With the traditional lock based (pessimistic) approach, writing reliable and
efficient multithreaded programs is impossible given a number "n" of threads.

This number "n" varies with the talent and experience of the programmer as
well, with a less significant factor, with the language used.

That's why people are working on transactional memory. When our customers will
have 100 cores in their machines, it's not realistic to hope to achieve
anything with locks.

------
bonsaitree
It's just Joel doing the "Joel 'Thang"--namely effective, but disingenuous,
attention marketing. Examine the context of his original statement.

------
joe_bleau
Hmm...maybe his definition of multithreaded doesn't match that commonly used
in the emebdded world. Lots of embedded projects are written in C, many using
an RTOS to allow multiple tasks/threads to run concurrently on a single CPU.

Or for Joel, all the world's a PC.

------
brown9-2
Big surprise: blanket statements are often inaccurate!

------
c00p3r
OMG! glibc was written by aliens!

~~~
uriel
Nah, just by gnus overdosed on crack and suffering from BSE.

------
uriel
It can be done, if you use the right paradigm and the right library:
<http://man.cat-v.org/plan_9/2/thread>

If you use pthreads, then you are certainly doomed.

~~~
DarkShikari
_If you use pthreads, then you are certainly doomed._

Our project has done it just fine for about 4 years. This is complete FUD.

Certainly there are use-cases where pthreads are more challenging, but for the
vast majority of cases they seem to do the job just fine.

In most cases you cannot eliminate the complexity of threading. To use terms
from The Mythical Man Month, it is "inherent complexity"; no matter what
language or library you use, one has to find a smart way to subdivide the
problem efficiently. There are implementation details that can be made simpler
(reducing accidental complexity), but the problem of parallelism--the inherent
complexity--will always exist.

Anyone who claims a magical way to do this without human input is lying, or at
a minimum talking about situations far too simple to fit any real use-case.

~~~
rjurney
Some languages are structured so that the hardest parts of concurrent
programming are solved for you by language features. C is not one of those
languages. That is Joel's point.

~~~
uriel
The language is irrelevant, the _model_ is what really matters, of course
Limbo or any other language built around CSP will be better than libthread,
but one can do CSP on pretty much any language.

One can use pthreads (or the like) in almost any language too, and it sucks
infinitely everywhere.

