zlacker

Let me respectfully disagree.

  man perldoc

would tell one needs to use -v key to learn about a var. And consequently

  perldoc -v '$|'

would tell everything one needs to know about $|

So it was actually reasonable advice.

>>broken+(OP)
RTFM might be reasonable advice, but its not "welcoming" advice.

>>bawolf+81
I agree in general (and already commented on this). But some people believe it's like giving fish instead of fishing rod. And I think it was prevalent idea in tech circles during 90s-00s that people who don't read that fm waste other participants time, and needlessly multiply forum topics or extend conversation history. Which was seen as uncivil behavior in those times.

>>broken+(OP)
Fair enough, but I think the first part of the advice would be a lot more helpful if it included the second part too. It's the intermediate step that turns people off: why do I need to learn about `perldoc` when I asked about `$|`? (And that's assuming the question asker is familiar with man-pages to begin with, otherwise, you need to read `man man` first!) It feels like you're sending them off on a wild goose chase, even if that's not your intent.

In the millennial web forum world, a n00b would ask "what does $| do?" and the answer would be "it disables output buffering", which is what the n00b wanted to know in the first place. It's the Stack Overflow model of giving men fish, instead of teaching them how to fish.

And in today's LLM-powered world that's only more true. If you ask ChatGPT "In a Perl script, what does $|++ do?" it will immediately give you a correct and concise answer, not make you read `man perldoc` first.

>>sltkr+d5
Yes, it would look and work better if presented with an explanation like "you can find any var description by using...". But as I commented already in another thread there was a widespread belief in 90s-00s that users who ask about already documented pieces are being uncivil, not vice versa. So it's not about Perl community per se. The same was norm in many Linux fora, for example.

>>bawolf+81
I remember being very enthusiastic about helping people on, say, Stack Overflow. It didn’t take much extra effort to be nice and made me happy.

But I also burned out relatively quickly. I’d happily answer new questions nicely, but the third or fourth time I saw the same question I spent much less effort to give a welcoming answer than I had the first time I saw it.

Of course, getting the same question repeatedly may suggest something should be redesigned.

I don’t know any good way to keep helpful volunteers helpful for a long time. The best idea I have is constantly recruiting new experts to continually replace the ones that burn out and chase off newbies.

>>bawolf+81
If they specified ‘perldoc -v $|’ instead of just ‘man perldoc’ I’d have been thankful for that as the entire response. It’s literally a pointer to where the answer is and to how to use the canonical tool to find it.

>>broken+(OP)
so they should have written that. Next you're going to tell me man man is reasonable advice

>>broken+(OP)
How would I know that $| is a var? It could be an operator, or a function, or a directive.

>>bawolf+81
Yep, especially when so many instances of TFM were awful. Perl's docs were fantastic, or so at least I thought at the time, but they were the first large open source project docs I devoured. I can imagine someone coming from another language not even considering just looking at the man page because they were used to awful documentation.

>>maxlyb+Xe
> getting the same question repeatedly may suggest something should be redesigned

Yes! There was a lesson in that and we all missed it. That was probably one of the failings of perl. It ran into a generation of people who never knew about "man pages", or couldn't read (jk - but only somewhat: for some people reading is very hard because various flavors of ADHD, dyslexia, executive disfunction, whatever) and the man page is then useless, or they go to google first and '$|++' failed (because google was raised on python).

Better marketing of the documentation would have helped.

I would say "we'll do better next time" but then perl 6... I'm not happy with perl 6 documentation. There is a lot of it - no problem there. But it insists on living online which necessitates a hosted search function. Which is always broken. And there is still no "local doc" solution.

>>chabsk+sz
There's no space for doubts at all. If it starts with $ then it's a scalar variable name. It's a very basic rule in Perl. Like any Perl tutorial would mention it within a few paragraphs from the start.

>>broken+zN
So then wouldn't that make $|++ the variable name?

>>kstrau+eD
You are right, Perl's docs are so unusually good that newcomers can't believe they don't need the internet to find clear answers, and go searching/asking anyway, sometimes in wrong places.

FreeBSD has the same problem: plenty of its new exploring users dismiss the most well-intentioned advice to read its excellent Handbook as a sort of joke.

>>Bratmo+NO
Smokey, this is not 'Nam! This is <Perl>, there are rules!

'$' guarantees a scalar. Then it either alphanumeric id, or a single non-alphanumeric symbol. And the latter means you deal with a 'special' var which with 100% certainty has a documentation entry.

>>broken+sQ
I’ve seen that one firsthand! “I want to do a thing.” “That’s in chapter 5 of the handbook.” “Oh cool. Is there a substack or something that explains it?”

>>creer+5E
man I hate that always online stuff. why isn't there the comprehensive man pages thing for perl 6? rhetorical question tho, I don't have much interest in perl 6.