Comment by codexon | Hacker News Reader

Comment by codexon | Hacker News Reader

Parent Full thread

He absolutely did not dissect my arguments. His responses were canned responses or rather irrelevant.

1. Haskell does not have good hash tables

His response: Just use HSJudy. He forgets to mention that it isn't even a hash table and its even LGPL. An amusing fact is that the default hash table implementations are so slow that someone had to implement their own from scratch on the GPLS benchmark

http://shootout.alioth.debian.org/u32q/benchmark.php?test=kn...

2. Haskell's lazy evaluation has bad consequences for SMP programming.

His response: First he tries to argue against it. Then when I convince him that I am not just making things up, he finally backtracks and says that's why he made a library to cover up the shortcomings.

3. Haskell's default static bundling of LGPL GMP.

I didn't specify the word "distribution", but I was talking in part about commercial usage where this is a reasonable assumption. He decided to harp on this single specific word and declared the whole point to be invalid.

These are all problems (to someone), but these aren't the reasons why people don't use Haskell. You are projecting your minor complaints onto the world as a whole, and that simply doesn't make for a good blog post.

1. I have written a bit of Haskell software. I have never suffered any performance problems by using a tree instead of a hash table. O(1) is nice, but O(log n) is very small for very large ns. "You are not Google", but even Google does fine with trees. If you are actually experiencing a performance problem, try HsJudy. If this doesn't solve your real-world performance problem, then you can complain. Right now you sound like you just read the Wikipedia page for "hash table" but have never had a dataset bigger than 10 elements.

2. Lazy evaluation does have consequences, sure... but so does strict evaluation. You are trading one set of problems for another set of problems. What's nice about Haskell is that you can use strict evaluation when you think it's required.

3. LGPL is not a problem for me.

Any software I would distribute to outside users would be GPL'd anyway. Any software that is worth money to keep secret is not distributed anyway. (Not everyone is like this, of course, but like I said... this isn't a problem for me.)

Anyway, you should just say you don't like Haskell if you don't like Haskell. Instead you are trying to say that it is objectively bad, which requires more proof than your blog post provided.

1. Using the "You are not Google" argument is a blatant disregard for the facts. If you've done the math, you would see that using tries and ternary trees often lose performance at 60,000+ elements, and this is even ignoring cache invalidation that often occurs in jumping through nodes. I'm sorry, but you are the one who sounds like you've never had a dataset bigger than 10 elements.

And speaking of Google, have you ever heard of this?

http://code.google.com/p/google-sparsehash/

2. The point is that lazy evaluation has More problems than strict. Not less. If you read the comments you will see that Dons actually agreed with me after arguing the contrary. Even Simon Peyton Jones believes that "the next Haskell should be strict".

3. LGPL is a problem for many companies. If you don't really care about it, good for you. You are in the minority.

In conclusion, I thought that Hacker News would be immune from Haskell group think, but I was unfortunately wrong.

In conclusion, I thought that Hacker News would be immune from Haskell group think, but I was unfortunately wrong.

I'm not Hacker News, I'm one poster.

And that's why I have multiple downvotes and everyone else arguing against me has multiple upvotes...

> An amusing fact is that the default hash table implementations are so slow that someone had to implement their own from scratch on the GPLS benchmark

Is that a fact!

You mean they didn't just translate the hash table from Clean, that I translated from the simple_hash.h that Doug Bagley provided for ye olde The Great Computer Language Shootout back at the end of the millenium?

Is your fact also why the Pascal program includes a Pascal translation of simple_hash.h ?

> Is that a fact!

Yep it is a fact. Did you disprove it? No. The benchmark is right there in front of you showing that Haskell is taking 10x longer than C++.

> Is your fact also why the Pascal program includes a Pascal translation of simple_hash.h ?

What is your point? Haskell supporters often cite its speed and brevity in GPLS. Instead of using the bundled hash table, the fastest Haskell program needed to implement their own, losing out in brevity. If this is not indicative of a problem in GHC, then what is?

> Yep it is a fact. Did you disprove it? No. ... What is your point?

Listen and you might hear the point.

Initially, simple_hash.h was a basis for comparison across languages.

Initially, the obvious comparison was between Haskell and Clean, so it was obvious to translate the hash table from the Clean program.

Your speculation about why the Haskell program includes a hash table is wrong.

Actually you are wrong. Next time be sure to read the entire article before you make uninformed assumptions.

You've obviously missed important information such as this link below and unsurprisingly made a Haskell fanboy comment without verifying the truth to your statements.

http://www.haskell.org/haskellwiki/Shootout/Knucleotide#On_m...

>This benchmark is completely bottlenecked by Data.Hashtable (in GHC 6.4.1) and this discussion is based on the assumption that I am using Hashtable optimally...The entry below runs 16 slower than the DMD entry on my powerbook G4. Profiling shows the bottleneck. I downloaded simple_hash.h and shamelessly optimized it to replace Data.Hashtable for exactly this benchmark code.

Reply on news.ycombinator.com