The Art of Computer Programming

A Conversation with James Gosling, Part I

by Bill Venners
March 25, 2002

First published in JavaWorld, March 25, 2002
Bill Venners recently spoke with Sun Microsystems Vice President and Fellow James Gosling at his Sun Labs office in Mountain View, Calif. In this interview, Java's creator imparts his thoughts on enterprise software, algorithms, the trend towards user-oriented software, flexibility, complexity, and other aspects of the art of computer programming.

When James Gosling isn't preaching Java's virtues, he spends his days in a quiet corner office at Sun Labs, dreaming up new ways to help programmers manage complexity. With the Star Trek Borg mask he wore at a prior JavaOne keynote staring down from a shelf, Gosling spoke to JavaWorld's Bill Venners about current programming trends, and his views on the design and construction of software systems.

Enterprise vs. Devices

Bill Venners: If Java exists on so many cell phones and smart cards, why does it seem like almost everyone does server-side software with Java?

James Gosling: I think that's a North American-centric observation. If you go to conferences in North America, people only talk about enterprise software. But I've been to Java events in Europe and in Japan lately, and nobody talks about enterprise software.

Bill Venners: What are they interested in?

James Gosling: It's devices, cell phones, how you build the whole end-to-end thing. It would have been eye-opening for North American journalists to go to the recent JavaOne conference in Japan because it was hard to find enterprise anything. There was embedded stuff, real-time stuff -- some goofy, some just amazing. They've got this thing about computation everywhere.

There's a core where enterprise software goes, but it doesn't make sense unless it's talking to something else, the stuff on the fringes. You need an end-to-end attitude before the pieces make sense.

The Art of Computer Programming

Bill Venners: I recently dusted off Donald Knuth's The Art of Computer Programming (Addison-Wesley Pub Co., 1998; ISBN: 0201485419), which extensively covers algorithms. It struck me as funny that of all the work I've done in my career, I've rarely done hard-core algorithm design. Do you think algorithms are the art of computer programming, or has something changed since the '60s and '70s?

James Gosling: Whether you're doing intense algorithm design or not, I think computer programming is always an art. Many people don't understand how to put software pieces together when performance counts, or understand a software piece's performance characteristics -- how to reasonably analyze what does what.

People rarely ask: "Could I do it a faster way?" They'll layer APIs 10 deep. You'll see these 10- or 100-levels-deep call stacks and say, "Oh my God!" These people lay abstractions upon abstractions upon abstractions. They build things out of, in some sense, an accidental complexity that is mind-boggling.

Bill Venners: You once said you were flabbergasted that so many people get into software development without taking an algorithm analysis course. You said the systems people build limp along on bad design. Would that be bad algorithm design, or bad object-oriented design, or what?

James Gosling: Oh, it's bad everything design. Bad algorithm design comes from not appreciating how things work. Say you're adding stuff to a table or an array, and you want to grow it. Do you make it 10 bytes larger each time, or 10 percent larger each time? That sounds like the same thing. But if you make it larger by 10 bytes each time, the performance is quadratic in the number of bytes you add. If you increase the length by 10 percent, instead of 10 bytes, it goes from being quadratic to being linear. It's a simple distinction.


Bill Venners: So, maybe the art of programming just makes things easier for people.

James Gosling: Absolutely. It's like what's happened to cars over the last 40 or 50 years. In the past, you could open a car's hood and understand what went on inside. Now, you open a car's hood, and it's completely hopeless.

Bill Venners: That's because it has so much software in it. You can't tinker with software with a wrench.

James Gosling: Some of it's software. There's a lot of little tubes that go from here to there, that do things like manage the engine efficiency, manage the air quality, manage things people didn't worry about before. Plus, today's cars work for people who just want to get in, turn it on, and go. As opposed to saying, "Well, gee, it's about 40 degrees out, so I need to preheat the engine, and the choke needs to be here, and if you pump on it like that, and it's a little humid, so you don't want to get too much gas in there."

Most people aren't concerned about what goes on under the hood. They want to go wherever they're going. Likewise, their business is their business; it's not fussing with the guts of software.

Bill Venners: You've said Java was intended for distributed, reliable, interacting-with-people software. I understand Java's architecture helps us build reliable, distributed software, but how does it help us build software that interacts with people?

James Gosling: Much of it ends up in the APIs, but you see most of it in the low-level language. Many of the other things you mentioned affect ease of use. For example, software that frequently breaks is harder to use. Software where you worry about what kind of CPU you're loading the software into is harder to use. The fact that your local software store has a Macintosh aisle and a PC aisle indicates a flaw in the whole market's structure. In Japan, a dozen manufacturers or so make Java phones, each with a different CPU and operating system. Yet they all interoperate. So, if you want a Tetris game, you just get a Tetris game. That's deeply an ease-of-use issue for people.

Bill Venners: You once said that building very flexible and very programmable systems had been a theme in your life. When I'm building a system, issues frequently arise among the team members concerning flexibility. Something may add flexibility, but it also adds complexity. How do you decide how flexible to make a particular piece of software?

James Gosling: It's the art of computer programming. So, there might be a certain complexity in adding to a piece of software, but if you don't add it, for the people who are using it, it introduces complexity because they must do things in a stilted way. It's an end-to-end energy sum thing, where you must examine how much energy to put into adding complexity to a program versus how much complexity it removes from people's lives. You're balancing complexity here, complexity there.

Bill Venners: Somebody once asked what you like about developing software. You said you most like fighting with complexity. So, what do you like about complexity?

James Gosling: Beats me. If you buy a watch, it's just a watch; it's got hands. But several companies recently introduced watches with clear cases, so you can see the little gears. I don't know why, but I look at those and say, "Ooh, isn't that cool?" The first time I saw one, I had to buy it. When I build the mental model of a piece of software, then somehow get the complex pieces to fit together, and it all meshes, and there's a smooth rhythm to it -- there's a pleasant feeling about that. Whereas yesterday, I was installing a new pair of speakers at home and had to confront the maze of wires at the back of my stereo system. That's the kind of complexity that just drives me nuts.


The Art of Computer Programming, by Donald Knuth is available at at:

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building into an ever more useful resource for developers.