with Peter Coffee
(February 2006)
What are the specific strengths that make Perl important in various domains?
Perl's main strength has always been its delicate balance between power and convenience. Larry Wall originally targeted it to fall between the "close-to-the-metal" power of C and the high-level abstraction of a Unix shell. That means that Perl scales very well. It has convenient built-in data-types and functions, which make it easy to whip up a program very quickly, but it also has a full range of more advanced programming-language features (such as introspection, OO, and closures) that support the more structured styles of programming needed for large development tasks.
In what situations would you not recommend its use?
I don't think Perl is appropriate for safety-critical code. I wouldn't want to see it used to run nuclear plants or for air traffic control, for example. But, then again, I don't believe that any of the popular languages (C++, Java, C#, VB, etc.) are suitable for those kinds of applications.
Perl is also not appropriate if you need to keep your source code secret. Because Perl is always interpreted directly from a source file, it's very difficult to develop something in Perl and then only release a binary of it.
Finally, Perl's interpreter is itself a large executable (up to 1Mb), so it doesn't really lend itself to most embedded systems.
In the past, I used to say that Perl wasn't suitable for any kind of real-time application either, but the steady increase in processor speeds is gradually proving me wrong about that. I guess, over time, a similar growth pattern in available memory might make Perl more feasible for embedded applications as well.
How have Perl's target audience and technical goals changed in the last several years?
Perl seems to have originally been aimed at sysadmins, toolsmiths, system programmers, and DBAs. That heritage is still evident in its large variety of built-in commands: not many other languages have primitives for controlling sockets, database access, signals, or networking.
Nowadays, Perl is used by a vastly wider range of developers, within a much broader set of problem domains. Today, Perl is used for ecommerce, information mining, website development, data analysis and modelling, report generation, document management, language translation, speech generation, print publishing, chip design, bioinformatics, CAD, cryptography, finance, genealogy, image manipulation, blogging, linguistics and natural language processing, email processing, data format translation, and all kinds of application prototyping and rapid development.
Catering to such a diverse user-base has certainly caused us to reconsider many aspects of the design of Perl. We've had to adjust our ideas about which existing features ought be remain "core" to the language, and what useful data structures and functions we're currently missing. For example, nowadays maybe 1% of Perl users ever use sockets, whereas maybe 20% regularly use XML in some way. So maybe sockets don't need a dedicated built-in function, but XML processing does.
We've also had to review the actual syntax of the language, with a view to making it less idiosyncratic. What was obvious and easy-to-read for a hard-core UNIX sysadmin is not nearly so friendly for a bioinformaticist or a VHDL designer.
Both of these issues have been very central to the Perl 6 project.
Have you encountered specific limits in widely used programming technologies, including Perl, that have led you to explore alternatives including Perl 6?
The major limitation of nearly all widely used programming technologies is the same: the language itself gets in the way.
For most developers a programming language is medium, a means by which they can think about problems and then describe solutions. But most programming languages make expressing a solution much harder than it really needs to be. You have to spend too much time setting up "infrastructure", devoting most of your mental effort on code that doesn't contribute directly to the solution.
The classic (perhaps clichéd) example is the traditional "Hello World!" program. In Java, you have to write something like:
class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); } }In C#, it's almost identical:
public class HelloWorldApp { public static void Main() { System.Console.WriteLine("Hello World!"); } }Even in ANSI C, it's still complicated:
#include <stdio> int main(void) { printf("Hello World!\n"); return 0; }In all those languages (and most others) around 75% of the necessary code has nothing whatsoever to do with the actual goal. It exists merely to frame your task in a standard scaffolding that allows the language to understand what you're trying to achieve. Compare that with the solution in Unix Shell:
echo "Hello World!"or Perl:
print "Hello World!\n";In these cases, all of the code is contributing directly to the solution. So that code is shorter, more comprehensible, and easier to maintain.
The example is trivial, but the underlying problem isn't. All I want is to print a string. Why should I have to create classes and methods, just because that's how Java and C# view the world? And why should I have to tell ANSI C that my program takes no arguments and makes use of I/O, when both of those facts are self-evident?
This same problem appears at many levels and in many other guises. Why should a developer have to reinvent common wheels, such as standard data structures or algorithms? And when such features are provided-- typically in a module or library--why should they be restricted to the limited, often cumbersome, syntax of the core language? Why should it be so hard to customize, reuse, or extend existing software? Why should it be so hard to customize, reuse, or extend core language features? Why should common data formats, like XML or PDF, be so awkward to read, write, or process?
We think Perl already eliminates many of those annoyances, and we'd like Perl 6 to do even better.
Are there particular skills or viewpoints that developers will find important to make best use of Perl?
Perl's overriding viewpoint is that a language should be flexible enough to allow you to write code the way you (or your team) prefer. So, for example, you can write:
if ($value > 10) { printf "%d is too big\n", $value; }or you can write:
print "$value is too big\n" if $value > 10;or even:
print "$value is too big\n" unless $value < 10;Perl's core philosophy is that "there's always more than one way to do it". The language is designed to allow people to write code in as natural a way for them as possible. That can seem very threatening when you come from a "There's only one way to do it" language. Until you realize that those languages are often really "There's only one--awkward, verbose, frustrating, suboptimal--way to do it", at which point Perl's adaptability starts to look much more attractive.
Of course, with great power comes great responsibility, and Perl's (in)famous flexibility does require some discipline on behalf of the developer. There are at least two dozen ways to write a case-statement in Perl, but it would be confusing and unmaintainable to use more than one of them in a given piece of code.
Are there any concerns or expectations that developers are likely to have about working with Perl that are likely to be misplaced?
The usual misapprehensions are that Perl's syntax is incomprehensible, that its flexibility produces unmaintainable code, and that it's not supported by some proprietary vendor.
The truth is that Perl's syntax is designed to be easy to comprehend...once you actually understand that syntax. Typically, someone will claim that a piece of Perl code such as:
my $text = do { local $/; <$file> };is incomprehensible. But that's only true if you don't know actually know Perl. As such, it's like claiming that:
SATIS OCULI, OMNIS CIMICES BREVES SUNTis incomprehensible when you don't know Latin. The assertion is correct, but meaningless.
On the other hand, it is true that you can write unmaintainable code in Perl...just as you can in C, C++, Java, C#, Python, Fortran, Ada, Eiffel, etc. etc. etc. But Perl's very flexibility also means that you can develop coding techniques and software tools that make Perl code considerably more maintainable than code in most other languages.
Finally, just because Perl isn't primarily developed by Generic Large Software Corp, doesn't mean it isn't supported. In the last two years alone, there have been official five point-releases of Perl, making bug-fixes and backwards-compatible enhancements available to every Perl user. There are numerous free public Perl forums where experts in the language regularly solve problems for free. Moreover, there are plenty of companies that do offer commercial support for Perl, such as ActiveState, Data-Plan Services, and PSDT.
If you had the chance to tell other developers what they'd most likely find surprising about Perl, what would you say?
I think the thing that new Perl developers find most surprising is how easy it is to just get your job done with Perl, without spending days agonising over data structures, struggling with implementations, or debugging your code.
For example, a few weeks ago I was at a Linux Conference in New Zealand, where they wanted to draw the number of a winning raffle ticket. The problem was, the tickets they'd sold weren't in a single sequence, and they hadn't sold all of them. So they needed to draw numbers without replacement from a non-continuous set of ranges. Being a hacker conference, they naturally asked for volunteers to write a program that would do that. I wrote mine in Perl. In under sixty seconds. In just two statements:
use List::Util 'shuffle';print and readline STDIN foreach shuffle 12001..13000, 14001..15000, 40001..41000, 67001..68000, 96001..97000;
For me, that's still the nicest surprise about Perl. It really does live up to its motto: "making easy things easier, and hard things possible".