If you bother to read even the TLDR of the original article you 'll find it says something completely different, which makes this article pretty poor as a response.
"So here is the bottom line. If you really need your code to run as fast as possible, and you are planning to spend half your development time doing profiling and optimisation, then go ahead and write it in C because no other language (except possibly Assembler) will give you the level of control you need. But if you aren't planning to do a significant amount of micro-optimisation then you don't need C. Haskell will give you the same performance, or better, and cut your development and maintenance costs by 75 to 90 percent as well."
Note the 'same performance or better' in there.
Maybe you missed that bit in the original article?
This wasn't a large effort by any stretch of the imagination and a factor of 5 difference compared to the Haskell code isn't even in the same ballpark as "the same performance", and about a factor 10 difference with the C code listed in the original article. You'll notice no micro optimizations were done in the re-write, just some global re-arranging of the way data flows through the program.
The rest is in response to the misleading title, that Haskell is 'faster' than C, faster to program, faster to debug, easier to maintain and so on while making claims about performance that are not born out by real world comparisons.
Speed was the wrong thing to compare on here, and should not have been part of the original article without a serious effort to become equally proficient in both languages.
Compared to the amount of optimisation that many people typically do (i.e. zero or close to zero), it was a large amount of extra work to get that performance boost. The global re-arrangements of the way data flows through the code are more difficult than many micro-optimisations, not less, so I don't understand how you can claim.
And you don't have to be an expert in C to make the claim he is making, because most people are not experts in C, but might turn to it because "it's faster". It's precisely this kind of person who needs to understand that with their level of knowledge, and the amount of effort that they might put into optimisations, Haskell can be just as good or better.
> it was a large amount of extra work to get that performance boost.
Not really, actually. It took a lot of time to document the transformations, but actually doing the coding was short, much less than an hour total.
> The global re-arrangements of the way data flows through the code are more difficult than many micro-optimisations, not less, so I don't understand how you can claim.
Maybe more difficult for you, but not for me. Micro-optimizations are actually harder for me, there are infinite possibilities there, flow has really only one (or very few) 'proper' mapping(s) from problem space to solution space.
> And you don't have to be an expert in C to make the claim he is making, because most people are not experts in C, but might turn to it because "it's faster".
Every tool has its uses. If you pick C then probably you're doing so because you are convinced that you need it. You should then study how accomplished users of that tool use it, not stop at the first naive use that you come up with yourself.
> It's precisely this kind of person who needs to understand that with their level of knowledge, and the amount of effort that they might put into optimisations, Haskell can be just as good or better.
That's very well possible, again, I do not know Haskell so I can't comment on it. But I don't see any meaningful comparison between the two languages here, speed certainly isn't it and you failed to acknowledge that the article in fact did make that claim.
If you bother to read even the TLDR of the original article you 'll find it says something completely different, which makes this article pretty poor as a response.