Oh wow, Miranda is still using an SK combinator reduction evaluator dating from 1986, in K&R C. It isn't even using supercombinators, which I read about in https://www.microsoft.com/en-us/research/publication/the-imp...

Combinators are fun, but not very fast :-) https://dl.acm.org/doi/10.1145/800087.802798 http://ioccc.org/years.html#1998_fanf

I promise I'll respond to this in the morning, I'm very tired right now and don't want to give a good and reasonable question an answer that hasn't been thought out well, especially given that my responses have been getting less detailed and concise as I've gotten more tired.

Just for comparison, C++ running the shortest, simplest possible quicksort does 100,000,000 32-bit ints in 8s. Three more lines, and it's 3.4s. That's 1.3ns each time it looks at an element.

So when you are already giving up an order of magnitude or two, another doesn't matter so much. It pays then to steer the conversation toward other merits.

> C++ and the shortest, simplest possible quicksort

wk_end was talking about "functional pseudo-quicksort" on immutable linked lists. You're presumably talking about a proper quicksort on mutable arrays. That's comparing apples to oranges.

And even if you weren't, how is that an argument? Person A says "X is faster than Y", then person B says "Actually I just ran X and it took 10x longer than Y" and then you say "Well Z, which isn't even part of this discussion, is 1000x faster than both X and Y, so your argument is invalid". How does that follow?

It means that speed is not a very interesting basis for comparing them. If you cared much about speed, you would look elsewhere.

Again I want to emphasize that you were comparing different algorithms on different data structures. It's like someone made a benchmark using the naive recursive Fibonacci definition and then you implemented the iterative version in another language and concluded from that that the other language must be much faster. The different algorithm is what gave you (most of) the speed up, not the language.

I mean, I don't doubt that C++ is in fact faster than Haskell, just not by that much.

Their criticism is fair: I have been making a performance argument. I do think they've misinterpreted my performance argument, though, which I'll get to. (There's a lot of backlog I need to catch up with; this thread is very large and my typing speed is significantly faster than the speed at which I can think.)