Interview for eWeek

with Peter Coffee

(February 2006)

eWeek

What are the specific strengths that make Perl important in various domains?

Damian

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.

eWeek

In what situations would you not recommend its use?

Damian

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.

eWeek

How have Perl's target audience and technical goals changed in the
last several years?

Damian

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.

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.

eWeek

Have you encountered specific limits in widely used programming
technologies, including Perl, that have led you to explore
alternatives including Perl 6?

Damian

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:

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.

eWeek

Are there particular skills or viewpoints that developers will find
important to make best use of Perl?

Damian

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.

eWeek

Are there any concerns or expectations that developers are likely to
have about working with Perl that are likely to be misplaced?

Damian

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 $/; };

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 SUNT

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

eWeek

If you had the chance to tell other developers what they'd most likely
find surprising about Perl, what would you say?

Damian

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: