Another day, another argument over how to document TIMTOWTDI.
Some people prefer to write tutorials for novices that start from "the
simplest thing imaginable" and then gradually introduce newer features. I took
a different approach in the Modern Perl book.
In the context of the
open tutorial discussion, the book very
deliberately recommends against the use of bareword filehandles (except in
named exceptions of
DATA) and always recommends
open over the one- and two-argument
This is a matter of philosophy on which reasonable people differ.
For the book, I wanted every example to run without error under
warnings. Most examples use Perl 5.10
features such as
say. That's part of the reason I wrote the Modern::Perl
metapragma—I wanted to explain once a single line of magic that helps
novices get as much assistance as
perl itself can provide to write
That does mean that any discussion of opening files depends on the reader already knowing how to declare a variable. That also means that the discussion of declaring variables has to take place at or before the discussion of assigning to variables.
Of course, someone who's never used Perl 5 before will, from the start, have strictures available to help catch undeclared variables and typos in variable names. The first lines of code this novices writes will be strict safe.
(I spent ten minutes the other day wondering why Devel::Cover couldn't
see the documentation for two methods generated during
as closures, and was almost ready to file a bug until I noticed that my
documentation had typos in the method names. Typos happen.)
This strategy also means that the
open code novices write won't
use package global variables, so they'll avoid spooky action at a distance if
they keep their lexical scopes sane. Even better, they don't have to understand
local works and what dynamic scope is in order to write safe
In other words, Perl 5 novices who read Modern Perl: learn from the first page to write code which:
perlto give better warnings and error messages about dubious constructs
- Limits the possibilities of using global variables
- Avoids subtle security problems from magical filemode detection
- Scales up to larger programs, mostly thanks to the first three items in this list.
In addition, these readers do not have to unlearn habits the book
has previously helped them adopt. Plenty of people use Perl 5 to write little
programs of a couple of dozen lines where the risk of a typo is minimal or the
spooky action of an unexpected global change is almost irrelevant, but there
are plenty of other people using Perl 5 to build bigger programs or programs
which will become big. Why deny them the
perl's full abilities to
help them write correct code?
All it takes is the philosophy of "teach people to write code that can scale to larger programs" and the willingness to rearrange the order of concepts presented so that variable declarations come before opening files. (It's easy to write real programs which only ever print to standard output until readers understand variable declarations.)
It's not that package globals or barewords are intrinsically and always bad,
and so you should never use them. (Even if I wanted that to be true, it
wouldn't be true.) Instead, the book always takes the approach of showing a
better (easier to verify, safer, more secure, easier to understand, fewer
loopholes, simpler) approach over the alternatives. That's why it teaches OO
with Moose, why it recommends Try::Tiny over
eval, and why autodie gets prominent
If experienced Perl 5 programmers use all of these great tools to take care of unsafe, complex, messy, fragile details, why not help novices use them as soon as possible? Certainly, some of them only need to know a few details to write a couple of dozen lines of code, and that's perfectly acceptable—but plenty of others could be great programmers solving real problems with more ease if we smoothed out the way for them a little bit more.