I feel that while type information is useful, some of the more advanced libraries have signatures that are very difficult to reason about.

Disclaimer: Didn't write read a lot of Haskell so it may be just that.

Definitely. It can go VERY overboard at times, and that's part of Haskell style, writing code that makes intelligible types appear. It means that both the compiler and your users will have an easy time with your code. Most of the best libraries are pretty good about that.

It's also a familiarity thing. The most complex signatures require some practice before they're easy to digest.

See, the issue I have with this is that in my own experiences with other language, this is almost never a problem. I don't need to know "what" something is doing, I need to know "why" the developer did it that way. Haskell seems like it goes out of its way to obfuscate intent with heavy abstraction, avoidance of semantic variable names, and sometimes avoidance of variable names entirely. That seems like exactly the sort of code that I find least comprehensible...

By "what" I mean semantically what---I need to know that this function turns a Tree into a List or a Person into a String. I find this information very useful as it's fairly non-operational. Usually functions are further documented with a bit of intent information.

The avoidance of variable names is hard to judge until you program in Haskell a lot. Variables (or "points") tend to just be used to wire pipes together. These variables are rarely used more than a line or two after their definition and thus short names emphasize this local context.

When people write code that involves variables naming mutable cells or long-lived context they provide long, descriptive names. I don't think anyone disagrees about the utility of that. It's just a rare style in Haskell.