[PRL] "Threads Considered Harmful" in the news

[Matthias Felleisen]

I am extremely pleased to see that I am wrong in that regard. --  
Matthias


On Jan 23, 2007, at 9:39 AM, Mitchell Wand wrote:

> Not entirely true (see, eg, http://www.oreilly.com/catalog/gnuext/).
>
> But I was talking about being active in the scientific space, not  
> the publishing space.
>
> --Mitch
>
> On 1/23/07, Matthias Felleisen <matthias at ccs.neu.edu> wrote: I am  
> pretty sure that OReilly has an explicit policy against
> publishing anything concerning parenthetical languages. -- Matthias
>
>
> On Jan 23, 2007, at 7:45 AM, Mitchell Wand wrote:
>
> > This meme has now reached O'Reilly Radar, along with Erlang,
> > Haskell, and E.  Scheme needs to play in this space!!
> >
> > --Mitch
> >
> > http://radar.oreilly.com/archives/2007/01/threads_conside.html
> > Threads Considered Harmful
> > By Nat Torkington on January 23, 2007
> > Professor Edward A. Lee from the EECS department of UC Berkeley
> > wrote The Problem With Threads (PDF) last year. In it, he observes
> > that threads remove determinism and open the door to subtle yet
> > deadly bugs, and that while the problems were to some extent
> > manageable on single core systems, threads on multicore systems
> > will magnify the problems out of control. He suggests the only
> > solution is to stop bolting parallelism onto languages and
> > components--instead design new deterministically-composable
> > components and languages.
> >
> > This paper reflects two trends we see here at Radar: the first is
> > towards multicore systems and the growing importance of distributed
> > execution; the second is the increasing relevance of languages like
> > Erlang, Haskell , and E. The growth of multicore is significant: if
> > you want your program to run faster, the days of buying faster
> > hardware are coming to an end. Instead, we're looking at a time
> > when you must make your program run faster on more (slow) hardware.
> > Enter parallel programming, clusters, and their hyped big brother
> > "grid computing".
> >
> > Google have obviously faced this problem and solved it with
> > MapReduce. Lee argues that this kind of coordination system is how
> > we solve the problem of threads' nondeterminism. It nicely
> > parallels (heh) the way that database sharding has become the way
> > to solve scalability (see the Flickr war story for example). For
> > this reason we're watching Hadoop, the open source MapReduce
> > implementation, with interest. (There are also MapReduce
> > implementations in Perl, Ruby, and other languages)
> >
> > MapReduce is built on a technique from the Lisp programming
> > language. As the need for speed forces us out of our single core
> > procedural comfort zone, we're looking more and more at "niche"
> > programming languages for inspiration. Haskell has quite the
> > following among the alpha geeks we know (e.g., the Pugs project),
> > and OCaml has a small but growing group of devotees. Then there was
> > the huge interest in Smalltalk at Avi Bryant's OSCON talk last year
> > ( SitePoint blogged about it here).
> >
> > Tags: erlang google hadoop haskell languages mapreduce ocaml
> > parallel programming smalltalk threads
> > _______________________________________________
> > PRL mailing list
> > PRL at lists.ccs.neu.edu
> > https://lists.ccs.neu.edu/bin/listinfo/prl
>
>
>