Hacker News Reader

Comment by by | Hacker News Reader

That is assuming you are comparing the speed against C. I rewrote one into short, sweet style and found it was much faster than python and ruby. The only frustration was being unable to get the code shorter than the ruby version.

Note that the benchmarks are still for 6.10.4, they might get a bit faster when run with 6.12.

I am curious, are you speaking from some particular experience of problems with the speed?

View on HN

I have experienced cases where simply recompiling with a new GHC speeds up my program 5x. I've also experienced cases where I had to take perfectly readable code and turn it into something ugly--but not to the extent that it is done in the Haskell code on the language shootout.

I would prefer to have the language shootout revert back to idiomatic versions of the programs, and then look at how we can optimize those idiomatic programs automatically in the same way that good SQL implementations optimize SQL queries.

> found it was much faster than python and ruby.

But it seems that Haskell, because of static type checking and compilation should compete against C, C++ and Java in terms of speed. Because if it is competing against Python, I'll just always use Python when I need to get things done.

Speed is definitely part of the appeal. Perhaps more important though is the degree to which static typing might reduce errors and make code more readable and maintainable. I haven't done enough coding in languages like Haskell yet to decide if static types do in fact help in either respect but I think those things might actually be more valuable to me than raw performance.

It does compete with Java, as both are garbage collected. C, C++ and Fortran are in their own category because they don't have to deal with the indirection of boxed heap objects.

The mythical "sufficiently smart complier" can remove these indirections, but no current compiler can do it perfectly, as doing so requires generative the copious amounts of object code that C++ is so roundly criticized for (templates). GHC is pretty good at removing these indirections. I understand C# compilers are as well. I've not used Java much but isn't there some issue where you can't store primitive integers in a collection because they don't inherit from the base Object type and/or the JVM doesn't support unboxed objects?* This is the same kind of annoyance you have to deal with in Haskell to get fast-as-possible performance (i.e. using types which are not polymorphism-friendly thus decreasing code reuse and increasing verbosity) so in that way I think they are equal with regards to the performance/brevity trade-off.

* I'm sure this has probably been fixed in some recent version of Java but it's still illustrative of why garbage collection imposes a real performance impact that C and C++ just don't have to deal with.

Reply on news.ycombinator.com