You are comparing the speed of interpreted code without any optimisation. If you compare compiled code with optimisations turned on, then yours is still faster. If however, you modify the bound in my solution to be sqrt x rather than x then it is as fast as yours.

The reason it is upvoted as best practices is because it is best practice to write declarative Haskell programs.

There are many many many tutorials on the internet explaining what each one should do.

I think when I made the kata that they were still using GHC 7.6 which doesn't have support for closed type families.

Fixed.

I considered doing this initially and I will now. Seems like a good idea.

I would have thought that te sum of the empty list was 0 as it is in Haskell at least. It also seems strange to index from 1 when most programming languages index from 0.

Maybe. I would prefer a solution where kata's could depend on each other which would mean that there could be followup kata's where user's could reuse their code from previous exercises. I don't want to make this kata too large, especially as it's something that many people find hard to understand.

There is a typo in the Haskell hidden tests. "ramdom"

Really nice tests!

It would perhaps be better to define the evaluator in the test suite rather than getting the user to implement it.

Thanks