4 ms·

I love me some ML/Haskell, but the article is about small C programs. Small utility programs is the domain where C shines. C is dead-simple, ubiquitous, and fas

by anon_d 15y ago

I love me some ML/Haskell, but the article is about small C programs. Small utility programs is the domain where C shines. C is dead-simple, ubiquitous, and fast. Just the tool-complexity of Haskell alone makes C the better choice for these kinds of programs. Over the last several years, I've experimented with rewriting some of my small C programs in Haskell or ML, and vis-versa. Amazingly, the C programs often end up being shorter, simpler, and significantly less headache (for these small programs). I am very comfortable coding in all three languages, so I think I'm pretty unbiased. Reading the code from the article, the Haskell code is much better written than the C code. I think the author is making a mistake in thinking the better code is a result of the merits of Haskell w.r.t C instead of just the result of the clean rewrite plus being more experienced with Haskell.

chalst 15y ago
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.
- anon_d 15y ago
  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.

by anon_d 15y ago

chalst 15y ago

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.

anon_d 15y ago
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.