You keep saying that, but I've never heard a justification for it that wasn't totally Kool-Aid flavored.
I'm all for safety in the sense of catching errors at compile time, provided they can be caught with minimal help from the programmer. Proof of more complicated properties should be optional. Haskell requires you to embed a proof of functional purity into every program you write, and this is just not how programming should work.
As to maintainability, this claim is clearly false. Pure programs become harder to change as they grow, because adding and removing side effects requires drastic restructuring.
Of course, most Haskell programs (in my limited observation) seem to deal with problems that are mostly mathematical or computational in nature, like compilers and Sudoku solvers, where these issues don't arise much. But that's not really an endorsement for something that purports to be useful in the Real World.
Re maintainability - it is not clearly false. The biggest problem with maintenance is figuring out what the code does in the first place. When you know that the code you're looking at has zero data dependencies other than its arguments, and what's more, cannot possibly introduce other data dependencies through any of its descendants in the call graph, it relieves the burden immensely.
Re adding and removing side-effects: I think you're just making this up without much experience. Most programs only need side-effects in certain areas, typically in the outermost loops and top-level functions. For example, a very simple single-threaded stateful web server could be implemented only needing I/O access in its outermost loop, implementing its request -> response function in a pure way, and using tail recursion to maintain state between different iterations of the server loop.
Re compilers: unless you've written several compilers, you can't make claims about techniques used in compilers not being highly useful in solving large classes of problems. In many ways, yes, compilers are the ultimate functional programs (output is a pure function of input), but guess what: the flow of a compiler - parsing input, inferring its semantic intent, performing required transformations and generating output based on recursive application of patterns - is exactly the same as the flow of an average web request.
I'm not sure where this idea that it is "mostly used for sudoku solvers" comes from. While clearly insulting, it is also clearly false.
The breadth of code on http://hackage.haskell.org/ gives witness to this, with just on 1000 libraries written over the last 18 months, most heavily weighted towards networking, graphics, guis, databases, and so on.
Similarly, the industrial users , http://haskell.org/haskellwiki/Haskell_in_industry , aren't writing sudoku solvers, but are finance houses, defense contractors, game companies, bioinformatics places, hardware dessign, a full range of applications, for a general purpose language.
Sorry, I didn't mean to imply that Haskell is only used for writing toy programs. I meant that Haskell people gravitate toward problems that are functional in nature. Many such programs are useful, though rarely in isolation.
If you're wondering where the idea comes from, here's an example. There is a thread on Facebook titled "What have you made using Haskell?"
6. A lambda expression evaluator with alpha equivalence testing
7. A hyperbolic raytracer
8. An image regression program
9. A program that finds equidistant letter sequences
10. A boolean expression to truth table converter
11. A resolution theorem prover
12. An interpreter of a Prolog basic subset
13. A Markov Chain generator
14. An anagram generator
15. A library for doing computation inside various algebraic structures
16. A maze generator and solver
Some of these are exercises, some are toys, some look potentially useful. But except for the first two, they are all pure-functional problems, and are rather abstract. Maybe this sample isn't representative of all Haskell usage or what Haskell is capable of, but the stereotype, like most stereotypes, exists for a reason.
Some of those are pretty big companies - clearly they're not using it for everything, but have decided it's the best choice for some particular problem domain. Sure, it's a general purpose language, but where's the "sweet spot"? I could write scientific number crunching stuff in Ruby, but that's definitely not its forte.
I would have never believed it without seeing it with my own eyes in my own programs, but Haskell's B&D type system really helps a lot in producing correct programs.
I am a relatively incompetent Haskell programmer and I am constantly amazed at how often algorithms I implement turn out correctly after I finally get them to compile.
It's an exaggeration to say that you must embed a proof of anything in your program. You just have to think a bit more carefully and explicitly about how your data is defined.
I'm all for safety in the sense of catching errors at compile time, provided they can be caught with minimal help from the programmer. Proof of more complicated properties should be optional. Haskell requires you to embed a proof of functional purity into every program you write, and this is just not how programming should work.
As to maintainability, this claim is clearly false. Pure programs become harder to change as they grow, because adding and removing side effects requires drastic restructuring.
Of course, most Haskell programs (in my limited observation) seem to deal with problems that are mostly mathematical or computational in nature, like compilers and Sudoku solvers, where these issues don't arise much. But that's not really an endorsement for something that purports to be useful in the Real World.