zlacker

The problem is with man pages themselves. You shouldn't have to read 100% of something to find 0.1% of something. In fact, this concept is covered extensively in CS theory about sorting. Reading a manpage is less efficient than asking someone who already knows.

>>gosub1+(OP)
Only locally, only for you, and only short term. You are wasting the time of the person you are asking, and you are learning absolutely nothing about the context of the answer. When the next question arises, you won't even know where to look, you will only continue wasting other peoples' time.

>>gosub1+(OP)
There are some manpages which are too long, and cumbersome but it's not a widespread problem I believe. In particular man perldoc is laconic and on point.

I don't think that RTFM is the best form to answer, but those who auto-reject "man" as an answer are definitely missing something important

>>gosub1+(OP)
The trick is to already know how to use regexes to make searching the manpages easier! But you really have to nail down the rules for escaping when you want to search for perl's gnarliest sigil magic.

>>gosub1+(OP)
The man pages were broken into competent sections over multiple man pages. About 260 of them on this machine (not really: there is a change-tracking man page per release recently.) The 1st man page is a very compact index to them.

After that, each section is long but very searchable.

But I can see how many people never even noticed."Man page? what's that? what for?"

>>creer+cx
But if every user is expected to read the entire manual cover-to-over before asking a question about a four-character operator, what's the point of dividing it into sections?

>>Bratmo+AI
I know you are not serious but let's go with it anyway. Since we have to be welcoming to newbies :-) Not expected to read cover to cover. Cover to cover would be the tutorial / course work. And even then in a layered language like perl 5, the later chapters only when needed. Layered: the language and coursework is written to add one layer of the language after the previous ones. So you can start writing things that do function after just the first layer.

Expected to know it's there, navigate through it to find the operators or system variables and that you can search through the thing. There are ~260 perl man pages on this computer - not expected to read them. For damn sure expected to use them.

Do read one more section from top to bottom now and then - if the thing is the one fundamental tool in your job!

>>creer+XJ
But that's what the ancestor was trying to do. Then he ran into a symbol he hadn't gotten to yet, asked about it, and got flamed for not reading the full manual!

>>Bratmo+bO
> flamed for not reading the full manual!

It was not for not reading the full manual. It was for not using the manual. Somewhere between "not at all", "not competently", "not persistently". And he was pointed to a perl-specific tool which is made for searching the doc. Not the same thing?

And he/they had missed an entire category of symbols. That none of the responses pointed at - their bad on that. That is, all these symbols are described in the same manual section. And used in illustrative examples all over the place. They are not exactly a deep hidden thing.

Also, regarding "flamed". No. Not really. They were handed the same response that countless other questions were getting. Anyone frequenting these forums saw them countless times. It is quite possible that it was their first time on that forum / chat and then that the answer was shocking and traumatic. Yes to that. So that in hindsight, the standard response should have included a pointer to a "how to use the doc" doc. That would have helped. Since it was a generation was seemed unaware of the man pages.

>>thyris+H4
That's a false assumption that the man page even has the info you need. There are channels to write bugs against code, but almost nothing to file bugs against man pages. That's not even a concept to most people, that it's a bug when you apply a use case (say, to apply eui-64 to SLAAC in IPv6 in order to generate a consistent address) and cannot find the information using the man page. If you filed a bug that the man pages failed you nobody would fix it because it's not sexy, glamorous work. Its easier to tell someone to RTFM.

In this case, you would have to already know about the existence of eui-64 to know that is what you want. I've seen this many times, you have to know what the thing is already, or know what the answer is to your problem, in order to find it in the man page.

Total waste of my time. I don't care if it's free or was created by volunteers, that isn't absolution of criticism when it represents something and fails to deliver it.

>>gosub1+pZ
Nonetheless, you are expecting other people to know the manpage and read it for you. That is a game you may be able to play with paid support, but usually not even there: They will be more wordy and polite, but in essence tell you to RTFM as well.

Bugs in Perl modules that are documentation related are normal bugreports and patches in the normal patch flow because documentation is embedded as POD within the source code.

Your example is very specific and weird (and maybe not even Perl-related). From which you deduce that it is OK to waste the time of volunteers because once one manpage failed you and you decided to never read any manpages again. You only seem to care about your own time, not anyone else's. That is not how anything works on this planet, either you deal with volunteers, where you have to make them care about your query by being considerate, friendly and respect their time as well as you would like yours respected. Or you are dealing with paid support, in which case you have to make them care by paying them for their time by the hour.

>>creer+4R
The problem is the implicit assumption that you can throw an entire book at someone and expect them to be able to figure out where to look for each piece of information in it without them knowing beforehand what things even are. If someone hasn't ever seen a variable like `$|` before, it's not necessarily going to be obvious to them what it is, and without knowing how to classify it, they aren't going to know how to tell what chapter it's described in. You're defining the bar for someone to be able to ask a question as high enough that they spent enough time reading through everything to be able to identify it. That's going to be fine for some people, but not everyone learns the same way, and when some people learn better a different way than you, it's not because they're stupid or lazy, but because there's just a lot of variety in what works well or doesn't for people.

Of course, you aren't under any obligation to spend time helping people who you don't want to, but if a community as a whole reacts this way when someone asks a question, they're making the bet that the there are enough people who are similar enough to them to sustain things in the future. Given that this both happened years ago to the parent commenter and now again when they tell the story again, it's not really that hard to believe that this might have been common enough that a lot of people experienced it. The entire point of this thread is discussing why Perl has faltered, and your explanation in the last paragraph comes across as basically saying "kids these days..." in slightly different words. I'd argue that even if the kids loved man pages, having a condescending attitude towards them would probably still come through in other ways, and that would have had pretty much the same effect.

>>saghm+zh3
I am agreeing with you that there was a mismatch between the expectations on using the elaborate documentation in its various forms and the tutorials and the stellar course - and a large set of potential users. Nobody expected "the entire book" but perl 5's rise came at the time when many stopped reading man pages, and many projects stopped providing them.

I agree with you that this probably was a contributor in some people giving up perl quickly. For python or php.

Like I mentioned elsewhere, for people for whom using a book would be a barrier - perl would have been a poor choice anyway. You can't program in perl without using the man pages and books. It's a large language, with lots of features purposely made less visible to the newcomer.

In addition, many people were exposed to perl from web scripts. And it was sooo tempting to just paste in a perl script, and then want to modify it, without spending any time on learning the language. Perl makes that frustrating (and compensates with a stellar course book). I still defend perl by arguing that (in perl) there is no point in discussing what $| might mean even before having covered the basics, for example sigils. The course book is layered, and for good reason: to let you write a program in useful order, fundamentals first. The special variables come up fairly early but then again the course book had an extensive index which includes these special variables first in a symbol section, and then again in the alphabetical order for their wordy version $| or $OUTPUT_AUTOFLUSH. I'm not trying to beat you over the head with the manual. Just pointing out that the course book was throrough and intelligently written.

I'll point out that throwing a question at a forum without poking around it a little to figure out the local mores - well, still now, that will get you barked at. Lesson: Forums would do well to provide a more useful paste-in than "RTFM" - ready to go for their users. Instead of "RTFM". At least if they want to foster adoption. Does any forum do that particiularly well, that you have noticed? Most discords for example, do NOT do that well: it's possible to create stickies and they are really not visible. So people create onboarding documents which then get too long and get skipped. A problem not solved there.