[Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

Wren,

I see at least three different issues being discussed here. I think it 
is important to delineate them:

1) Does Haskell and its libraries need performance improvements?  
Probably yes. Some of the performance issues seem to be related to the 
way the language is implemented and others by how it is defined. 
Developers really do run into performance issues with Haskell and either 
learn to work around the issue or try to fix the offending 
implementation. The wiki performance page gives insight into some of the 
performance issues and how address them.

2) Are language performance comparisons useful? They can be, if the 
comparison is focusing on what each language does best. They aren't 
useful if they focus on benchmarks that aren't relevant to the target 
domain of each language. I think the problem with current comparisons, 
is that they are designed to favor imperative languages.

3) Are the negative perceptions generated by popular performance 
comparisons important? Only if you care about the broader adoption of 
the language. If you don't care, then the point is moot. If you do care, 
then yes the comparisons are unfair and simple minded, but they do have 
an affect on the percepts of the language. It is not uncommon for 
management to raise roadblocks to the introduction of new technologies 
due to flawed reports that were published in popular magazines.

If Haskell were a product and I  was responsible for its success, then I 
would be using common marketing techniques to combat the negative 
perceptions. One is a technique called "changing the playing field" 
which means producing documents that reset the criteria for the 
evaluations and comparisons. This is not "deception", but merely making 
sure that potential users understand where and how to make the proper 
comparisons, or more importantly that my "champion" was well armed with 
documentation to counter argue popular but flawed comparisons.

On 5/16/2012 6:54 AM, wren ng thornton wrote:
> Haskell is just too different, and its in-the-large cost model is too 
> poorly understood. I'm not even aware of any helpful generalizations 
> over comparing two specific programs. Even when restricting to things 
> like parsing or compute-intensive numeric code, the comparison comes 
> back with mixed answers.