PERL Beginners - Learning Perl - the Good and the Bad (Tutorials, Habits, and Tools, etc)

Author

Learning Perl - the Good and the Bad (Tutorials, Habits, and Tools, etc)

umptious@gmail.com

2006-01-29, 6:56 pm

I've been learning Perl in my spare time for the past w

or so. I
have had experience with dynamic languages before, so my perspective
may not be typical. Without too much effort and frustration I'm at the
stage where I feel I've got the rhythm of the language and progress on
to do anything I want in it - in particular variable context isn't
causing me a problem anymore and I cab build any damn data structure I
want using references.

It has been my experience in the past that once you know a language
well it is almost impossible to understand the issues that gave you
problems while learning, so I thought I'd make some notes now in case
they were helpful to other people learning the language.

Overall
=====
Learning Perl is somewhat more difficult than learning, say, Python,
but not as much more as you might think at the beginning - especially
if you do things right (see The Good below). Context and references
will give you more trouble than anything else, but they context is
definitely a feature you will appreciate when it clicks (well, it was
for me) and explicit control of reference vs value is a very nice
feature to have. Perl's parameter passing seems (very) primitive at
first, but it's powerful and you soon learn to live with it.

Compared, again, to Python, I'm finding that although Perl was harder
to learn as a language, I need to remember many fewer library functions
to get work done. Overall, I'd call this a win.

Probably the biggest feature of Perl as implemented that I'm less happy
with is that it uses reference counting for memory management - I
believe this will change with Parrot (so possibly by the end of this
year?) and that I haven't found an equivalent of Python's "Pickle" yet
for easy persistence.

The Good
=======
* There are several visual debuggers available for Perl. I'd get one
and use it right from the start (unless you are an Emacs and gdb
fiend).

* ActiveState's Komodo is a superb tool. The Personal Edition is free
for a month and then $30. It includes not just a terrific debugger but
a syntax aware editor that identifies and *explains* a lot of errors as
you type. If Komodo runs on one of the OS's you are willing to use then
I'd suggest downloading it at the same time you download Perl. I really
feel that using Komodo may literally halve the difficulty and time in
learning Perl compared to using a conventional editor and no debugger.

* "Roberts Perl Tutorial" and especially "Perl in 20 Pages" are both
excellent tutorials.

* "Teach Yourself Perl In 24 Hours" by Clinton Pierce is editted by the
legendary Scott "Effective C++" Meyers - to C++ programmers, enough
said.

* The standard Perl docs are excellent. In particular make sure you
read Perlreftut (about references) and Perlrequick (regular
expressions). (The one negative thing I'd say about ActiveState is that
their layout of their docs rather buries the original table of contents
that supplemented these gibberish names with meaningful descriptions.)

* Lots of excellent quality articles, eg on Perl.com. Anything by
Conway, Dominus, or Cozens will be worth reading.

* Perl.Beginners.

The Bad
======
* "Learning Perl" aka The Llama book. It doesn't work. An introductory
book Perl book that doesn't explain references is like a C book that
doesn't that explain pointers - the reader could program after a
fashion - badly. I don't see how someone who has read Llama and nothing
else could write a useful function to add two arrays. Worse, the Llama
doesn't explain that you are missing a key piece of the puzzle, and by
the time you discover references you may completely have to break a
model of Perl programming that has solidified in your mind. If the
Llama book warned you - at the start and on at least the back cover -
that it was missing a treatment of an essential topic, I might say fair
enough - but the book is being sold as an adequate introduction to Perl
for professional programmers and it is NOT. This might have been
tolerable when Perl was introduced, but there are better books (and
free net tutorials) available now, and I think the problems the Llama
creates are di

vantaging Perl compared to Python and Ruby, as well as
creating needless difficulties for people who read the book.

umptious@gmail.com

2006-01-29, 6:56 pm

The other comment I'd make is that if you download the html docs from
perldoc.perl.org (rather than e.g. relying on the ActiveState docs or
not bothering to get the docs at all) is that they come not only with a
built-in search, but that this search fails to give you anything useful
it takes you straight to google, with the option already set (but
changeable) to limit your search to perldoc.

Very thoughtful!

usenet@DavidFilmer.com

2006-01-30, 3:55 am

umptious@gmail.com wrote:
> [experiences learning Perl]

You've progressed well if you can build any sort of data structure
using references.

One suggestion I'd add to you list of reading material: you mentioned
Damian Conway, but didn't specifically mention his "Perl Best
Practices." This is the ONE Perl book I REALLY wished I could have
read when I first started learning (but it hadn't been published yet).

Perl hackers tend to develop their own style early on, but their lack
of knowlege and experience may lead them to develop and get in the
habit of using a style that might be generally functional but is
actually not very sound.

I was one of those who developed and became accustomed to bad
programming practices. If I could have read Damian's book from the
beginning, I would now be in the habit of writing much better, cleaner,
and more maintainable code. As it is, I now struggle to un-learn and
overcome my bad habits to incorporate his excellent and well-reasoned
advise.

Except for one thing: You will need to physically remove five keys from
my keyboard to keep me from using unless() statements :}

--
http://DavidFilmer.com

umptious@gmail.com

2006-01-30, 3:55 am

David Filmer wrote >> One suggestion I'd add to you list of reading
material: you mentioned Damian Conway, but didn't specifically mention
his "Perl Best
Practices." This is the ONE Perl book I REALLY wished I could have
read when I first started learning (but it hadn't been published yet).
<<

This is at the top of my reading list but I didn' feel able to
recommend it as I haven't read it yet. I have a copy of Effective Perl
that I rate highly. Then there's the Cookbook, and at some stage I'll
grab HOP.

At some point I'll probably come back to this thread and note which
articles at Perl.com I found most useful.

Paul Lalli

2006-01-30, 7:55 am

umptious@gmail.com wrote:
> The Bad
> ======
> * "Learning Perl" aka The Llama book. It doesn't work. An introductory
> book Perl book that doesn't explain references is like a C book that
> doesn't that explain pointers - the reader could program after a
> fashion - badly. I don't see how someone who has read Llama and nothing
> else could write a useful function to add two arrays. Worse, the Llama
> doesn't explain that you are missing a key piece of the puzzle,

Hmmm... You seem to have a reading comprehension problem.

>From the Preface:
We can't give you all of Perl in just a few hours. The books that
promise that are probably fibbing a bit. Instead, we've carefully
selected a complete and useful subset of Perl for you to learn, good
for programs from one to 128 lines long, which end up being about 90%
of the programs in use out there. And when you're ready to go on, we've
included a number of pointers for further education.

>From "Beyond the Llama":
So as not to repeat ourselves in every paragraph: the important part of
what we don't cover here is covered in the Alpaca. Read the Alpaca,
especially if you'll be writing programs that are longer than 100 lines
(alone or with other people)

Seems pretty clear to me.

Paul Lalli

and by
> the time you discover references you may completely have to break a
> model of Perl programming that has solidified in your mind. If the
> Llama book warned you - at the start and on at least the back cover -
> that it was missing a treatment of an essential topic, I might say fair
> enough - but the book is being sold as an adequate introduction to Perl
> for professional programmers and it is NOT. This might have been
> tolerable when Perl was introduced, but there are better books (and
> free net tutorials) available now, and I think the problems the Llama
> creates are di

vantaging Perl compared to Python and Ruby, as well as
> creating needless difficulties for people who read the book.

umptious@gmail.com

2006-01-30, 6:56 pm

>>Hmmm... You seem to have a reading comprehension problem.
>From the Preface:

We can't give you all of Perl in just a few hours. The books that
promise that are probably fibbing a bit. Instead, we've carefully
selected a complete and useful subset of Perl for you to learn, good
for programs from one to 128 lines long, which end up being about 90%
of the programs in use out there. And when you're ready to go on, we've
included a number of pointers for further education.

>From "Beyond the Llama":

So as not to repeat ourselves in every paragraph: the important part of
what we don't cover here is covered in the Alpaca. Read the Alpaca,
especially if you'll be writing programs that are longer than 100 lines
(alone or with other people)

Seems pretty clear to me. <<

Paul -

In the same spirit: you seem to have an intellectual honesty problem.

Or: read what I wrote, not what you wish I'd written..

No programming book I'm aware of claims to cover ***all*** of a
language. The innocuous disclaimers you quote above would have been
honest and appropriate if Llama had merely negelected, say, advanced
regex construction or Perl OOP - just as similar prefaces are for C++
books that don't cover the more esoteric details of templates, or Lisp
books that tell you macro programming exists, but no more. This is
expected, reasonable, and therefore does no require any more than the
usual level "this book doesn't tell you everything" paragraph. For this
reason it is dishonest and worthless - like a sign on a car with
malfunctioning brakes that merely warns you that no car is perfectly
safe.

Well, Doh! Of course no book ever covers a major language completely.

But Llama is totally unique for a major language book in that it leaves
out at least one key feature without which you can't understand the
language properly - you can't even write a decent function to take a
dot product. This - especially in a book that assumes some programming
experience is completely unique for a major language book. ***It
therefore requires, from simple honesty, a different level of warning -
one stating that rather than having left out an advanced or
intermediate topic it has left out a basic and essential subject for
writing even as simple a function as a dotp competently.***

I don't believe that any programmer would expect this level of short
circuitedness from the warning you cite, Paul, anymore than they would
expect a C book that gave a similar warning to lack a treatment of
pointers.

As for the 128 line crap - well, even for writing programs this length
a halfway comptent programmer should know what a reference is. I needed
to before I'd gone over a fraction of this length.

Note: I'm not criticizing Llama for being incomplete - I'm criticizing
it for not clearly stating the (capitals for the rude and the brain
dead, Paul) UNUSUAL - UNIQUE AND DANGEROUS - LEVEL OF ITS
INCOMPLETENESS.

You seem to have a reading comprehension problem, Paul. I hope the
capitals help.

Or maybe you really do regard passing arrays to a function as an
advanced topic? They're not - both those Internet tutorials I mentioned
cover them at least well enough to give a beginner a fair view of the
language. So much for that "We can't give you all of Perl in just a few
hours" excuse - this is an utterly essential feature to understand that
can be covered in minutes.

PS Thank you for being pointlessly rude - otherwise I would have had to
spend time thinking of a way of phrasing the above so that you didn't
look like an idiot.

Paul Lalli

2006-01-30, 9:55 pm

umptious@gmail.com wrote:
> In the same spirit: you seem to have an intellectual honesty problem.
>
> Or: read what I wrote, not what you wish I'd written..

I read exactly what you wrote. I just disagree with your opinions.

> But Llama is totally unique for a major language book in that it leaves
> out at least one key feature without which you can't understand the
> language properly - you can't even write a decent function to take a
> dot product.

You are creating examples which back up your opinion. You are stating
that the Llama is defficient because you can't write a subroutine to
create a dot product with just its given knowledge.

Let me count how many times in eight years of Perl programming I've
needed to write a program to compute a dot product........ Got it.
Zero.

Should I attempt to list all the subroutines you *can* write with what
the Llama gives you?

> As for the 128 line crap - well, even for writing programs this length
> a halfway comptent programmer should know what a reference is. I needed
> to before I'd gone over a fraction of this length.

Congratulations. So the Llama wasn't enough for you, personally. But
to suggest that it's crap because it leaves out this one feature and
isn't explicit about how much you personally needed that feature is
idiotic in the extreme.

> Note: I'm not criticizing Llama for being incomplete - I'm criticizing
> it for not clearly stating the (capitals for the rude and the brain
> dead, Paul) UNUSUAL - UNIQUE AND DANGEROUS - LEVEL OF ITS
> INCOMPLETENESS.

More idiocy. References are an important and powerful feature of the
language, no question. These days I use them in about 70% of the
scripts I write. But for an introduction to the language, no, they are
not important. I completely agree with the authors that 90% of the
Perl programs a beginner will write does not need references.

> Or maybe you really do regard passing arrays to a function as an
> advanced topic?

Advanced? No. Important for a beginner? Also no.

> They're not - both those Internet tutorials I mentioned
> cover them at least well enough to give a beginner a fair view of the
> language.

I completely agree. perlreftut, perlref, and perlrefref are some of
the best perldocs out there.

> So much for that "We can't give you all of Perl in just a few
> hours" excuse - this is an utterly essential feature

We simply disagree.

> PS Thank you for being pointlessly rude - otherwise I would have had to
> spend time thinking of a way of phrasing the above so that you didn't
> look like an idiot.

For my part, I do apologize for the rudeness. I should have counted to
20 or so before posting. Further apologies if it extended into this
reply.

Now for the kicker - I completely agree that references should be
covered in the Llama, and I wish they were. My reason, however, is
that they are not as complicated as they are made out to be, and can be
taught with relative ease, not that they are vital to a beginner's
understanding of the language. My disagreement with you is that the
book is somehow either worthless or dangerously deceptive because of
their lack of being mentioned.

Paul Lalli

umptious@gmail.com

2006-01-31, 7:55 am

>
> You are creating examples which back up your opinion. You are stating
> that the Llama is defficient because you can't write a subroutine to
> create a dot product with just its given knowledge.
>

It's very kind of you to say so, but, no, I didn't invent the idea of
the dot product - it was some dead guy's idea...

> Let me count how many times in eight years of Perl programming I've
> needed to write a program to compute a dot product........ Got it.
> Zero.

Paul: it wouldn't matter if you were a total innumerate and couldn't
even understand what a dot product is. The dotp, Paul, is what is
called an "example". The point, Paul, is that someone who read Schartz
and Phoenix' book:

1. Would not be able to write a function that dealt with two arrays in
a reasonable fashion, . So comparing two arrays, getting the union,
intersection, or difference of two arrays is out.

2. Would not be able to create the the sort of data structures that
programmers take for granted in other languages - because in Perl these
require refereneces.

3. Might not KNOW that he did not know these things because of his
choice of book rather than the deficencies in Perl.

4. Would not be able to return eg two arrays elegantly from a function
- something that is trivial in Python or Ruby

The dotp was just a simple illlustration of part of this problem.
Here's another good illustration: look at the Markov chain program in
Kernighan and Pike's "Practice Of Programming". K&P picked it as a
simple example suitable for evaluating a language - but would you
really want to code it without references? With C++, Ruby, Python, Lua,
Lisp, Ocaml, etc, it's a warm-up piece. But apparently with Perl it's a
magnum opus for advanced programmers...

> Should I attempt to list all the subroutines you *can* write with what
> the Llama gives you?

Yes, please do that. And pass the task on to your children. When one of
your descendents realizes that being able to write an infinite number
of functions is not the same as being able to write every useful
function, have him contact me.

Paul - when people (people who can already program!) can read a 300
page book on a language - or take one of S&P's $14,000 4 day courses -
and they come away unable to write functions that act on two arrays,
and with not even an idea how they might use the equivalent of a
struct, ***then there is something wrong with either the language or
the book.***

Unfortuntely, Llama's status as one of the two "authorized" texts for
Perl (with the Camel being MUCH thicker and less accessible) means that
people who are using it for a quick overview are getting a distorted
idea of Perl as a sort of idiot-savant language, a programming
"Rainman" good for writing throw-away text processing scripts and
nothing more.

Now, my impression of the current marketplace is that Perl is suffering
from this impression - and so are Perl programmers. But exactly the
text that a lead programmer or project manager in a hurry will pick up
to get a fast overview of Perl will leave them convinced that Perl is
problematic!

Finally and once again, the disclaimer on Llama would be totally fair
if either:

1. In general, programmers who pick up a 300 page renowned and
community recommended text on a programming language do NOT expect it
to tell them how to write functions that take two arrays, or how to
construct data structures.

2. People who read the disclaimer REALIZE that, yes, Perl does let you
write functions that take multiple arrays - but this book passes this
topic by - and, yes, Perl does let you create powerful data structures
- but this is missed out too.

Frankly, I don't think anybody reading the preface you referred to
would believe the first or realize the second.

Llama cheats a good number of its readers, turning many of the best of
them away from Perl for life - and it probably costs ordinary Perl
programmers jobs. (Would you commission a 10,000 or 100,000 line
project in a language where using the equivalent of a struct is a
advanced topic?) If it was called "Perl For Web Programmers" or
something similar I might not have a problem with the book. But it
isn't. It is called "Learning Perl", and you don't - you mis-learn it.

This problem is serious, and it is unique to Perl.

umptious@gmail.com

2006-01-31, 7:55 am

>> If it was called "Perl For Web Programmers" or
something similar I might not have a problem with the book. But it
isn't.<<

Sorry - that should have been "Web Designers" or something like that -
people who can who write a little Flash code and twiddle very
cautiously with an exisitng PHP script.

Obviously *real* web programmers have just as much need for, and
awarenes of, data structures as anyone else... I don't want to get
flamed from two sides at once here!

Sponsored Links