Re: Re: Write Haskell as fast as C. [Was: Re: GHC predictability]

andrewcoppin:
> Don Stewart wrote:
> >I don't understand what's ugly about:
> >
> >        go s l x | x > m      = s / fromIntegral l
> >                 | otherwise  = go (s+x) (l+1) (x+1)
> >
> >And the point is that it is *reliable*. If you make your money day in, 
> >day out
> >writing Haskell, and you don't want to rely on radical transformations for
> >correctness, this is a sensible idiom to follow.
> >
> >Nothing beats understanding what you're writing at all levels of 
> >abstraction.
> >  
> 
> What sets Haskell apart from every other programming language ever used 
> in mainstream programming? You might say conciseness, or the ability to 
> use lazy evaluation to structure your code in usual ways, or something 
> like that. I would say what sets Haskell apart is "abstraction". There 
> are other things, but this is the big one. Haskell allows you to 
> abstract almost everything. The result is often highly succinct yet very 
> readable programs. It would seem a terribly shame if you always have to 
> throw away Haskell's key advantage to get decent runtime performance.
> 
> If you're trying to get a real program to work, right now, then yes, you 
> may have no choice. But that doesn't mean we shouldn't strive for ways 
> to keep code high-level yet performant.
> 
> [I'm curios about your other comment. Does anybody, anywhere in the 
> world, actually make *money* using Haskell? This seems rather unlikely 
> to me...]

Yes, and that's the point. When money is on the line not every line is
going to use a research result from the last 5 years. You'll have a lot
of code using standard idioms, reliable techniques. Because that's what
gets the job done.

-- Don