On Mon, Aug 25, 2008 at 7:54 PM, Niels Aan de Brugh
<nielsadb@gmail.com> wrote:
Christopher Lane Hinson wrote:
Here's an error the Haskell run-time system might throw:
*** Exception: Prelude.head: empty list
(or whatever)
So now what? Action plan = [].
rgrep " head " .
Lists 17 items for three projects I've been working on summing to 10000 lines of haskell. Use listToMaybe or pattern matching and -Wall, and raise an explicit (error "with explanation"), which is all good practice in the C world as well. Please, don't make undocumented use of partial functions in serious code.
You're absolutely right, and the compiler can warn the programmer for such mistakes. However, I've found that analysing the run-time behaviour/errors (if they do occur) in a Haskell program to be harder than in a language like C(++) which has many very mature engineering tools available. No doubt this is a matter of time and money, not which language is better suited for "real work".
I sort of agree with this, but I don't think that the total amount of time spent on that activity is even comparable for the two languages. In C/C++ breaking into the debugger and stepping through code is often the easiest way to even understand working code. That's both a testament to the high quality of the visual studio debugger, but it's also an indictment of how difficult it is to understand code written in the language.
In Haskell, on the other hand, everything is much more modular and "direct" and if you can't work out what the program does, a little poking in an interactive session will usually get you there far faster then anything you could do in C++. The same goes for tracking down bugs, IMO. It would be nicer to have better traditional debugging tools of course (particularly something that ties into a nice IDE), and I do think this should be a priority, but even then they wouldn't need to be used nearly as often as for C/C++.