Developer Spotlight: Damian Conway
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 modeled 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 organizations, 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 5.
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 module 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 Parse::RecDescent, 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 community.
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.