A conversation with the founder of the Perl programming language

Larry Wall:  My name is Larry Wall and I am variously known as a husband and father and as the creator of the Perl programming language and to some people, sort of a cult leader in the sense that Perl is a culture, a vibrant culture, with many people involved in it, and I feel it's my obligation to help people understand how a culture can surround a computer language and the culture and the language reinforce each other in a positive way.

Question: How would you explain what Perl is to a non-programmer?

Larry Wall: Well, people have ideas of what programming is like from the movies and such, but it's not really much like that.  Perl is what we call a scripting language.  It's for doing ad hoc things and just one-off things that you really wouldn't almost think of as being programming problems.  It's a language that is kind of like, you might think of writing a, you know, a ransom note and you're going to grab a newspaper and clip it into little pieces and so you want to find the right text really quickly and then you want to have some way of gluing it all together in the right order and that's kind of what a scripting language is good at, it's good at taking text and gluing it together.

But more than that, I mean, there's many scripting languages in the world, Perl is a little bit special because it is based more on some ideas from the way natural languages work.  My training was in linguistics, as well as computer science, so I've tried to make a language that works on a deep level, like human languages work.  You don't have to know the whole language to use it usefully, you can do baby talk, you can do grown up talk, you can cuss in it, you can write poetry, you can be a playwright, is sort of the idea.

How you use the language is really based on things that are external to the language itself.  So many computer languages try to force you into one way of thinking and Perl is very much the opposite of that approach.  It's kind of like a, well, sometimes Perl has been called the Swiss army chainsaw of the internet, but it's more like a Swiss army machine shop.  It really gives you a lot of tools, some of which are dangerous, but it lets you get your job done very quickly.

Question: How is Perl a “post-modern language”?

Larry Wall:  Well, the way I think of post-modernism, there's, post-modernism, of course, is about having many different views of something; it's about, you know, some people think of it as tearing down the power structures.  But in my experience, the post-modern movement has mostly been about not getting hung up on one particular idea or way of doing things, like modernism tends to do, and instead, sort of picking and choosing from different historical eras—I'm thinking more of architecture, where you can see different architectural features that the architect has used, just because they think they're cool and they can combine, you know, classical and romantic and baroque even, different ideas, and even modern, sure.  But you pick things because they're cool and because they'll be useful, not because somebody says this is the only way to do things.

And so Perl is very similar in the way it has collected features from other languages, things that seem to be distinct ways of doing things and finding a way of meshing those in a pleasing fashion—the same way a poet might take words that are very different from each other and mesh them into a coherent poem. Perl, in that sense, is very, very much, it doesn't have an agenda and it really is not trying to tell you how you're supposed to do your job, it just tries to get out of your way as much as possible. 

Question: Is Perl a good first language to learn for aspiring programmers?

Larry Wall:  In a sense, it's a good first language.  I've known people who learned it as a first language successfully, but that's not its primary purpose.  There are languages that are designed with the purpose of being a good first language, but they tend to run out of steam about the time your programs get interesting.  I think of Perl more as a last language that you would want to learn, that while Perl is like a human language and that you can start with baby talk and you're not expected to, you know, we don't expect a 50-year-old and a 5-year-old to speak with the same diction.  That's fine.  But we expect that when you need to know something, you can learn a new thing and the resources will be there for you to learn as you go.  So, it can be learned as a first language, but we really concentrate on having an expressive language, not an easy-to-learn language.  And sometimes an expressive language is a little harder to learn, but we think it's worth it. 

Question: Did your study of linguistics play a role in Perl’s development? 

Larry Wall:  Yes, it did, indeed.  My linguistics training...I wasn't intending to write a computer language when I took the linguistics training.  It was really, my wife and I were actually intending to be missionaries, so it was very practical linguistics, in terms of field linguistics.  We were going to go out and learn a language that had not been written before and produce a writing system for it and do translations into the language, but I developed a bunch of health issues that prevented me from doing that.  So instead, I went on into industry and used some of my computer skills, but my interest has always been in the way languages work and I written compilers before Perl, and so when the time came that I had a problem that I couldn't solve with any of the tools I already had, I just said, "Well, I can do better than that."  So I took some of the ideas that I had used in my previous languages and I took ideas from other languages and I shoved them all together in one spot and I, then I decided, "Well, I, you know, this isn't just for myself, I'd like it if other people used what I do," so I sent it out and other people liked it to, and it just grew from there.

But the design all along has been to pull things together in almost a random way, the way in natural languages, you know, English pull stuff from Viking and French and Anglo-Saxon and what have you, even a little Japanese in there—a skosh.  But the say a natural language is put together like that always fascinated me and so I'm interested in, not in a shallow linguistic sense, you know, the old Cobalt language sort of had stock phrases that you plugged things into it, that was sort of cargo-cult natural language.

Perl is more on a deep, fundamental level, how do people use language, how do they expect it to be extended, how it would evolve over time, who gets to contribute to the changes in the language.  All these on a deep level, Perl is much more like a natural language than most computer languages.

Question: How are human languages and programming languages similar?

Larry Wall:  Well, human languages tend to be much more ambiguous than computer languages because humans are much smarter about interpreting the context.  So there is a scale of how much a computer language resembles human language and primarily based on how much context is involved.  If there's very literal context, it's very literally, there's some computer languages that are like that.  And then other languages know a little bit more about, you know, what has been stated earlier in the program, or what the immediate surroundings are in the program, and Perl kind of takes this to more of an extreme, not as far as human languages, because no computer is smart enough to understand human speech in that way, yet.

But they are all, you get things happening that happen the same in human languages: you get dialects, you get languages that get smooshed together so you get Creoles and pidgin languages.  And you get languages that you think ought to be understandable to two different people, but they aren't.  You get languages that have the same name, but are different from each other.  You get languages that have different names, but are really essentially the same language.  So all the processes that happen as natural languages evolve through time, it happened in computer languages, too.

Now, there are some other differences.  Natural languages generally are not designed by humans, they're just designed by the participants and you say something new and somebody else says, "Oh, that's a cool way to say it," and the next thing you know, everyone is saying it because it's shiny.  There's one.  But computer languages tend to have explicit designers, but if a computer language is well designed, the computer language designer stays out of the face of the programmer and gives the programmer ways, various ways of having the flexibility that they would have in natural language, to pick one way of saying things or another.  And to the extent that they can give that flexibility, sort of give an artistic medium to the programmer to be creative, to that extent, people can take great joy in writing a computer program in the same way they might take great joy in writing a great poem or a play.

Question: How do Perl developers differ from developers of other languages? 

Larry Wall:  I think by and large Perl developers are more social; they really believe in community in the way that many other developers do not.  I'd like to think that I've encouraged some of that by my talks and by trying to show by example.

But really, I think they think of themselves as artists.  Perl is  not really so much a way of trying to think like the computer, which most other languages tend to encourage, but it's more like an artistic medium, and it's a set of paints and a canvas that you're allowed to sort of do whatever you like and try to please the other people.  And the only judge of whether something is good or bad in the Perl community is whether the rest of the community likes it or not.  But people are really, really motivated by this and Perl has more shared software, shared modules, that people put out there for other people to use, than any other computer language.  There's about 18,000 modules, last I counted—well, I didn't count them, I just looked at the number—and, like any collection of programs or any collection of anything else, they all follow what's known as Sturgeon's Law: 90% of everything is crud.  But of that 10%, there's just a wonderful selection of ways to get your job done, things that are just crazy.  Let's you program in Latin, they let you program in white space, so you look at your program, and it's just spaces and tabs and you can't see it at all.  It's just lots of fun stuff.

The Perl culture is a culture of fun and we really encourage that and do not think that it is in any way counter to the notion of doing good work.  Fun seems to be something you're not allowed to have in a lot of modern, corporate culture and we think that—maybe this is another one of those post-modern things—you can have fun and do good work at the same time. We really believe that.

Question: Will you appoint a successor to take over Perl?

Larry Wall:  I've thought about that from time to time and generally when I think about who I would appoint as a successor, I don't generally tell anybody and usually by five years later, it would be someone else.  And I don't think there's anyone who thinks quite like me, so I think that really has to be something that needs to be figured out by the community if I get run over by a bus.

I think that I have managed to pass along a number of the principles by which Perl has been designed that even if one person emphasizes this aspect of the design and another person emphasizes a different aspect, they'll be able to work that out.  Hopefully not the way that the four generals worked it out after Alexander The Great.  But I trust the Perl community to do what's good for the Perl community.

Question: Have you made any money from Perl?

Larry Wall:  Well, that depends on how you define it.  I get a few book royalties, but it's not really enough to make a living.  I have received a few grants over my life, but that's also not enough to make a living.  I would say that the real way in which I have benefited from Perl is the way in which many open source authors or creators benefit, and that is that some company will be willing to hire them just to work on that.  So in a sense, I have my current job because of Perl, and I am mostly expected to work on Perl, and also advise them in things that are related to that.

But in a sense, my job is remuneration for that.  They're not going to make a movie out of Perl, this notwithstanding, so I don't expect to have a Harry Potter on my hands. But I'm comfortably well off because of Perl.

There's one other way in which I have actually made some money from Perl.  That's some number of years ago, Yahoo was about to go public and they said, "Hey, we used Perl heavily in everything we developed here, so would you like to buy some pre-IPO stock?"  And I said, "Yeah, sure."  And so I bought a little bit of that stock and that turned out over the years to pay for all my kids' college expenses.  So that sort of thing happens every now and then.  It was very nice to not have to worry about how to pay for their college.

Question: Can you explain the basics of the computer programming in five minutes?

Larry Wall:  Well, I can certainly try.  Computer programming is really a lot like writing a recipe.  If you've read a recipe, you know what the structure of a recipe is, it's got some things up at the top that are your ingredients, and below that, the directions for how to deal with those ingredients.

Well, a very similar thing happens in a computer program.  You have, you list out the various things that you're going to be dealing with, typically, and then you have some instructions that say what to do with those ingredients.  So, if you can understand a recipe and follow it in, you know, in your kitchen, then you can program on that level.  But you can take it a lot farther than that.  Many of you, I'm sure, have seen the Iron Chef show, I love to watch that, especially if they are given strange ingredients. I'm not sure I would like trout ice cream either, but one of the things that happens there, if you follow along, is that the Iron Chef, or whoever the chef is, doesn't actually do all the work.  They have what are called sous chefs, that they farm out, subdivide the jobs to, and they'll do the kind of busy work.  And programming is kind of like that, too.

You are the head chef, but there are bits and pieces of the computer out there that will do things for you.  Now, it's not quite like Iron Chef, because Iron Chef, you have some fairly intelligent sous chefs who know how to coddle an egg or chop up a fish.  But your computer tends to be more like a bunch of really efficient robots, but they're very stupid robots and very literal minded.  So you have to, at some level, you know, tell them exactly what to do.  But once you've told them, that you can just point to the robot and it'll do the same thing over and over and over again, and do it exactly the same.  And computers are like that, that's how they are valuable, they sort of take over all the boring bits of our thinking.

And then you can kind of take it beyond that, instead of just thinking of yourself as the chef that's in control, sometimes you want to program more like you're thinking about how the food actually goes through the process. And maybe even take it up a notch and say, here's a factory that produces some food item—Twinkies, or whatever—and you have raw ingredients coming in—that's assuming you think Twinkies are food—you have raw ingredients coming in, and they go on various conveyor belts and get chopped up in various ways and get recombined and there's this flow of the materials through the factory. And eventually it comes back out with some sort of a product that we considered to be food.

So there's programming languages that work like that, too, that just talk about how the data runs around in the program.  For instance, your Excel spreadsheet: you're putting data into little cells, and you have other cells that say, "Well, just make a little conveyor belt of these cells and add them up in this cell."  You're really doing programming, even if you think you're just writing cell macros.  So that's like a little factory on your desktop there.

Now going beyond that, there's various ways that you can get into, you know, sort of more highfalutin concepts that you would learn if you were taking a computer science degree.  The whole idea of programming on this level is you're saying one thing, some abstract thing, and that controls a bunch of other things.  So the next step that happens is that instead of just thinking about data as the pieces of things you're working with—strings, text, your phone numbers, whatever. You start thinking about those bits of recipe, and those recipes can also be considered data and can be sent around on the conveyor belt in your factory.  So it's like a little conveyor that you might have in your café, you put little things up there that order things up.

So when you start talking about actions and abstracting them, then you can start talking about doing the multiple times and looping and this action may do this action, which may do that action, which might come back and do the thing, and you get a recursive, sort of fractal pattern.  And so these are the basis of the more mathematical views of programming, but you don't have to do all that at the beginning.  You can just start off with the simple recipe idea and add things on as you go and learn as you go.  And then you'll do fine. 

Question: What are the five programming languages everyone, even non-programmers, should know about and why?

Larry Wall:  Oh, boy, that's a really tough question.  It's kind of like asking what are the five countries you should know about if you're not interested in geology, or geography, or politics, and the answer varies depending on what your actual interests are, or what are the five companies you should know.  And the answer changes over time, too.  Back when I was getting started, lo these many decades ago, the answers would've been Fortran, Cobalt, Basic, Lisp, and maybe APL, and those were very formative languages back then and people learned a lot from those, but these days, it might be more important for you to know Java script, even if the only reason you know that is that you know whether or not to click the enable-Java-script button in your browser.  But Java script is a nice, lightweight, object-oriented language and that's why it can fit in a browser and do these things such as run little programs that help you input your data and then send it off to a web server somewhere.

There are heavier-weight object-oriented languages and the elephant in the room is sort of Java, you can't really make a list of modern languages without talking about it.  Java is sort of the Cobalt of the 21st century, I think. It's kind of heavyweight, verbose, and everyone loves to hate it, though not everyone will admit that.  But managers kind of like it because it looks like you're getting a lot done, you know, if 100 lines of Java code accomplish a task, then it looks like you've written 100 lines, even though in a different language, it might only take 5 lines.  You know, it's like, you know, you can eat a 1-pound steak or you can eat, you know, 100 pounds of shoe leather and you feel a greater sense of accomplishment after the shoe leather, but, you know, maybe they're some downsides.

But it also, because it is sort of considered an industrial language and programmers are sort of interchangeable parts, managers like it for that reason, and for that reason, a lot of Java jobs have been outsourced from the United States.

Oh, what other languages?  I think going in a different direction, coming more from academia, we have a language like Haskell, which we call a functional programming language. That means function in a mathematical sense, not in the sense the other languages are dysfunctional.  But a function mathematically has an input and an output and it maps to, you know, with a great deal of mathematical certainty what those are.  Haskell is one of those languages that mathematician-type-minded people love; it's sort of a language for geniuses, by geniuses.  So you should probably know about it, if only to be able to say, "Well, is this kind of like Haskell?"  And if so, then you know you have to hire some really smart people to program in it.  Haskell is sort of a modern kind of Lisp in that sense.

What else?  Well, we can't leave off modern languages without talking about C.  The C language, that’s just spelled with the letter C, is actually about 40 years old, but people have tried to replace C with other languages that are like it and have by and large not succeeded because C is a very minimalistic language and very close to the metal, as we say, on a machine, and lets you get down and do very fine grain stuff, very efficiently, but it's a lot of hard work.  But once you've done that work, you can run it pretty much everywhere.  So almost all the other languages that you see, Java, Perl, whatever, actually if you look down underneath, they're actually implemented in C, or in a closely related language.  So that continues to be a very fundamental language, if only because everyone is trying to reinvent it and not succeeding in doing so.

And finally, for a fifth language, well, you'd probably want to pick one of the scripting languages.  There's several to choose from, there's Python, there's Ruby, but of course, I am prejudiced in favor of Perl, because I think it has the liveliest community and because we have intentionally been redesigning it lately to leapfrog all the other languages. For the last number of years, we've been redesigning it to out all the warts that we've noticed over time.  And we figured it was just our one chance to break backward compatibility, break the things that need breaking, keep all the things that make Perl, Perl, keep it a joy to use, and with this redesign, make it a language that will be able to be useful and enjoyable for decades.  And so I'd recommend Perl, but I'm known to be prejudiced in the matter. 

Question: What skills or characteristics do you need to be a great programmer?

Larry Wall:  Well, laziness, impatience, and hubris.  These originated as sort of a joke in the first edition of what we call the Camel Book, Programming Perl, and in a sense, they are the three virtues of a programmer.  A lazy person will try to always find some way to do something; they'll always be looking for ways of doing something faster, more efficiently, and if you really want to control the world, that's a really sort of hubristic notion—excessive pride, the thing that Zeus zaps you for having.

But it really was sort of a joke, in the Japanese edition, the translated edition of the Camel Book, they actually had to put "laziness, impatience, and hubris – this is a joke," because they felt that they would take it seriously.

So really what makes a good programmer is much more than those three things.  If you've either read the Lord of the Rings or seen the movies, you know about hobbits, and hobbits manifest many of the virtues that you need as a programmer.  You know, you need to have persistence, when the going gets rough, to keep slogging through, a kind of innate stubbornness—in a happy way, not in a mean way.  You have to be smart enough to outwit your enemies occasionally. And you have to be able to be social, you have to be able to deal with a group, your team members, some of which are like you, they're other hobbits, some of which are elves, and dwarves, or even men, and they think very differently from you.  So you have to be able to contribute your part as a hobbit, but also be able to understand other things.  So the day is long past when most programming is done individually.  Almost all programming is done in teams and so you need to be literate in a sense of, the hobbit sense of knowing your letters.  You have to be able to read documentation; you have to be able to write documentation that others can understand.  But mostly you have to be just slightly insane in the way that hobbits are, where they can view the long term, you know, the goal is to get back to your comfy burrow, and view all the, everything between here and there, at the same time, forget about all that and just deal with the problem you have at hand.

So in more concrete terms on a computer, you're telling it to do various things by name, and it's going off and doing those.  You have to simultaneously be aware of what it's doing down underneath, but if you're always aware of everything it's doing, you go really nuts.  So you also have to be able to shut that out and work on the high level abstraction.  And doing both of those simultaneously gives the best result in programming.  If you ignore either one of those, you end up messing up.  So, that's what you really need.

And like a hobbit, laziness, a hobbit is lazy in a very industrious way, and a hobbit is very impatient in a very patient way, and a hobbit is proud in a very humble way.  It sort of seems like contradictions, but to the extent that you can increase your dynamic range on all of those, you'll be a better programmer.

Question: What do you think of Apple?

Larry Wall: Well, Apple has always been, tried to be, at least, the arbiter of good taste and we need some of those.  I think that the world would be a much poorer place without Apple as part of the cultural ecosystem.  But we also need the other people who keep that from being the only way to do things, because when good taste becomes mandatory, then it's not really good taste any more, it's just manners. In the 20th century, we came out from the 19th century that was very mannered, and there are many novels about how you can have all these good manners on the top and, you know, culturally smooth, but, you know, underneath there's this ferment that doesn't get answered if it can't come out.

So I think going to a more evolutionary approach where Apple has their particular ecological niche that they fill, and others are trying to optimize for different things than just the coolest fashion statement.  I think that's healthy to have that kind of diversity and that's really, I guess, my post-modernism poking out again.

Question: How do you feel about software patents?

Larry Wall: I am very much against the notion of software patents because I do not believe they provide equal protection under the law to the little guy.  I consider myself to be one of the little guys.  I cannot afford to spend my time researching patents and trying to steer clear of them.  And if I did, I would be more liable.  So all the creative stuff that I do, I have to completely ignore the patent system and just put it out there and just hope for the best.  There's no way, I, as an individual, who's contributing free software to the world, can afford the patent system on that level.

And so I think that there's lots of different arguments you can make about the software patent system. There have been a lot of ridiculous patents on what we would consider to be trivial inventions, and I just can't afford to spend time worrying about it.  So I wish software patents, as a technology, would just die and go away.

Now, that's not say hardware patents haven't been useful.  I think that they're a little different and putting together a gadget or a machine is the old fashioned kind of invention.  But computer programming is more like writing down math formulas, and we don't patent math; we probably shouldn't patent the human genome.  Things that are sort of naturally the way the world works, they should just be sort of what everyone has to work with as a fair playing field and I just don't think software patents are a fair playing field right now.

Question: What’s the most overrated language?

Larry Wall: Pretty much every language is overrated by its practitioners and underrated by everyone else; it tends to be fairly tribal. Either a language matches the way you think or it doesn't.  So I tend to think that perhaps languages that are pushed for reasons other than the technical merits of the language would tend to fall in that category.  Some would label Java with that—though Java is a good language for what it does do—but it's not the be-all and end-all, and no language really is.  I've seen people try to do things in Perl that I wouldn't try to do myself and in that sense, in their mind, Perl is more than what they, than what I would rate it as.

So really, any language outside of its realm can be considered overrated, just like, you know, any expert outside of their field starts talking hogwash.  So don't listen to me on any subject other than linguistics and computers, I guess. Well, maybe theology.

Question: What is your work set-up like?

Larry Wall: Well, my company just moved a couple weeks ago from one office building to another.  We had been across the street from Google headquarters and now we're a few miles down the road near the Great America theme park.  So at the moment, my office is pristine, but that's because I haven't actually worked in it yet.  My office would tend to be rather messier. The way I think is not linear; the way I consider problems, I just have to let things stew around, bubble.  I can't say what's going to be important, but pretty soon the important thing bubbles up to my consciousness and then I do something about it, so my office tends to reflect that.  You know, I've got my hands in 30 or 40 different pots simultaneously and so I have a little bit of all of that where I work.

Question: Do you work better in the morning or at night?

Larry Wall:  Oh, I'm definitely a night owl.  I get going about the time my wife crashes and goes to bed.  And in some sense, I've had to learn to be more of a cat napper in recent years because Perl development, Perl design and development, has become a worldwide phenomenon—not just mailing lists, but RSC channels, Twitter even. This all happens 24 hours a day.  And people come up with questions at any time of the day or night. I have people working on this in Europe, in Japan, China, Australia, India, South America, all over the world, except maybe Antarctica.  No, I think we even have a Perl programmer in Antarctica.

So I've had to learn kind of sense when the questions would be coming and be ready to handle them.  There's a lot of education and reiteration that happens on these online channels and sometimes it's tempting to just say, "Well, just go and read the documentation," but you know, people appreciate being led along and taught and mentored. This is part of the reason I'm not too concerned about the future of Perl after me, because I see how these people are interacting with each other and even when I'm not there, they are helping each other and solving each other's problems in a way that I could not do, even if I were there.

So while I have historically been a late worker, you know, sometimes I even like to get up early and see what's happened in the few hours of the night and then I often take a nap in the middle of the day just to sort of make up for stretching my day out.

Question: How do you stay alert during late nights?

Larry Wall:  Well, coffee is my drug of choice, generally, with a little bit of Pepsi here and there, if I need more sugar.  But yeah, if I could do intravenous coffee, I would.  But I guess that's pretty standard.

Question:  Do you listen to music when you're writing code?

Larry Wall:  I used to not be able to listen to music.  I was raised a musician and I played classic music, violin, in orchestras and music comedy theaters, I have music running around in my head all the time, and if I hear music that's too interesting, I have to pay attention to it.

For a while there, I could really only work if I had sounds of oceans or [ocean sound] in my head.  Lately though, I find that music like, that is very complicated structurally, like jazz, I can actually listen to that and work at the same time, because I can just let it wash over me and not have to bother analyzing it.  That works for me.

Question: Do you procrastinate?

Larry Wall:  Never put off till tomorrow what you can put off till the day after tomorrow.  Like a variant of the song, Tomorrow, only it's more of the idea, the Mexican idea of mañana, you know, [singing] mañana, mañana, I love you, mañana, you're always a day away.

So, yeah, I procrastinate, but mostly because there's always too many things to do, and I got the stew in my mind that things do bubble up, so I'll throw things in there and let them stew around. It's sort of like greasing the squeaky wheels in my own brain.  When something gets loud enough or I feel guilty enough about it or somebody else complains about it, or I just feel it's the next thing to do, then the thing will de-procrastinate itself at an appropriate time. Basically there's just so much stuff flowing past on the internet now, you have to let most of it go.  And I've grown accustomed to the process of not worrying too much about the stuff I'm not getting to, because the important stuff will come back around.