Perl: the challenges ahead
In this exclusive interview, Perl's creator and chief architect, Larry Wall, and his boss, Tim O'Reilly, talk about future plans and technical challenges for Perl and how Java might affect its development
Since that day when, as the story goes, "
awkran out of steam" and Larry Wall first created Perl (practical extraction and report language or pathologically eclectic rubbish lister, depending on what kind of day you're having) nearly 10 years ago, it has blossomed into one of the most popular languages on the Internet. During the week of August 18, Perl will prove it's become big enough to warrant its own conference as O'Reilly & Associates, the company that now employs Wall, hosts the first annual Perl Conference in San Jose, CA. In this interview, Wall and his boss, O'Reilly & Associates CEO Tim O'Reilly, discuss the state of Perl today and their strategy for keeping Perl from the snares and pitfalls that have embroiled another popular Internet language: Java. (3,000 words)
Larry Wall: Well...Yes.
Tim O'Reilly: I think of Perl as the Intel of the information revolution. Many of the information sites have Perl inside, you know, in the same ways that the PCs all have Intel inside. And I think that's not an accident. I think that has to do with the way that Perl lends itself to the kinds of products that are really being built in this next generation of the computer revolution. They tend to be information products; they tend to have text in them -- and Perl is really good at handling text -- they tend to be put together by non-programmers, and Perl, despite being a very full-featured language, is very easy to get started with.
SunWorld: We're at version 5.004 of Perl right now. Is there a version six planned?
Wall: I think Perl may end up like Unix did and get stuck at system five. There's a version 5.005 that a fellow named Malcolm Beattie is working on. It will have multithreading support, and it will have a compiler back end to it that can be extended very easily.
SunWorld: Are there any great technical challenges that remain ahead at this point?
Wall: There are always technical challenges. When you talk about Perl, version whatever, you're mostly talking about what you think of as core Perl and in that sense, yeah the language itself is pretty much stabilizing. But if you talk about Perl in terms of culture, that is simply exploding. And I think that's healthy. One of the reasons that Perl culture is growing so fast is that we're stabilizing the core.
A similar thing happened with Unix. There's not a whole lot of Unix kernel reinvention nowadays. What Unix means nowadays is pretty stable.
O'Reilly: Comparing it to Unix is maybe a bad idea. What about comparing it to something like C. What version of C are we at?
Wall: So it serves as a stable platform. But by design Perl 5 included an extension mechanism so that we could, in fact, decentralize the further development of the language. And that was intentional. A lot of the strength of Perl culture is built into this decentralization notion. There's just an awful lot of strength in the grass roots. And I as a language designer, do not want to make decisions. Just like I believe in limited federal government, all the decisions that can be made at the local level, I think, ought to be.
That is where I think the strength of the language is in the future. Because the dynamics of how Perl develops is more like a natural language than like a computer language. With a typical computer language, the word comes down from on high: "this is the next thing that is going to happen to the language." Whereas with Perl it's always been a very cooperative effort, a very, "let's-see-who-needs-help-the-most-right-now, let's-grease-the-squeaky-wheel" effort. And that implies it's viewed as a rough-and-ready language because we have taken a practical approach to it -- a bit of a populist approach, if you will. But that's why it gets people's jobs done for them.
SunWorld: What mechanism is Perl's development centralized through?
Wall: Most of the development at this point centers on a mailing list called Perl 5 porters. It started off just being people porting Perl to other platforms. It's about 200 people that actively participate in the feature side of Perl.
O'Reilly: You bring up a really interesting point here. And that is this collaborative versus centralized development model. There is something that's really vital about collaborative free software development that I think has not got as much attention as it should. Look back at the last 10 or 15 years in computing and look at what were some of the really, really significant things that were developed that have become almost a universal substrate. You take something like C. Well, you know it's not exactly something like free software, but it was developed in a R&D kind of environment, not as a commercial product. Unix was developed very collaboratively. Even though it was theoretically owned by AT&T it was developed, really, by hundreds, maybe even thousands of distributed programmers. Look at the Internet, which was an outgrowth of that. None of these things were created by a single company going, 'Wow! We're going to make this great new product.' Most of the really significant stuff that's really out front right now was developed through a collaborative development process.
Perl vs. Java
SunWorld: Who owns the Perl trademark?
Wall: There is no Perl trademark.
SunWorld: So it's in the public domain, basically?
Wall: The name Perl is not trademarked. You know, Ada trademarked the name Ada, and they sort of decided to un-trademark it later. Basically, there's a period of time in the middle where it's dangerous -- where somebody might grab it. But you know both Perl and Ada have grown to the point where anybody who tried to grab either trademark would be shouted down by the entire industry.
SunWorld: That's an issue for another language these days.
SunWorld: Has Java had an impact on the development of Perl.
Wall: It's probably well-known that Perl has borrowed freely from ideas from many languages, and Java has good ideas in it. At the moment I'm working on a hybrid Java/Perl kind of language just to see how the two can cooperate with each other.
My view of language is that languages need to be taught to cooperate, and by-and-large people in industry only think of languages as competing. So I'm interested in seeing how the two can be made to talk to each other and augment each other's strengths. What I've got right now is a little thing with Java class wrappers and Perl implementations, and it seems to be an interesting little gizmo to play with. So we'll see where we go with that.
SunWorld: Would that gizmo eventually become part of Perl?
Wall: That depends how you define Perl. It will definitely be part of the Perl culture. Whether it's part of the Perl standard distribution or not depends on lots of things.
SunWorld: How have these Java ideas shown up in Perl?
Wall: In particular, Java has a very rigidly defined class structure. And Perl's is very fluidly defined. The strength of Java's definition is that you can sort of establish Java as the universal assembly language of the 'Net. I view that as a kind of ecological niche that higher-level languages -- and I don't really classify Java as a high-level language in that respect -- can fill. And I think Perl can be one of those higher-level languages.
It's like a CPU architecture. It has very strict ways of how you're going to call functions and return from subroutines, and your compiler makes that easier for the programmer to deal with. In the same sense, I think Perl can make the rigid Java substrate easier to deal with on a day-to-day basis.
SunWorld: Are there new things that O'Reilly is developing for Perl?
O'Reilly: Part of what we're doing is looking at how to commercialize Perl. Larry came to work for O'Reilly a year and a half ago now, and part of that was around this idea of, "What was the appropriate way to commercialize free software." There's one path that says, 'Oh wow, Perl is hot, let's go out and get a bunch of venture capital, and we'll try to make some kind of Perl language company.'
It's hard to build companies around languages, as Borland has proven. We said, let's say 'Perl is free software. We want it to stay that way. Is there a way to commercialize it?' And it's kind of interesting because our history as a book publisher actually has given us some clues for a way to do that.
The product we're focused on right now is actually a series of Perl resource kits -- analogous to the NT resource kits that Microsoft did. What we're going to do is have a cluster of added-value things: utilities and additional documentation, various kinds of things that will make something you've already got more useful to you.
Rather than trying to take over the core of the language. You know, say 'this is the authorized Perl. Sorry, that free thing is deprecated in some way,' we said, 'No, the free thing is the real thing, but we're going to give you added value in the form of these resource kits.'
So that's really our product strategy, and we're expecting to come out with the first Perl resource kit this fall.
SunWorld: Do you have any advice for the people at JavaSoft?
O'Reilly: I know there were a lot of people, when Eric [Schmidt, Sun's former chief technology officer] first made the deal with Microsoft to do the official reference port on Windows, who thought 'Oh boy, this is a dangerous, dangerous move.' And it has proven to be so. Sun's interest in keeping Java cross-platform and Microsoft's interest in tying it into Windows are really divergent. That's a tough one for Sun, which is primarily a hardware company: to keep up with Microsoft in that game. It'll be interesting to see how that whole challenge works out; whether we end up with Sun Java or Microsoft Java or competing Javas.
Wall: That's my advice also, as a language designer: don't allow divergent implementations. Do whatever it takes not to allow that.
O'Reilly: This started to happen in the Perl world with the involvement of Microsoft because they commissioned a Win32 port of Perl. Partly for some specific implementation reasons, but also, I think probably it was just not all that well coordinated. There's some divergence in the two ports, and we're taking some steps to bring them back together. That's one of the things we'll be talking about at the conference. So we will actually end up with one implementation of Perl for both Win32 and Unix systems.
SunWorld: What steps are you taking?
O'Reilly: We're working very closely with ActiveWare, the people who did the original Win32 port and getting them working with the freeware Perl community to bring the two together.
SunWorld: When do you think that will happen?
Wall: It should be a done thing by version 5.005.
SunWorld: When is that expected, within a year?
Wall: It depends on which definition of 5.005 you take. Definitely within a year. We're talking about before the end of this year, certainly, and hopefully several months before that.
SunWorld: Tell me about next week's Perl conference.
O'Reilly: We had a meeting at our offices where we invited in a bunch of people we knew who were concerned about the future of Perl for a brainstorming summit. We had about 20 people. And we said 'boy, it's really great to have all these people coming together to talk about this, face to face.' And we said, 'hey, we really ought to do a conference.'
Just a few weeks after we made that decision, Larry gave a talk at Computer Literacy Bookshop, and one of the people in the audience got up and said 'I was just at JavaOne. How come there isn't a PerlOne?' It's funny because I think people are starting to recognize there's a lot of people using Perl. Why isn't there this visibility? That again is a lot of what we've really been focusing on. Here's a language so widely used on the Internet, and because it doesn't have a lot of money behind it -- there's nobody who cares about it in the stock market -- it doesn't get a lot of press. And it's sort of silly, so we said, 'Let's put on a conference. We need to raise the profile of Perl.' And, sure enough, we're heading toward 1,000 people coming. And this is not a trade show kind of thing; this is just conference and tutorials.
Perl: a victim of its own success?
SunWorld: Is Perl in danger of becoming a victim of its own success?
O'Reilly: I think it's certainly possible that Perl could become big enough that you could imagine Microsoft coming along and saying, 'Well, we're going to do a Microsoft Perl that is slightly different. Use ours.' And, you know, get into the whole kind of game that they're doing with Java. But so far we haven't seen that. Microsoft has been pretty supportive. But it's hard to say.
Wall: So far Perl has succeeded by taking the low road. And at this point we're taking a medium road. Hopefully we can still make that look like the low road where it needs to look like the low road, and look like the high road where it needs to look like the high road.
O'Reilly: Obviously as you raise the profile you do get people coming in there and saying, 'Wow. There's money to be made here. How do we make money? What are we going to do?' You start to see collisions. You know, two companies claiming they have something called PerlScript, and they're not the same.
Wall: In fact, we actually see this sort of fragmentation in the Linux market. And I've taken a slightly different tack than Linus Torvald [the creator of Linux] has. He's gone to work for a chip manufacturer because he wants to stay totally out of the fray. My feeling on that matter is: I know that there has to be some growth in the commercial area as well as in the freeware area. So I'd like to be close enough to that action that I can sort of bless some aspects and not-bless other aspects of it.
That's the main motivation for me coming to O'Reilly a year ago. So that I could be part of this and sort of boot up the commercial aspects of this in a controlled fashion. And, by and large, so far it seems to be succeeding very well.
I'm sure we'll have some heartbreaking things down the road, but there's such a tremendous feeling of cooperation that is built into Perl culture that I think that there is...nobody is going to succeed in Perl culture against my express wishes very easily. I try not to abuse that. And hopefully, you know, this sort of benign dictatorship that I've been having, if I don't abuse it, if I choose my battlefields very carefully, I get to have the right amount of say in order to develop things.
SunWorld: Looking back the nearly 10 years Perl has been around, is there anything that you would have done differently?
Wall: You mean like spell create with an "e?"
That's a hard question. I so much believe in the evolutionary approach that Perl has taken that I have difficulty even admitting to myself that some design decision along the way was wrong.
There are some things that I would have done differently. Certainly, if you just look at the list of deprecations for Perl 5, that's a pretty strong list of things that I decided later I didn't like. Early Perl had a lot of magical action at a distance. You know, magical variables that would influence the behavior of the entire program. And a lot of that sort of thing has been deprecated in Perl 5. That's probably the biggie.
In terms of syntax, I don't repent most of my syntax.
O'Reilly: Actually that's one of the things that people complain about.
Wall: Yeah, but I actually designed the syntax to work more like natural language, initial impressions notwithstanding. I'm sort of half a linguist and half a computer scientist, and the linguist part of me is not going to apologize for what I think is good human engineering.
O'Reilly: The fact is the things that people who don't like Perl complain about are actually features that people who love Perl most appreciate. And I think there are some real reasons there, and the fact that they're good reasons is borne out by the fact that Perl is in such wide use.
O'Reilly's Perl Conference will be held from August 19-21 1997 at the Fairmont Hotel in San Jose CA.
If you have technical problems with this magazine, contact email@example.com
If you have technical problems with this magazine, contact firstname.lastname@example.org