[Haskell-cafe] What's the deal with Clean?
ketil at malde.org
Thu Nov 5 04:00:44 EST 2009
Bulat Ziganshin <bulat.ziganshin at gmail.com> writes:
>> Right, the interesting thing is not how fast I can get with N times the
>> effort, but if I can get fast enough with 1/N.
> - while i say that haskell is slow compared to other languages,
The "other languages" being C and C++. I believe Haskell is fast
compared to Ruby, Python or Lisp.
> i don't say that it is slow for you or that you need sped at all.
> why it's repeated again and again? why you don't write to Don what you
> don't need speed when he wrote that haslkell is fast
I'm not saying I don't need speed. I need programs that are fast
*enough*, and I would like to build them with a minimum of effort on my
Which is why I would like to see how fast GHC can make more idiomatic
> but wrote this to me? :(
Because I am trying to agree with you. :-)
>> Many of those people are making fairly simple mistakes. I think a
>> somewhat seasoned programmer using good libraries can write declarative,
>> concise, and readable code that still is reasonably fast.
> i don't think that omitting strictness declarations is a mistake :)
If your program is slow because you misunderstand how laziness affects
execution, and if it's easily fixed by adding a bit of strictness, then,
yes, that is the kind of mistake I'm talking about.
>> At least for some approximation of the word. Only one benchmark on
>> the shootout has C at a 3x advantage.
> oh, can we stop saying about shootout?
I'm using the numbers that are available, you are free to suggest better
> if you want to see speed of pure haskell code, look at papers about
> fast arrays/strings - their authors have measured that lazy lists are
> hundreds times slower than idiomatic C code. is use of lazy lists
> counted as mistake too
Yes!¹ You don't have to program a lot of Haskell to realize that for
performance sensitive data, you need to use ByteStrings or some other
packed data structure, not lazy lists of Chars. Many of those
complaining on poor performance are advised to use ByteStrings instead,
and more often than not, it helps tremendously.
Again, I'm not contradicting your claim that C will usually be faster,
or that writing very fast programs in Haskell takes a lot of effort.
I'm saying that programs have to be fast *enough* and correct *enough*,
and when those goals are achieved, the question is how we can achieve
them with a minimum of effort, and with a maximum of clarity.
¹) Probably not a mistake in those papers, that depends on what the authors
wanted to illustrate. But clearly a mistake in a performance sensitive
program, and clearly a mistake if you want to argue that Haskell is too
slow to use for real programs.
If I haven't seen further, it is by standing in the footprints of giants
More information about the Haskell-Cafe