If you look at a pixelized color image there are more or less two ways ofrepresenting that in memory. You can represent it in memory as an array ofpixels where each pixel contains RGB or CMYK data for the spot on theimage. That’s typically the way display controllers work, for example.

The other way, which is more common in the printing industry, is to havean array that contains the amount of red for each pixel and then anotherthat contains the amount of green for each pixel, then another that containsthe amount of blue, etc., etc. If you’re processing things on a pixel-by-pixelbasis, this is less convenient. On the other hand, it doesn’t impose any apriori constraint on how many different inks or how many different platescan go into the production of a given image.

Seibel: So if you have a printer that can use gold ink, you just add a plane.

Deutsch: Right. This certainly is not common in consumer-grade printersor even typically in office printers. But in offset printing it is relativelycommon to have special layers. So that was one area of insufficientgeneralization.

So that’s an example where even with a great deal of thought and skill Imissed the boat. It doesn’t illustrate my point well; in a sense it underminesmy point because, in this case, even careful foresight resulted in insufficientgeneralization. And I can tell you exactly where that insufficient foresightcame from—it came from the fact that Ghostscript was basically done byone very smart guy who had no acquaintance with the printing industry.

Seibel: Meaning you.

Deutsch: Right. Ghostscript started out as strictly a screen previewer forpreviewing PostScript files because there wasn’t one and PDF didn’t existyet. If I was going to draw a moral from that story, it’s that requirementsalways change, they always are going to at least attempt to change indirections you didn’t think of.

There are two schools of thought as to how you prepare yourself for that.One school of thought, which I think is probably pretty close to the way XPlooks at it, that basically says that because requirements are going to changeall the time, you shouldn’t expect software to last. If the requirementschange, you build something new. There is, I think, a certain amount ofwisdom in that.

The problem being the old saying in the business: “fast, cheap, good—pickany two.” If you build things fast and you have some way of building theminexpensively, it’s very unlikely that they’re going to be good. But this schoolof thought says you shouldn’t expect software to last.

I think behind this perhaps is a mindset of software as expense vs. softwareas capital asset. I’m very much in the software-as-capital-asset school. WhenI was working at ParcPlace and Adele Goldberg was out there evangelizingobject-oriented design, part of the way we talked about objects and part ofthe way we advocated object-oriented languages and design to ourcustomers and potential customers is to say, “Look, you should treatsoftware as a capital asset.”

And there is no such thing as a capital asset that doesn’t require ongoingmaintenance and investment. You should expect that there’s going to besome cost associated with maintaining a growing library of reusablesoftware. And that is going to complicate your accounting because it meansyou can’t charge the cost of building a piece of software only to the projector the customer that’s motivating the creation of that software at this time.You have to think of it the way you would think of a capital asset.

Seibel: Like building a new factory.

Deutsch: Right. A large part of the sell for objects was that well-designedobjects are reusable, so the investment that you put into the design paysitself back in less effort going down the road.

I still believe that, but probably not quite as strongly as I did. The things thatI see getting reused these days are either very large or very small. The scaleof reuse that we were talking about when we were promoting objects wasclasses and groups of classes. Except in situations where you have acollection of classes that embody some kind of real domain knowledge, Idon’t see that happening much.

What I see getting reused is either very small things—individual icons,individual web page designs—or very big things like entire languages or largeapplications with extension architectures like Apache or Mozilla.

Seibel: So you don’t believe the original object-reuse pitch quite as stronglynow. Was there something wrong with the theory, or has it just notworked out for historical reasons?

Deutsch: Well, part of the reason that I don’t call myself a computerscientist any more is that I’ve seen software practice over a period of justabout 50 years and it basically hasn’t improved tremendously in about thelast 30 years.

If you look at programming languages I would make a strong case thatprogramming languages have not improved qualitatively in the last 40 years.There is no programming language in use today that is qualitatively betterthan Simula-67. I know that sounds kind of funny, but I really mean it. Java isnot that much better than Simula-67.

Seibel: Smalltalk?

Deutsch: Smalltalk is somewhat better than Simula-67. But Smalltalk as itexists today essentially existed in 1976. I’m not saying that today’s languagesaren’t better than the languages that existed 30 years ago. The language thatI do all of my programming in today, Python, is, I think, a lot better thananything that was available 30 years ago. I like it better than Smalltalk.

I use the word qualitatively very deliberately. Every programming languagetoday that I can think of, that’s in substantial use, has the concept of pointer.I don’t know of any way to make software built using that fundamentalconcept qualitatively better.

Seibel: And you’re counting Python- and Java-style references as pointers?

Deutsch: Absolutely. Yes. Programs built in Python and Java—once you getpast a certain fairly small scale—have all the same problems except forstorage corruption that you have in C or C++.

The essence of the problem is that there is no linguistic mechanism forunderstanding or stating or controlling or reasoning about patterns ofinformation sharing and information access in the system. Passing a pointerand storing a pointer are localized operations, but their consequences areto implicitly create this graph. I’m not even going to talk aboutmultithreaded applications—even in single-threaded applications you havedata that’s flowing between different parts of the program. You havereferences that are being propagated to different parts of the program. Andeven in the best-designed programs, you have these two or three or fourdifferent complex patterns of things that are going on and no way todescribe or reason about or characterize large units in a way that actuallyconstrains what happens in the small. People have taken runs at thisproblem. But I don’t think there have been any breakthroughs and I don’tthink there have been any sort of widely accepted or widely used solutions.

Seibel: They aren’t, perhaps, widely used, but what about pure functionallanguages?

Deutsch: Yes, pure functional languages have a different set of problems,but they certainly cut through that Gordian knot.

Every now and then I feel a temptation to design a programming languagebut then I just lie down until it goes away. But if I were to give in to thattemptation, it would have a pretty fundamental cleavage between afunctional part that talked only about values and had no concept of pointerand a different sphere of some kind that talked about patterns of sharingand reference and control.

Being a compiler and interpreter guy, I can think of lots of ways ofimplementing a language like that that doesn’t involve copying around bigarrays all the time. But the functional people are way ahead of me on that.There are a lot of smart people who’ve been working on Haskell and similarlanguages.