Developer Spotlight: Damian Conway

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.