Here's a small function from a real world module used in a Haskell web backend. It decides whether a "work unit" is appropriate to pick from a queue. The first iteration was a pretty complex piece of code. When I refactor, I often think "this is unclear and should be commented," but I've learned instead to think "this is unclear and should be factored out and given a significant name." So I ended up with this:

    shouldPickWorkUnit :: (ImportId, WorkUnit) -> STM Bool
    shouldPickWorkUnit (k, u) =
      case hostNameFor url of
        Nothing       -> return True -- Invalid URLs are fast to process.
        Just hostName ->
          takeWorkThat'sAlreadyDone <*>
            (don'tTakeSomeoneElse'sWork <*>
              don'tExceedTheRateLimitFor hostName)

This way, the domain logic is legible from the actual code, which strikes me as almost always better than having tricky code with comments. Trying for this also encourages "domain-driven abstraction," and this is one of Haskell's greatest strengths.

In fact, the remaining comment can be factored away too:

    shouldPickWorkUnit :: (ImportId, WorkUnit) -> STM Bool
    shouldPickWorkUnit (k, u) =
      takeWorkWithInvalidUrl <*>
        (takeWorkThat'sAlreadyDone <*>
          (don'tTakeSomeoneElse'sWork <*>
            don'tExceedTheRateLimitFor hostName))

Advice like "avoid comments" needs to be taken as a calling for actually spending time and effort to write obvious code, and for using appropriate abstractions!