Is debugging functional oriented code harder?

Hi,

in popular languages like Perl, Python or C it's easy to add debug mechanisms into existing code, increasing it or decreasing their verbosity and details, it's also easy to add prints, that indicate execution flow of process.

How is it functional languages, where you can't just insert them? I tried this approach when I started to learn Haskell and results were miserable. Also some of you may say, that real world programmer should prefer debuggers, but I think, it's just different tool, they are usable, but for some cases prints or logs are much better. My questions are, do you use logging mechanism in your functional languages? Do you use somehow ordinal prints for this? Are there better ways?

Debugging functional _^Lisp code is easier, I just open up the REPL, load the code, call the function with some test parameters, check if it's correct. Don't know for Haskell, but it should be more or less the same.

>>2
I just open up the REPL, load the code, call the function with some test parameters, check if it's correct.
This. If this doesn't work for you, you're doing functional programming wrong or something. Split your code up into pure functions that do most of the real work and debug them separately.

>>2
>>3
You're right, but it's a good way when you create code, but what when you do  maintenance? What if you have complicated scenario, when you don't know when or why it fails? Testing single functions is hopeless in those cases, but some module tests + good debugs can made the job.

>>4
when you don't know when or why it fails?
If it fails somewhere, it fails there. The error message is informative enough to give me the function that failed, its parameters, the parameter that made it fail, and some context (i.e., file/line/column of the function definition, its name).

Most of the time, you have enough information to find the problem and fix it, debug prints usually are the last resort.

The secret is to separate all the undebuggable IO code from the pure code, and split the pure code in many little (3~10 lines) independent functions. Like >>3 said.

>>4
If you know that the functions that you've written works as they should then it can only be in the functions utilizing those functions that the error lies. Errors give pretty good info in Common Lisp.