3 ms·
As such, it's critically important that the program is concise and well-defined; both properties that are quite hard to get in C code. This is baseless FUD.
by anon_d 15y ago
As such, it's critically important that the program is concise and well-defined; both properties that are quite hard to get in C code.
This is baseless FUD.
- chalst 15y agoI do think that it is easier to acquire confidence that well-written Haskell is correct than well-written C, and there is some evidence supporting this belief. There's room to argue this, but it is very far from baseless FUD. For an example of the kind of techniques available to Haskell but not to C, check out: http://www.andres-loeh.de/Contracts.html http://www.andres-loeh.de/Contracts.html Some correctness infrastructure, such as Quick Check, have proven themselves to be eminently practicable. It is perhaps also true that it is easier to write Haskell well than to write C well: certainly there is no shortage of awful C coding out there.
- anon_d 15y agoI 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 agoI 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 agoI 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.