[Haskell-cafe] Haskell vs GC'd imperative languages, threading, parallelizeability (is that a word? :-D )

[Michael Vanier]

Hugh Perkins wrote:
> 
> I'm not trolling, despite strong appearances to the contrary ;-)  My 
> primary objective/goal is to find a way to make threading easy.  Thread 
> management today is like memory management in the early 90s.  We kindof 
> had tools (new, delete in C++ for example) to do it.  At some point we 
> started to use things like Smart Pointers to make it easier, but none of 
> it really worked.  Issues such as circular referential loops caused this 
> not to work very well.
> 
> At some point, someone came out with the idea of a garbage collector, 
> which is really very simple once you know: all it does is walk the graph 
> of variables, starting with those we know are definitely used, and 
> delete all those objects that didnt get walked on.  Simple, easy, magic.
> 
> We should do the same thing for threads.  Threading is going to become a 
> major issue soon, maybe not tomorrow, but there is a GPL'd Niagara 2 out 
> with 64 threads (I think?), so the time is now.
> 
> Haskell solves a huge issue with threads, which is locking, which is a 
> total PITA in imperative languages, it's of the same order of magnitude 
> of problem as eliminating memory leaks, without deleting something twice 
> etc, used to be in pre-GC C++.
> 

Just to get the history right: garbage collectors have been around a _long_ time, since the '60s in 
Lisp systems.  They only became known to most programmers through Java (which is one unarguable good 
thing that Java did).

As for threading, in addition to Haskell's approach you might also look at Erlang, which has a quite 
different (and quite interesting) approach to the whole problem.  I wonder if anyone has tried to 
implement a message-passing style of concurrency in Haskell.

Mike