can a lazy language give fast code?
Andrew J Bromage
Thu, 1 Aug 2002 10:29:16 +1000
On Wed, Jul 31, 2002 at 09:59:31AM +0100, D. Tweed wrote:
> It's in saying this is warranted by `almost all'
> processes being bound by things other than throughput which may be true in
> the average sense, but I don't think that all programmers have almost all
> their programming tasks being dominated by something other than raw
> throughput but rather there are sets of programmers who have all of the
> tasks being dominated by the need something else (robustness, say) and
> some who have all their tasks being dominated by the need for raw
Fair enough. I was speaking in generalities and average cases and
deliberately avoiding the special needs of many programmers and
applications. I've worked in enterprise applications, web
applications and high-performance servers (both CPU-bound and
I/O-bound) and the concerns of all of them are different.
Perhaps if I cut down on the superlatives I can say something that
everyone agrees with: An awful lot of new code today is written in
languages like Visual Basic and Java, despite their relative
unsuitability for high "throughput". If it doesn't stop the use
of those kinds of languages, it shouldn't stop the use of Haskell
either, especially since Haskell arguably scales much better.
Therefore were I someone with a stake in the future of Haskell, I would
not be not overly concerned about these kinds of benchmarks. Speed is
important, and it should be worked on, but it's not as important as
the things which Haskell already does better.
> You make very good points in what I've snipped below, again it's just
> the use of `most' in a way that implies (to me) taking an average as
> the representative of what everyone has to deal with that I `disagree
Sure. I wasn't implying that it was representative of what everyone has
to deal with. It's certainly not representative of what I do for a
living, though it's pretty close to something I used to do.
Perhaps the quibble is over the word "average". While I don't think I
used that word, if I did, I'd mean "mode" rather than "mean". :-)