I've had this book a while. To give you an idea, the third edition came out in 2000. I've only just finished actually working through it, and more on that below. Why's it taken me so long to read it? The idea of Perl seems to me to be a good one - I think I should like it. A nice scripting language that makes gluing together text files and generally doing Unix shell things easy. Indeed, I do tend to use it for this purpose.
In practice, however, I don't like Perl. There are several reasons. I don't like 'there's more than one way to do it'. I like the idea there's a correct, neat way to do something, the Platonic ideal to which one should aspire. So, you can write many languages in Perl, and this makes maintenance a nightmare. Even if you stick to idiomatic Perl, the object structure and module structure... yuck. Even for retro-fitted features, they're disgusting. It could have been a small, neat language, but but it's just grown ugly. Or perhaps it's neat, but in just such an alien way.
But most of this reasoning stems from the fact that fundamentally, I don't understand Larry Wall, therefore I don't understansd this book, therefore I don't understand Perl. This book is supposed to be the description of Perl. However, it's full of Larry Wall's rambling, jokey descriptions. Which would be fine except I still have no idea about how a Perl expression might be executed. There's no precision in any description of how expressions are put together and evaluated - the exact meaning of the different contexts and data structures, how built-in structures differ from user-defined functions, and generally, how one might get an understanding of how you'd interpret a program.
But that's apparently ok, because the book's full of example code, and Perl has all these convenient little special corner cases anyway. It's like a conversational language course that doesn't bother with grammar, but instead lets you pick the language up 'naturally'. Except programming requires lawyerly command of a language. Furthermore, you want this book to be usable as a reference - after all, it has a chapter called 'The Gory Details'. However, I can never find what I'm after in it. Grrr.
So, why have I finally finished reading this book? I think Perl's a badly designed, badly described, and badly extended language built around a good idea. It still does lovely text handling, and the operators it has make it, in many ways, rather like a functional language - as shown in Higher Order Perl, which I suspect is a book that'd almost make me like Perl. However, what I really want now, is to have the power of Perl in a proper (and statically typed) functional language, rather than write functional programs in Perl. So, I've been re-reading up on Perl with a view to seeing how difficult it'll be to do Perl-style basic text manipulation in Haskell. If I can do all the scripting I used to do in Perl in Haskell, I shall be a happy man.
Posted 2009-12-23.