August 2000 Archives

Report from the Perl Conference

Were do I begin? Like Willy Wonka said, "..the beginning is a very good place to start..." So let's start with my journey to the conference.


Day 0: July 15, 2000


My flight to San Jose wasn't delayed too long. During my wait I did get to down some Sam Adams and Jack Daniels while reading Java and XML. Yeah, I know it's probably blasphemous to read a Java book on the way to TPC, but I was looking for some good ideas on using XML, and it is an O'Reilly book.

In any case, I had a thankfully uneventful flight (way too many babies on board, but they remained quiet the entire trip). Picking up the rental car and driving to Monterey wasn't too bad other than occurring after midnight.


Day 1: July 16, 2000


This was an enjoyable day of wandering about Monterey. I mostly walked around the northern marina, watching the ocean and walking enjoying the sand and surf. It was a pleasant day just seeing restaurants, pubs, and other businesses I didn't suspect even existed (like the movie theatres near the hotels).

In the early afternoon I picked up a buddy at the Monterey Airport, feeding his Jack in the Box addiction, and registering for the conference.

Monterey is really a lovely place to visit on the company dime.


Day 2: July 17, 2000


Well, this is the first day of tutorials. I am scheduled to attend both of Damian Conway's Parse::RecDescent classes. It was something I looked forward to, these were the tutorials I really wanted to attend.

After a quick breakfast, I dashed off to "Practical Parsing with Parse::RecDescent". It was such a delight to attend the lecture. Damian was funny, witty, and ably conveyed the basic principles and concepts of parsing and lexing (something I had very vague notions about prior to this tutorial). I had been reading the ample documentation that accompanies the module in the months prior to the conference. I had started to grasp the material, but I hadn't the time to fully grok and apply it. This class brought everything into sharp focus.

There were a few things that really stuck with me:

  1. "Parsing with Occam's Razor". The idea to make your grammar as simple as needed. This along with his C parsing examples gave me some good ideas on how to do some qualitative analysis and verification of code.
  2. "Any sufficiently advanced syntax is indistinguishable from semantics." Any interesting twist on what I believe is an Arthur C. Clarke quote. This was an opening remark Damian made leading into the section where he created a grammar to parse natural language queries into SQL statements.

The afternoon class was icing on the cake and an iron maiden for the mind. "Advanced Parsing with Parse::RecDescent" was as inspiring as it was frightening. Creating self modifying grammars on-the-fly is a mind melting concept, let alone to see an actual implementation of it. Two examples that stuck out were:

  1. A parser that is created on the fly to parse Apache config files so that it can create another parser for the error log.
  2. A parser written in pure Perl that can "(nearly) parse Perl". Very frightening how close Damian is to doing this.

Damian is probably the First Virtue incarnate. Anything that might save some work, reduce redundancy, or in general minimize effort for maximum effect was attempted by Dr. Conway. Truly amazing. Additionally, I think I have stumbled upon a new form of software, "Christmas-ware". I leave it as an incentive for the reader to attend one of Damian's talks to truly understand this new paradigm in software development. ;-)

Unfortunately the tutorial went long, as Damian is infamous for, because I had a dinner reservation at the Sardine Factory. If you're ever in Monterey don't hesitate to have dinner there. You won't be disappointed. For example, I had a very reasonably priced 5-course dinner.

  • Appetizer: Blanched green beans in a vinaigrette
  • Soup: Albacore bisque, probably the best soup I've ever had
  • Salad: Huge chunk of iceberg lettuce with a Maytag blue cheese and balsamic vinaigrette.
  • Entree: Beef Tenderloin on a bed of spinach and grilled slice of onion, with Southwestern-style shrimp. Can't exactly recall the sauce, but it was beef based and spicy
  • Dessert: Creme Brulee, very good

The grand finale of the evening however was the double feature, Office Space and Evil Dead II. A pleasant finish to the day. A little Dilbertian office satire and the genius of Sam Raimi. On the big screen no less.


Day 3: July 18, 2000


I had such high hopes for this day of tutorials. Some rather interesting and potentially useful topics. Unfortunately, they proved otherwise. Both were taught by capable and knowledgeable folks, however they both had flaws.

The morning tutorial was "Exploiting Perl on Windows with OLE/COM". It started off with 45 minutes of definitions and such. Not one line of code to be seen. I could deal with some cursory examination of what certain acronyms meant. That's why I have a workbook of the presentation that I can refer to when I don't understand a term. To be fair to David Roth, he was very knowledgeable about Perl and its use on Windows systems. He also has provided invaluable work by contributing many modules. However, I have come to expect a lot of examples and code. "Show me the code", so to speak.

I bailed on that and caught some of the "Object Oriented Perl" tutorial. Talking to my buddy that was attending the tutorial, it was mostly going over similar topics discussed in Damian Conway's Object Oriented Perl book. This wasn't much of a surprise since Damian was the lecturer. :-)

After the break for the morning sessions I checked out Mark-Jason Dominus' "Tricks of the Wizards" class. I had taken it last year and just wanted to see if anything might have been added. After a few minutes it looked that it hadn't, why change a good lecture? So I decided to relax a bit and wait for lunch.

After lunch I had high hopes for the afternoon. Like I said, it was a bad day. The tutorial, "XML Hacking with Perl and XML::Parser", was excellent, but it was more of an intro course. The first hour passed by without much new knowledge being transferred. I was hoping more for application of the module and some good ideas of how to use XML in general. Consequently, I strolled on over to Dominus' "Advanced Programming Techniques" class. I particularly enjoyed the bit about infinite lists and their implementation in things like: network client requests and numeric approximations. Very useful stuff.

I recalled that O'Reilly was going to sell off any leftover tutorial workbooks. During a section that was in "...Wizards" but was moved to "...Techniques" I went and purchased some of the workbooks. It was nice to get some feedback from the O'Reilly folks handling the sell-off, mostly what they've heard other attendees had to say about the class and the workbooks in particular. This feedback along with getting to thumb through the text I was able to avoid some duds.

Once the tutorials were over for the day I took my buddy to the airport so he could go catch the Comic Convention in San Diego. The lucky bastard was be able to get some of the inside dirt on the upcoming Lord of the Rings movies.

I made it to the Perl Trainers BOFs. The first one was most just Perl Trainers trading war stories, tips, and general training strategies. For example, the sequence of topics, the difficulties most newbies have understanding hashes, and how to approach the idea of context. One good story was the experience one trainer had when he was teaching Perl to a bunch of COBOL programmers. IIRC, they had a bit of trouble with file handles, but quickly understood regular expressions when explained within the context of COBOL principles they understood. I guess that just highlights the need to understand your audience and how to take advantage of their pre-existing programming knowledge. It was very interesting and informative since I want to do some Perl training within my own company.

After that BOF there was Nathan Torkington's BOF for teaching Perl to beginners, specifically those that have never programmed before. It was more of the same, but delved more into how to teach Perl. One technique that I liked best was to have the students start using the code as quickly as possible. Also, using examples that are relevant to their needs, once again "know your audience", or something that is "cool".

Good Perl books for beginners were discussed. While "Llama" is the de facto standard, it is not always appropriate. Andrew Johnson's Elements of Programming with Perl, was mentioned a lot. This is a really good book for the complete programming newbie, not just Perl newbie. Clinton Pierce's Learn Perl in 24 Hours was mentioned a few times. Simon Cozen's Beginning Perl was brought up but it was new enough that not many had read it to give it a good review. All in all these BOFs were a good time.

Then it was off to dinner and the Sendmail bash. That was very fun, I got to mingle with some very cool Open Source and Perl folks. I mostly chatted with some guys from HP and a dude from "USA Today". The HP guys mainly dealt with load balancing and performance issues, they also drank a lot of stout with me that night. The guy from "USA Today" was responsible for reformatting news feeds and sending them off to the various departments for publication. I sincerely wish I could remember their names, but it was a long, drunk night and I met so many great folks.

Of course, all of the free beer was great. It was a great end to an otherwise disappointing day.


Day 4: July 19, 2000


An early, but rough morning preceded the opening keynote speech. Drinking until 2 am will sort of do that to you ;-)

Andy Hertzfelds' speech was wonderful. Much better than Guy Kawasaki's or Bill Joy's from last year. It was full of hope, history, and humor. Everything you would expect from one of the original Apple hackers.

The speech I came for was of course Larry Wall's. Once again he had an entertaining speech concerned with the complexities of systems; music being the system he explored in breadth. From the simple instruments (fingers and hands) to percussion (bongo drums, spoons, and claves),to strumming a bass, acoustic guitar, violin/fiddle, autoharp, bowing a saw, and a synthesizer just to name a few.

Larry then saved the biggest sound for last, the announcement of a total rewrite of Perl. Something that was well received by all.

After the State of the Onion, I proceeded to catch a couple of channels of Damian TV. Most notably his papers presenting a switch/case statement for Perl and the yet-to-be-released module Lingua::Romana::Perligata. Perligata was a great presentation. Damian took advantage of the inflected nature of Latin, word order in a sentence doesn't matter because the form of the word determines if it is a noun, verb, object, etc. By judicious and ingenious selection of the various forms, Dr. Conway created a module that allows you to write perl programs in Latin! Definitely get a hold of this module/paper and read it.

In between Dr. Conway's talks, I caught a bit of Kevin Lenzo's "Field of Memes", a very interesting look at the IRC bot, purl. It was interesting looking at a system that is somewhere between AI, expert system, and knowledge base. It reminded me of how I think an agent/diva would/should work but much simpler. Basically, you asked purl a question and purl answered it the best it could.

As for the afternoon talks, they were good but not very memorable.

Then it was off to the Caribbean Bash, the free food and booze party for all of the conference attendees. Once again, it was fun to mingle with folks.

After the bash was a BOF put on by Dominus, "Something Cool Dominus is working on". At the BOF we got to find out how pathetic his phone company was at doing DSL. This was a fun rant to listen to, but it meant he couldn't demo some of the cool stuff he has prototyped and he couldn't look at his special projects file. Nonetheless, he talked about the work he started for the creation of a regex debugger. He created a working prototype and had the engineer working. Very cool. If I was a better C programmer I would have probably picked up where he left off and played with it. It does have me thinking about how to implement one in pure Perl.

He briefly touched upon his documentation idea, basically how to create an extensible and adaptable manual. Unfortunately, we were kicked out of the room before he could get into it.


Day 5: July 20, 2000


Tim O'Reilly's speech was ok. It mostly focused on the idea that the next killer app would be to have applications run on the web instead of your desktop, Application Service Provider type of stuff. This isn't something I'm excited about but I thought I would see where he was going with it. His two big examples were Mapquest and Amazon.com.

Needless to say this didn't inspire me. Here I was at the Open Source Conference and the head dude at O'Reilly was using proprietary examples for what he thinks are the "Next Big Thing". Sure it's nice that Mapquest provides a good service, but Tim was talking about your applications existing on the net. Lots of privacy and data ownership issues to ponder and worry about.

An interesting talk, but I would hope for more from the head of a company that is a major proponent of the Open Source movement.

Gregory Benford's speech was a good foil to Tim's. Its foundation was the ongoing war between personal privacy and marketing. It is becoming easier and easier for marketers and advertisers to learn more about us and thus create ads that are more precisely targeted.

The real ironic thing about it is that we, the development community, are the ones that is making it easier for them to invade our privacy. As we create more sophisticated applications to better serve customers we are also better able to track a consumer's spending habits as well as personal habits in general.

A very good keynote speech and something to definitely think about.

The rest of the morning was filled up with some rather interesting talks, but some of us continued with Dominus' BOF from the previous night. Fortunately, he could log into his web site and demo his cookbook idea. Like I mentioned before it is basically a way to create extensible documentation. If you didn't understand a term or technique, you could expand that area and include it in your "recipe".

After lunch was the Perl Golf Apocalypse. One of the events many folks were anxious to see. It had a rough start and eventually fizzled because of some technical difficulties. Regardless, it is an interesting contest and I hope that the hard work that was put into this year will come to fruition in next year's TPC.

As a result, Damian Conway was asked to give an impromptu presentation of his Perl and Quantum Computing speech that he gave at YAPC this year. It was quite fascinating to see someone explain "basic" quantum physics in about 10 minutes. Even better was his continuation of these principles as they apply to quantum computing. The foundation of which is the qubit. Where the bit as we think of it has 2 states, a qubit can have infinite states (quantum superposition). By just adding operators to Perl ('any' and 'all'), one can do all sorts of interesting things. Lets just say that you could do factorizations in constant time. Damian has actually submitted to CPAN his module to do this, the documentation is here. Though he didn't get to complete it, it was still a fascinating and inspiring bit of work.

Previous to this, I was part of a group in the hallways that was talking with Dr. Conway about this. He either has or will give this talk to a variety of audiences. Depending upon the audience the speech comes off differently. In front of a Perl audience, it is somewhat humorous and amazing. Quantum computing does that to us Perl folks I guess. In front of physicists and those that are really serious about quantum computing, it plays as a very serious piece of work and a goal to strive for. It appears that observers can even affect a talk about quantum computing. :-)

Then came the Perl Town Meeting. This is a fun thing since the community gets to air questions, make comments, and generally express to the community at large their concerns. Most of the questions dealt with Perl 6, which was understandable considering the change this means for Perl. Another large portion dealt with the conference itself. How does TPC relate to what YAPC is doing, how can we make it more affordable for all, and how we can make the conference better overall.

I really enjoyed being able to attend the conference from beginning to end. I got to meet a lot of great people, put facesto Usenet postings, and in general learn more about the programming language that is near and dear to me. My thanks to O'Reilly and Nathan Torkington for putting on a spectacular conference, thanks to all the presenters and tutorial teachers, and thanks to Larry Wall for creating a language that lets a diverse bunch of people work together and apart so well.


Day 6: July 21, 2000


Not much happened on my return trip other than spending about 20 hours in airports/airplanes. It did give me plenty of time to read all of the papers for the presentations I missed as well as go over the tutorial workbooks, again.

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