DDJ: "As close as possible to C but no closer." That was the title of a paper by you and Andrew Koenig wherein you identified the differences between ANSI C and C++. The tone of the paper was that those differences are proper and necessary given the different purposes of the two languages. The paper also stresses the inconsequential nature of most of the differences. Do you see those differences as proof that C and C++ can not be combined? Should they be combined?
BS: I don't think the two languages should be reconciled further than they are. The differences are quite manageable by conditional expressions. If you are writing C++, you use the new keywords and it isn't ANSI. If you are writing ANSI C you could have an option in your compiler that suppresses the C++ subset, and it will not affect the way you write code. It's much more an issue for language lawyers than it is for programmers. The whole thing can be exhaustively discussed on two pages and the differences can be listed in about ten lines.
DDJ: Will you rewrite your book, the C++ Programming Language, to reflect the new features of version 2.0?
BS: I will as soon as I get time. But it's more important to get the language stabilized, and so I'm working on a new language definition, a new manual. I am working on a book, as well, with Margaret Ellis that explains what C++ is, not, as the first book does, how you go about using it. The book states what the language is, what the implementation techniques are that make sensible implementations of certain parts, and why certain decisions were made.
This is a "what" book, not a "how to" book. In theory, it's a book for experts. If you have a question about what the language is, the answer should be there. Lots of people prefer to learn languages from such explanations. You never know who would want something like that. I learned ALGOL 60 out of the ALGOL 60 Revised Report. I'm not the only one who is sort of semi-masochistic in the way I read things.
DDJ: When will this new book be available?
BS: It's supposed to happen in December or January. The question is whether I can make it. The manual work itself is taking longer than it should. It's about twice the size of the original manual, not because version 2.0 is twice the language as version 1.0, but because I need to go into much greater depth.
If you can assume your reader's culture, you can take shortcuts in explanations, and there are certain words that you can forget to define without getting into trouble. C++, however, is breaking out of the C ghetto. People who were brought up with Pascal and wouldn't touch C with a barge pole are getting on board with C++. They come in and they try to read some of the standard C++ literature. When you get their comments, you learn what assumptions you made without explaining them. Such things must not be done in the manuals we are working on. It's getting harder to write a manual because the audience is becoming more diverse.
DDJ: One of the problems we've observed when function-oriented programmers attempt the transition to object-oriented systems is that there doesn't seem to be any way to describe the new paradigm to them in a way that they can learn it without actually using it.
BS: We'll eventually do better. The first books on C++ just said what the language was, put a thin veneer on top of it, or described it primarily as a better C. Lipmann's book and Dewhurst and Stark's book go beyond that and demonstrate how things are done. We have a major education problem on our hands. I've been saying that for years. You can write Fortran in any language, and if you only use C++ as a better C, you'll see improvements in your programs and productivity, but you won't get anywhere near what you can do or what we have seen demonstrated with greater degrees of data abstraction and object-oriented programming.
DDJ: The function-oriented programmer does not understand intuitively what the advantage of that is.
BS: It's hard to explain how to bicycle. I can talk myself hoarse and still you go up to a bicycle, and you fall off the first time. A certain amount of practice must be done. Programming is an art like riding a bicycle. It's learned by doing it. But you can certainly help the process. You don't just say to somebody, "Here's a bicycle. Ride." Similarly we need better education on how to use a language like C++ for object oriented programming. You can write better articles, use videotapes, put training wheels on the new programming environments, help programmers get started. It can be managed. It will be managed. The gains in doing so have been demonstrated often enough.
DDJ: Programmers have been told that they must unlearn what they have learned in order to use object-oriented programming, and they reject that.
BS: That's not what I am telling them. C++ is a better C, and it supports data abstraction, and it supports object-oriented programming, and, yes, you can forget all you have learned and jump into the deep end. But lots of people do it differently. They start out using it like a better C, they experiment on the side with the techniques they don't quite understand. Follow the literature so that you know the syntax, the basic semantics, and your tools before you take that big leap. Then try to focus on classes for a new project.
One of the advantages of C++ is that you can take some of the preliminary steps without a paradigm shift from function to object-oriented programming. You can learn the tools, the language, the basics, how to use debuggers, whatever it takes. And then one day when you find the right project, you can try the next step. We've seen that done quite a few times.
There are people who enthusiastically read all the literature, go to C++ conferences, and then go straight in, design huge class hierarchies, and program them. I'm always amazed when it works, but it does quite often. There are people who can write perfectly standard designed C programs, go away and wait two months and come back and write their first program in C++, truly object-oriented with tens of thousands of lines, and, lo and behold, it works. By all laws, it oughtn't. But it's happened.
Of course, I'm sure there are also people out there who have gotten burnt trying to do that.
DDJ: Would you offer your comments about the future of programming. What kinds of things do we need to understand in order to deal with software development in the near future.
BS: I think we'll see much more emphasis on the design of classes and the formal interfaces between parts, and an increase in the reuse of existing programs and libraries of classes. We will need tools that help us do this and draw structure or draw inference on what the structure is. Things like performance analysis and coverage testing will all be available. It's worth remembering that it's not a solitary activity -- not just one guy sitting there with one machine; many of the key activities are social.
We'll also need to develop ways of talking about programs that are ahead of what we are doing today. It's no good if we can compose programs and components out of classes if we can't talk about that activity in a sensible way. We don't have the vocabulary. It would be nice if we knew what object oriented design was. By and large, we don't know it yet. But that will emerge in five years and will be virtually accepted almost universally after that.
Al is a contributing editor and columnist for DDJ and the author of a number of books on C.
