|Hear Larry Wall's Keynote|
(Because of the time length, we've broken up Larry Wall's keynote at O'Reilly's Open Source Roundtable into four seperate audio files.)
Today, I'll need all of the support I can get. I'm running an experiment today in sleep deprivation. Actually, I've been running the experiment in sleep deprivation for the past six months or so. If what I say today comes out like puddle mush, well, you can just assume that I used up all my pitiful supply of good writing for that little book some of you have been carrying around.
I decided to talk about music this year because I talked about chemistry last year. The two are naturally associated in my brain for some reason. Of course, all music can be viewed as better living through chemistry - brain chemistry that is. Here, have some neurotransmitters. [Plays music] Feel happier? This talk will mostly be auditory, but for you people who are visually oriented I have a sop. I have some new tokens that we'll be adding to Perl. Actually, these are some of the Unicode characters that are in the process of being approved up in the surigate area, but, you know, UPSA can handle that. No, I can't wait until I can overload some of these as operators. I'm not entirely sure what "dollar A trill dollar B" would mean, but it will do something to your neurotransmitters.
But neurotransmitters aside, chemistry and music are also associated in my mind because, although I eventually graduated in computers and linguistics for my first two years in college, I was pursuing a double major in chemistry and music. Kind of the story of my life that I've always been interested in too many things. Jack of all trades and master of maybe one, I don't know. Anyway, I've uttered that phrase chemistry and music so often that it's almost a Pavlovian response. "Hey Larry, you talked about chemistry last year. What are you going to talk about this year?" [Sound of bell] Slobber, slobber, slobber. I'll talk about music.
It wasn't until three days ago, though, that I actually sat down and asked my left brain, "Why do you want to talk about music this year?"
"Dah, I don't know. Ask my right brain."
"I am your right brain, stupid."
I think part of the answer is that I worry about how Perl culture is going to grow up. If any of you have kids, you know that kids are complex and they get more complex as they get older. Fortunately, there's only so much complexity that any one kid can hold and either they eventually go insane or, if you're really lucky, they go sane. Even so, understanding any individual completely is impossible. The Perl culture is composed of many people and so the complexity of Perl culture can grow without bounds. No one person can understand Perl culture completely. If the complexity of Perl culture is going to continue to grow beyond the ability of any one person to fathom, even me, how can we continue to think constructively about it? I believe that we must learn to apply constructive analogies from other systems that are too complicated to understand completely. On the one hand, we can pull ideas from those scientists that have had to deal with overwhelming complexity, such as chemistry, biology, neurophysiology and so on. On the other hand, the more humanistic pursuits have always been overwhelmed by complexity, whether you're talking about sociology or political science. You can study literature all your life and not even read everything you're supposed to read, let alone what you want to read.
Music is the same way. Many of us know thousands of songs or musical pieces, but nobody can know them all. Even if you could somehow combine all the songs that are currently playing somewhere in the world, it would just come out as pink noise. Terribly musical. And that's exactly how your brain feels if you've read too many Perl mailing lists all at once. Only God can hear all the songs that are being played simultaneously and only God can read all the simultaneous mailing lists, newsgroups and Web sites of the world. Pretty soon, only God will be able to understand the CPAN. As humans, we have to simplify. In fact, we must oversimplify. We all specialize. We can focus in one style of music or on a particular piece of music or on a particular instrument. We can focus on rhythm or harmony or melody. We can focus on any of the ways that music affects our moods, whether tied directly to words or subtly as background music in a movie or background music in an elevator. We can focus on any of who, what, where, why, when or how. On a good day, we can focus on several things. But, we can never focus on all of them. So for the rest of this talk, I'd like to oversimplify Perl culture by looking at it through the lens of music culture.
Now the problem with music culture is, of course, that although it makes a nice analogy, it's also too complicated to talk about or even think about. So I brought along a few props. You can think of them as extension modules. Extension modules come in all shapes and sizes. Of course, you can program without extension modules. Those of you who have evolved far enough to have opposable thumbs have a built-in percussion instrument. [Snapping fingers] OK, that's a snap, of course. With a little work, you can develop a crackle and a pop as well. To do the crackle, you first learn to snap twice with each hand and then you combine them in sequence. OK, that's your crackle. To do a pop, you just make a little resonant cavity with your hand and you go [popping sounds], something like that. And then you get, you know, [sounds of snapping and popping combined], things like that.
Long, long ago at a campfire far away, somebody discovered that pigs have spare ribs. At least they're spare after all the meat is gone. Well, at least the pig doesn't need them anymore. Now, if you work these just right, you can get a kind of a triple rhythm. You know, they say it's all in the wrist. [Sounds of triple rhythm] Well, I'm going to have to bone up on that. [Drum & cymbal] Here's a more intuitive interface. These are called claves. At least these would be called claves if they were from Spain, but they're not. They're from Papua-New Guinea, so I have no idea what they're called there. I've asked various people from Papua-New Guinea what they're called and they have no idea either. They're probably called about 750 different things, since that's about how many languages there are in New Guinea. Every time you go over a hill the next tribe speaks an entirely different language. It's like being in your typical computer science department where every professor wants you to learn their favorite computer language which is different from the other 750 favorite computer languages of all the other professors. I suppose you could think of these as opposable sticks, though, in the history of our species, sticks have usually been opposed to crania.
Eventually our ancestors got tired of grilled spare ribs so they figured out how to boil pigs. Not long after that, they discovered soup. And not long after that, they invented the spoon. Technology was developing really fast back then. Anyway, shortly after they invented the spoon, they invented two spoons because that way they didn't have to share. [Sounds of two spoons] Now, this module is actually rather awkward to use, kind of like a Perl 4 module. That's the same sort of, well, you know, I've got a better thing. Here's the Perl 5 version of the same module. [Sounds] OK, I am going to move this over. We have the technology. [Laughter] We don't need the technology. [Laughter] OK. Now we're missing the technology. OK.
OK, back to our regularly scheduled program. This is the same sort of noise you get when two people butt heads against each other in Perl 5 quarters, you know, bonk, bonk. That's what oppositional behavior sounds like. The entire field of percussion is based on oppositional behavior - two objects trying to occupy the same space at the same time. So this is definitely an object-oriented module. You notice the relationship between the two spoons has been encapsulated so that the user no longer has to specify it explicitly. Actually, this is the second version of this module. Unfortunately, one of my kids broke the encapsulation on the first version. But, in fact, all percussion instruments are object oriented. After all, they indicate the rhythm, right? And rhythm is object oriented. You look like you don't believe me. Rhythm really is object oriented. Surely you've all heard of the rhythm method. [Laughter. Drums and cymbal.] Furthermore, you'll note that people who use the rhythm method are frequently members of the Lamaze class. [Laughter. Drums and cymbal.] Personally, I've been through three Lamaze classes, so has my wife. Now, many of you know that we have four kids. For our fourth kid they told us not to come back, since it was obvious we already knew all there was to know about heavy breathing. Actually, the Lamaze techniques are an interesting application of rhythm for the purpose of distracting the participants with pantings of various sorts. "OK, honey, now do sixes, twos, threes, sevens, and fives, not necessarily in that order." "Nurse, take my husband, please."
In the abstract, rhythm is about even programming, kind of like a Geiger counter. Here's our current background radiation. [Sounds.] Here's if you sit too close to the TV in your hotel room. [Sounds.] Those of you who know Morse code probably know what that said. I don't. If you don't care to sit too close to your TV, just move to Boulder or stay here and wait for the Diablo Canyon reactor to melt down. Random events aren't really all that interesting, however. It's get more interesting when you program which events happen when. [Sounds] You can do all sorts of, don't do that - [Sounds.] Enough of that. Other than little games like that, there's really only one sound that spoons can make. The conga drums, by contract, provide a richer interface. You can think of the interface as parameterized in several different dimensions, most of which are infinitely variable, but for all its richness, it's still an event-driven module. Perl also has an event module and it's maybe a little more portable than these, but it could use a little more work on that. But you can do some various interesting event loops on these things. [Conga drums] Now as a linguist trained in Tagnue, I tend to think of these things in terms of fields, waves and particles. Harmony is a field while melody is a wave. I think of rhythm as particles where the events are the points at which things happen. Actually, it's the events themselves that are particles, but rhythm is a higher level of abstraction, sort of connecting the dots in our head. So event questions start with "when?" while rhythm questions tend to start with "how often?" like, "How often should we have a Perl conference?" [Rhythm] "How often should we have a Perl Whirl cruise?" [Faster Rhythm - Laughter] Actually, it's like this. [Rhythm] It's a three against two rhythm, a sort of hemiola. You know, the Perl Conference is once a year, while the Perl cruise is scheduled to be once every 18 months, which gives you three beats in one hand to two beats in the other.
Here's three beats against four. [Rhythm] Here's three against five. [Rhythm.] If you want to figure these out for yourself, it's really just a bit of math. Multiply the two numbers to find out how many subdivisions you need. With three against four, you need 12 subdivisions and with three against five, 15, and you just chart it out.
Now, in reality the rhythm of Perl culture is more of a fractile with many smaller interactions for all of the larger ones. You know, here's the Perl conference. [Rhythm] All sorts of stuff going on in the interest of these. But, speaking of fractiles, I noticed an interesting thing about the rhythm of releases. As the size of the Perl core and libraries gets bigger, it takes longer to rev a major release, so it naturally gets slower. Perl 1, Perl 2, Perl 3, Perl 4, Perl 5. [Sound of beat on drum gets slower] Then we start getting subreleases and then they get slower. Then we get sub-sub versions, and they get slower and slower. Eventually the subversions are taking as long as the original Perl 1 - Perl 2 thing, but that's because they are actually accomplishing just as much. Anyway, I just thought that was interesting. In compensation - up until now, we've seen instruments that specialize in rhythm, which is a particle effect. In contrast, there are other instruments that specialize in harmony and melody. Here is an auto harp. You know, it's always on the wrong side. [Harp sounds] Well, you push buttons and you get harmony. It's almost a pure harmony instrument with a little bit of rhythm on the strum a little.
But harmony is an abstraction, a construct we manufacture in our own minds. Unlike rhythm, harmony is spread out in the pitch dimension and behaves as a field. By that, I mean it seems to fill space in a way that neither rhythm nor melody does. You can play rhythms and melodies simultaneously and they tend to keep their individual identities. But if you tried playing two chords simultaneously, you either get a different chord from either of them or you just get mush. Interestingly, you can't actually add two chords together on an auto harp because an auto harp builds harmonies by subtraction not by addition. You know, it's like trying to mix paints when you ought to be mixing light, and the more you try to mix the less you end up with. So we [Harp sound] subtract the most to get what we want and we subtract - we get fewer and fewer notes. Eventually we get no notes and that's not the way to make harmony. To actually mix harmony you need an additive device like a keyboard. [Sound of electronic keyboard] Something else again entirely.
We talk a lot about harmony in Perl culture and actually we yell at each other a lot about harmony and Perl culture, but it's very harmonious yelling. Remember that harmony tends to monopolize your mental space, but that's kind of an illusion. It's easy when you hear two people arguing in a public forum to think that the entire whole forum is bogus, but if you look carefully there's usually still a background of nonfighting going on as well. Normally people fight all the time. It just seems that way when we try to fit too many notes into the same mental space. You don't actually have to harmonize every note everywhere all at once. We have different locations. Different chords can happen in different places. Different pieces have different standards for dissonance and that's fine. Maybe a Perl friend's mailing list would be like Mozart and comp.lang.perl.misc is like Schoenburg mixed with John Cage with Metallica thrown in for good measure. Well, five quarters is slightly more civilized. It's a bit like late Mahler where part of the time the music is atonal and tortured and the rest of the time the music is tonal but still tortured. Actually, I like Mahler an awful lot. He's my favorite composer and this is no coincidence. Mahler once said he always tried to put the whole world into each of his symphonies. Know also that my favorite author is Tolkin, who also put an entire world into his work, so perhaps this is kind of natural that I try to hook up the entire world to Perl one way or another. Of course, you can't have the whole world in one spot without accepting a certain amount of dissonance.
But there's another form of abstraction which we call melody. In some ways, it's the most mysterious because, in fact, it really is object oriented and in a deep way. A melody is a sequence of notes that we perceive to have been played or performed by a single object, which we often call a voice even if it isn't one. Object permanence is something we learn at a young age. That's why we play peek-a-boo: to figure out that mommy didn't actually disappear when she went behind the towel. Similarly, you can take temporally separate notes and creatively imagine that they came from the same instrument. How many of you have ever played the computer game The Seventh Guest? You may recognize this melody, which is permanently burned into my personal E-prom. And then you solve that particular puzzle. I hope I didn't give anything away. That game intentionally makes it really hard to follow the melody since it treats the notes as discreet, but some instruments make it really easy to follow a melody by making the transitions continuous.
Life is always interesting, isn't it?
OK. Wonder how you play one of these things. Actually, you need a double inflection point, a double inflection here, or a double curve and you find the inflection point in the middle, maybe. We'll try for "Mary Had a Little Lamb." [Plays something - laughter] Wow, learn something new everyday. Now, I don't know who first came up with the idea of playing a saw. It's not what you would call obvious. On the other hand, some things are so obvious that if one person didn't invent it, the next person would. For example, whistling. [Whistles "We Wish You a Merry Christmas"] Another rather obvious invention I think is the bottle whistle. [Whistles in bottle] Perrier works really great for this. As W. C. Fields once said, "I'd rather have a bottle in front of me than a frontal lobotomy." Actually, a bottle in front of you doesn't have a lot to recommend it either. In particular, the melodies you can play with this module are rather monotonic, not to mention monotonous. Here's "The William Tell Overture" on the bottle. [Plays bottle] Other wind instruments can at least vary the pitch parameter, but most wind instruments are by nature melodic in that they can only produce one single note at a time. There are exceptions, of course. Take the bagpipes, please. I don't think the bagpipes are an obvious interface either. I don't know whether playing your hands would be considered obvious or not. I don't know why but you have to wet your whistle to do this. It doesn't make sense to me. [Whistles hands] I discovered that one by accident myself. One day I was leaning on a table with my hands folded and I just happened to blow in my hands suddenly to warm or something. [Tries blowing] Can't do it anymore, can I? [Tries blowing] Well, this is actually the hard way - with your fingers interlaced.
Now, but this actually illustrates a very important musical technique. One that many of us have had to learn repeatedly. Oddly, this technique is called unlearning. It's like back-tracking in real life. Sometimes you have make negative progress in order to go forward in the long run. For instance, when I started taking private lessons on the violin, I had to unlearn a year's worth of bad habits I'd picked up in school. Now in the case of playing of my hands, I had to learn to hold my hands a different way if I wanted to have greater pitch range. So once I'd relearned how to play my hands, I could get almost an octave. That leaves out "The Star Spangled Banner," but there's lots of melodies that will fit into an octave. [Plays hands] I almost have that octave. Let me tune it up here a little bit. [Plays hands] Which is, of course, "How Much Is That Camel in the Window?" Of course, you can do much the same thing with an extension mechanism that's official. Anybody want to play the box? [Plays something] Easy does it, Larry. [Plays something] One and three. Thank you. This is my wife's. [Plays.] OK. Obviously, that's my main instrument. And certainly one of the most obvious wind instruments is your voice, at least we certainly produce a lot of wind with our voice, but - no, I'm not going to sing anything operatic for you and, although I'm preaching to the choir, I'm not going to make you sing either. That should play something on my computer. We have ways to make you talk. [Computer sings "Allelulia"] Hey, a percussion instrument. Yeah, I know. I'm a sound engineer at my church, I'm allowed to do that.
Anyway, but you'll recall that melody is an abstraction of object permanence. As I mentioned earlier, these instruments call such an object a voice whether it's a really a human voice or any of the other instruments, but the really interesting thing to me is the relationship of melody to harmony and it has to do with what we call voice leading. Here's a guitar. You can play the guitar in many styles, but the most notable feature of the guitar is how much it's used for harmony rather than melody regardless of the style. I don't want the pick yet. [Plays guitar] You know, that's a little more Spanish. Here's something else. [Plays guitar] Something like that. [Applause] Of course, if you're a classical guitarist, you'd do a lot of melody, too, but the very basis of harmony is all the little melodies going on in the middle of the chords and you can actually hear the little waves in there if you listen. You can hear a chord change. [Plays] But you hear things like this happening in the middle and things like that - little voices - and so the harmony is actually, in a reductionist fashion, it's just a bunch of little harmonies, but holistically, melodies. But, holistically, you don't perceive it that way. It's perceived as a field, you know, so when you hear chords, you don't actually hear the individual notes here, you somehow intuit the whole - whatever it is.
You ever notice that music is sometimes hard to talk about? I never have any trouble talking about Perl. Anyway, the bottom note of a chord is kind of in a privileged position. It behaves more like a melody of its own, but it's a funny kind of melody in that it's perceived to drive the rhythm and the harmony. If you take the bottom four strings of a guitar and drop them an octave, you get one of these. [Shows something] Yeah. Got to get the slouch right here. Ready? [Plays something] Now, some of you will think that that's "Mission Impossible," but that's actually "Man from Uncle," which was my favorite show when I was young. Here's "Mission Impossible." [Plays] Recognize that? Bass guitar is really fun even if you're not good at it. Sometimes I think I'm the bass guitarist of Perl culture. I play the strange melody and then a whole bunch of other people start playing these strange rhythms and harmonies around me, but now I'm going to go back to hitting things again. This is what is known as a hammer dulcimer. It actually belongs to my wife, whom I like because she lets me borrow her things. The one thing about this that is harder on other instruments, especially wind instruments, is it's actually multithreaded. It's the beginnings of multithreading. It has two separate threads of control, so - [Plays] What shall I play? OK. [Plays] Nope. [Plays "Oh Suzanna"] OK. [Applause] "It rained all night the day I left, the weather was dry. Got so hot I froze to death, Suzanna, don't you cry."
Musicians delight in contradictions, but so do language designers. You have to be able to see both sides of every question when you design a language. It helps to have multiple-personality disorder. It also helps to have a multithreaded interface like the piano. [Plays "Oh Suzanna" on piano] You know, a piano is just a fancier interface for a dulcimer in a way. It still has hammers - a real piano does - that go out and strike the strings in another form of oppositional behavior, but it's a percussion instrument, in other words, but it happens to have a pitch parameter as well. It also has a more developed multithreading model. It supports up to 10 threads in two groups of five. Advanced implementations can handle 20 threads, but that requires two CPUs. You know, I'm afraid the piano module must still be considered experimental.
Still, the interface is somewhat user friendly. [Plays "Chopsticks" on piano] Etc. I don't actually have time to talk about counterpoint, except to say that this simple tune illustrates two contrapuntle principles we see in the Perl community: contrary motion and parallel motion. Contrary motion is when you have two programmers, or that is melodies, going in opposite directions. [Plays] Parallel motion is when the programmers agree on how to get where they're going. [Plays "Chopsticks"] Actually, I joked about it being experimental, but the piano interface is actually one of the most standard interfaces we have. Unfortunately, organs are not so standard. Once you get away from the keyboard itself, how you set one particular stop really depends on the kind of organ you have. In pipe organs, you might pull out one of the stops puller-outerers. On a Hammond organ, you might just adjust the draw bar. On this organ, I push D-35. [Plays organ] You got to love Bach. The next time someone says Perl is baroque, thank them for the compliment. [Plays organ]
They say it's easy to get a composer out of bed in the morning. All you have to do is go over to the piano - or the organ in this case - and play an unresolved chord and then they have to get out of bed and resolve the chord. [Laughter] It's hard. I can't stand it. [Plays] Now, I promised I'd bring my violin and, as you can see, I didn't break my arm in Aikido, so I guess I'll have to play it some. The violin is one of those traditional standard instruments. As I say, nobody ever got fired for buying a symphony orchestra. But, if you did get fired, your orchestra can play for you. [Plays violin] That's very sad. There's lots of happy music, too.
But, a violin is actually two different instruments and I actually brought it here to illustrate polymorphism. People ask what's the difference between a violin and a fiddle. There's no difference really, it only depends on which class you call the method from. Here's the fiddle interface. You just choke up on the bow a little bit here and a - [Plays fiddle] [Applause] Funny how people who claim to be tone deaf can nonetheless recognize various styles of music when they hear them. Our pattern-matching capabilities are usually much better than we admit. In fact, Perl's design banks on that. That last little bit of music actually can stand on its own. [Plays] That's usually known as "Shave and a Haircut, Two Bits," so music also has its one-liners.
Here's another piece known as "The Mouse Trap Concerto." [Plays one note] [Laughter and applause] Actually, I've played a lot of serious music on my violin. It was my privilege to spend six years in the Seattle Youth Symphony under the direction of Wilhelm Sokle. There wasn't anything that we couldn't play, but we just had to work at it a little longer than a professional orchestra would, which reminds me of Perl development sometimes. One thing I learned while playing in various orchestras is the importance of faking it. You have to be able to fake playing an instrument before you can really play it and I'm faking most of these instruments. My whole first year in the youth symphony I was petrified that I might get called upon during rehearsal to play a part that I wasn't ready to play. Fortunately, I was never called upon. My second year I made a startling discovery. I just learned the music thoroughly and then I didn't have to worry about whether anybody called on me to play it.
How does this play out in Perl culture? Well, we have to be willing to let people fake it for a while. If Perl is getting their job done, then that's fine, but we also have to find ways of encouraging people to upgrade their abilities when they're ready for that step, and we don't do that by beating them over the head. We do it by showing the positive benefits of learning Perl for real. You know, I probably could have actually been a professional violinist. Had I been only interested in music, I might have been, but then I wouldn't be up here waving around a violin at you. But I'd also like to use this violin to illustrate reusability. [Plays portion of "William Tell Overture" on violin] Or something like that. Well, I don't think William Tell would have minded the Lone Ranger using his music, but when I was growing up there were still cigarette commercials on TV and sometimes you heard, "Have a Lark, have a Lark, have a Lark, today." Later on it was "Have a pizza, have a pizza, have a pizza roll." I'm sure William Tell would just love to shoot a pizza roll off of someone's head.
Finally, I'd like to finally introduce officially my synthesizer here, Korg 5S, meet Perl hackers. Perl hackers meet Korg 5S. I've been pretending it's a piano and an organ and any number of other things, but it's really just a bunch of switches and oscillators and such. Like Perl, it can be viewed as a tool that got out of hand. Like Perl, it can be viewed as just another tool in the toolbox as well. I joke that the piano interface was experimental, but this interface really is experimental. The keyboard interface is pretty standard, it's an awful lot of fun to use this thing in its current state, kind of like Perl. It does a pretty good job of emulating some other tools in the toolbox. For instance - [Plays on keyboard] - easier here than there, unless you're my wife. She does this easier here too. Now I'm going to get in trouble. The thing that is really cool about this keyboard is that it can play various different styles of music, Tim Tody and all that. My favorite button is the one that locks in the different styles into the same tempo so that you can go from one style to another and see how the same tune sounds in different cultural contexts. For example, how would "Pachabel's Canon" come out if it were played by Mick and Keith or by John, Paul, George, and Ringo, or by Elvis? Well, we can find out. [Plays] [Applause] Well, one could go on all day with that.
One of the things we love about Perl is that it supports many different styles of programming. That's something we never want to lose with Perl. There's also just the intrinsic joy in making music that has nothing to do with whether we're using the music for some other purpose. Likewise, there's an intrinsic joy in programming in Perl that has nothing to do with the purpose we're putting it to. That is also something we never want to lose. In fact, there are many features we want to conserve in Perl, but music is continually re-inventing itself and so is Perl culture. Most music is evolutionary, not revolutionary. People don't usually riot over new music - Stravinsky's "Rite of Spring" being the exception that proves the rule, but people don't usually riot over new Perl modules either. But occasionally there does come a time when we have to think like revolutionaries. Someone has to throw the tea into the Boston Harbor. Someone has to decide that it was time to write the document starting out, "When in the course of human events it becomes necessary" etc., etc., but before that someone had to decide to alter the course of human events.
Yesterday, a bunch of us radicals decided that it was time to alter the course of human events. Some of you may have heard rumors of this. So, today, I'd like to announce to the world that the effort to write Perl 6 has begun in earnest. [Applause] And I'd like to use the synthesizer to make an important point. If you manufacture something like this, you eventually come to a point where you say, "This is a really neat gismo, but we can do something better. Do we continue to make small improvements in the current design or do we redesign the interface to let us do what we would really do down the road? And, if we do a redesign, can we keep everything people like about the old design while getting rid of all the things people don't like about the thing they have right now?" Well, that's kind of the state Perl is in right now. We really, really like what we have. We like it a lot, but we can think of lots of ways we can do it better and the things we'd like to do better come in several categories.
First, the language itself could use some revision. I'm allowed to admit that. There are many historical warts on Perl that wouldn't have been there if I'd known what I was doing, but, hey, I was faking it back then. You didn't know that, did you? I'm more of a competent language designer than I was 13 years ago and I have a lot more help these days, plus it's time to steal all the good ideas we can from those other languages that developed in the last decade. One of the things I realized yesterday was that we're actually in a much better position than when I designed Perl 5. Nowadays, we have code back-ins, such as B::B Parse, that can spit out the Perl code corresponding to the compiled syntax tree. If you think about that, it means that it would be relatively easy to make it spit out a closely related language, such as Perl 6.
Perl has always been designed to evolve but now we actually have the capability to be evolving a little faster. This means that for the first time in history we have the opportunity to make some incompatible fixes to Perl while preserving a migration path for the current code. I really couldn't do that when I designed Perl 5. We had to make almost everything upward compatible, or backward compatible, whichever one it is. But now it's the first chance to make that sort of changes and, since it is the first chance, it probably is also the last chance, so I think we should. Of course, we are not interested in breaking things just to break things, but I'm sure you can think of things you might have done differently. Myself, I really wish I'd made the system call return "true" on success rather than "false." I wish I'd made local time return the actual year and not the year minus 1900. I'd really love to throw out select file handle and there's general consensus that type gloves may have outlived their usefulness, and a number of simple but potentially powerful features have already been put on the table for consideration. That's not to say we're going to do all of them. My overriding goal for the redesign of Perl's language is that easy things should stay easy, hard things should get easier, and impossible things should get hard, as it were.
Another place we'd like to do better is in the implementation of the language as opposed to the language itself. I think I did a pretty good job with the design of Perl 5 and making it extensible at the language level, but the internal APIs necessary to write extension modules could really use to be cleaned up. Some of you may have noticed that. We could scrap Excess for something better, and, of course, we want the chord to be smaller and faster, always. I'd like to run Perl on my Palm, but perhaps more importantly we could design the extension system so that installing a new version of Perl doesn't break all your existing extension modules. We have many other ideas for improving the implementation as well and these will come filtering out, but neither language changes nor implementation changes will happen unless we also reinvent how we do things.
So we've already started a redesign of Perl culture, trying to keep the good aspects and leaving behind the nonproductive aspects. We intend to abandon the Perl 5 porter's model of development, which demonstrably leads to a lot of talk but little action. Instead we'll break down the design of Perl 6 and the maintenance of Perl 5 into manageable tasks given to meaningful working groups with meaningful charters and meaningful goals. We have collectively resolved to make these working groups work, and where they do not work to work at making them work until they do work. We will continue to refine all aspects of our development model until every itch is scratched as efficiently as possible.
We are really jazzed about this. It is our belief that if Perl culture is designed right, Perl will be able to evolve into the language we need 20 years from now. It's also our belief that only a radical rethinking of both the Perl language and its implementation can energize the community in the long run. In the long run means 10 and 20 years down the road. Finally, it is our belief that Perl 5 will be better supported than it would be if we merely tried to guard what we already have. The best defense is a good offense. Now, this is not going to happen quickly. We expect to have alpha code a year from now, or some definition of alpha. We might even ship it, but we expect it to be well-designed alpha code.
In the meantime, we are not abandoning Perl 5 anytime soon. We all like Perl 5 a lot. We all use it a lot. Many commercial interests will guarantee that Perl 5 continues to be well-maintained and stabilized for quite a few years to come, and we fully expect, given the history of Perl 4, that five years from now a lot of people will still be using Perl 5. We do expect the rate of new development in Perl 5 to taper off, of course, and that can be viewed as a feature, but no, open-source software specifically rejects the get-big-quick philosophy of the typical Web startup. Such rapid growth tends to fragment the culture and, in the long run, leads to ruin. Instead, we intend to proceed at the fastest speed at which we can efficiently propagate our cultural values to newcomers in our culture, but no faster. This is the healthy way forward and the only way to compete in a competitive space.
We have to be better, not just get there faster. Part of being better is making sure the stragglers don't get left behind. We are determined to do the right thing by everyone. To this we pledge our lives, our fortunes, and our sacred honor, as it were, what there is of it. Many more details of our plans will be coming out in the next few days and weeks, and we'll tell you who has taken responsibility for what. We'll set out a road map or chart if you're into music of where we'd like to be when. Look at www.perl.org for more as time goes on. Things should be showing up there today even. But right now I would like to call each of you to play your part, whatever that part is. You, yourselves, are individual melodies. Your being here today may be an event that changes the course of your tune. Certainly your being here with everyone else who is here today makes a kind of harmony, a lost chord that will never be played exactly the same again. Together we perform a contrapuntal jazz improvisation that can only be recorded imperfectly. Music has always been an ephemeral art, and even with CDs and DVDs people still go to live concerts. So remember, you were here when a new thing was born.
Every Perl conference is a cool event because Perl people are the best people in the world. In this age of mailing lists and Web pages, it's really nice to get personally acquainted with all the folks that you've met on the Net. But this conference is not just about getting together with your buds. It's also about finding new friends, forming new bands, creating cool new sounds, maybe landing a recording contract on the CPAN. Sometimes it's about more than that. Today it's about more than than. We're really serious about reinventing everything that needs reinventing. The way I look at it, Perl 5 was a composition largely by a single composer - me. It's a fine classical composition, but in essence it's one person's view of how to make music. If you work with Perl 5 you have to follow the score pretty closely. Perl 6 is going to be designed by the community. We're going to be doing some jamming. I'll still be exercising some artistic control over the language itself, but instead of playing off a score, I'm going to be playing off charts now and you're going to be seeing a lot of people improvising melodies of their own and interweaving them creatively in ways that will make Perl 6 much better than Perl 5, just as Perl 5 was much better than Perl 4, and if you know anything about me, you know I take the promised land quite seriously. We're all going to march in there someday. [Plays music.] I'm jazzed. [Applause.]
Narrator: John has very kindly offered to let Larry do a Q&A for the next 15 minutes on the grounds that there is not enough time to cover the full details of how to rebuild civilization after the Apocalypse. Larry would you be willing to do a Q&A?
Larry: If you'll help, I'd like to introduce our interim program manager for Perl 6. [Applause.] Now that we've got that out of the way.
Larry: Is Perl 6 going to be in C++? Maybe. Chip has a lot of experience with thinking about Perl and C++ and we intend to use the lessons he's learned one way or another.
Question: When do you expect the Perl 6 plan to appear and when can we start work on it?
Larry: Well, it will come out in stages. We are, in cultural terms, we are starting working on it already, and over the next month or so you are going to see the chart, the road map, come out and my own personal goal - for some reason, they wanted me to take the position of language designer - of course, I'll have a lot of help on that, but my goal for that part of it - I'm giving a talk at Linux World Expo in Atlanta in October and they wanted me to do a keynote there and I didn't know what I was going to talk about. Well, now I do, and I'll talk about the new Perl and where it's going as a language. The language design is now going to be separate from the implementation design and we've got a number of other positions that we've named names for and you'll see those if you look at the press release, but the schedule is not nailed down yet, but we'll try to act a bit like pointy-haired bosses and do some of that scheduling.
Question: Will Perl 6 have specs and then you could implement something that looks like this, or will it be kind of like now, where the system won't work?
Larry: Yeah. I don't know how strict a spec it will be from the language design point of view. I'm not really big on that sort of spec and there is some value to using the reference implementation approach and what we currently have is a reference implementation will no second implementation, well, unless you count the JVM work, but, obviously there are benefits to having things justified well enough that you could implement another one even if you didn't want to, so we'll definitely be working in that direction and - do you have something? And there was something else I was going to say - what we particularly want to stress in terms of - is not perhaps so much the spec as developing our current regression test. Well, we call them regression tests, but they're almost more acceptance tests, but, we developed our acceptance into real regression tests then you'd further develop the real regression tests into a validation test of what the language actually means and actually go out and explore all the nooks and crannies and say, "This is Perl, this is not Perl," and then we actually have a machine-readable spec. And to me that's actually a lot more important than what the verbiage on the human readable thing says.
Question: I think that one of the problems with the P5P model is the infrastructure of mailing lists tends to push people into a "I say this," "but I say that," "but I say this," "but I say that." Kind of heads banging against each other and not really resolving anything. There's various kinds of work. Horscht Ritter did his Ivis project and there's Wicki's and things like that that are used to try and resolve things and give people a place to put their argument as best possible and then they can move on to something else, so you might want to look into some of that.
Larry: Yes, we're already planning to do some of that. Each working group will have somebody in charge who makes the final decisions. We will have mailing lists which are at least two tiered in that they will have official inner ringers but anybody can listen in and contribute indirectly if they want to contribute to the actual working group - the people who are actually on the working group. We want to have an official RFC sort of kind of mechanism for not just this sort of off-the-top-of-your-head "Oh, wouldn't it be nice if this," "Wouldn't it be nice if that." If you have a real proposal for a feature, make an official proposal in an official place with all the things that make it an official proposal, and, you know - I guess that's it about that one.
Question: Thank you for taking on this endeavor. Can you hint at any language changes that you're considering?
Larry: I hinted at some of them. Everything is negotiable, but everything will not be traded away. On a philosophical level, I have the profound feeling that if I like something, other people will like it and if I don't like something, other people probably don't like it so much, and so I really trust my instincts on where things will be going. I'll be getting a lot of feedback on that, too. We've been getting a lot of feedback for the past 10 years on things that people think are kind of grouty. For instance, there's really no reason why formats should be in the core anymore. They should be a, you know, come in as a module. There are things that could be done perhaps to clean up ambiguities and indirect object impacts. Basically what we are saying at this point is if we are going to bite the bullet and require translation of Perl 5 to Perl 6, that really means that we can consider anything that still allows us to translate most scripts. Now we do not expect to be able to translate a 100 percent, but if we can translate with 95-percent accuracy 95 percent of the scripts, and 100-percent accuracy 80 percent of the scripts, then that's getting into the ballpark, but on the other hand, sometimes you have to break a few somethings or other to make an omelette. Other specific features, can you remember any of the ones we named?
Question: One of the problems with language translators is you lose all the comments and formatting and things like that.
Larry: Not the Ox to Perl translators. I wrote that.
Audience member: Well, can you make sure that will be the way it works in the Perl 5 to Perl 6.
Larry: It may, it may lose some of the formatting information, but there's ways to annotate a syntax tree with additional information. And if we have to get a little incestuous with the compiler and turn off certain optimizations to get a more pristine syntax tree to translate that -- lots of things like that can be done. This is subject that -- I enjoy doing things like that, so I don't think you need to worry about that not getting done reasonably adequately.
Question: I somewhat disagree with your bracketing and indentation style, but respect your right to observe your particular religion. With the automatic language translation that you're having, will I have, within reason, the ability to observe my religion? How long have you been thinking about doing this? How long have you been stewing on it?
Larry: Since yesterday.
Audience member: Are you contemplating any changes to Pod?
Larry: Everything is negotiable.
Audience member: You said you wish to steal from some languages. Which languages in particular over the last decade?
Larry: Cobalt. Identification Division. I always wanted an identification divisioner. No, really, I don't want an identification division. The problem with identification division is it really puts a crimp in Perl's poetry, or in Cobalt poetry. How many poems can you start off identification division? One. What's your favorite language, besides Perl? You know, lots of languages do more of a byte code thing. Some of these things, a lot of these things are not borrowing from a specific language. There's multiple languages that use the byte code thing. There's various languages with a cleaner object interface to their IL and such. There's lots of languages that, I don't know, do various things, but we - when something like - when you see all the new languages coming out and they all have a garbage collector and that helps them fit together into browsers and things like that better, you start thinking, maybe we ought to think about that.
Question: Larry, more and more people, of course, are using Perl today to write larger and larger software. Is there anything in Perl 6 that you can think of off hand that might make that easier? Large software tend to have - tend to appreciate things like stronger touch up checking, for example.
Larry: Yes, certainly. We already got the hooks in there to start putting some things in there optionally, and you could have used strict-type checking if you wanted to or you could use Stricter or something. You can use bondage and discipline - whatever you want to call the module. Also, as part of the redesign - here's a biggie - we intend to get rid of quite a few of those strange global variables or the strange one. We will certainly get rid of dollar sharp.