

Modern Perl: The Book: The (draft) PDF - another_ali
http://www.modernperlbooks.com/mt/2010/10/modern-perl-the-book-the-draft-pdf.html

======
rjurney
I took a six month break from Perl. I know it better than any other language.

I recently started using it again for one offs. I love Perl. It is so much fun
to be totally fluent in a language.

Then I wrote a one page app in it. Oh my god, I can't believe anyone still
uses Perl.

Its strange. I love it. I hate it. Its great. Its a piece of shit. I am
familiar with Modern Perl practices... I just can't understand why anyone
without a massive legacy codebase bothers.

~~~
jrockway
My experience is the opposite. I've used Perl for one-page web apps. I've used
Perl for one-hundred-page web apps. I've used Perl for HTTP load testing. I've
used Perl for high performance messaging. I've used Perl for writing desktop
apps.

Every time I do it, I finish and say, "this is great". The code is easy to
read. The code is easy to extend. The code is easy to test. The code is easy
to deploy. And I had fun making it. And it's fast. For stitching together
complex apps that need to interact with the outside world and not randomly
die, Perl is the best tool there is.

Incidentally, people tend to think the opposite -- Perl is for text munging
oneoffs, not for complex apps. This isn't my experience, though. Perl is great
for gluing things together, but it's not the best tool for performing compute-
heavy work on data.

Situations where Perl has served me well: "Produce a CSV file from this data
derived from a web page and this database and this C-based analytics library."
"Open up as many HTTP connections to this server as possible." "Accept
connections from 30,000 clients, and send them a JSON message when a certain
event occurs." "Allow someone to interactively edit a complex data structure
on the web." "Send a message to server a, poll server b until the message
comes back, and report the latency to a monitoring tool over XMLRPC, and write
the result to a database." etc.

These worked well because of the great tools I have available in Perl. Moose,
with MooseX and roles, to keep my code organized. Bread::Board for making it
easy to wire components together, without sacrificing modularity. 100s of
Test:: modules to make it easy to exercise all my code ("unit" and
"integration" are both really easy with Perl). EV for high-performance IO.
Coro for making the async-IO code look "normal". AnyEvent for writing modules
that do async IO, without requiring the author to make a decision about which
event loop to use. Plack for making all my web apps look the same to the
server. Tatsumaki for making streaming easy. Catalyst for making big apps
easy. DBIx::Class for making complicated database queries easy. KiokuDB for
making my in-memory data persistent.

Situations where Perl has not served me well: "Write a language independent
API that adds a tiny bit of business logic over a network protocol." "Load
data via a proprietary and buggy C-based library, do complex transformation
and normalization, and write the fixed data to a new file."

Why did Perl fail? In the first case, because there is a mental hangup of
linking Python or Java with -lperl, even though it's easy to write the C to
expose Perl modules to *. It's easier to write your simple "value-add" in C,
because then everyone can use it and they feel like they are not making any
political decision. And it turns out that C is not that difficult if you are
willing to think like a defensive programmer when programming in it!

In the second case, Perl was slow. Writing an XS binding is straightforward,
but not trivial. Creating objects, something you need to have at least
somewhat-organized code, billions of times is... pricey. Doing a lot of work
on a lot of data just isn't very fast. So I use Haskell for this type of work
instead. It's trivial to write a binding to a C library (you can do it
interactively with ghci and :load, no compilation necessary!), and you can
write an expressive, maintainable, abstract program to operate on your data
without sacrificing any runtime speed.

In conclusion, you might be doing it wrong. Or you might have picked a bunch
of tasks that Perl is bad at and not stopped to notice how good it is at
everything else.

~~~
gaius
_The code is easy to read. The code is easy to extend. The code is easy to
test. The code is easy to deploy_

I don't doubt that it is, for its author - but that's what all Perl
programmers believe.

 _Why did Perl fail?_

For no purely technical reason. It failed because too many people got burned
on inheriting horrifying tangles of spaghetti legacy code and vowed, never
again. There's just not a critical mass (left) in the Perl community who
believe that the target audience of their code is the next programmer who
works on it.

~~~
jrockway
I agree with you up until "There's just not a critical mass (left) in the Perl
community who believe that the target audience of their code is the next
programmer who works on it."

I think those people left and moved to PHP. All that's left in the Perl
community are a bunch of people who think tests and readable modular code are
good. (Not everyone _implements_ this really well, but at least it's in mind.)

And by community, I mean "people that write CPAN modules and hang out on IRC",
not "people that submitted their resume to the open 'PERL' position". Those
people are more than happy to write spaghetti, but it's because the market
allows it. Start firing people for writing crap code, and start paying the
people that write great code a lot of money, and you'll see a lot of great
code -- Perl or otherwise. As it stands now, code quality and pay are not
linked, so there is a lot of bad code being written for a lot of money.

(Ask me about 10,000 lines of C++ to encrypt a password and send it over a
socket...)

------
scalyweb
I've been working with Perl on and off since 1997 and similar to many I've
been disgusted by some of the code I've come across created during that time.
Perl has come a long way even since version 5.0.0 and is quite a different
character these days. The problem I've had with recommending the language is
that unlike C which really hasn't changed(at least to me), Perl has slowly
evolved but many of the books in print still point to the older version. While
Perl is excellent in maintaining backward-compatibility with earlier versions,
knowing and learning the "modern" versions has been a more painful task then
it should be. I think this book changes that.

I just spent about 30 minutes skimming through it. It's only 260 pages in
clear and articulate English. Should this be THE new Perl book? Could be...I
think this coupled with Effective Perl Programming that came out a few months
ago are great for getting onboard or returning to the world of Perl. Hats off
to you Chromatic for your work on this.

There may not be any reasons to learn Perl if you already know
Ruby/Python/Tcl/Lua but you certainly won't be worse for it if you do. At the
end of the day, it's just another tool and I love having access to so many
great ones these days.

------
adrianhoward
Glad to see the book - and it looks a good read. Perl really has evolved as a
language & community over the last few years and it's still my go-to language
for my own projects. Despite having been mostly Python/PHP on the dev side the
last couple of years - and being a huge Ruby fan.

The core of the language still has some warts - but there's still some
interesting stuff to play with.

Three reasons to have a look at the language if you haven't before (or take
another look if you've been away from perl for a few years):

* Moose - <http://moose.perl.org> \- is becoming the de facto OO layer on top of Perl's basic OO system. It has some interesting features that you don't see in most other OO languages (Roles for example.)

* CPAN - <http://search.cpan.org> \- the library of perl modules. Interesting for a couple of reasons. First it's scope is amazing. When I need to talk to some weird API there's usually something there to help. Cuts development time enormously. Second - the infrastructure of CPAN itself is fascinating. The way that things like <http://cpantesters.org>, <http://search.cpan.org>, the standard methods for building libaries and modules, etc. all work together is an interesting software ecology. Worthy of study. Lessons to be learned there for gems et al.

* Testing. The testing infrastructure in perl is _amazing_. It's the best I've used in any language. That's because it's evolved around a language/framework agnostic testing protocol TAP (<http://en.wikipedia.org/wiki/Test_Anything_Protocol>) that allows many different styles of testing to co-exist in the same test running framework. Really nice stuff.

~~~
gaius
_The testing infrastructure in perl is _amazing_. It's the best I've used in
any language._

Well, it has to be, because it's too difficult to second-guess when Perl will
DWIM and when it won't. So you have to move a whole lot of complexity out of
where it should be, the compiler, and into your own head and your own code.
Check out Haskell's QuickCheck for this done right.

~~~
adrianhoward
No. That really isn't the issue that I see at all.

I've used Haskell's QuickCheck. Declarative testing is lovely. But it's one
particular approach to testing - suitable for finding a class of problems and
bugs.

TDD via an xUnit framework is another approach - suitable for finding another
class of problems and bugs (after, of course, driving the design - which is
it's main purpose).

Style/lint testing is another approach to finding a different class of
problems and bugs.

Load testing is another approach to finding a different class of problems and
bugs.

The most languages it's an annoying pain to get different kinds of testing
framework. TAP and Perl's testing framework makes that really easy.

In Haskell if I want to combine doing TDD with HUnit and declarative testing
with QuickCheck - I have to do work to get both frameworks running and
integrated at the same time.

In Perl if I want to combine doing TDD with Test::Class and declarative
testing with Test::Lectrotest (the QuickCheck style testing library for Perl -
<http://search.cpan.org/dist/Test-LectroTest>) it comes out of the box -
because they both output TAP.

I can even interleave declarative styles test inside my xUnit tests - because
the both output TAP.

If I discover I need to write some custom test library to poke at some
specific corners of my app - I can just output TAP and it's instantly
integrated with the rest of my test framework.

Stupidly useful.

------
kevinpet
This looks interesting and I'm always happy to see good documentation appear,
even if for a language I rarely use. My one suggestion would be a PDF typeset
for on-screen reference. The font size is very hard to read at "best fit" on a
1152px high screen, even when maximized. If you wanted to match the print page
numbers, you could cut down the margins on the electronic version.

~~~
chromatic
I thought about that earlier today. This PDF will become the printed version,
but I can render a version for letter-sized paper and another for A4. If I had
a good sense of what's most readable on screen, I'd do that too (though the
epub version is easiest). There's no strict need to keep the page numbers
identical across versions.

------
mhd
Quickly browsing through it, it looks quite okay. I'm just a bit sad that
"modern Perl" is OO Perl, and not more in the style of Higher-Order Perl.

~~~
chromatic
_I'm just a bit sad that "modern Perl" is OO Perl, and not more in the style
of Higher-Order Perl._

There's an element of practicality. Perl doesn't force the use of any specific
paradigm, but as it's not a pure functional language, the dominant paradigm
for maintainable, large applications tends to be OO.

------
tszming
For web developments, be sure to check out the Mojolicious framework (created
by the founder of Catalyst). When used with PSGI and Moose, a lot of
interesting stuffs can be built.

<http://mojolicious.org>

~~~
adrianhoward
Folk should also take a look at Catalyst <http://www.catalystframework.org/>,
Dancer <http://perldancer.org/> and Jifty <http://jifty.org/> \- they're all
nice to work with.

Dancer being my current fave :-)

~~~
tszming
Thanks for introducing me to jifty, looks cool.

------
ddemchuk
Ok, I am a solid PHP developer, pretty advanced with Ruby, and can do front
end code and JQuery with my eyes closed.

Should I be interested in Perl? Is there any reason to learn it if I know
these other languages? I am genuinely curious

~~~
msbarnett
On the one hand, I tend to think that learning a new language or tool kit is
always a valuable experience. On the other hand I switched from Perl to Ruby
as my go-to scripting language about 6 years ago and haven't felt like there
were any niches which Perl serviced that Ruby failed to, for my uses.

Still, I'd say try it out for a few small things; you might find that Perl
better fits the way you think, and if not, at least you can say you know a bit
of Perl if anyone ever asks.

~~~
drac
By and large, I've had the opposite problem making a lasting switch from Perl
to Ruby.

I know Perl better than most other languages in my toolbox, and it's my
default prototyping and one-off utility language. I don't find a lot of niches
(for my typical uses, of course) that are served better by Ruby, so it's been
really difficult to switch away from Perl.

