Well, actually, I don't think I am assuming that the poster hasn't read the FM; rather, I am suggesting that a post whose answer is obvious -- from the documentation's text or examples (IOW, in the FM) -- strongly suggests that the poster has not RTFMed (or has not RTFMed will diligence). Yeah, that's a lot of qualifiers... almost to the point of making a distinction too fine to worry about...

But you are not the usual poster of what I call 'gimme' questions -- questions that are or are tantamount to "Please write my code for me;" "please do my work for me;" and "I'm ignorant of the existence of the FM." I think the distinction is obvious... and if you post one that falls in the class to which I'm objecting, then I'm going to assume that the issue is a momentary case of brain-lock, not to laziness.

And a request: within the class of well-written docs -- that is, those with decent examples and explanations -- re-examine your last para. Lord knows, I'm as likely or more so than most, to blindspot myself while reading a doc, but (YMMV) find that re-reading a well-written doc ofter provides a face-palm moment when the scales are lifted away.

I am suggesting that a post whose answer is obvious -- from the documentation's text or examples (IOW, in the FM) -- strongly suggests that the poster has not RTFMed (or has not RTFMed will diligence).

In this context, the difference between perceiving a suggestion and an assumption, besides being too marginal to call or argue about, still misses the possibility that the OP has read the documentation and has simply misunderstood it or just didn't understand it at all.

I think that it is all too easy for those with long-term familiarity with the Perl docs to assume they are the very model of suffice and clarity, forgetting the struggles they themselves once had with them.

When I first came to Perl, despite 20 odd years of experience of other languages on several platforms, I found many parts of Perldoc to be quite opaque. Particularly because much of it assumes access to and familiarity with POSIX APi documentation. The assumption that "xxxxx() works the same way as xxxx() (2)" will mean something is rife in some parts of the docs.

And there are other parts that still go right over my head. Eg. The use of \G (and (?>...) for that matter ) in regexes. If I sit and read the docs and play in my REPL, I can usually, eventually make these constructs deliberately do something of my choosing. Usually. But you'll rarely if ever see me use them to solve real problems. I've simply never found the analogy or example that allows me to assimilate them into my way of thinking. As such, I've found other ways of solving the problems they are there to solve, and they do not figure into my approach to solving problems.

Concluding that an OPs failure to understand the relevant part of the docs is due to a lack of "due diligence", is assumptive in the extreme.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

"I think that it is all too easy for those with long-term familiarity with the Perl docs to assume they are the very model of suffice and clarity, forgetting the struggles they themselves once had with them."

      :-{)

Trust me! That's not me you're talking about, whether because of my own (relative) nooby-ness, my lack of a formal cs background; or simple simple-mindedness... but for my $.02, far too many perldocs -- esp. those for modules -- are on a par with the worst of the nixish documentation -- reflecting, IMO, a mindset by the writers that "I know what I mean; I worked hard to get here; let the reader share the pain."

Want a specific example of a core doc which doesn't begin to say enough to make use of its function? read truncate (which, unlike the POSIX doc for truncate(), fails to mention writability as a precondition); want one that's merely confusing or ambiguous? There's a wealth of such docs.

Fixed link to the truncate doc

The assumption that "xxxxx() works the same way as xxxx() (2)" will mean something is rife in some parts of the docs.

I do not see a problem with that. It's just a reference. Not also that in many cases, it cannot be documented more accurately in the Perl docs, as it will indeed use the xxxx() from your system, and that may be implemented differently on different platforms.

And there are other parts that still go right over my head. Eg. The use of \G (and (?>...) for that matter ) in regexes. If I sit and read the docs and play in my REPL, I can usually, eventually make these constructs deliberately do something of my choosing. Usually. But you'll rarely if ever see me use them to solve real problems. I've simply never found the analogy or example that allows me to assimilate them into my way of thinking.

Sure, but what's the alternative? Write even more documentation? That will make the fraction that's saying there is too much documentation making it hard to find stuff stronger. Or would could just take out a lot of things from Perl (regexes are hard -- remove them. IO is hard -- remove them), moving them into libraries (or modules). But then, if I want C, I know where to get it.

Concluding that an OPs failure to understand the relevant part of the docs is due to a lack of "due diligence", is assumptive in the extreme.

Perhaps. I don't see many questions of the form of "I read 'X Y Z' in the documentation. Can anyone explain what it means, and whether (and how) I can use it to solve problem W'?". If there are parts of the documentation that turn out to be unclear for large groups of people, I'd like those people to be vocal about. If they don't give any indication they've checked the documentation, and they ask a question that can be answered by just quoting from the documentation, I'll assume they haven't checked the documentation.