You are currently browsing the tag archive for the ‘Perl’ tag.

I have a soft spot in my heart for Perl. It was the first language that I made any serious use of as a professional software developer. I’ve learned a lot from Perl and about Perl, and I know that the language has a reputation for being ugly. So how does a developer transform an “ugly” language into something special and possibly even “pretty?”

In the Perl community, the proposed question might be met with reactions of “TIMTOWTDI!” (pronounced “Tim Toady” and representing the very long acronym of “There is more than one way to do it!”) After all, they might say, what is “pretty” code? To me, pretty code is code that is maintainable, robust, and fast, probably in that order of preference. I think that there exists a book about Perl that illustrates how to write pretty code (per my definition) and here are my thoughts about it:

Last week I finished reading a book written by a well respected individual in the Perl community. Like Douglas Crockford with the JavaScript language (whom I mentioned in my previous post), this author is someone who has had a presence in Perl and really knows his stuff because of years of experience. The book is Perl Best Practices and the author is Damian Conway. Unlike Crockford’s JavaScript: The Good Parts, Conway’s book is much larger and spans more than three times the number of pages of Crockford’s 153 page book. Damian uses that space quite effectively and provides some great insight into how to write better Perl code.

Perl Best Practices is not a book for fledgling Perl developers. If you’re learning Perl syntax for the first time, look elsewhere (e.g. Programming Perl or Perl in a Nutshell), however, be sure to come back quickly to this book! The real strength I see in Perl Best Practices is the overarching guidance about how to craft Perl code into something maintainable by people. For code to be effective, it cannot exist in a vacuum. The best code is used and read and maintained by many people. Conway’s book explains some critical concepts to write rich code, but he writes it in a way that emphasizes how to make the code safe in the future and update-able to others. After reading Perl Best Practices, I feel better equipped  to write Perl code that other developers would value. I would love for those hypothetical developers to look at my future work and say “Oooo… that’s pretty!”

I just finished reading Perl Testing: A Developer’s Notebook by Ian Langworth and chromatic (yes, one of the authors identifies himself/herself as “chromatic,” presumably for privacy concerns). All in all, the book was eye opening in understanding the world of testing in Perl. I develop Perl code at work in a culture that does not focus on unit testing, but, equipped with the things that I learned from this book, I am now even more adamant that I will be creating unit tests for all of my future Perl code.

Unlike Python’s core testing library, unittest, which is focused on objects and test methods, Perl’s core testing libraries, Test::Simple and Test::More, are focused on procedural style testing. As a consequence of being procedural, Perl test code has a style that reads very differently from a Python test case, and it is this style that was so eye opening about the Perl Testing book. The style difference isn’t a bad thing, it just requires some mental adjustment shifting.

Perl Testing is written in a no-nonsense manner that jumps straight to a solution for how to solve some hard problems when testing Perl. Personally, I think that the book’s style makes the material such a useful resource when considering how to test a problem. The Perl community likes to say TIMTOWTDI, which means “There is more than one way to do it,” but sometimes there are too many ways to do something. Langworth and chromatic provide lots of solid examples of how to test things so that you, as a future Perl test code author, will not have to recreate the logic necessary to test some really challenging code.

The book isn’t perfect, but the overall quality of the material, and the incredibly helpful libraries that it introduces, makes Perl Testing: A Developer’s Notebook a valuable resource for any Perl developer who wants to test his code (which should be every Perl developer).

This should be educational:

matt@eden:~$ sudo apt-get install perl-doc

matt@eden:~$ perldoc perl

(and all associated sub-parts).

Then maybe I’ll start hunting around on the CPAN for modules or at least figure out which Perl modules Ubuntu bundles by default.

(Possible alternate title: Becoming a Better Perl Developer)