[Haskell-cafe] Can Haskell outperform C++?
glebovitz at gmail.com
Wed May 16 16:40:26 CEST 2012
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.
More information about the Haskell-Cafe