I don't know whether Haskell or C is best for these kind of programs, but I have three considerations:
1. You seem to presume that good C programmers can be confident that their short, simple C programs are correct. The anecdotal figure I follow for error incidence is an error per 1000 lines of code, for code written by and check by professional programmers. In this 600 loc program, that's over a 50% chance of error at the end of the auditing process; the authors are worried about security, which makes looking for alternative sources of reassurance make sense.
2. Being comfortable coding in two languages doesn't mean that the set of problem-solving idioms you have for the two languages are equivalent. IO code in Haskell is indubitably more complex than in C, and has some particularly sharp edges, but the price tag in terms of code complexity does not map into a similar price tag in terms of code-comprehension complexity: the complexity arises from disciplines that, when married to the use of good IO idioms, make it easier to reason about the code.
3. Reading the code from the article, the Haskell code is much better written than the C code -- This does suggest that the author is right to use Haskell in cases where you would use C, since you have different skill sets.
I think it's silly to continue this without using (better) concrete
examples, but I'm don't think it'd be worth the effort.
>> [Author is better at Haskell than C].
> This does suggest that the author is right to use Haskell [...].
Certainly.
1. You seem to presume that good C programmers can be confident that their short, simple C programs are correct. The anecdotal figure I follow for error incidence is an error per 1000 lines of code, for code written by and check by professional programmers. In this 600 loc program, that's over a 50% chance of error at the end of the auditing process; the authors are worried about security, which makes looking for alternative sources of reassurance make sense.
2. Being comfortable coding in two languages doesn't mean that the set of problem-solving idioms you have for the two languages are equivalent. IO code in Haskell is indubitably more complex than in C, and has some particularly sharp edges, but the price tag in terms of code complexity does not map into a similar price tag in terms of code-comprehension complexity: the complexity arises from disciplines that, when married to the use of good IO idioms, make it easier to reason about the code.
3. Reading the code from the article, the Haskell code is much better written than the C code -- This does suggest that the author is right to use Haskell in cases where you would use C, since you have different skill sets.