[tome]

> Right. It is quite easy to build convoluted Haskell code just as it is easy to to build convoluted Java code.

I don't think it's quite as easy, but I'll concede the point so I can make the more important point: it is much easier to write clear Haskell code than clear Java code (at least, "clear" as I understand clarity, YMMV).

> You can reason about it, the type checkers can check deep properties about it, but it is difficult to actually observe the computer executing it!

Certainly purity makes it hard to observe, and laziness makes it hard to understand how the program executes. However purity also means that static debugging (e.g. QuickCheck) is far more powerful than in other languages so dynamic debugging (actually watching your running program) is less needed. In fact I do far less debugging in Haskell than in Python, say. I first fight the compiler. When I win, the end result is correct more often in Haskell than in any other language I've ever used.

> To me, this is a deal breaker.

That's fair enough. Everyone has their own preferences. Personally I've never noticed it be a problem.

Disclaimer: I don't write performance sensitive code. I expect performance tuning in Haskell is harder than what I've described above.

[seanmcdirmid]

> I first fight the compiler. When I win, the end result is correct more often in Haskell than in any other language I've ever used.

And now we get to a few of questions related to bias:

* Given that debugging is difficult in Haskell, do Haskell programmers to get in the habit of statically debugging their code? Is that really more "better" than dynamic debugging? Some type error messages in languages like Scala and Haskell can make static debugging quite painful.

* Does Haskell's powerful type system bias it to well understood problems with meaningful types? I attended a WGFP meeting once, and it was amazing to hear people like SPJ talk about how they found elegant solutions to icky programming problems, but I thought that, given a dirtier language, you could just write a dirty solution and be done with it.

* Would Python's dynamic type system make it more suited to problems with dirtier less clear types when compared to Haskell? If you know both Haskell and Python, do you divide your potential programs into "Python programs" and "Haskell programs"?

* When one writes Haskell code, do they really not have to debug and test their code?

[mercurial]

> * Given that debugging is difficult in Haskell, do Haskell programmers to get in the habit of statically debugging their code? Is that really more "better" than dynamic debugging? Some type error messages in languages like Scala and Haskell can make static debugging quite painful.

I'm not sure what you mean by "static debugging". You're going to get type error messages while you're trying to compile, but certainly not at runtime. GHC really does its best to make them as explicit as possible and often suggests the correct fix.

> * Does Haskell's powerful type system bias it to well understood problems with meaningful types? I attended a WGFP meeting once, and it was amazing to hear people like SPJ talk about how they found elegant solutions to icky programming problems, but I thought that, given a dirtier language, you could just write a dirty solution and be done with it.

Not really. It is really a general purpose language, and you find very good libraries to interact with less strongly typed systems (eg, JSON).

> * Would Python's dynamic type system make it more suited to problems with dirtier less clear types when compared to Haskell? If you know both Haskell and Python, do you divide your potential programs into "Python programs" and "Haskell programs"?

If anything it would be more a question of libraries. One thing you won't be able to get in Haskell though is something like an ORM, with lazy-loaded collections and stuff like that. I find myself missing SQLAlchemy. Persistent does not have the same flexibility, despite Esqueleto which looks nice.

> * When one writes Haskell code, do they really not have to debug and test their code?

No. The best type system does not help when you write the wrong values with the right type in your program, or get the logic of your program wrong. But the errors tend to be more interesting. Also, you have a very powerful system to test the pure parts of your code (QuickCheck).

[tome]

I don't have good answers to your first two questions, since they're very open ended. I can give you my personal experience regarding the second two.

* Would Python's dynamic type system make it more suited to problems with dirtier less clear types when compared to Haskell? If you know both Haskell and Python, do you divide your potential programs into "Python programs" and "Haskell programs"?

No, I classify my potential programs into "Haskell programs". I haven't missed Python once.

* When one writes Haskell code, do they really not have to debug and test their code?

Haskell programmers still have to debug and test, but I find it somewhat easier than I've found it in other languages.