[Haskell] Haskell as a disruptive technology?

[Robert Dockins]

On Mar 27, 2006, at 9:03 AM, Sebastian Sylvan wrote:
> On 3/27/06, Paul Johnson <paul at cogito.org.uk> wrote:
>
>>
>> Is there a market that is poorly served by the incumbent languages  
>> for
>> which Haskell would be an absolute godsend?
>>
>
> As far as I'm concerned, yes almost every market. At least soon.
> Within a few years (say, five) we will have tens of cores on the
> desktop. The speed of an application will correspond fairly directly
> to how well it uses multiple threads. This will only become more and
> more true in the future.

FWIW, I'd like to voice my agreement with this view.  The hardware  
manufacturers are hard at work building the perfect niche for Haskell  
-- all of commodity desktop computing!  Moore's law is still packing  
more transistors onto the silicon, and it seems like people have run  
out of ideas for what to do with them, so they just start duplicating  
cores ;-)  All we have to do is be ready for it when it arrives.   
When people see that, using Haskell, they can write programs using 1)  
fewer man-hours with 2) fewer bugs which 3) scale effortlessly to  
highly parallel hardware to beat the pants off C/C++/Java/what-have- 
you, they'll be beating down the doors to get it.

I'd love to see Haskell on highly concurrent hardware becoming more  
of a reality: Haskell on the Cell is a great idea; I'd love to see  
Haskell over MPI (using YHC bytecode maybe?); Haskell-over-GPU (you  
know you like it!); and of course, SMP Haskell is also interesting.   
One of the things I love about Haskell is that the language  
definition transcends execution strategy/environment.


> Haskell (lightweight threads + STM) really is a godsend in this area.
> It's really not feasible to distribute a general application to tens
> or hundreds of threads in C++ (or any imperative langauge, really).
> Some specific problems (e.g. raytracing) are simple enough to be
> easily parallellised in any language, but in general we need purely
> functional programming with good support for concurrency and
> parallellism if we are to have any hope of remaining sane while using
> these massively multicore systems of the future effectively.
> Haskell (or rather GHC) is ideal here. Parallellising pure functions
> are fairly easy, for concurrency I think message passing and immutable
> values are really pretty the best story right now, and even if you
> decide you need some layer of shared-state concurrency we can remain
> pretty safe using STM.

Indeed.  And for this reason, I'm glad to see concurrency very  
seriously considered for Haskell'.  I'd even go so far as to say that  
STM is a good candidate for inclusion, or at least for addendum  
status.  STM makes writing concurrent programs a joy rather than a  
total PITA.





Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG