Pre-order Learning Perl 8th Edition

Learning Perl, 8th Edition, covering up to Perl v5.34, should be available in August. In the previous post I outlined some of the updates, although back then we though v5.32 would be the last version in the Perl 5 range.

It’s now available for pre-order on Amazon. Amazon has an initial price that’s a bit high, but I expect that to come down (the same thing happened for my last book). You will also be able to read it through Safari Online.

I expect to add a few additional exercises to Learning Perl Exercises some of the new material, but that book is still good for this edition. The chapter order has not changed so everything still lines up.


Looking for Learning Perl reviewers

[I’ve found enough reviewers and am not accepting more. If you’ve been a reviewer for a past Learning Perl, however, you can volunteer again. If you’re interested in doing this sort of work, pay attention to any of my blogs since I’m likely to start revising another book when I finish this one.]

I’ve got Learning Perl, 7th Edition building on O’Reilly’s Atlas system. That means I can start showing it to other people for comments and reviews. If you think that you’d like to be one of those people, send me an email (the first step being the sort who can find my email address). Continue reading “Looking for Learning Perl reviewers”

We’re starting Learning Perl, 7th edition

The holiday season tends to find me writing Perl books. This time it’s the next edition of Learning Perl, last published for Perl v5.14. This time we’re targeting v5.24, and there are lots of exciting new features that we want to tell the new Perl users.


"7"


We can’t make promises at the beginning of the book, but here’s the rough idea so far:

  • Goodbye, smart match. We gave it a chapter, but now it’s experimental .
  • But, subroutine signatures! People are going to love those.
  • So, an appendix on experimental features. Or maybe a chapter. Mostly on how to enable them.
  • the /r modifier for s///
  • Removing most of the stuff that Perl has discarded without abandoning people using older versions.
  • Key-value slices, and slices, and splice.
  • The double diamond operator <<>>.
  • New Unicode regex stuff

I’ve done this too many times to promise a release date either, but late summer wouldn’t be a bad guess. When I get the current version into something editable and fixed up, I’ll start putting out review versions somehow. I don’t know how that will work yet.

Should we call it “Learning Perl 5”

Should we re-title Learning Perl to Learning Perl 5 for the next edition? How much of a fuss would we cause?

Our trick is to position our book for the major version of Perl that most everyone uses (Perl 5) next to the same sort of book for the mostly different language with the same name (Perl 6).

Up until now, we distinguished the version of the thing called “Perl” in a ribbon on the edge of the book. But, this thing called “Perl 6” is out there and it’s not an upgrade to Perl 5 (unless you think of Perl as an upgrade to awk). The books aren’t going to be compatible and we don’t want people to buy the wrong book.

For most people using Perl as part of their job, they want the current track and not the Perl 6 one. However, at the same time, they aren’t going to realize the difference and go for the highest number.

Who has some good advice for us? We have a Survey Monkey survey (which might show up embedded right under this), or you can leave a comment.

The survey is closed with an overwhelming cry for renaming the book.

Why we teach bareword filehandles

There’s a debate raging in Perl 5 Porters over some updates to perlopentut. Mike Doherty sent a patch to remove the bareword filehandles, stepping into the overlapping minefields of fashionable practice and documentation authorship. That second one is beyond the scope of Learning Perl, so I’ll ignore it even though that’s almost the entire debate.

There are three reasons we teach bareword filehandles in Learning Perl: generality, immediacy, and history. Having said that, we are not choosing between barewords or filehandle references, even if we do use the references for most of the book. We’re agnostic, and we leave it to our reader to make the best choice for them. We don’t see out job to tell you how to program. We just want to explain what Perl actually lets you do.

Generality: We don’t write books for individual people. That just doesn’t work since it would take more time than any author has, even if authors did nothing but write every second of every day. For a book such as Learning Perl which sells tens of thousands of copies just in the paper version, we have many sorts of people to think about, virtually none of whom we have ever met, will ever meet, and will never give us feedback. We don’t know why you are using Perl. You could be system administrators, web programmers, data mungers, or, sometimes, non-techies. We don’t know if you are writing new code or adjusting old code. We don’t know what you need, so we don’t make judgments based on what we don’t know. If you are talking to one of us during a face-to-face class, we can ask you questions and find out more about what you need.

Perl suffers from success in vastly different areas. You can write quick one-liners or huge, enterprise systems. You might need an interactive user interface, or not. Different tasks and different domains require different practices. Instead of assuming that you are going to limit yourself to just one of those areas, we aim to make Learning Perl useful to most of those areas.

Immediacy: In a tutorial like Learning Perl, we have to start somewhere. A bad book can quickly overload a reader with several concepts at once. Our goal is to get people writing code as soon as possible, which is the fundamental goal of Perl. Larry Wall wants people to be able to program even if they don’t consider themselves programmers. He doesn’t want people to have to spend hours of research to be able to doing something useful quickly. Larry’s term for this is “baby Perl”.

There are several concepts that go into a this single line of Perl, none of which are immediately useful to someone who wants to write the sort of short program we consider in Learning Perl:

open my $fh, '<', $filename or die '...';

In their first afternoon of Perl, the new programmer has to be comfortable with my as well as the concepts around open, its modes, and its lack of punctuation. That my $fh inside a larger expression is really confusing for beginners. We don't make any judgements based on that. We just know that's the way it is. To avoid the extra sources of confusion, it's easier to reduce the problem to one with the fewest distractions:

open FILE, $filename or die '...';

Don't forget that the tutorial for open is almost 1,000 lines long. This is not a simple built-in. Once people get used to the idea of a very basic open, we can expand on that to add more to the readers knowledge and understanding. All education is a continual process of refinement and adjustment as you integrate new concepts with what you already understand.

History: Finally, no matter what we personally think about one form or the other, we can't deny that people are going to see the bareword versions. The "Modern Perl" movement would like to pretend that bareword filehandles don't exist, but they can't ignore STDOUT, STDERR, STDIN, or DATA. Perl has bareword filehandles and most people are going to write new code using bareword filehandles, indeed, even relies on those barewords, even if they subscribe to all of "Modern Perl". Putting that aside, though, people are going to see bareword filehandles in old code. Our readers need to know what those are and what they do. Programming is not just about writing code, it's about reading code. We can't hide widespread patterns because they've become unfashionable to some people.