[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.

[draegtun]

Well, it has to be, because it's too difficult to second-guess when Perl will DWIM and when it won't

I've personally never seen this issue when testing perl code.

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

Actually the perl compiler with use strict; use warnings catches a lot more at compile time compared to most other dynamic languages.

[chromatic]

... it's too difficult to second-guess when Perl will DWIM and when it won't.

You don't need to guess, never. I can recommend a book which explains how Perl 5 works (and which features to avoid because they're too difficult for novices--and sometimes experts--to use correctly).