Peter Wainwright is the author of Wrox's "Professional Perl Programming". In this virtual interview he shares his thoughts on Perl, being an author and more...When did you first start programming with Perl, and why?
I first looked at Perl when I needed to write some simple CGI scripts, for which the build-compile-test cycle of C was too cumbersome and long-winded. At the time I was already well-versed in C, so using Perl wasn't a case of knowledge but of convenience: It was quicker to learn Perl and then implement scripts in it than it was to apply my existing C experience. At the time I wasn't aware of Perl's other advantages like taint checking, but in hindsight they would also have been good reasons to adopt Perl.
In your opinion is Perl well suited for real-world applications beyond scripting for the web and for system administration?
Any language - well, almost any - is potentially suited to real-world applications, but to actually be useful for serious application development, a language needs to be well supported. Java, for example, is popular as much for the wide array of supporting APIs as it is for any advantages conferred by the language. Originally pitched as a client-side language, Java's popularity in server-side programming only took off when servlets appeared. Perl is similarly fortunate to be very well supported in third-party libraries and modules. This is what makes the difference between a language that is theoretically capable of large-scale application development and one that is practical. Every conceivable application area is covered.
There are Unix shells that are now almost as capable as Perl, but they don't have the same range of library support and nothing like CPAN (Comprehensive Perl Archive Network) to encourage them. Technically, there is no reason why they might not have grown to challenge Perl as the scripting language of choice, but since they were traditionally thought of as "for scripts only", they never did. In this respect the defining moment for Perl was the introduction of proper support for modules and packages (and as a side-effect, objects) in Perl 5, which transformed it from a better tool for shell scripts into a language that supported and encouraged the use of libraries. Since then, Perl has exploded in both scope and popularity. So yes, Perl is well suited for real-world applications - and if you don't believe me, just list the modules available on CPAN (www.cpan.org).
What are the most powerful aspects of the Perl language?
There are many common answers to this question - regular expressions, for example. But I would say that the single most powerful aspect of Perl is simply its ease of use. It is a very easy language to think in, which means that I can spend more time working out how to solve a problem and less time working out how to implement that solution. That means more constructive use of my time, which is ultimately one of the key traits that any language should have.
Perl's motto is "there's more than one way to do it". Do you think that this is a positive trait for a language, or does it have drawbacks?
Both - the counter motto is "Just because you can do it doesn't mean you should". I actually thought I'd come up with this on my own until I found it hidden in Perl's own documentation one day :-) Perl tries to impose as little control over how you use it as possible; that's the reason why it is so flexible. Perl's particular appeal is that it manages this while still providing a powerful basis for programming. The catch with this is that if you're a sloppy programmer then Perl won't snap you into line, unlike more rigorous languages.
How would you respond to those who accuse Perl of encouraging programmers to write illegible code?
This follows the last question. Perl will support almost any programming style, which makes it very easy to migrate existing practices. Of course, if they're bad practices, they won't magically improve just because you're now writing in Perl. It's not the language but what programmers bring with them to the language that leads to illegible code. That's true of any language, but Perl's strength and weakness is that it is more permissive, which leads to greater flexibility but less strict enforcement.
One of the defining characteristics of a programming language is the stance it takes on whether and how much to control how code is written. I would disagree that Perl encourages illegible code, but equally it doesn't try to enforce legible code through its syntax. Plenty of other languages do, and each finds its own compromise between flexibility and control. Some argue that Perl lets programmers get away with bad coding, and they may be right, but that doesn't alter the fact that bad coding comes from the programmer or suggest that writing in a stricter language will magically turn a poor programmer into a good one.
Are there any changes/improvements that you would like to see made to the Perl language?
Actually, a lot of changes and improvements to Perl are already in hand in the shape of Perl 6. For details of the current specification and progress see http://www.perl.org/perl6/ If I had to pick one feature I'm looking forward to, though, it would be threads. Perl already supports them, but only experimentally. Other than that, I would like to see Perl remain recognizably Perl and not suffer from feature bloat. Perl manages to leave in code features that other languages implement internally, which allows it to remain both versatile and free of ideological dogma. I wouldn't want to see that change.
There are already many Perl titles on the market. What makes Professional Perl stand out from the others?
It seems to me that a lot of books put the cart before the horse - they start out with the features and then explain how to use them to solve problems. That's great if you already know how to do something in general, but it's not very handy if you have a problem and want to know the best way (or ways, as there are often different approaches, especially in Perl) to solve it.
In my previous book, Professional Apache, I tried to write from the point of view of the problem rather than the solution, covering the features of each approach to solving it and covering other ideas and drawbacks in passing. Judging by reviews this seems to have been largely successful.
I've applied the same logic in writing about Perl. If anything, given Perl's motto, "There's more than one way to do it", it's even more appropriate for Perl than it is for Apache. So I hope that readers of Professional Perl will find it a more accessible book, which will result in less time actually reading it and more time programming.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.