Be sure to link this the next time someone unironically recommends learning Hasklel
>purely functional dictionaries are typically 10x slower than a decent hash table
>most functional programming languages (OCaml, Haskell, Scala) are incapable of expressing a fast generic mutable hash table because they lack the killer combo of: reified generics, value types and a fast GC write barrier
>if you want a shared mutable collection such as an in-memory database then there is no efficient purely functional solution
>Compare Prim’s algorithm in 12 lines of Python with Prim’s algorithm in 20 lines of Haskell. And why does the Haskell use Prim’s algorithm? Probably because Kruskal’s algorithm is built upon the union-find collection and there is no known efficient purely functional union-find collection
>For years the functional programming community brandished beautifully short implementations of the Sieve of Eratosthenes and Quicksort algorithms. These were even taught to students for years. Only many years later did it emerge that their solutions did not implement those algorithms. Melissa O’Neill even published a paper correcting the Sieve of Eratosthenes in Haskell. In particular, her genuine sieve requires 100x more code than the original Haskell. Same for quicksort where Haskell’s elegant two-line sort is over 1,000x slower than Sedgewick’s Quicksort in C because the Haskell deep copies lists over and over again, completely blowing the asymptotic IO complexity of Hoare original algorithm
http://flyingfrogblog.blogspot.ca/2016/05/disadvantages-of-purely-functional.html
What the fuck even is haskell and functional programming in general
>one implementation is bad therefore the language is inherently slow
>>54932447
How many implementations of Haskell are there?
>>54932399
>There are no purely functional concurrent collections
there are no concurrent collections. Every collection implementation (list, array, map) is inherently prone to errors due to concurrent access. It's usually up to the programmer implementing concurrency above them.
That's why STM exists.
>Purely functional programming is theoretically good for parallelism but bad for performance in practice, which is the sole purpose of parallelism.
blatant lie. Try to write a parallel implementation of quicksort in, say, clojure. Can't speak for haskell, though.
>Most graph algorithms look worse and run much slower when written in an FP style
subjective. Also, the example the author provides is wrong, since they have a similar length. Also, python's implementation is gonna be a whole lot slower because python's performance a shit.
> It took 50 years for normal people to dilute the smug weenies to the point where you can get a useful answer about functional programming on social media.
If you're seeking help on social media on such a difficult and complicated topic as programming languages and their internals, you deserve all the "smug weenies" you can encounter. You're not gonna search info about the chemical composition of some fucking polymer on some fucking subreddit, nor about the advanced microbiology - on a notorious mongolian fingerpuppet BBS, because you know that you'll be submerged with bullshit.
>>54932399
>OCaml
>Objective Caml
>an object-oriented language with imperative features
>uses mutable and imperative dictionaries and hash tables
>allows you to write programs functionally when appropriate and makes it easy to do so
lol?
>>54932447
If all languages had an idealistic maximum performance implementation, all languages would perform equally well. May as well write everything in Python or Go at that point.
>>54932399
true, use F# like Dr Harrop
