News for hackers. Stuff that matters.
Re:On Marketing Haskell by somewhereoutth on Saturday May 30, 2020 @06:49PM (#23365529)
Following links in your 1), I liked https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf 'The Genuine Sieve of Eratosthenes' by Melissa E. O’Neill. Somewhat damning and to your point.

Are there any theoretical barriers to writing algorithms in a pure and lazy language with the same space/time complexity as a side-effectful and strict language? I suppose quicksort (also mentioned) is an obvious candidate for study in this regard.

Re:On Marketing Haskell by insulanus on Saturday May 30, 2020 @09:57PM (#23366561)
Thanks for linking this. I just read it, and that is some DAMN fine writing.

Sometimes when I complain about jargon and bad writing in scientific papers, people argue back that the author has to be precise. This paper makes it clear that these are orthogonal issues. Writing is a skill, too.

The author is being extremely technical and rigorous, but she is also CLEAR.

Quite the badass.

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.)
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.
Re:On Marketing Haskell by spekcular on Saturday May 30, 2020 @10:32PM (#23366677)
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.

Re:On Marketing Haskell by tome on Sunday May 31, 2020 @05:09AM (#23368268)
FTI, HAMT = hash array mapped trie
Re:On Marketing Haskell by JohnL4 on Sunday May 31, 2020 @09:49AM (#23369576)
FTI? FYI? At any rate, thanks for the clarification.
Re:On Marketing Haskell by tome on Monday June 01, 2020 @04:12AM (#23376305)
"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!
Re:On Marketing Haskell by dllthomas on Sunday May 31, 2020 @10:39PM (#23375045)
"Thy"?
Re:On Marketing Haskell by todd8 on Sunday May 31, 2020 @09:06AM (#23369323)
Sacrebleu, how can this be? The Haskell one-liner compiles so it must be the genuine sieve of Eratosthenes.