note
liz
<i>The future is threaded.</i>
<br>
Maybe on a hardware level. But on a software level, I would say:
<h1>Threads Are Primitive And Should Die!</h1>
<p>
Why would you need to use threads? To do things in parallel? Why not let the computer figure that out for most cases (generally any action on more than one element without side effects).
<p>
This is probably a broken analogy, but I see threads as wheels on a car. Do you have turn each frontwheel seperately? No, you have something like a steering wheel or a joystick. Do you have to think about the fact that, when turning left, the left wheel has to turn a little more than the right wheel? No. The car does that for you.
<p>
I think the focus on threads (and fork) is what is so past century. We need new ways to think about using computer systems that are no longer capable of only doing one thing at the time. And rid ourselves of engrained thought patterns.
<p>
[http://en.wikipedia.org/wiki/Software_transactional_memory|Software transactional memory] is such a way, and it is already available in [http://pugscode.org|Pugs] already supports it.
<p>
Combined with [http://en.wikipedia.org/wiki/Continuation|Continuations], which are already supported by [http://parrotcode.org|Parrot], this is a very powerful base for language definition and implementation.
<p>
Personally, I welcome the lack of a threads.ppd. Ever really tried to program more than trivially threaded programs in Perl or C? Or tried to debug them? Get all of the locking right? Eridicate all possible race conditions and dead locks? For me, it is the nearest thing to hell for a programmer I can imagine. That's why I heartily support the death of threads in HLL's!
<p>
Liz
580004
580004