Sponsored Link •
Bill Venners: In an interview with Rogue Wave, you said, "I wouldn't like to build a tool that could only do what I had been able to imagine for it."
Bjarne Stroustrup: Yes.
Bill Venners: How do we do that? How do we design for situations we can't imagine?
Bjarne Stroustrup: You listen to a lot of people and then you aim for generality.
Bill Venners: By generality do you mean more abstract solutions to specific problems? Or do you perhaps mean facilities that a lot of people will need to use? Define generality.
Bjarne Stroustrup: Let's take an example. A class can do just about anything. C++ does not have separate language constructs to specify classes for big objects, for small objects, for object-oriented classes, for value types, for GUI events, for properties, for threads, and so on. The C++ class concept is general enough to allow a user to specify all of those, and to do so efficiently. One example of generality in the design of C++, then, is that I didn't decide that classes should be only for big expensive operations because it's expensive to call them.
In addition to generality in the sense that you're not restricting users, you can also aim for generality in the mathematical sense. You make make sure all the cases work, that a whole logical design space is covered, as opposed to saying there are these five features you should be able to do and no more. Why five? When you design in terms of lists of features or lists of alternatives, you never get the design quite right. There always turns out to be just one more case, or one less. For example, in C++ there are no built-in facilities for doing exactly the events system for a particular operating system. There are general mechanisms with which you can write a class that does an events system for any operating system.
Bill Venners: Going back to the topic of the application designer who is thinking in terms of libraries, when should they put in general facilities versus specifically solving the problem that they have before them?
Bjarne Stroustrup: I really don't know. That's such a general question, and an honest answer must include "sometimes" and "it depends." I think I have a tendency to build the specific case first if I haven't tried something several times before, because it is pretty fundamental that we understand the concrete solution better than the abstract. When I see the same problem again and I get half way into the solution, I say, "Wait a minute, I'm doing the same thing twice." I did it once. I sort of understand it. I know what I mistakes I made in the previous solution. Now is the time to step back and see if I can have a general solution. That approach contrasts with the approach taken by people who start generalizing before they've tried it once—they sit trying to design a general solution to a problem that they have no experience with.
Bill Venners: That sounds like premature generalization.
Bjarne Stroustrup: Yes, that's right. You can have premature generalization as well as premature optimization.
Bill Venners: In your C++ Style and Technique FAQ, you say, "An ugly operation should have an ugly syntactic form." I thought that was an interesting approach to design. You want to discourage users from doing something, but you don't want it to be impossible for them to do it when they really need to, so you provide a way, but make it ugly.
Bjarne Stroustrup: Yes. That's the new cast syntax. Casts do provide an essential service. The new syntax is an improvement over the C-style casts because it allows the compiler to check for errors that it couldn't with the old syntax. But the new syntax was made deliberately ugly, because casting is still an ugly and often unsafe operation.
Bill Venners: What should our ideals and aims be when we are designing, and why? You talk about "elegance" a lot. What is the business return on investment for elegance, or whatever it is you think should be our goal in design?
Bjarne Stroustrup: "Elegant" and "simple" are very related words. "Understandable" is another word in that area. What do they mean? It comes to down to: you can apply tools to your program. You can optimize it. You can maintain it. You can port it. If you can logically identify something, you can deal with it. If it's just a bunch of code scattered throughout a large program, you can't do a thing with it.
One of the most elegant things, by the way, is something that's declarative. It's one of the reasons I like statically typed languages. You can say: this is a matrix of double precision floating point numbers. Now you know a lot. You know what it means to multiply. You have a whole theory for matrices. When you declare a class with a constructor and destructor and then make an object, it has been declaratively said that the resource will be released in the destructor. It's clear. It's right there. Humans gain understanding. Both humans and tools can do things.
When I use elegant,...
Bill Venners: Yes, what does elegant mean?
Bjarne Stroustrup: It's hard. If you see a proof in math, you can say it's elegant. It's as clear, as general, as short as you can make it. I was trained as a mathematician, among other things, and I think that's the kind of notion that shines through. There's an aesthetic here, but the aesthetic correlates very strongly to things people really want, like maintainability and reasonably fast development, because you're working at a higher level of abstraction and using higher level constructs. And there's efficiency if you want it.
I keep telling my students that they should be lazy. I reject programs that are too long, because when students get to do real work, they won't have time to write that much code. A lot of the things I call elegant you'll find are short compared to alternatives. One of the things that amazes people is when you compare good C++ code to good code in other languages, the C++ code tends to be shorter. C++ code is shorter when it's written in terms of things like the standard library or other good libraries, because you can express ideas very succinctly. That's one of my ideals. Say what you want. Say it clearly. Say it as generally as possible. You'll find the resulting code is relatively short and it will probably run fast too.
Come back Monday, March 1 for the next installment of a conversation with Bertrand Meyer. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Bjarne Stroustrup is author of The C++ Programming Language, which
is available on Amazon.com at:
Bjarne Stroustrup is author of The Design and Evolution of C++, which
is available on Amazon.com at:
Bjarne Stroustrup's home page:
Bjarne Stroustrup's page about the C++ Programming Language:
Preface to Third Edition where Bjarne talks about Programming is Understanding:
Publications by Bjarne Stroustrup:
Interviews with Bjarne Stroustrup:
Bjarne Stroustrup's FAQ:
Bjarne Stroustrup's C++ Style and Technique FAQ:
Bjarne Stroustrup's C++ Glossary:
Libsigc++ Callback Framework for C++:
C++ Boost, peer-reviewed portable C++ source libraries:
Al Stevens' review of The C++ Programming Language, by Bjarne Stroustrup:
Biltek interview with Bjarne Stroustrup in which he talks about not being a "great believer
in elaborate design methods with supporting tools":
Rogue Wave interview with Bjarne Stroustrup in which he says, "I wouldn't like to
build a tool that could only do what I had been able to imagine for it."
Enough Rope to Shoot Yourself in the Foot, a phrase Bill Venners mentioned in this interview in the context of the
question about protecting users from themselves, is the title of
a book of C/C++ style guidelines by Alan Holub: