* Not quoting a heredoc terminator is hardly bad style.

It implies double quotes, which newbies often don't expect. How many questions have you seen about why code doesn't work that look like this (warns because of @bar):

print FOO <<END_OF_MAIL;
To: foo@bar.com
...
END_OF_MAIL
[download]

If you use the terminators unquoted now, better get used to quotes before Perl 6 arrives. Quotes will no longer be optional, according to one of the Apocalypses.

# Strict isn't mentioned early enough which is a valid complaint, but even Learning Perl 2nd ed didn't have and entry for strict in the index, though it does actually talk about it for a few paragraphs on page 99. Did you used to recommend this book?

No, I do not recommend Learning Perl. I read it after learning the language, and was disappointed. Didn't even finish reading. It's a nice book for people who want Perl as a scripting language to automate some common tasks, but maybe I'm too much involed with larger projects to judge. I have recently read some Java books, and although I hate the language, I must admit the learning part is better, partly because some style is enforced.
strict should imho be default in every example, at least use my a lot. Do not let beginners drown first only to tell swimming was the better option. Perl tutorials and books often get this wrong. Good programming habits seem to be unimportant, and I disagree. That you can do without declaring variables, doesn't mean you shouldn't. I'm glad strict will be default in Perl 6 modules.

# Subs at the bottom is more of a religious issue.

It is only religious to those who put them at the bottom. Most of the top-subbers are rational.

Yes the file scoped lexicals are then shared with the subs but I've never once seen this cause a real-world problem with the code and many coders, of varying skill levels, I've worked with.

Either you don't combine your "main" code with subs, or you haven't done large projects. Another possibility is that your main code itself is in a sub.

# Using # as a delimiter is fine, in the right context.

I did not say it was bad. It's just confusing. Tutorials are for beginners, not for people who already know how to make choices.

# srand was not automatically called in versions prior to 5.004, and 5.004 only initially came out the same year this tutorial was first written (1997 according to copywrite notice).

My mistake. I thought automatic srand was introduced together with 5.000 itself.

* He did show the C for loop style, for with range, and foreach over an array discussing implicit use of $_. I really don't grasp your complaint on this point.

The order is, in my opinion, wrong. First comes the C-style loop, then comes a foreach loop that still uses an array index and then there is our beloved foreach loop that uses the actual array values. It should be the other way around: first loop over the array itself, then show how one can use the indexes and then discuss the advanced topic of C-style loops. -style loops should be accompanied by a while-equivalent, as it's strange to assume newbies will understand what EXPR, EXPR and EXPR are.

It was still, and maybe still is, one of the better such tutorials out there.

That is the nauseating part. This being one of the better ones means that most tutorials are even worse. But as I said, this tutorial could very well be a good one if some changes were made. Unfortunately, the author could not be reached at the address near the end of the tutorial.

I haven't read the new perlintro in 5.8.0RC1 yet.

It's a good introduction, but not really a tutorial. I would recommend beginners to read it before they read a tutorial or book.

- Yes, I reinvent wheels.

- Spam: Visit eurotraQ.