On Mar 27, 2006, at 9:03 AM, Sebastian Sylvan wrote:
On 3/27/06, Paul Johnson <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
