Re:On Marketing Haskell
by spekcular on Saturday May 30, 2020 @07:49PM
(#23365905)
There's also hash tables. IIRC, Haskell didn't have a good hash table implementation until relatively recently because people religiously avoided mutable data structures. (And the implementation I'm thinking of is not purely functional.)
[ Parent
| on HN ]
Re:On Marketing Haskell
by centimeter on Saturday May 30, 2020 @08:13PM
(#23366026)
Haskell has had good HAMTs for quite some time. There isn’t really any benefit to using a mutable hash table over that. In fact, it would probably be slower given the way copying GC works with mutable values.
Yes, there is a benefit: correctly implemented hash tables are faster. Haskell's GC may prevent a good implementation, but that's a problem with Haskell, not with hash tables.
Re:On Marketing Haskell
by yakshaving_jgt on Saturday May 30, 2020 @11:57PM
(#23367057)
Writing the fastest possible implementation of something is rarely a valid business goal.
The ideal is the midpoint on a Venn diagram of 1) fast enough for our purposes, 2) logically robust, 3) cheap to implement.
Besides, if something absolutely must be the fastest implementation possible and this can’t be done in Haskell, then there’s no reason why one couldn’t drop to the FFI at that point. You could even use template Haskell and write inline-C. It works.
Re:On Marketing Haskell
by centimeter on Sunday May 31, 2020 @11:29AM
(#23370150)
A marginally faster mutable hash table is not really useful for much. If that 30% speedup or whatever is going to make or break your application, a single hash table was the wrong choice anyway.
If this is the kind of thing that keeps you up at night, you should just be using C.
FTI, HAMT = hash array mapped trie
FTI? FYI? At any rate, thanks for the clarification.
"For their information". It's not for centimeter's information, he/she clearly already knows. It's not for mine either; I discovered the answer by DuckDuckGoing!