A Conversation With Bjarne Stroustrup

In late 1989, Al Stevens stopped by AT&T's Bell Labs and chatted with language designers Bjarne Stroustrup, designer of C++, and Dennis Ritchie, known for his seminal work on C. The interview that ensued appeared in Dr. Dobb's C Sourcebook for the 1990s. Al recently made a return trip to Bell Labs and Bjarne and picked up where they left off.

--Editors

DDJ: Since our last interview in 1989, there have been many new developments in C++, most prominently the convening of the ANSI X3J16 committee. What is your role in standardizing the language you designed?

BS: Basically two roles. The formal role is that I am the chairman of the working group concerning extensions. We try and make policy for what can be accepted and what can't be accepted, and we try to look into specific proposals that come, trying to make sure that we don't have the language sink under an avalanche of good ideas. That's actually a very difficult role, partly because most of the ideas coming in are good. But if we took all the good ideas, the language would sink without a trace.

I take all the opportunities I can to tell the story about the good ship Wasa. It's a ship that was built in Sweden at the time when they had big wooden battleships, and it was going to be the best and most beautiful battleship in the world. It was even named after the royal family. They got it halfway built when the king noticed that the opposition was building ships with two gun decks instead of just one. This could be rather embarrassing because if the Wasa came next to one of these new two-gun deck battleships, the Wasa would soon be on the bottom of the sea with a lot of holes in it. So they added a few features. They added another gun deck, they added lots more beautiful statues. The king apparently was reasonably happy, but I hear the designer went halfway mad and died out of panic over what had been done. But whatever the case, the Wasa only made it halfway across the Stockholm harbor before it keeled over with a gust of wind and killed 50 of the people on board. You should go to Stockholm to see the Wasa; it is most impressive. I tell this story to people who want just another feature.

Avoiding featurism is not that easy, so one of the things I do is try to keep the language coherent, try and make sure that the features accepted actually fit into the language instead of being warts on the side. Of course, everybody claims that their feature fits into the language, and it's not a wart. You can argue for every feature--and people do.

In general, I try to take as much part in the standards process as I can, and try and bring a longer perspective to things. I've been involved in this for 12 or 13 years, and some people came in a couple of months ago. I try and point out that there's a history here, try to point out that some of these problems and suggestions we've seen before, try to point out that the whole world is not a Cray, that the whole world is not a PC, try to point out that not every programmer is a C programmer, not every programmer thinks that Pascal is the greatest thing since hot dinners; I basically try to balance things out. That's another sort of role that is hard for a lot of other people to play. For that reason it sort of fell on me because I was there. One of the things that's important in this context is trying to keep the language from mutating into something very strange, keeping C++ as close to C as possible but no closer. That is a policy that allows us to gain the benefits from C, from the C standardization, and from the C experience without closing the path of evolution and of using new techniques.

DDJ: When do you foresee the publication of a formal standard?

BS: We have to go for public review in late '93 according to plans, and then it takes many months for people to come in with comments, and it takes at least a year to work over the comments and work them into the standard. So, maybe '95 or something like that. Now, people think that's forever. But what they don't realize is that that is actually an incredibly ambitious program for an ANSI and ISO standardization. C took seven years.

People should realize that there is a very important role for the standards committee in addition to producing the standard. That is to act as a forum where people can meet, discuss things, and agree on things at least until they agree on something else. It allows the community to pull together around a draft standard and settle issues instead of having people sitting, one guy in California, one guy in Seattle, one guy in London, and making their own decisions about what really should have been in and what really was meant by this or that sentence in the ARM [Editor's note: The Annotated C++ Reference Manual, Ellis and Stroustrup, Addison-Wesley, 1990]. So, I think that the ANSI/ISO committee is very, very important as a forum for discussing issues and for disseminating knowledge and disseminating techniques. In that sense, the standardization effort started to do good at least a year before the ANSI/ISO committee was convened. Because that was when the community started talking seriously about should the language be standardized, when should it be standardized, how should we standardize it. People started talking together. To a large extent the ARM was the first effect of what was coming. It was written with the knowledge that a document would be needed. If you look at the acknowledgment list, there are more than a hundred people, and you didn't get onto that acknowledgment list just out of politeness. These are people who did some work.

DDJ: Can you predict how close to the ARM the standard will be?

BS: Many of the words will be different because one of the things we need is more precision. But the spirit of the language will be the same, and many of the details will be the same. There are millions of lines of C++ out there, and most of them will still run in five or ten years. I don't see any major language extensions coming--but you can have a nice little debate about what is major. I most certainly don't see any major incompatible changes being done. There are things in the C++ language that I don't like. There are things in the C++ language that I've tried to remove on several occasions. But I don't think that we can do such things. I'd like to get rid of the declarator syntax, but I know I can't. It's not even going to be seriously discussed because it's there, and even an ANSI/ISO committee can't do anything about it at this stage. We know how to live with it and so we'll curse a bit, but we will actually not make a change. Compatibility and stability are very important goals.

DDJ: Will Cfront continue to evolve during the standardization process?

BS: Sure. I expect that Cfront and all the other C++ compilers will continue to evolve. Some of them will die for various reasons. At least they might conceivably--I'm not sure that any of them will. But since there are so many players and since there is a fair amount of commercial competition, it wouldn't be surprising if some of them didn't survive or if some that are being built don't quite make it to completion. I think Cfront still has a niche. Cfront was designed as something very portable, reasonably correct, as a tool for giving people the ability to port to something new, to use C++ on platforms where there wasn't any specific native C++ compiler. And with the hope that eventually somebody would--in each ecological niche--build something that could take advantage of local quirks to do a better job. But Cfront was built to be hard to beat--to force competitors do do better--and it will act that role out for some time yet. Even when all the specialist niches have been taken over, some version of Cfront may still have a role as a vehicle for cross-platform portability. Some versions of Cfront actually have "gone native" as they start taking advantage of specific environments. The Cfront version that goes on the HPs, for instance, has native code generation and integration with an environment. Similarly, the Cfront version that is part of Centerline's (Saber's) environment doesn't look or feel like Cfront, but it is. Versions of Cfront adapted to local environments may have a long life.

DDJ: Are you still actively involved in modifying and maintaining Cfront?

BS: No, but I use Cfront as an experimental tool. I feel uncomfortable talking about language extensions without having implemented them. For example, the series of ideas for runtime type identification I implemented using Cfont. So for me it's an experimental tool--and of course my compiler for everyday work.

DDJ: Have there been major standards issues where you and the committee have disagreed?

BS: I don't think so. There has certainly never been a situation where here's the committee and here I am. There have been situations where part of the committee goes one way and part of the committee goes another way. The most major of those was the so-called "great debate" over termination semantics for exceptions, which we worked on for a long time and before accepting the semantics described in the ARM by a great majority. In discussions, of course, I'm in the minority some of the time and in the majority at other times. Working things out takes time, and you work it out. I don't get my way all the time, but I've got a pretty good track record simply because I can work on this slightly more full time than a lot of people, and to some extent because I'm more willing to compromise. I don't get along very well with "true believers," and I feel that a lot of compromise is necessary when you are dealing with something as big as C++ with so many interests involved. For example, one of my language-extension proposals was shot down in flames. That is probably a good lesson for some people who want to add features to C++. Apparently good ideas don't always work, and even some of mine go down in flames. Typically because they ought to go down in flames. In the case I'm thinking of, it's just good we noticed the problems before we voted on it.

DDJ: You attend software development conferences, often give keynote addresses, and talk to the programmers. Is the mood of the programming community shifting closer toward acceptance of C++ than it was three years ago?

BS: I really try to go away from my office only once every second month for a conference or something like that. And that means with ANSI standardization in the works, I probably only make three or four major trips a year. It's not exactly as if I was a traveling circus. But yes, I go and I try to keep my ear to the ground and understand what people think. One thing that's a problem with conferences--or talking to people in research departments, or reading the net--is that there are a lot of people who are at such places because they like new ideas, because they really want to know the latest or because they really know what the latest trend is. It's actually much more interesting and much harder to talk to people working on software "in the trenches." At conferences and such I like to be lurking around in a corner arguing with somebody who's not up on the latest trend and seeing what their problems are. It's much more interesting hearing about problems than hearing--for the thousandth time--the latest solution looking for a problem.

DDJ: In your keynote addresses you still recommend that the shift from C to C++ should be a gradual one, with programmers learning the improvements a small step at a time. Do you foresee a day when object-oriented programming is the first natural way that students learn to write software?

BS: Yes, I think so. I'm talking to mostly fairly experienced programmers who are coming aboard to C++ and object-oriented tools and techniques from a background in something like Pascal, Modula-2, C, or Fortran. For such people it makes a lot of sense to leverage what they know and move them along a gradual introduction to the ideas. That's what we know how to do, that's what we've done, that's what we've seen successes with, and we haven't seen the disasters that have been noted from coming from the other "100 percent OOP now!" direction. People express fear that programmers never get to the object-oriented stage by "going slowly." That's just not my experience. Sometimes people say that they've been using C++ for half a year and they're not fully OOP yet. So what? After half a year people are much further on than they used to be and after a year to a year and a half you will see them all the way. "Going slowly" also allows people to gain a much greater appreciation of where the different approaches work best.

Now, the question is not so much will there come a day when another approach is more appropriate because there will. The question is, "What will it take to make the other approach reasonable?" Partly it will take that a lot of the professional programmers have already made it most of the way so they can start. In other words, the gradual approach will have brought the majority of programmers to the point where they are ready for the OOP and data-abstraction techniques. But it also takes better libraries and better environments than are common these days. In particular, we're only just seeing the beginnings of decent environments supporting C++ programming. We have the UNIX/PC traditional environments, which, from sort of a detached point of view, are so-so. Of course, they're much better than they used to be, but still we're only a very small step along the way, and we have the Smalltalk implementations that are sort of great in some ways but do not support a statically typed language all that well and have a tendency to lock people into a small environment. What I would like to see is a programming environment that really understands the language--and by that I primarily mean the static type system--and that really can be helpful in finding things in debugging, in designing, in displaying the structure of programs, in performance measurements. One of the sources of problems with object-oriented programming has been people going overboard with purity and cleanliness, and creating very slow monsters. I think the only thing that really will bring that to an end is the ability to do decent profiling simply. We will need better libraries, because if you want to start out with object-oriented programming, you need a good library to support the concepts.

With C++ quite often people as a first exercise write a string class and as a second exercise try to do a graphics system. That is very challenging and might be very nice for a professional programmer, but it's not the best way of teaching the average student programmer. What we need is an environment that has a very good string class that you can take apart and look at and has a very nice graphics system so that you never care about Windows or X again unless you absolutely want to. So I think the two things needed to be able to start with object-oriented programming are an environment and a library. Then we could also do with better textbooks for beginners and we could do with better design books for slightly more advanced people. All the components of what I'm talking about are "almost there." We have decent textbooks for beginners, although I'd like to see them better. We have decent design books, although I'd like to see them better. We have decent environments, although they're not as good or as widespread as I'd like them to be. Give it another couple of years, five years maybe, and we'll actually have all these bits and pieces together. It will be most interesting. Then, I don't think there will be any real discussion about what the right approach is. People who want to jump straight to "true object-oriented programming" now have simply underestimated the size of the job and have overestimated the ability of the current support for doing so. It's alright to jump, but we have to land on our feet.

DDJ: In your presentations you joke about C++ and call it a "strongly hyped" language....

BS: No I don't. I joke about people having strongly hyped languages and about people using hype and exaggerated claims about the languages to get users, and using advertising gimmicks instead of logical argument and solid case studies. I am against that behavior even when done by C++ proponents. Maybe it's worth remembering that for many, many years the only language in the field of object-oriented programming that did not have advertising and marketing and all of that was C++. C++ became the most used object-oriented language before the first C++ marketing campaign and the first paid C++ advertising appeared.

DDJ: Nonetheless, there has been hype. Do you think it has hindered or advanced the cause of C++?

BS: I think all hype has the effect of giving a temporary advantage which turns into a larger disadvantage soon afterwards. People don't deliver what they promise. I think that C++ has promised much less than the opposition and delivered a much larger fraction of what was promised.

DDJ: The ARM identifies templates and exception handling as experimental. Compilers and translators now exist that implement templates in close compliance with the ARM's definition. Are the template and exception-handling designs reasonably firm now?

BS: Oh, definitely. They're marked "experimental" because you must have a first or a second printing. In the third and later printings, the "experimental" has gone and instead there's a note saying that this text was voted into the language by the standards committee complete with the dates of when it happened. Yes, the designs are firm. They have been implemented. Minor details will be elaborated and made more precise, reflecting the experience from implementation. There may even be minor changes. I wouldn't be surprised, but I do expect my old code to keep running. I am quite unhappy about standardizing things where I don't have personal implementation experience, but I seem to have been reasonably lucky with exception handling and templates. They can be implemented, and they have been implemented as specified. I have talked to several of the implementors and gotten some of the darker corners pinned down and some of the things where the text is either so short that people could wonder if it was really there or where it could be read in several ways. I think we'll see some clarification but you have to be a language lawyer to even find the spots.

DDJ: What are the major additions Version 3.0 adds to C++?

BS: Version 3.0 is the language described in the ARM and in my second edition [Editor's note: The C++ Programming Language, second edition, Addison-Wesley, 1991], minus exception handling. Version 2.0 didn't have exceptions and didn't have templates, and there was a variety of minor facilities and clarifications that hadn't been implemented, but they are very minor. The new thing in 3.0 is templates, and the next wave of C++ compilers will be exception handling. I hear that IBM has actually started shipping their compiler for the RS/6000 series, which supports both templates and exception handling. If so, it's the first generally released one.

DDJ: Have you used any of the C++ compilers on the PC, and can you comment on them?

BS: People always ask me that. And people keep sending me implementations--and often two weeks later their marketing department asks what I think about it. I have a simple defense. I don't have any hardware that can run that stuff. I never load them. Actually, I would like to play with them because I hear that they are very good, but I hardly dare to do it: It would cost me too much time.

It is amusing to hear these discussions about whether X is better than Y because, for most users, X and Y are simply beyond what they've had before with C and other languages by a large factor. They have major squabbles about the last fraction of a percent and usually about very obscure things. I think the technical departments of just about everybody in the C++ field are better than what people have been used to in the C field. Marketing is scrambling to find ways of saying they're much better than competitors, but they're all so good that that's a hard job.

DDJ: Some C++-style conventions are emerging and being taught, particularly in the area of class design. For example, we are told to place public members before private members; to have no public data members; to code inline member functions outside of the class declaration; and so on. How important are such conventions, and should they be formalized?

BS: Style is important, but it's very hard to legislate. It's like saying, "Do you like dark chocolate or milk chocolate?" I prefer dark chocolate, especially with nuts, but it doesn't mean that I should legislate that you have to eat it. From a language designer's point of view, I try to teach a little bit by example, and I try not to make statements of the form, "Thou shall not," or "Thou shall." If you look at some of the style guides, you often find lists of things you must and must not do, which are simply transcriptions from where my second edition says, "You might like to do that," and "Only do this if you know what you are doing." If you have a software shop with a group of people who have to work together, it's a good idea to sit down and make a set of rules. It's good to look at something that has evolved over time to have some experience. You can look at the style used in my books or somebody else's book. Start from one of them, evolve from one of them, try to have a house style, and don't get upset about spelling rules and whether public or private comes first. That doesn't matter very much. It matters much more whether the programmers understand what is an abstract class and what do you use it for. What are the pros and cons of having a rooted hierarchy? When do you want a concrete class? Things like that, which are not usually in the style guides, are much more important for writing successful programs. The trouble with a style guide, especially if it's enforced by a non-C++ programmer, is that it favors form over substance. A good style guide would free people from thinking too much about stylistic issues. I dislike style guides that think they can force people to do what's right because a style guide can't.

DDJ: Programmers and managers often ask, "When should we use C and when should we use C++?" Given a competent and motivated design and programming team and the availability of both languages, are there circumstances in which C is a more appropriate tool than C++?

BS: Given all that you say, no. My usual answer to that question is, "Look at the tools." If the C++ tools are there, use C++. Otherwise use C. You may not be able to make the transition tomorrow, but that's usually because you need to install the tools. C++ is a better C. Just go use it. Notice that my answer is different than the one I gave some years ago. Things have matured.

DDJ: Let's play a phrase-association game. I'll mention some areas of interest to C++ and object-oriented programmers and ask you to share your thoughts on them with us. Concurrency.

BS: It's been well known for the last 30 years or so that next year concurrency will be very important. I did my PhD on concurrency issues, and I came out of Cambridge knowing 40 ways of getting it wrong. I was sure that I did not know a single way of getting it right for everybody. From that observation came the policy for C++ that we don't put concurrency features into the language. We try to provide libraries and primitives that allow you to build concurrency features--systems for a particular application. This has been done. A simple and primitive example was the task library which I wrote for simulation and which was later adapted for robot programming. There are other examples of concurrency-support libraries. I have not seen as much as I would like in that respect, but I would like to see libraries supporting a variety of notions of concurrency for C++. I consciously decided that I didn't want a medium-level facility like Ada's, which pleases teachers but is too high-level for the kernel hackers and too low-level for the database guys.

DDJ: Persistent objects.

BS: It's easy to say and hard to do because persistence covers every thing from writing an object out to disk and getting it back to having a full-blown distributed object-oriented database system with concurrency control, transaction logging, etc., for multiple users. It is an area where a lot of work will be done. We have several systems supporting various forms of persistence for C++. But again, I strongly suspect that it's not a language issue. It's an environment issue; it's a library issue; it's a tools issue. The work that we are doing on runtime type identification will provide some support for people who want to do databases and object I/O. There will probably be a standard form for tying in added information about object layout and such.

DDJ: That old chestnut, portability.

BS: Portability is an economic issue. You're portable if it's cheaper to modify the program to run somewhere else than it is to build a new program from scratch. The best definition of portability is that it's much cheaper to port it. People who are thinking about 100 percent portability are deluding themselves. You can only get 100 percent portability provided you port between two systems that are very similar. And we can't get everything in the world very similar in that sense. I don't think the environment of a Cray should be the same as the environment of a 386 to the point where you could guarantee that every program that ran on the one would run on the other. The people who use the one kind of machine have one kind of concerns, and the people on the other have other kinds of concerns, so portability is always something that will take a certain amount of work. Though we'll always curse and say that's too much, I suspect that over the years it will steadily become better. But people should realize that 100 percent portability is a very dangerous idea, because that's sort of a return to the Middle Ages where everything is what it was in my father's time, and nothing changes. That's a caricature of the Middle Ages, true. It wasn't like that. If it had been, we would never have gotten the Renaissance. We don't really want the world to be so uniform that 100 percent portability could be guaranteed. We don't want to live in such a world.

DDJ: Standard class libraries for fundamental data structures.

BS: One of the things that I regret about C++ and its development was that I didn't take a half-year break just before I published my first book to write the libraries I planned. It would have been very useful to get just the basics. We have I/O. I had complex in as an example. It's not very important except as an example and to some mathematicians and engineers. It would have been nice to get lists--arrays with bounds checking--especially in associative arrays. They're the most useful single data type there is. Just a few things like that would have created immense leverage for people building more extensive libraries. Beyond that, I have my doubts about libraries intended to work for "everybody." We need libraries that are standardized for a given domain. A standard library for workstations, maybe, one for certain kinds of mathematicians, one for Frenchmen, and another for Japanese dealing with text processing. A standard library for a certain industry such as CAD/CAM or telecommunications. I don't believe in intergalactic standardization. The world is just too big. You have to have room for innovation in many places, and you have to understand that not everybody can agree on everything. The basis for agreement in C++ for the moment is too low, but there is a lot of healthy diversity also in the C++ world. The standards committee is looking into this problem. One reason I didn't solve the problem in '85 and one reason that the standards committee hasn't gone further was that we lacked model libraries that didn't lock everybody into doing things the "one right way." A lot of people were looking to Smalltalk and the single root hierarchy as the standard way, and it was clear to us that we couldn't do that because that imposes a fixed cost on everybody. You can never get a really fast complex number if you have to fit into a library hierarchy that has a class object at the bottom. You can't get a real small complex number. You can't get a complex number that will have layout com

patibility for a

n array of complex numbers with Fortran. In other words, you damage the ability to invent independently and to cooperate with the rest of the world in your own language or in some other language. We needed a model of libraries that didn't have that problem. I think we have one now. The library-design chapter of my second edition discusses the classification of classes by saying, "We have concrete classes." These are classes that are meant to behave the way the built-in types are. It's things like a complex number or string. Nothing fancy. They're meant to be reused as building blocks for something else, but not through derivation. They're meant to be focused on one problem, not generalized. They're meant to be efficient in time and space. They are very much like integers. They are free-standing for that same reason. They are not part of a framework. At the next level we can have abstract classes. You have an abstract interface, and you can use hand-coded implementations for them through derivation, or you can use concrete data types to implement them. The abstract data types then become a way to tie in separately compiled and separately developed classes--separately developed code to have a common interface to use. Importantly you can do it after the event, after classes have been developed separately. What is wrong about the class hierarchies is that you have to design the hierarchy first and then fit things into them. With the abstract classes you can have all the bits and pieces out in the world and then you can tie them together after the event. I think you'll see a lot of libraries that build along that idea, and I think you might see a little bit of work in the standards committee in providing a set of classes that can be used to do something like that.

I'll give you an example. Say that I want to write my program so that I can read data structures--files and such. I can build myself an abstract iterator class that gives me the next element. I can then tie it to either a Borland container or a Microsoft container, depending on which way the wind is blowing or which day of the week it is or maybe even use both of them in the same program. Importantly, I can write my program independently of which of the so-called "standard libraries" we are using. On the other hand, I'm not trying to dig into their business. I'm not trying to replace their library or replicate the work they've already done. I'm just trying to provide an interface between what they offer and what my program uses. That kind of thing is very important. In the context of libraries, there were language feature reasons for not succeeding in '85. If you read the paper I wrote in early '86, "What is Object-oriented Programming?" you'll see I bemoan the absence of templates as a way of expressing container classes and operations that are parameterized by types. I don't think we could do a really good job before we had templates. Now we have them.

DDJ: C++ CASE tools.

BS: I don't have much personal experience. There seems to be lots of them. There is one kind of CASE tool which I have seen, and I'll draw a deliberate caricature here and hope that nobody will recognize their own product in it. In the caricature, you have a bunch of managers who have decided that programmers are evil, and you have to produce a straight jacket for them, so that they cannot think, and if they think, they have no way of expressing what they thought. They should just provide the code that designers wearing suits have come up with and specified. One of the worst things you can have is language dependence, so everything has to be language independent, meaning you have to program in the common subset of C and Cobol that these managers and designers knew when they were young, back in the Middle Ages. This is the caricature, and this is what gives CASE a bad name.

The last time I looked around a trade show, I didn't see anything offered that fit that model very well. Everybody was trying to be more flexible, everybody was trying to understand that there were such things as classes, and that types had some place in a programmer's conceptual world, and that class hierarchies were important and such. To the extent where CASE tools actually help programmers instead of just being a straight jacket and stifling anything new, to that extent it's good. You can do nice things. But I still feel that there may be a legacy somewhere that's very worried about what the programmers might do. There are a lot of people in the computing industry who don't like, understand, or trust programmers. Traditionally, one of the slogans in C is, "Trust the programmer." To some extent, C++ has that in it still. I do not consider programmers inherently evil or stupid, and I think any system, be it a language or a CASE system, should leave open the possibility for showing initiative and doing things in slightly unusual ways because, related to one language or one CASE system, most of the world is unusual. For a better idea of what I think about design issues and how they relate to language issues, read chapters 11 and 12 of my second edition.

DDJ: Critics of C++ tend to also be critics of, or at least holdouts from, object-oriented programming. They often point out imperfections in the C++ language. What, in your opinion, are its major weaknesses?

BS: First a general observation. Since C++ is so much out in front, it seems that everybody agrees that it's wrong and not good enough. That's the only thing they agree on. Some people want some other object-oriented language, somebody wants a 4GL, somebody wants a functional language, somebody wants something completely different, somebody wants to stay back in the C and assembly-code world. But everybody agrees that C++ is not the answer. This is the nature of being out in front. A friend of mine once said, "You know when you're out in front. The guy out in front has the arrows in his back."

C first and then C++ are among the few languages that say, "Yeah, we're not perfect." There are a lot of trade-offs here. This is the real world. There are some things we don't like, and we can't do anything about them. There are some things we don't like, and it's too hard to do anything about them. Perfection, in some language theoretical sense, is not an aim of C++. Utility is. C++ allows you to write programs faster than you can do in C. It allows you to build better tools. It allows you to write programs that run faster than anything comparable in terms of expressiveness. It allows you to structure programs well. It allows you to deliver on time and within budget. In many cases it allows you to support various design strategies. It allows you to fit in an environment that is not meant specifically for an object-oriented system. It allows you to coexist with C and Cobol and Fortran. That's what matters, not whether I know a better syntax for declaring variables than the one we've got in C++. I knew that 15 years ago, but it's a second-order issue. So my answer is, "It works."

DDJ: Do you have any opinions about what form the next major programming paradigm might take?

BS: Not really, I spend too much time in the trenches getting C++-related stuff to work. I don't think that whatever the next great wave is will sweep away everything in front of it. Like all the other good ideas, they tend to get absorbed and adapted. Ideas that are totally alien from what we have now don't make it out of a cult world. Structured programming worked as far as it fitted into ordinary programming. Data abstraction worked as far as it fitted in with other programming techniques. Object-oriented programming is going to work as far as it fits in with the rest of the world. Whatever comes next--I would like to see some rule-based systems, I would like to see some parts of a system functional, and such--will fit in with other things. Otherwise they will stay largely unused. People forget that the idea of having exactly one language used for everything else is sort of strange. I don't think a single language can serve all uses even for one model of the adventurous programmer. We'll always see places for many languages, some of them very specialized. We will see experimental languages that you hope will do things much better than C++ in some areas. What comes next will absorb from these experiments.

DDJ: Will you continue to contribute to language design and development beyond C++?

BS: I don't think so. I got into this because I needed some tools. In a couple of years I will have them--10 or 15 years later than I thought. After that I don't quite know what I'm going to do. I have no wish to become a professional language designer. It doesn't seem a good idea. I am currently trying to use what little time I get to move away from language design and get more into tool design. To my mind that's not all that different because the language and its compiler are just prominent tools. So I'll go back and dream up some different kinds of tools, maybe to do with programming. But, language design? Nah.

Copyright © 1992, Dr. Dobb's Journal