Extreme Perl:  Chapter 3: Perl   An Evolving Book
about Extreme Programming
with Perl
Previous: Chapter 2: Extreme Programming   Next: Chapter 4: Release Planning

Perl is a language for getting your job done.

-- Larry Wall

Perl is a dynamic, object-oriented, interpreted, applications programming language with a full complement of security features, syntax-directed editors, debuggers, profilers and libraries. You can also write scripts in it. Perl lets you program any way you want, and XP helps you choose which way is the most effective for your project.

This chapter discusses how Perl shares similar values with XP, and how the Perl culture uses XP programming practices. Finally, we note why XP is needed to organize Perl's exuberance.

Core Values

Perl and XP share a similar set of values. It's rare for programming languages and methodologies to define values at all, so this basic fact puts Perl and XP in a unique category. We discussed XP's values in Extreme Programming, so let's compare Perl's core values to XP's:

  • Laziness means you work hard to look for the simplest solution and that you communicate efficiently. You don't want to misunderstand what someone said which might cause you to do more work than you have to.

  • Impatience encourages you to do the simplest thing that could possibly work. You use the code to communicate your understanding of the problem to the customer, because you don't like sitting through long, boring meetings.

  • Hubris is courage born from the fear your code will be too complex for others to understand. Hubris makes you strive for positive feedback and to react quickly to negative feedback from your peers, the computer, and the customer.

Larry Wall, Perl's inventor, calls these values the "three great virtues of a programmer".[1] They tell us why Perl is the way it is: a language that grows organically to meet the demands of its customers.


Perl and XP were invented in the trenches. Larry Wall had to produce reports for configuration management based on netnews.[2] Kent Beck was tasked with saving the Chrysler Comprehensive Compensation project. Neither Perl nor XP were designed in the ivory towers of academia. Both XP and Perl were developed to solve a specific problem, and quickly so that Kent and Larry would keep their jobs.

It's too early to tell with XP, but Perl has remained true to its roots. Perl continues to evolve based on feedback from its customers: the Perl community. Features are added or changed if enough people clamor for them.

This smorgasbord approach to programming languages is non-traditional, much like XP's focus on people over process is non-traditional in the development methodology community. Perl gives you a wide variety of tools without constraining how you use them. For example, Perl is object-oriented but objects aren't required to create modules or scripts. Perl programmers aren't forced to encapsulate all their code in objects to solve every problem, especially when simpler alternatives exist.[3] XP asks you to ignore what you aren't going to need, and Perl lets you put this principle into action.


Another parallel between XP and Perl is testing. The Perl culture is steeped in testing, and in XP, we test to get feedback from the computer and the customer. Perl comes with a complete test suite for the language, and virtually every CPAN (Comprehensive Perl Archive Network) module comes with unit tests. Testing in Perl is about impatience. It's faster to get accurate feedback from a unit test than by firing up the whole system to see that it works.

It's easy to write tests in Perl. The software quality assurance community has long known this, and Perl is a favorite tool among testers.[4] Perl programmers are lazy, so sometimes on CPAN the only useful documentation for a package is its tests. Some programmers find it's easier to write tests than documents, and conveniently that's the XP way of doing things anyway. Unit tests communicate exactly how to use an API, and acceptance tests demonstrate correctness and progress to the customer.


In XP, we share code in a collective repository. CPAN is probably the largest collection of Perl code on the Internet. There are over 3500 open source packages available for download. It's also the official repository for the Perl core implementation. Any perl programmer can get the latest version of Perl, and perl developers check in their changes directly to CPAN. The Perl community shares openly, because they're lazy, and want to solve problems once and only once.

Hubris plays a role on CPAN and in the Perl community in general. For example, type in xml parser into http://search.cpan.org, and you'll get at least six pages of results. It took some time for us to find the right XML parsing package to use in It's a SMOP. CPAN, like Perl, offers you many more ways to do it than any one project needs.

Organizing Your Workshop

Perl is often called a Swiss Army Chainsaw. When you add in CPAN, it's really more like the world's largest selection of hardware.[5] You can get lost in the dizzying array of choices. Some programmers find Perl daunting.[6]

This is where XP comes to the rescue. XP is the organizer in the Extreme Perl marriage that complements Perl, the doer and fixer. XP's role is to keep Perl from fixing the car when the kids need to be put to bed. XP gently guides Perl to do the right thing for the customer.

The next few chapters show you how Extreme Perl is organized, and the second half of this book shows you know Extreme Perl gets things done.


  1. Programming Perl, 3rd Edition by Larry Wall et al, p xix.

  2. This wonderful story of doing the simplest thing that could possibly work is elaborated in Programming Perl, p. 646.

  3. See Object-Oriented Programming in It's a SMOP for an example of when objects obfuscate.

  4. Visit http://www.stickyminds.com, and search for Perl.

  5. McGuckin Hardware in Boulder, Colorado (http://www.mcguckin.com) is the physical world equivalent of Perl.

  6. In a presentation at the 2002 PHP Conference, Michael J. Radwin lists Perl's Motto, "There Is More Than One Way To Do It", as one of the three reasons Yahoo! was moving away from Perl. Visit https://www.radwin.org/michael/talks/yahoo-phpcon2002.pdf for the complete presentation.

Previous: Chapter 2: Extreme Programming   Next: Chapter 4: Release Planning
Copyright © 2004 Robert Nagler
Licensed under a Creative Commons Attribution 4.0 International License.
  back to top