[bedman12345]

It’s slow. Example: quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter (< p) xs greater = filter (>= p) xs

It’s really complicated. Everybody includes lenses https://hackage.haskell.org/package/lens I don’t want to read all that stuff just for imperative syntax.

It’d both slow and hard to read. Compare these two: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The c examples complexity lies in using SIMD. If you know simd it’s easy. You should know simd, it’s useful. The Haskell example is drivel. Long complicated and in the end hopelessly slow compared to the c example. You could als use simd in Haskell, but then it would just be C with extra steps.

[jrrv]

The Haskell looks much better, and I don't even know Haskell.

> If you know simd it’s easy.

Surely "if you know Haskell it's easy" is equally applicable.

[bedman12345]

> The Haskell looks much better, and I don't even know Haskell

Plain crazy take. The c example uses basic coding to implement some clever maths with special fast instructions. Thehaskell example is just some dumb algo implemented with complicated programming. There is obviously nothing good about that.

You can also look at a c example without simd https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It’s shorter and simpler and faster than the Haskell version. It’s not even close???

[jghn]

> It’s really complicated > hard to read

You did not provide objective measures. You're just providing subjective opinions.

[bedman12345]

True. My statements are meaningful because of that. The objective measures we could agree on are obvious, so they need not to be stated. The heart of the debate is about the things that are hard to measure. As most things in software engineering. I ignored your question because it is a bad one.