One can write simple, structured code for simple problems in any language. But complex problems require languages that don't attempt to babysit programmers.
(IMNSHX, YMMV)
Scala is quite flexible and can accept good and bad code, which is good. I was only calling out FP abuses and its promotion as some sort of holy grail that is so much better than objects. If you compare Scala FP to Java OOP, ya, Scala FP is better, but if you compare Scala FP to Scala OOP, it's a much fairer battle and I put my faith in the latter (with the caveat that I can always use Scala FP when it makes sense to do so!).
Instead one should be able to just hack away until the code kind of does what they want (even though they can't prove anything about that piece of code) because that is the only way to really manage inherently complex problems?
The older I get the less I find writing code an attractive method for understanding a problem. I also find utilizing something like a type system to enforce invariants in code liberating - and actually conducive to solving problems.
You could have it output the value after each function is applied, but that would either break purity (by having I/O) or, per the GP's point, be tedious to write. At this point, the Haskell community made the decision that in debugging, "screw purity", and the output is effectively untyped.
Certainly, you can use tests of expected invariants (eg QuickCheck), but that just tells you that the whole thing fails.
That is, I think, also the GP's point: that the same things that make your final code good in Haskell, also make it hard to write.
(No to say I don't like haskell; this is just a peeve,)
Programming is not just about implementing solutions, but also about finding solutions.
When constructing a set of rules in the first place (or when first formalizing an existing, but implicit, set of rules), the human can do the requirements gathering, design, bug-finding, etc. But humans are terrible at simulation--they can't foresee what each and every consequence a particular rule might have. When constructing a rule-set, a human's productivity is enhanced by the computer taking over the "simulation" part, to explore the consequences for them, where the human can then change the rules in response.
Type systems of all kinds, though, basically assume that the rules defining the code are invariant. They don't help with simulation at all.
