> ... I am a bit lost
Google "cognitive dissonance" and the "sunk cost fallacy."
Google "cognitive dissonance" and the "sunk cost fallacy."
That is dangerously close to the infamous "if it compiles, then it works" boast, which Haskellers make all the time (while denying that they make it), demonstrating in the process that they don't write real software, where the defects one encounters are very often of a nature such that the program behaves exactly as intended by its authors, but the intended behavior is itself wrong. How does the type system help here?
My comment wasn't glib. I actually think those phenomena quite well explain much Haskell advocacy. Considering how massive an undertaking it is to learn the language and its Byzantinely-complex, PhD-theses-in-disguise libraries (each of which sports a zoo of custom operators) and how small the payoff is, it's unsurprising that those who take the plunge begin zealously encouraging others to do the same, lest their own investment have been for nothing. In a way it's like a conspiracy.
The "if it compiles, it works" thing describes people's experience. It isn't always true and it isn't a valid excuse not to do proper testing, but in Haskell a non-working solution is usually at least broken in a way that makes sense in the context of the problem you're trying to solve. If you program an incorrect solution to a problem, you'll probably get a wrong answer. But a wrong answer is different than nonsense, which is what you get if, say, you write past the end of an array in C.
The Haskell type system is a very good nonsense filter, and probably a majority of programming errors are from telling the program to do something nonsensical. If you filter those out, sometimes what's left is a working program.
A Haskell programmer is unlikely to write a several thousand line program and have it work correctly the first time, but even large programs are written in small pieces. When those small pieces work correctly the first time, it's gratifying.