A big selling point of Haskell is type safety/making illegal states unrepresentable. Classes of bugs that would show up deep in your stack at runtime now bubble up to compile time. This means that the user is expected to interact A LOT with type errors. I’m not sure how much UX has gone into making error messages easy to navigate but I often times find the error messages difficult to read.
E.g. forgetting a comma in a list or missing parens.
There have been efforts, see the repo in the Haskell Error Index.
I think most Haskellers first check the location of the error, and only then the error (for example, a missing comma often results in a wrong application, with a barrage of abuse from the compiler).
Yeah, I think you get pretty good at spotting minor syntactic errors when you get a bit more experienced with the language. Of course that is not good for newcomers, but it explains the status quo.
Error messages are incredibly hard. This is, of course, not an excuse, and the GHC team puts a lot of effort into improving them. Here are some interesting measurements:
GHC’s constraint solver (which is the most complicated part of the typechecker) is around 6,229 lines of code, while the error generation code is about 10,542 lines of code …
If you see a bad one and/or have an idea for improvements, GitHub - haskell/error-messages accepts reports (posted earlier here at Proposal: An issue tracker for better error messages )