Damian Conway Talks Shop


Dr. Damian Conway is best known in the United States for authoring Object Oriented Perl, published by Manning. His lectures at Perl conferences are becoming legendary and are a joy for Perl hackers of all levels. I managed to catch up with Dr. Conway just before his fall semester of lecturing at Monash University in Australia began.

Joe Johnston: Although you give a pretty decent account of your teaching career at http://www.csse.monash.edu.au/~damian/bio.html, could you state your day job for the record?

Damian Conway:

Name: Conway, D. M.
Rank: Senior Lecturer, Computer Science, Monash University.
Serial number: 8371 466.

JJ: Fred Brook's Mythical Man Month and No Silver Bullet are classic essays on the business and art of software engineering. The main point of the former is that application developers need to be managed more like commissioned artists, rather than as factory workers. The later work suggests that there will never be a design tool that significantly makes software development schedules more deterministic. Are these works still relevant and do you have your undergrads read either of these?

DC: I often recommend "MMM" to my software engineering students, but mainly for the real life horror stories it includes. They do a semester of SE and think they're ready to build their own operating system. Brooks' tales from the trenches are a useful antidote.

Both books are still relevant, even though we're now living in The Future. The situations and problems they describe may be now mainly historical, but the underlying issues are perennial.

Programming is a Dark Art, and it will always be. 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.

And when you look at it, we haven't come that far in the quarter century since Brooks first published "MMM." Sure we have more development tools and techniques, but most of them (and most programming languages too!) don't really help. Especially not on large projects (i.e., anything over three or four developers).

They're designed to force the software team into someone else's (usually academic) conception of how a program should be created. Generally they advocate ways of working that make no allowance for the needs, motivations, and goals of the humans in the system. So Real Programmers don't use them, and programming stays a handicraft -- a multi-trillion dollar cottage industry.

Of course, it would be easy to fix that: make the software vendors liable for the correctness and reliability of their software and you'd see an instant revolution in development. There's plenty of research and practical experience in building reliable systems using unreliable components (i.e., programmers). But as long a companies can turn a buck or two (billion) by shipping pre-beta quality software, why would they bother to find or mandate better ways?

JJ: There are those in the Open Source Community that point out that greed is not sufficient motivation to produce quality software, which is often the labor of love. How can Joe Programmer (not this Joe programmer) learn to love developing accounting applications?

DC: He or she can't. No more than you can make a COBOL programmer love hacking kernel. People sometimes offer me contracts writing DB interfaces or building websites, but I tell them I'm not worth what I'd charge to do that. Because I'd be doing it strictly for the (very large amount of) money, rather than for love of the project. They wouldn't get my best.

Whatever software your trying to build, you need people who are inspired by the idea of that software. Even if they aren't virtuoso hackers: you can always teach a person to code better, or tidy their code after it's written; you can never teach a person to love your project. And without that emotional engagement, you'll never get the superhuman effort that's required to produce quality software.

It often seems to me that recruiters ask the wrong questions when interviewing programmers. Sure you have to find out if they know the difference between an argument and a parameter, but it's vastly more important to discover what kind of enthusiasm and energy they're going to bring to your project, why they'll put in 18-hour days on it, why they'd pay you to work on it. Find those people and you'll get quality accounting software.

And in a roundabout way, that's why we need diversity in languages (and within languages). So that there can be languages that fit a diversity of brains. So that every kind of geek can find his or her passion. Many of us love to diss COBOL and VB and Ada and PHP and Python, but we need to remember that, without those languages and the brave souls dedicated to -- and inspired by -- them, we would have to write accounting software and bad GUIs and defence protocols and dull websites. In Perl. :-(

JJ: The world needs uncool software. Can we judge the hepness of an application by its quality?

DC: No. Because to some folks it really is hip to be square. All you can tell about quality software is that someone thought it was important enough to care about, to invest themselves in. And people can feel that way about the oddest, unheppest things: model trains, mime, cloisonne eggs, folk dancing, even accounting applications.

JJ: At Perl Conference 4.0, the Best Technical Paper award was renamed the Damian Conway Award. I don't even have a name on my office door. Will you be posing for the award statue?

DC: I'm only 5'6''. Put me on a block of marble and I could be the award statue!

JJ: That won't work. You wouldn't stand still long enough to present the award.

DC: That could be the criterion: to win the award you have to keep up with it :-)

JJ: If a calendar of Perl Hunks were assembled, which month would you be?

DC: JJ: You have to get off the drugs, Joe! And soon! A Perl Hunk calendar??? How sick is that?

Oh, very well then: August.

JJ: This just in from the Perl section of Teen Beat, what tunes are on your CD/LP/MP3 player these days?

DC:

  • "Five", J.J.Cale
  • "Oxygene", Jean-Michel Jarre
  • "'Gladiator' soundtrack", Zimmer & Gerrard
  • "'Sense & Sensibility' soundtrack", Carl Davis

JJ: Speaking of fluff, Paul Allen has been real busy spending money these days. From seeding Transmeta to donating millions to the Search for ExtraTerrestrial Intelligence (SETI), Allen has been spreading his Microsoft millions liberally. What projects would you like to fund with your future trillions?

DC: C'mon! I'm a mad scientist/hacker from Australia. I seriously doubt I will ever have major disposable income.

But if I did, I'd be funding:

  1. Nanotechnology. I want microbots tending each blade of grass on my lawn and quitely rolling dust and dirt off my floors.
  2. Vacuum point energy research. I hate having to recharge lap-top batteries. Energy wants to be Free.
  3. Gerontology. We only get one go, and 100 years isn't nearly long enough.
  4. Education. Better education reduces world misery in so many ways. It fights poverty, overpopulation, prejudice, and tyranny.
  5. People. I'd spend my time finding humanity's best and most creative people, and just pay them to be them. Sure, you might not pick the right person 9 times out of 10. But what if the tenth were another Mary Shelley, or Frank Lloyd Wright, or Murasaki Shikibu, or Larry Wall?
  6. A Buddhist monastery. Peace is a renewable resource, but the world lacks enough processing capacity.

    JJ: For the people that have read your book "Object Oriented Perl" or heard your conference lectures, your commitment to bring respectability to Perl's OO model is well known. Oddly enough, you have seem to have other comp sci interests. What is "automation of hypermedia" and how does it apply to user interfaces?

    DC: Anyone who has put together a large website knows how long and hard the process is. Anyone who has tried to use a large website knows how rarely the process is done well.

    For a time, I was developing tools to make it possible to generate navigable, comprehensible, usable websites with nothing more that vi. I developed a system that used text files for content, with very minimal mark-up, to generate full websites for various programming courses I was running. It would index all the material, cross-reference it, annotate it with exercises, hyperlink it back to glossaries and bibliographies, construct course syllabuses and outlines, etc., etc.

    And, of course, it was all done with a single, rambling, arcane, semi-sentient Perl program :-)

    JJ: Have you used HTML::Template or HTML::Mason? Both allow Perl to be embedded in an otherwise static HTML page. This is sort of the server-side include method as used by ASP and Cold Fusion.

    DC: I haven't used them, but I've heard very good things about both modules.

    JJ: More generally, is Perl ready for next generation web applications or are Perl tools not evolving fast enough for very large websites with large and diverse development teams?

    DC: I'm not sure anyone or any tool is ready for the demands of mega-websites, anymore than existing software development approaches are ready for Programming In The Very Large. I don't think we know how to reliably create huge linear programs that are safe, robust, and efficient. Add in the web's demands for multimedia, hyperconnectivity, and interactivity, and I think our software technologies are at least a decade behind demand.

    Some parent groups in the U.S. question whether computers are having a positive impact on children. They claim that video games are not meaningfully more interactive than Plain Old TV (POTV). Should any nation eschew raising teachers' salaries in favor of installing classroom computers? Are the Luddites right?

    DC: Technology is not the enemy. Deification of technology is the enemy.

    Any nation that favours a technological fix over funding good teaching is going to get what it deserves: neither a technological fix, nor good teaching.

    Western culture is increasing about magic bullets. We think a pill or a weekend course or a laying-on-of-hands is going to instantly solve our problem. As though we lived in a weekly sitcom with a 30-minute story arc.

    Putting computers in classrooms instead of teachers is doing just that: Latching on to a single "quick fix".

    Of course, you do have to give the kids access to the technology. Not doing so nowadays is as criminal as not teaching them to read. But you still have to teach them to read, and think, and learn, as well!

    Put 30 kids in a room with an easel, a computer, and a guitar. You'll get one Van Gogh, one Von Neumann, and one Van Halen (or Van Morrison). And 27 burger flippers. :-(

    Every child has some great potential, but almost all of them need help to find it, and nurture it, and control it, and master it. They need a teacher, a guide, a role model. No machine is going to give them that. At least, not for a long time yet.

    JJ: The big news at TPC 4.0 of course was Perl Episode 6, The Phantom Rewrite. What are three (or more) things you'd most like to see addressed in this reconstruction?

    DC: Well, I have a list of 40 or so things I'm hoping to propose for Perl 6. The big ones include:

    • Getting rid of the requirement for a final true value in require'd files
    • Finding a better name for local
    • Making == work more DWIMly on numeric operands strings
    • New control structures: co-routines, switch statement, multiway comparisons
    • Fixing the nested iteration behaviour of hashes
    • Redesigning the format syntax and make it a subroutine in a pragma
    • Subroutine parameter lists and extra context specifiers
    • Numerous enhancements to OO Perl:
      • hierarchical construction and destruction
      • built-in encapsulation of attributes
      • extended, integrated operator overloading
      • multimethods
      • method redispatch
      • method pre-conditions, post-conditions, and invariants (also for ordinary subroutines)
    • Regular expression matching against subroutines and filehandles
    • Run-time access to source code parse tree, and simpler source filters
    • Higher order functions
    • Lazy evaluation of subroutine argument lists
    • Extended context detection features
    • Superpositions

    JJ: What are the three scariest nightmares the corporate world has about Perl that prevent wider adoption of our favorite language?

    DC: I don't know very much about the corporate world, but I guess three common fears might be:

    • Perl is unclassifiable
      COBOL is a banking language, Fortran is a numerical computation language, C is a systems programming language, Visual Basic is a GUI applications language, Java is a web programming language. What is Perl?
    • Perl is unmaintainable
      Line noise programs, numerous defaults, subtle context propagation, symbolic references, closures, unconstrained OO model, one-liners, weird modules maintained by weirder hackers, typeglobs, AUTOLOADING, operator overloading, source filters, etc., etc.
    • Perl is unsupported
      Yeah, I know, I know. But there's no $599 MS-Perl with a GUI interface and an exorbitant support contract.

    The Perl Mongers are making valiant in-roads against those perceptions, but they can't make Perl the static, commercial, boring tool that many managers are used to. And hence comfortable with.

    We'll have to wait until the grunts who are actually using Perl in the trenches -- and holding entire organizations together with it -- get promoted into management. For them, Perl will be the safe and familiar option.

    JJ: You're a big burly OO dude. Why aren't you programming in Python?

    DC: When you live in Australia, you learn to be wary of snakes.

    Seriously though, I don't use Python because I'm not just a big burly OO dude. I'm also a frightening functional dude, and a devious declarative dude, and an insidious imperative dude. In order to mess with people's minds, I need to be able to mess with a programming language's syntax and semantics: add a switch statement, change the dispatch model, superimpose scalars, lock down hash access, intercept error messages and convert them to haiku, impose design-by-contract constraints, or reconstruct the language in Latin or Klingon. Only Perl lets me push (fold, spindle, multilate) the envelope like that.

    JJ: What's your favorite part of your native country?

    DC: The hilly spa country around Daylesford, Victoria. Rolling green hills, temperate climate, clean air, perfect.

    JJ: The US "Dot.COMomy" has become colder than a bartender after closing time. Will those programmers who have only been in start-ups have a hard time adjusting to an economy in which they aren't lusted after like jade idols?

    DC: Good programmers will always be in demand -- there are so few of them around. And computers and the Internet are here to stay, even after the hype has died.

    Those refugees from Start-Ups are not going to see the same mania for their services, but they'll still see good salaries and packages. What they'll have trouble adjusting to is an economy where they're expected to perform within the rules, keep office hours, wear shoes, write reports, cut code to spec rather than because it's cool. That's going to hurt. But the companies that survive will survive because they extract more value from their employees than those employees cost. In that sense, there is no "new" economy.

    The down side is that, in the future, you'll have to be right on the end of the bell curve to offer your boss enough value to justify the cost of your bohemian behaviour.

    JJ: If Perl were to disappear tomorrow, what would its legacy be?

    DC That programing languages should be made to fit humans, not vice versa.

Visit the home of the Perl programming language: Perl.org

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en