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.

"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.

I do not see a problem with that. It's just a reference. ... Sure, but what's the alternative? Write even more documentation?

Neither remark is intended as a critique of, nor a call for changes to, the current documentation.

They are simply supporting argument to the premise that no documentation can be expected to be able to teach everything there is to know. That sometimes, even with due diligence, some of us need help interpreting the documentation. Whether because we don't work with POSIX platforms and docs and so need help in understanding how those APIs might have been emulated on our platform; or because the subtleties (and changing subtleties) of the way certain features (and the regex engine is a prime example) are just very complex and require the acquisition of a 'mental model' that fits our own way of thinking.

Sometimes we need an additional nudge for some parts of the docs to 'click'. But the crux is, each person will need that addition nudge for different parts. It would be nigh impossible and certainly counter productive to try and incorporate all those additional nudges, for all those different people, into the documentation. Especially as they are probably only required the first few times until the penny drops.

And that's what this site is (or should be) about.

A place where people of any level, can come and find others of a similar level of understanding, with whom they can discuss their particular blind spots and resolve them without incurring the wrath of those with more experience who have achieved greater levels of understanding.

And all that is needed to make that work is for those of us with more experience of Perl to recognise that when someone asks a question that we consider trivial or obvious, that they aren't asking that question specifically of us. We should not feel the need to be affronted by it. If you read an OP and feel the question is obvious, trivial and a waste of your time -- don't allow it to waste your time. Just move on. Certainly don't waste your own time and theirs by posting some "make the effort and look it up" flaming response.

There will be someone else along soon, for whom the answer is a recent addition to their knowledge, who is only too happy to give back and share that new found knowledge.

Physically, the simplest thing in the world to do is to 'click the back button'/'hit the back key'; but on the evidence of this place, psychologically, it seems to be a very difficult thing for many people to do. Kind of like the way sorry is the hardest word.

---

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?