Interview: Rasmus Lerdorf, PHP Guru
“Over the years PHP has grown from a single guy, me, to now 800-900 people around the world contributing”
- Rasmus Lerdorf
As straightforward, engaging, and gracious as the world-class scripting language he has created, Rasmus shared with us his background as well as his thoughts about the upcoming PHP 5 and beyond. We hope that you enjoy this interview with Rasmus as much as we enjoyed capturing it.
Welcome to India, Rasmus. All of us in India are great admirers of PHP, which is very popular here.
Q: Is this your first visit to India?
Rasmus: No, this is my third visit to India. I was at the two Bang Linux conferences, in 1999 and 2000.
Q: What is your background? I understand you’re from Canada.
Rasmus: I was originally born in Greenland. I grew up in Denmark. Then we moved back to proper Denmark and then to Canada. I spent some time in Brazil and now I’m in the US. I’ve been all over. And job-wise, I’ve worked for all kinds of companies over the years. I was at various Bell companies in Canada and the telcos. I was at Bell Northern Research for a while. I was with a company called Bell Emergis which does Internet related stuff in Canada. I built some large Internet systems for Bell and a big system for the University of Toronto back then. This was the beginning of PHP. I had written some tools just for my own Web page which became known then as Personal Home Page (PHP). They started to get somewhat popular. Everyone else on the same ISP saw my pages and they slowly started to be used on other ISPs as well. Then I took this contract job with the University of Toronto to build a very large dial-up system to provide access to the Internet for students and professors. Behind the scenes we needed a system that could keep track of all the users and their accounts. They wanted a Web-based management system that could talk to the library’s database. I couldn’t talk directly to this database so we would do a nightly dump of all the users. I would then import that into a database called miniSQL which was a predecessor to MySQL. And that would be the database I would query in realtime on-line to configure all this stuff out. I wrote all kinds of code that would have little graphs of usage and a lot of PHP was written for that particular project. Then I went on to Bell and did built some country-wide services. After that I went to IBM in North Carolina (Research Triangle Park RTP). That was sort of just before the [dot com] bubble really started to take off. And while I was at IBM, Red Hat had their IPO. They were also in RTP right next to us. So the Open Source folks that were sitting at IBM were looking across the street at Red Hat going “whoa, there’s some interesting stuff happening here.” Red Hat did give me some stock so I got to buy a car from my stock from Red Hat.
So that was sort of what prompted me to make the shift to Silicon Valley. There were a lot of startups because that was when all the venture capital was flowing into these companies and they were fighting over each other to pick up engineers. Engineers with a little bit of a name looked good on their IPO paperwork. So I went to Silicon Valley to Linux Care in San Francisco and was there for a year and a half till the bubble burst. Then I took a little time off because my wife was pregnant. And I took some time off to finish the O’Reilly book, Programming PHP, and to take care of the baby. And then Yahoo came calling asking if I could help migrate a bunch of their stuff to PHP.
Q: They figured they’d come to the source…
Rasmus: I mean why not? I was living close by actually and I did not have to move. The technical challenges of working with something that big, the biggest Web destination in the world: if I could make this stuff work to that scale.
Q: Google is not the biggest Web destination?
Rasmus: No, in terms of visitors to it, it’s not. Search is just one thing people do and Yahoo’s search is quite popular as well, not as popular as Google’s search obviously, but Yahoo has been number one for all the other things that you can imagine that people do. Mail. I mean mail-dot-yahoo. Look in India. How many people use Yahoo Mail in India? Lots and lots. Look at auctions in Japan. Ebay is not in Japan at all. The standard auction site is Yahoo. So I mean worldwide, yes, Yahoo is by far the most visited site.
Q: What have you re-engineered?
Rasmus: We’re transitioning various proprietary tools in a mostly FreeBSD environment. Proprietary in the sense that they were home grown, not in the sense that they were commercial and bought. Because Yahoo started so early, the Open Source stuff back in ‘93 and ‘94 wasn’t really there. They had to write stuff. But now as various Open Source tools mature, they can say “OK, well, let’s migrate, let’s save some engineering resources.”
Q: Do you have staff at Yahoo?
Rasmus: No, not really. I have various groups that I work with, but I don’t have anybody reporting directly to me. I don’t really like managing people in that sense. I do my technical stuff.
Q: Do you have a team in Bangalore?
Rasmus: Well, they don’t work directly on PHP, the folks in Bangalore. But we do have a big office here, of course. And every now and then we hand off some PHP work to individuals. But we probably will get some more folks here in Bangalore and hopefully at some point I will get a few guys that I can sort of shuffle things off to. That would be nice. We have a slight problem here in India in that Yahoo isn’t seen as a very technical company. Yahoo is seen as a company where, if you can write nice Web pages, you can go work for Yahoo. This is completely untrue. I mean the infrastructure and the technology that is required to build something the scale of Yahoo and have it be fast and reliable and robust, there’s such an amazing amount of technology that the HTML portion of it is insignificant. Nobody here in Bangalore sits and writes HTML pages. None of them. They’re all working on really interesting infrastructure back-end algorithms. Really, really cool stuff.
Q: What is your current role with PHP?
Rasmus: I wrote the first two engines, the actual parser behind PHP. The parser is a somewhat small part of the PHP in the sense that it takes the HTML, parses out the tags, evaluates them and makes the back-end calls into all the other things you can plug into PHP like database extensions, LDAP, and SNMP. So that parser is sort of the traffic cop that says go here and go there. It’s important to have a really good parser and I wrote the first two versions and Zeev and Andy in Israel came along and said, “Hey, we can write a better engine. If we write a better engine, will you put it into the next version of PHP? ” And I said sure. I mean, this is “open source” code: if it is better, it goes in. So they did write one for version 3 of PHP and they’ve rewritten it for version 4 and extended it a bit now for version 5. But over the years, it’s grown from a single guy, me, working on this stuff to, now, 800 to 900 people around the world contributing. More than half of those are writing documentation. If you don’t document, you might as well not write the code to begin with. So we have a really strong documentation team.
Q: How is the PHP project managed then? How do new features get put into PHP? For example how did PHP 5 get defined?
Rasmus: There were a lot of user requests for better Object Orientation in PHP. And a lot of the younger kids coming out of school these days want OO. Everything is Object Oriented. I’m old. In the computer science, Internet stuff I’m pretty old. And back when I came out of school, we didn’t have any Object Oriented languages. That really wasn’t how I thought about stuff. I taught myself how to program in C by basically writing a couple lines of C, compiling it, then disassembling it and looking at the assembly instructions. And then, after a little while you figure out, OK, if I write it this way, this is the assembly I get and it takes this many instructions and this many (machine) cycles. Back then I could look at a piece of code and I could say that’s about 87 cycles for this piece of code.
Q: Try doing that with OO!
Rasmus: Kids today have no idea. You ask them how many cycles a particular Java method takes and they have absolutely no idea (they can’t easily know, of course). In another sense you can be a lot more productive when you don’t have to sit and worry about registers and cycles. Still, getting as close to the hardware as you can does make for the most efficient code. It’s, of course, a trade off. So all these user requests for better OO have spurred on the changes in PHP 5, but it’s not a revolutionary change.
Q: Who decides what changes will go in?
Rasmus: It’s a very cooperative process. There’s a lot of arguing back and forth and discussing. We do have a core PHP group of about 9 guys who have the final say on any of these features. It’s a bunch of guys that have been around forever. There are a couple of German guys. There are two folks from Israel. A guy from Norway, guys from Canada and the US. We’re a pretty varied group who can never agree on anything. So when we do, we’re right! This has worked over the years.
Q: So introducing something like SQLite is based on consensus?
Rasmus: For SQLite the whole philosophy of PHP is to have a really simple tool for users to use. PHP should be as simple as possible for everything. And SQLite fits perfectly into that. MySQL is getting more and more complex. We can easily use MySQL at Yahoo, but still, at the very low end, as you get more complex, adding transaction views and triggers, people have a hard time implementing solutions. SQLite is very nice in the sense it’s just flat file management with an intelligent interface on top of it. The Web is inherently concurrent. You’re going to have two concurrent requests that are both going to write to the file. Oops, then what? Then you have to lock one and the other one has to sit and wait on the lock. What if you forget to unlock it? Putting some sort of marshalling layer in between the Web application and the flat file is perfect. We don’t really think of SQLite as an SQL database, it is an intelligent layer on top of a flat file. You can then take your SQL statements and migrate your application to a real SQL database at some point. The migration path should be quite simple.
Q: What about PHP 6?
Rasmus: We are thinking about it. Again, we don’t all agree on what direction that should take. My personal view on what I’d like to try, though I have no idea if it will work, is to go for Parrot. Parrot is the really cool new engine behind Perl 6. But it is not tied that closely to Perl. Larry Wall doesn’t have much to do with Parrot because he is defining Perl 6 from a top down approach. The Parrot engine is being developed by a couple of other folks and is being written to be language agnostic, in the sense that you can plug any language into it. And I’m not sure Perl 6 will be the first language to use it. Because Larry is being very ambitious in what he wants to do in Perl 6. All kinds of stuff has changed including regular expressions: it doesn’t really look like Perl anymore. So I’m a little skeptical on how fast they can get a usable Perl 6 out the door. And how many people will actually start using it. There’s another project called Pony which is to take Perl 5 and put it on the Parrot engine. I think we will see Perl 5 on Parrot long before we see Perl 6 on Parrot. At the same time we are also investigating, with a project code-named Pint, putting PHP onto the Parrot engine. And there are some really cool things that could be done if that happens.
Q: Is Python creator Guido von Rossum behind Parrot also?
Rasmus: No, Guido does not have anything to do with it. I have not heard him say he is looking at it seriously. There are other folks who have looked at putting Python onto Parrot. And I don’t know what their long-term strategy is for that. If both PHP and Perl run on top of Parrot then I would expect to see Python as well.
Q: Might Ruby also be ported to Parrot?
Rasmus: Well, if we have three, we might as well put all of them on there. The big win is not necessarily just the engine part and performance. There are some significant performance improvements. But it’s the interoperability that we get. So we don’t have to have four different Oracle extension projects. PHP to Oracle. Perl to Oracle. Python to Oracle. Ruby to Oracle. We can have one Oracle extension that everybody works on. The Oracle connectivity can be a standalone Open Source project that people who are interested in Oracle can work on. Because right now we have a bunch of good PHP guys that work on the Oracle extension. But they are primarily PHP guys that happen to know a bit about Oracle because they have written the Oracle connectivity. That’s not really the ideal thing. I want to get the Oracle geeks, and I don’t care if they know any PHP, I want to get the Oracle geeks to write a really cool Oracle connectivity layer. So we put that down into the Parrot level, so that all the various languages that talk to Parrot can talk to Oracle at that layer.
Q: Would Parrot replace Zend or would they work together?
Rasmus: It would basically replace it. Just like Zend replaced my engine a couple of years ago. We’d go for the best engine along the way. There would be plenty of other Zend code that would still be in there. But those are some of the arguments we are having in the project right now. Which direction do we take with this? Is this really a better engine? And things like that. Until we have some code running and look at performance, at CPU and memory usage, and at how easy the API is to use, only then we can take a decision.
Q: Are there corporations that are contributing to PHP?
Rasmus: Sure. The 800 people I talked about, they all work, they have to put food on the table and stuff. So every one of the companies that employs one of these contributers supports PHP although they may not all know about it. A lot of the documentation folks do it as a hobby at home. But most of them use PHP at work. And they do contribute a little bit back. So when they find a piece of PHP that’s not documented well, they just sit down and fix it. There are a lot of companies contributing to PHP knowingly or unknowingly.
Thank you, Rasmus.