

Ask YC: What is the best way to learn Perl? - rob

Language wars aside, what is the best way to learn Perl if one wants to use it primarily for web development? There are so many books and websites out there, it's hard to separate the good from the bad. If it helps, I am pretty proficient in PHP and know the basics of Ruby and Python.
======
benreesman
I work in a company that writes almost everything in Perl, and as a result I
have personally written tens of thousands of lines of the stuff, and I
maintain and debug several times that amount. This code is used for everything
from serving web pages to interacting with carrier SMS-C to number crunching.
So believe me, Perl is definitely the devil I know.

That being said, the only advice I can offer you is unsolicited: don't learn
Perl. Perl is a very powerful language in a lot of ways and in its day it was
the only game in town for serious rapid development. It is fundamentally
broken in a lot of ways though, and unlearning the brain damage that you will
get from becoming a Perl expert could take a very long time (it has taken me
years). I won't launch into a diatribe about these language characteristics
unless you ask me to, but do not doubt that I could.

People talk a lot about how great CPAN is, and it does have a certain charm,
but it is ultimately more trouble than it is worth. There are CPAN modules for
everything, but just as often as not they are flawed or buggy or too limited
and you don't realize this until you've sunk a considerable amount of time
into the problem. Just the other day a colleague wasted an afternoon trying to
get LWP::Parallel to work as advertised before realizing that it could not be
done.

Perl is great for building prototypes, but when you go to deploy the stuff you
realize that DBI fundamentally can't do connection pooling in the way you
want, and mod_perl has an execution lifecycle that can only be described as
'whacky' (depending on how you include your handler modules, sometimes
mod_perl will simply stop evaluating your module when it reaches an error,
leaving your symbol table partially filled in with no error warning), and once
you've used a couple of CPAN modules they'll all invite their friends and
those friends will invite their friends and pretty soon your Apache children
are using 15-50 megabytes of _unshared_ memory each. Yeah that's right, the
interpreter goes and touches a bunch of pages of Perl 'code' post-fork and
blows the COW and now all your RAM is belong to mod_perl. It's really cool
when an 8-way Xeon server with 16GB of RAM can only handle a couple of hundred
req/s before it starts faulting and crashing Apache children on malloc.

Do yourself a favor and use Ruby instead. Ruby is so much like Perl that you
can almost call it a dialect, but just not quite as broken. Pretty broken
still, but not nearly so broken as Perl. It has all of Perl's good
characteristics and only most of its bad ones. And if the availability of
libraries, or the lack of decent threading or other deployment characteristics
bother you, then use JRuby which is now basically the fastest production Ruby
and can call into all of the Java libraries (which _can_ do connection pooling
in the way that you want). Personally I prefer Common Lisp and Rhino but you
can't go too wrong with JRuby.

If you go the Perl route you will definitely come to regret it.

~~~
aneesh
Two things are certain in life: every language has its pluses and minuses, and
every person has an opinion.

There are lots of things perl is bad at, but it has a lot of strengths,
especially if you work in the biological space. I also know several successful
internet startups that run on perl, so I have to disagree with benreesman's
advice to not learn perl.

Is it good for everything? No. (and no language is)

~~~
benreesman
If there are libraries for doing biological computation written in Perl that
do not have available bindings for other languages then that would constitute
a reasonable excuse for using Perl. This would be just as true if the library
was only available 1990s Visual Basic, and is just as irrelevant a factor in
the assessment of a language as a whole.

Beyond the availability of some particular piece of code (in my case the tens
or hundreds of thousands of lines of legacy systems that I lack the resources
to replace) there is literally no excuse for using Perl or for inflicting its
insanity on another hapless generation of web programmers.

All of Perl's admirable qualities (convenient object-literal notation, first-
class functions, correct Scheme-style lexical scoping, powerful and seamless
regular expressions, convenient string processing and Unix integration) are
available in other languages. All of them, period. Many of these languages do
not share Perl's unforgivable faults (sigils to dereference variable
namespaces, contexts, typeglobs, references, dismal error handling facilities,
confusing and nonstandard object facilities). The only way to use Perl to
build a large system is to lean on Conway's methodology, which consists of a
book that reads like an airtight indictment of Perl by one of its chief
implementors and a collection of CPAN modules that demonstrate a brilliant
mind with a perverse allegiance to a cult-like cause. Do sensible class
hierarchies without Class::Std, I dare you. Do reasonable try-catch-finally
exception semantics without Error.pm, I dare you.

try { ... } otherwise { ... } finally { ... }; # works try { ... } otherwise {
... } finally { ... } # no trailing semicolon, oops I just clobbered your next
statement and produced a catastrophic failure that even an experienced hacker
could stare at for hours without seeing

It only takes about two hours reading 'Perl Best Practices' to realize that
it's a brilliant book, written by a brilliant mind to attempt to make Perl a
workable language for building large systems. It's a shame because he comes so
close, but it turns out you can't rewire a language like Perl with libraries
alone, even if only because you can't compel others to use them.

Perl is a language for expert hackers only, no one else should be allowed near
it. And even expert hackers are working harder than they need to because there
is a constant intellectual tax on the inconsistency of the language. It only
offers a little bit more power than Python, and actually less than Ruby at a
much higher cost.

There is no excuse for Perl in the 21st century, and you clearly have not
spent time trying to use it to build large and complex systems or else you
would feel the same outrage that I do than anyone would continue to
contemplate it.

------
edu
Read Learning Perl, keep a copy of Programming Perl and Perl Cookbook near
(the three books are from O'Reilly).

Then, for webdev I recommend Catalyst
[http://search.cpan.org/search?query=catalyst&mode=all](http://search.cpan.org/search?query=catalyst&mode=all)
with it's great doc, <http://search.cpan.org/~jrockway/Catalyst-
Manual-5.701003/>. Catalyst uses DBIx as ORM,
[http://search.cpan.org/search?query=DBIx%3A%3AClass&mode...](http://search.cpan.org/search?query=DBIx%3A%3AClass&mode=all),
which also has a pretty good doc [http://search.cpan.org/~ash/DBIx-
Class-0.08010/lib/DBIx/Clas...](http://search.cpan.org/~ash/DBIx-
Class-0.08010/lib/DBIx/Class/Manual.pod).

Finally, I suppose you will use Apache as a server, then you must look at its
doc and mod_perl one (although you can also run the perl app as a cgi).

~~~
staunch
I also recommend Catalyst/DBIx::Class. It's a deadly combination. Both are
totally modular, so you end up creating a really flexible system when you
build a large application. I recommend using Catalyst under FastCGI with nginx
(using TCP to connect to your FastCGI processes.)

------
aneesh
The best way to learn any language: Write something in it! Think of a
particular webapp you want to build, and do it (referring to a
book/CPAN/anything else. Perldoc is useful to learn specific syntax.

The CPAN modules are pretty useful, especially DBI (databases) and Mechanize
(automate website interactions).

------
epi0Bauqu
Perl has been my primary language since 2000. I would learn it in the context
of building an application. Read chapter 1 of the Camel Book (the basics),
which you can get online. Then just jump in and search the web or look in the
book when you run into problems.

Note: tons of stuff has already been done for you at CPAN:
http:://search.cpan.org

I've also found the Perl Cookbook and Mastering Algorithms with Perl somewhat
useful. However, much of their content is now in bits and pieces on the Web,
and so searching for your specific problem often is enough. If you don't know
the site already, check out <http://perlmonks.org/>.

~~~
jlf
I left Perl behind some time ago, but I second epi0Bauqu's recommendation of
Perlmonks. It's quite an amazing community and resource, and well worth
exploring.

------
aditya
Read the man pages.

Start with man perl, then read the following: perlintro, perlreftut, perldsc,
perlretut, perlboot, perltoot.

This should get you started then read all the others, get the Camel book which
is the defacto reference.

And write as much code as you can (which is really true of learning any
language.)

Dropping into #perl on EFNet (now on freenode) used to be helpful, but it
doesn't look like it anymore.

~~~
initself
On the contrary, #perl on freenode is extraordinarily helpful.

------
menloparkbum
The best book for learning the language is "Learning Perl" published by
O'reilly. If you work through all the exercises you'll "know" perl well enough
for doing most things. Also helpful is the Perl Cookbook. Contrary to other
advice, I didn't find Programming Perl (the camel book) as valuable as
Learning Perl.

You could learn via web and man pages but perl is weird enough so that the
Learning Perl workout is valuable.

~~~
initself
I think the best book for learning Perl is 'Beginning Perl', 2nd Edition by
James Lee, published by Apress.

<http://www.amazon.com/gp/product/159059391X>

------
prepositionjoe
benreeseman somehow missed the bit which said "language wars aside"!

If you're learning Perl for web development, after you've got through the
Camel book and the basics, you would go to PerlMonks, as many have said, and
I'd say the main task before you is to get to know the various templating
systems.

There's a progression of using perl for HTML and it goes like this:

1) hundreds of annoying print() statements

2) fewer print() statements because you've discovered HEREDOCS, but still
annoying

3) using a templating module

and in my case it was 3 a) using a templating module badly then 3 b) using a
templating module properly.

So check out the options like HTML::Template, Mason, Template::Toolkit, and so
on to see what they do.

------
vishaldpatel
My day job is basically as a feature programmer for a perl based web
application system. Trust me. Learn python / ruby for web applications. Or
stick to PHP.

The thing that made people love Perl is the same thing that makes more mature
people hate it. The language is so flexible that you will invariably write bad
code. You need a very strong set of coding standards if you'd like to write
perl systems that remain maintainable.

Learn python or ruby to make your web app. Learn C# / ASP.Net if you'd like to
be on a windows stack.

~~~
initself
Have you ever coded in Catalyst/DBIx::Class? Pure joy.

------
noonespecial
I've got different advice. Don't start with a full blown web app. Getting perl
and apache and a db going can complicate the issue a bit.

Start by simply replacing some bash scripts with perl instead. Everything you
can do with a shell script, you can do better with perl. When I was starting
with perl, I started replacing my init scripts with better perl verions on my
Fedora system. You'll be pleasantly surprised by how much shorter and more
elegant init scripts become in perl!

~~~
anewaccountname
Now you've got two problems.

------
schleyfox
let your cat walk on the keyboard, execute it, and try to figure out what it
does.

------
Kaizyn
Perl has a number of books, but the one that seemed most useful to me is
Intermediate Perl because it covers Perl's object orientation and references
in great detail. To learn the basics of the language either spend money for
Learning Perl (which I would not recommend you do) or use the online tutorials
and websites.

Honestly though for web development, unless you either have a legacy Perl code
base you have to work with or are already a Perl guru, nearly every other
option for web programming will run faster and have lower maintenance costs
(in time and effort) than Perl.

Since you know PHP and have dabbled with Ruby and Python, why not take a look
at Seaside Smalltalk or PLT Scheme?

    
    
      Seaside: http://www.seaside.st/
      PLT Scheme: http://www.plt-scheme.org/

------
rplevy
I agree with the advice to read Higher Order Perl, but read Wall's (Blue
Camel) book Programming Perl first. Both are fun to read, but I found HOP much
more useful after reading Wall's book. If you don't already know regular
expressions, read Mastering Regular Expressions. Then for additional ideas try
the Perl Cookbook, also from O'Reilly. For additional inspriration along the
lines of Higher Order Perl, read On Lisp by Graham, which is not about Perl,
but shows how the same concepts and more are elegantly applied in Lisp. The
web documents Higher Order Javascript and the Little Javascripter are
interesting if you want to also understand that Javascript, like Perl is fun
in the same ways that Lisp is.

~~~
SwellJoe
This is all good advice, but I'm not sure the Perl Cookbook is a necessary
component. HOP definitely is, though. Learning Perl and Intermediate Perl are
great learning books...they make a nice starter before the camel (though the
camel is a must-have, no matter what, so pick it up at the same time and treat
it as a reference until you're ready to dig deeper).

------
davidw
Is the camel book still pretty much The Book? It was back when I learned Perl.

~~~
SwellJoe
Yes, and it has continued to get better through its revisions.

------
mk
I agree with most of the suggestions here. Read the man pages, perlintro,
perlreftut, all those. The Camel book is great also. And of course write
scripts. One thing I would like to add is reading Higher Order Perl.
[http://www.powells.com/biblio?PID=29575&cgi=product&...](http://www.powells.com/biblio?PID=29575&cgi=product&isbn=1558607013)

------
xenoterracide
I can't say, although I agree with some people who say 'don't learn perl'. I
would say Learn it, and then don't use it unless you have to. I'm just
starting a class on it. I only intend to use it to fix existing code, or read
it to re-implement it.

------
Jesin
I don't know Perl, but I've read good things about O'Reilly's _Programming
Perl_ (also known as The Camel Book).

I am looking forward to a time when O'Reilly's _Programming Arc_ exists. It's
still too early for that, though.

------
jbum
> write as much code as you can

Can't agree with this one enough. Also, it is better to write a lot of small
scripts, than to write one big one. They will be easier to debug, and you'll
get more done.

~~~
Kaizyn
Well, Perl code is usually write only anyway. So why not?

------
ejs
The only way I can learn languages is to start a project using it, then figure
it out as the need arises.

------
hsmyers
Like every one has said so far, find something to do and code it in Perl.

~~~
aneesh
"Like every one has said so far"

Then why start a new comment? This is what the "upmod" feature is for!

~~~
anewaccountname
Shouldn't you have used the down arrow?

