

Plain Threads are the GOTO of todays computing [video] - adamnemecek
https://www.youtube.com/watch?v=4OCUEgSNIAY

======
_yosefk
Actually, plain threads indeed are pretty much the goto's of parallel
computing, one difference being that while various techniques analogous to
"structured programming" \- "structured threading", if you like - are
available, they all work for some systems better than others, and often aren't
very portable/ubiquitous yet. So right now they can't almost-kill raw threads
the way ifs, fors and whiles almost killed goto's.

~~~
fmstephe
I think this is a really important observation.

There was a very interesting discussion between Cliff Click and Rich Hickey
(linked at bottom). The highlight of it for me was Cliff Click suggesting that
people often assume that because we use a range of great abstractions every
day, garbage collection was his example of a very successful abstraction,
there is tendency among programmers to assume that all abstractions are great.
Cliff Click gives the example of a MPI as an abstraction which proved powerful
in some domains but very fragile in general.

As far as I can tell we are still looking for a really good abstraction to
replace threads.

[http://www.azulsystems.com/blog/cliff/2008-05-27-clojure-
stm...](http://www.azulsystems.com/blog/cliff/2008-05-27-clojure-stms-vs-
locks)

~~~
_yosefk
Personally I'd probably label MPI as "too low-level" an abstraction, not
unlike threads; and I think there are many great high-level threading
abstractions which I wouldn't call fragile, from Cilk/TBB and the like to
transactional memory.

What I meant to say was, Cilk/similar can be very useful at times,
transactional memory at _other times_ , Erlang-style fully isolated
lightweight processes at _still other times_ , etc. - and none of these
approaches comes with a universally available interface, also none is
universally taught (while threads are.)

So my guess is that raw threads will be used increasingly less but (A) it will
take time and (B) either we miss something right now or it will take more
mechanisms and approaches to replace raw threads than it took to replace goto.

That said, anyone needing to do something with threads today at any sort of
scale (even if it's one guy who writes something that needs to be maintained
over a long span of time) should IMO hide the threads behind _something_. (My
take on it is
[https://github.com/yosefk/checkedthreads](https://github.com/yosefk/checkedthreads))

~~~
fmstephe
I agree that it looks like we will end up with a much larger, and less
universally applicable, toolbox of abstractions.

Feels like a fun time to be programming, while we search for the right set of
abstractions. :)

------
rubiquity
I like to think exceptions are also a slightly less egregious form of the
GOTO.

~~~
jeorgun
Many things are — [http://repository.readscheme.org/ftp/papers/ai-lab-
pubs/AIM-...](http://repository.readscheme.org/ftp/papers/ai-lab-
pubs/AIM-443.pdf)

~~~
MetaCosm
I am a bit confused, what is the relevance of that paper to the comment?
Unless I misunderstood, the comment appeared to be about flow control issues
of exceptions(hidden control flow and corrupt state), and I don't see that
addressed in that paper.

~~~
rubiquity
The paper is about subroutines (function calls) being a lot less complex
because all a subroutine can do is finish and then go back to its caller.
There are no semantics in subroutines for jumping around willy-nilly.

