The death of tribal knowledge

Michael Schwern talks about Perl5's shortcomings, and explains how perl5i can overcome many of them - it is a pragma to fix as much of Perl 5 as possible all at once. While I haven't worked with perl5i much, I wanted to talk about something Schwern talked about that resonated with me, and that's the concept of "tribal knowledge."

One of the nice things about Perl (and Perl culture) is that you can talk baby talk, and as you learn and grow, your use of the language becomes more sophisticated. I certainly put that into use as I taught myself Perl (and continue to do so). I started by cargo-culting more or less 100% of what I was doing - and I was learning programming itself as I learned Perl. That's probably part of why Perl is the language I feel most fluent with (which is not to say I am fluent).

As I did that, I made an effort to ask about best practices, and so I quickly learned to - for example - check the return value of open. That's a simple example, and I would have figured it out eventually, even if I did so the hard way. But there are a bunch of things that I wouldn't have learned had I not made an effort to ask, or read extensively. For example, I probably wouldn't have encountered autodie, which is a truly golden module. And here's why:

When opening a file, it's seldom a good idea to continue if the request failed, so open is frequently used with die. Even if die won't do what you want (say, in a CGI script, where you want to format a suitable error message (but there are modules that can help with that problem)) always check the return value from opening a file. [an excerpt from perldoc open]

So, the documentation gives you the right idea: you should check that opening didn't fail before your program tries to use the filehandle. And it gives some more good advice: In a CGI script, you might prefer CGI::Carp to handle errors rather than dying in the normal manner. I've done that, and while the Modern/Enlightened Perl people eschew CGI.pm, it has a place still. But note that there's no mention of autodie. Why not?

So, "everyone" knows about autodie - it's great, and we love it. But "everyone" isn't really everyone, it is actually a select group of people who work with Perl a lot, and make it their business to know about these things. The recent Perl book Modern Perl does an excellent job of highlighting these new but optional features of the language, but most documentation does not. Unless you've read a book (I assume other Perl books mention the more modern bits of Perl too), or otherwise know about autodie, you're out of luck.

That's because knowledge about such things is passed around socially. Michael Schwern likens this to the generational transmission of tribal knowledge, an apt parallel. And he's not the only person to have noticed this. Max, a Bugzilla contributor, pointed this out years ago:

The problem with Perl, I think, is that the basic documentation that everybody reads doesn't say, "Okay, here's the Good Way To Do Things. Use Moose and Be Object Oriented." I had to really go out of my way and research the best way to do things in modern Perl... Imagine that you had a book that taught you how to write, and then after you were done with it, somebody had to come up to you and say, "Okay, that's not really how you write. I mean, you could write that way, but everybody would laugh at you. Also, you can't use that pencil, you should use this special pen, because it makes life a lot easier."

I agree wholeheartedly - I'm very thankful that the Perl community is so easy to talk to, and join. Nearly every Perl community member I've reached to for help has given it in abundance. But that's because I asked, and read, and looked around for the best way (or at least, hopefully, a good way) of doing things. I made an effort - and I'm not even sure I got it all right.

The Perl community needs to make an effort to codify tribal knowledge. perl5i is a great start, and reversing the effect of the feature pragma could be another great idea. Another might be sprinkling hints throughout perldoc. Why shouldn't perlopen mention autodie, and why shouldn't perlsub suggest using Method::Signatures? You shouldn't need to tack Modern Perl onto the documentation Perl ships with to know about these things, and you shouldn't need to ask for the last 9 years of features to be enabled. Newcomers should be able to get the power the insiders use without being an insider. If you have other ideas for killing off tribal knowledge, I'd be happy to hear about them.

Comments
Comment from arun prasaad - February 11, 2011 at 10:49 pm

".. why shouldn’t perlsub suggest using Method::Signatures?"

Some answers to that question can be found in this discussion

Comment from brian d foy - February 12, 2011 at 1:16 am

The Perl 5 core documentation documents the language, not the best practices. That's the way it should be. I don't think you are going to fix anything by changing that because people already don't read the documentation. The latest practices are never going to be in your distro because they are updated too frequently for most vendors to track that stuff. You could distribute something, but it would be out of date within several months.

If you want to keep up your Perl skills, spend 10 minutes a day following Planet Perl, reading the latest books, and doing the normal things good programmers do to stay current. We don't need to make any additional effort to educate you. You need to make that effort with everything that we provide. Instead of blaming the community, consider all the community provides for free for those who care to pay the slightest attention.

Comment from Gabor Szabo - February 13, 2011 at 11:46 am

I think there is a big difference between mentioning autodie or Moose (just to take an example) in the core documentation and that is the fact that autodie is a core module while Moose is not.

In any case maybe, the documentation should point to some place ( http://www.perl.org ?) where further recommendations can be found.

That said, unfortunately I can only teach limited aspects of "Modern Perl" as most of my students are stuck on some relatively old version of Perl and in many cases it is hard (politically) to install new modules.

BTW, brian, I don't see any blaming in this post. I do see a bunch of caring.