A Conversation with Bill Joy
Pages: 1, 2
O'Reilly: When you say "if things become a service," I'm assuming that obviously there will be services that come where people are converting existing software into services. They're going to be new services, presumably Napster will try to offer itself as a subscription service. But how are you going to find all these services? What do you think about things like UDDI as a stab in that direction?
Joy: Categorizing and finding things is a problem that's just vexed philosophers for thousands of years and well into some of the craziest thinking of the 20th century. It's not easy to name and categorize things, and no single method of doing that will be sufficient. You'll need things at different levels of abstraction and you'll need some things that machines can do, some things that humans can do. Sometimes people are involved. Everything cannot be described as a bunch of predicates.
O'Reilly: Sure, that's fair. But you can still get something useful. Both Yahoo and Google I find work pretty well for their respective uses, and presumably we could do something like that for services if we start thinking about it.
Joy: It may be very difficult to say, "What I want to do is to interconnect these parts." With Jini we said, "We're going to describe the parts as Java types," because in the end the actions and the data formats that they're going to interconnect with have to interoperate. That was basically the equivalent of designing guns with interchangable parts. For the military that makes a huge difference. But it's still relatively brutal in that it's mechanically engineered, as opposed to biological systems. Biological systems are designed in a way that is more tolerant of misalignment. Things in an engineering sense have to be machined to be very precise. But when you try to make parts that are machined that are more biological, you fall off the end of computer science, basically. We don't know how to do that yet. We don't know how to describe systems in a more flexible way.
O'Reilly: So what do you think about .NET?
Joy: I don't know, they had to do something. It's imperial overstretch. It's just way too much. It's a top-down design, where they weren't even clear - the problem is they need a strategy, not ... the goal is total world domination and they invented something really complicated and messy.
O'Reilly: So SOAP and XML-RPC - things like that - are in some sense relatively simple. Do you see them ...
Joy: But Java and linking together the data types solves this component service composition model using programming language technology. XML doesn't because it's still just data. You still have to have a type system to plug the things together and essentially, dynamic linking, and you don't find that in XML just by itself. So you need Java and you essentially need what Jini does - whether you're hooked together with Jini RPC or an XML-formatted RPC is really kind of irrelevant. You still need the moral equivalent of dynamic linking if you're to have rich things that connect to each other. People will eventually realize that you need to do something like Jini.
O'Reilly: I wouldn't necessarily disagree with that. On the other hand, I would argue that from a pragmatic point of view, systems that don't have all the features often beat systems that do. You know the Web was sort of ...
Joy: Well, but either you can compose components with behavior or you can't. It's like the evolution of multi-cellular creatures. You can go along with single-cell organisms but at some point you will come up with a multi-cellular body plan. And you either can do it or you can't. And the problem is that without the ability to plug together behavior, you're basically stuck in these single cellular things. You end up with 1,000 different XML-based thingies that don't ever really compose to do anything together. You don't have composable things because you don't have the algebra to put things together.
I think WAP is an example of a similar problem. Why did WAP fail? Because it's boring, and it's boring because it's static, because it didn't have any behavior. The screen is small and there's no way to really do much of anything dynamic. And so what you needed is downloadable behavior. You need basically a scripting language or Java or something in the handset to make it interesting.
I think a similar problem here is XML. Yeah, you can do a few little things, but you're going to quickly run into the fact that you need behavior, not just data formats, because otherwise everything is too static and brittle. As long as there's no alternative, it's fine, but then you quickly discover things get to be kind of messy.
O'Reilly: I'm not sure I agree with you there. I think you can in fact ...
Joy: I know. The market doesn't agree with me, either. We'll come back in five years and find out.
O'Reilly: Well, but is it really either-or? There really isn't ...
Joy: Yes, I think ultimately these data-driven things will prove to be unsatisfactory. If anything, what we need is procedural component things plugging together using a more biological metaphor rather than -- Java is an engineered connection and what we really would like is some sort of constraint-based list-like connection which is, you know, rather difficult. We really wanted something that's beyond the state of the art, even goes beyond Java to do things in a much more organic-biological kind of way.
O'Reilly: So is there anything else like that you say we're missing now that we're going to be kicking ourselves 10 years from now?
Joy: I think in particular there are a couple of things going on here. One is I don't think we're ready for the explosion of optical bandwidth. I think we really still have failed to deal with the manageability problem when you have lots of these devices. The industry just hasn't done a good job of taking responsibility for making them easy to own and to use. We've tried with Java and with Jini. I wish we had made more progress on the usability side. I think people haven't recognized how important this is, to have really reliable software in individual devices. So that's a coming embarrassment: in my opinion, the continued use of unreliable languages in a lot of these devices.
O'Reilly: You're keynoting at our Peer-to-Peer Conference. What can you tell us about what you're going to be talking about?
Joy: I can't.
O'Reilly: In other words, people have to come to the conference to find out?
Joy: Well, no, I mean we're going to be as upbeat and talk about as much stuff as we can talk about, and we're doing stuff in an entrepreneurial style. We hope to be a player in this space, but a very supportive one. And so I think our efforts are the appropriate kind of efforts for a company of our size who can make a commitment that people can depend on. We will decide what we think is right and stick to it, like we've done with Java.
Tim O'Reilly is the founder and CEO of O'Reilly Media, Inc., thought by many to be the best computer book publisher in the world. In addition to Foo Camps ("Friends of O'Reilly" Camps, which gave rise to the "un-conference" movement), O'Reilly Media also hosts conferences on technology topics, including the Web 2.0 Summit, the Web 2.0 Expo, the O'Reilly Open Source Convention, the Gov 2.0 Summit, and the Gov 2.0 Expo. Tim's blog, the O'Reilly Radar, "watches the alpha geeks" to determine emerging technology trends, and serves as a platform for advocacy about issues of importance to the technical community. Tim's long-term vision for his company is to change the world by spreading the knowledge of innovators. In addition to O'Reilly Media, Tim is a founder of Safari Books Online, a pioneering subscription service for accessing books online, and O'Reilly AlphaTech Ventures, an early-stage venture firm.
Discuss this article in the O'Reilly Network General Forum.
Return to OpenP2P.com.