[Haskell-cafe] What's the deal with Clean?

[Bulat Ziganshin]

Hello Ketil,

Thursday, November 5, 2009, 12:00:44 PM, you wrote:

>> - 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.

of course

>> 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
> part.

well, why you don't write this to Don? what i said is just what ghc
generates much slower code that gcc. there is nothing in my letter
about your haskell usage, so why it's all?

> Which is why I would like to see how fast GHC can make more idiomatic
> Haskell code.

i think it would be more natural to write this to someone who thinks
that haskell is fast based on measurements on non-idiomatic code
rather than to me

>> but wrote this to me? :(

> Because I am trying to agree with you. :-)

really? :/

>>> 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.

for me, analyzing of slow program and finding where to add "bit of
strictness" isn't something easy. it's whole optimization work and
finally you got with need of strict lists or strict arrays

>>> 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
> benchmarks.

it's here:

>> 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.

the problems is what it's string-only and doesn't speed up even all
programs using strings (for example, we have hand-made BS.readInt
operation since it cannot be made efficient w/o low-level coding).
another example - afaik, there is no BS version of ParseC what
demonstrates substantial speed increase

> 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.

it's obvious. why i don't write to everyone complaining about lack of
some haskell features that i don't need it?


> ?) 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.

i don't say that haskell is slow for real programs. i say that
idiomatic haskell is much slower than idiomatic C and these papers
demonstrates how much, for simple computation-intensive loops



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com