Builder AU recently caught up with Australian Perl guru Damian Conway to talk about Perl 6, his reasons for choosing Perl over other languages, PHP, and the upcoming Open Source Developers Conference in Melbourne.

A guru in the international Perl community, Damian Conway has developed scores of popular free software modules, a book author, three time winner of the Larry Wall Awards for Practical Utility and currently runs an international IT training company, Thoughtstream, providing programmer training across the world.

Currently much of his time is spent working with Larry Wall on the design of the new Perl 6 programming language. Before the start of the inaugural Open Source Developers Conference Builder AU spoke with with Conway.

Builder AU: What first attracted you and kept you interested in Perl?

Damian Conway: I first became interested in Perl as a young academic, when I was
researching programming languages as a form of user interface
design. Programming languages are the interface between the programmer
and the machine, and I was interested in making that interface as simple
and convenient as possible. Perl provided a flexible tool for that
research, because Perl itself is so malleable, and so well adapted for
building parsers and interpreters for other languages.

But once I started using Perl, I found it was the user community, as
much as the language itself, that kept me interested. Over the last decade
the Perl community has provided me a working environment populated
by supportive, intelligent, playful people with similar interests
to my own. That’s an extraordinary asset.

So why not say, Java?

Leaving aside the uniqueness of the Perl community, from a purely
technical perspective Java is far too restrictive for the kind of work
I do. And it’s far too demanding on the programmer. Sure, it has a lot of
great libraries that make it easy to get particular things done, but I
didn’t want to do those particular things. And certainly not in the ways
Java would require me to do them.

What do you mean “demanding on the programmer”?

Java programs require too much infrastructure, too much syntactic
scaffolding. Programming in Java always feels like a chore to me,
because the language so often gets in the way of the problem you’re
trying to solve. The clichéd example is, of course, the well-known
exercise of getting a language to print “Hello World”. In Java, that’s:

      class HelloWorldApp {

         public static void main(String[] args) {

            System.out.println(“Hello World!”);



It’s a cheap shot to point out how syntactically overburdened
that is, but it does illustrate a far more important point: that it’s
*cognitively* over-burdened too.

To get the job done (i.e. print out a simple greeting), the Java
programmer needs to understand the concept of classes, Java’s particular
class mechanisms and class declaration syntax, the concept of methods,
Java’s method syntax, the general concept of types, the specific concept
of a void type, the concept of parameters and return types, Java’s type
and parameter syntaxes, the concept of arrays and Java’s array
declaration syntax, the concept of static methods, the concept of public
class members, the concept of — and Java syntax for — method calls,
the notion that method calls can return other objects which can then
have method calls applied to them, the concept of class methods, the
notion of a System class aggregating all system interactions, the
concept of an I/O class mediating input and output, and the fact that
“println” is an abbreviation for “print line”.

And *then* you can print “Hello World”.

Of course, every language has some kind of cognitive loads, some minimal level
of understanding that’s required. But it doesn’t have to be *that* convoluted.
For example, Perl gets by with:

print “Hello World\n”;

in which the only arcane part is that C-ish “\n” newline. And in Perl 6,
even that won’t be needed:

say “Hello World”;

And that’s what attracts me to Perl. The demands of the language itself
don’t get in the way of *using* the language.

In an interview a few years ago you said that “Programming is a Dark Art, and it will always be”. Don’t you think with the advent of Model Driven Development that this thought of programming being a dark art will cease to exist?

Well, I guess we can always hope. But no, I don’t think MDD (or even
AMDD) is the silver bullet. It seems that every few years a new
development technique is hailed as the start of the Programming
Renaissance, the Golden Age of Scientific Software Development. And none
ever is. Stored instructions. Assemblers. High-level languages.
Structured programming. Functional programming. Logic programming. Object-
oriented programming. 4GLs. Model-View-Controller. Visual programming.
UML. Extreme Programming. And despite them all, operating systems and
applications are buggier, less reliable, less secure, and less usable
than ever.

Of course, the problem is not in these development tools. It’s in us.
All of these approaches are based on a false premise, the same desperate
illusion that every programmer clings to: that the universe
of problems to be solved is homogeneous, and that our task as programmers is
predictable enough for one approach, one methodology, one language, one
standard library to fit all problems.

But the real world isn’t like that — no matter how much our politicians
and our religious leaders and our advertising executives would like us
to believe it. Our world is complex, and inconsistent, and piecemeal.
And it’s the same in the virtual worlds in which programmers work.

The second half of that quote is: “The programmer is fighting against the
two most destructive forces in the universe: entropy and human
stupidity. They’re not things you can always overcome with a
‘methodology’ or on a schedule.”

If we’re talking specifically about Module-Driven Development, the
underlying fallacy this time is that real problems are always
susceptible to being modelled accurately enough. Or at all. Whereas the
quotation points out that the universe is governed by entropy — the
tendency for disorder, lack of pattern, and non-conformance to coherent
models all to increase over time.

And that same tendency is present in every human system and all our
organisations, which grow and diversify and adapt under a myriad of
conflicting influences and demands, until they collapse under the weight of
their own internal contradictions and stupidities.

So, for the programmer, reality is constantly outstripping, outsmarting,
and out-weirding our ability to model it. And that fundamental limitation is
only made worse by the fact that we build systems that are to be used,
controlled, operated, maintained, and extended by human beings: creatures of
consummate inconsistency, self-contradiction, and irrationality. So not only
can’t you model your proposed system accurately, you can’t even model the
expected usage of your system. And the final nail in the coffin is that your
system has to be designed and built by the self-same inconsistent,
contradiction-wracked, irrational humans (i.e. you). So you can’t even
reliably model the development of the system.

There is no silver bullet. Because not every problem is a werewolf. Some
are vampires — for which you need the wooden stake of OO design or the
garlic of functional decomposition. Some are demons — for which the
sacred rites of M-V-C may be the cure. And many problems aren’t really
classifiable at all: just Frankensteinian amalgams of unrelated parts,
cobbled together by some crazed developer. In which case your only
option is to grab your favorite text editor, roll up your sleeves,
descend into the darkness, and start hacking.

During 2001 the Perl Development Foundation coordinated to pay your annual salary to work on Perl. Was that something you enjoyed doing and would you do it again?

It was an extraordinary privilege to be given the opportunity to
work for the Perl community for that time. And to be given that opportunity
through the extraordinary generosity of the community itself.

Being freed to concentrate exclusively on Perl projects meant I was able
to be more creative and productive than perhaps at any other time in my
career. During that time I developed nearly two dozen individual Perl
modules (some of which were later added to the core Perl distribution
and all of which are now freely available on the CPAN). I was able to travel
around the world several times and provide over 400 hours of public
talks and seminars in six countries. I was also able to devote a
large amount of time to working with Larry Wall on the early stages of
the design of Perl 6, and I had time to start writing the “Exegesis”
series of articles.

It was an exciting and challenging experience and one that I will always
treasure. Could I do it again? Probably not. For a start, it was only
possible for me to give up that year because it happened to coincide with
an academic sabbatical I was scheduled to take. Nowadays, I’m a self-
employed Perl instructor, who also subcontracts
to other training companies. It would be
*much* harder now for me to “drop out” of my work commitments for another
year, no matter how much I might relish the opportunity to do so.

What projects are currently taking up your time in the programming world?

The Perl 6 design project has been taking up most of my time in the last
few years: working with Larry on redesigning Perl, and then
explaining our ideas to the wider Perl community. Another part of that
job has been experimenting with the new features we’re proposing —
prototyping them, sanity-checking them, and then backporting many of them to Perl

And, of course, my restless brain keeps coming up with new modules that
aren’t in any way related to Perl 6. For example, in the last few months
I’ve released a module for simplifying interactive prompt-and-reply
programs, a module
that provides a (sanitized) #include-like mechanism for Perl modules, a module that
makes it easier to write maintainable regexes, and a
that makes comments an active and useful part of your program.

Other than that, I have an international training business to run and
I’m also busy writing a new book on best practices in Perl coding, which
will be published by O’Reilly in the first half of next year.

What project, module written, piece of code or work in progress are you most proud of thus far?

The project I’m most proud of is undoubtedly Perl 6. It’s going to be
a huge leap forward for Perl. And within that project, I think I’m
proudest of my work on the concept of “junctions” which I hope
will make it very much easier — perhaps even painless — for ordinary
programmers to use parallel programming techniques in Perl.

There are two modules of which I’m equally most proud. The first is
because it has been of so much benefit to so many people and is now
used in some of the most exciting fields of business and research, from
Wall St to NASA. The other module I’m especially fond of is
Lingua::Romana::Perligata. In
contrast to Parse::RecDescent, it’s utterly useless in a practical
sense, but its concept and execution have an intrinsic elegance
that seems to delight many people, both within and beyond the Perl

What are your thoughts on the Australian Computer Society’s idea to license software developers? Do you think this will create better quality software with more accountability?

I applaud the idea. It’s an important sign of maturity in Australian IT,
a big step in moving from what is still often a “cottage-based” industry
to a more professional structure.

But whether licensing will result in better software or more
accountability…of that I’m not so sure. Certification ensures that all
registered practitioners have a minimal set of core skills and
knowledge, but that doesn’t necessarily translate into the experience,
the understanding, or the talent required to solve large real-world
problems any better.

PHP seems very much in vogue now compared to Perl for Web programming. Do you see Perl gaining more popularity in this area again or should Perl and PHP not be compared?

PHP’s popularity for Web development isn’t at all surprising. The language is
tremendously well optimised for those kinds of programming tasks, and
the implementation is very easy to set up. Perl, being a general-purpose
programming language, is nowhere near as highly specialised for Web-based
development. Comparatively few people seem to need the extra power that Perl
can provide (e.g. the enormous resources of CPAN), so PHP’s ease-of-use wins
out most of the time. As it should.

No matter how much I enjoy programming in Perl, as a computing
professional part of my responsibility is to select the right tool for
each job. My earlier comments about the impossibility of having a single
perfect tool for every design task apply just as much here as well.
There is not (nor could there ever be) one single perfect implementation
language. Every programming language is optimised for something,
which means that every language has to compromise on something else:
speed against flexibility, readability against expressiveness,
standardisation against portability, portability against native optimisation
(i.e. speed).

Unfortunately, many programmers only ever learn a few languages;
increasingly, just a single language. Apart from the well-known
consequence that “when all you have is a hammer, every problem looks
like a nail”, this high degree of specialisation also promotes the
perception that the various languages are in competition, because as a
specialist programmer I have to compete with specialists in other languages.
But, to the multi-lingual programmer, languages are just tools, to be selected
and used according to the task at hand. Saying that languages compete is as
bizarre as saying that hammers and chisels and saws are in competition. For
what? The carpenter’s mind-share?

So I have no problem whatsoever with PHP being more popular than Perl for Web
development. Or, for that matter, with Perl being vastly more popular for
system administration tasks. As long as I’m allowed to continue using both of
them for the jobs to which each is best suited.

As a professional instructor and senior lecturer at Monash University is there a golden rule or piece of advice you give to programmers?

I think the single most useful piece of advice I have tried to pass
on comes originally from Brian Kernighan:

    “Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it.”

That makes it imperative to write the code as simply and as correctly as
you can in the first place. That’s what I try to teach.

What will you be talking about at the inaugural Open Source Developers Conference?

I’m really looking forward to telling the Australian Open Source
community about Perl 6, especially about the extensive new OO features
we’re adding
to the language.
I’m also excited to have the opportunity to talk about my minimalist approach
to developing user interfaces and software APIs: a philosophy I call
“Sufficiently Advanced Technologies”. It should be fun.