The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

Elegance and Other Design Ideals
A Conversation with Bjarne Stroustrup, Part IV
by Bill Venners
February 23, 2004

Page 1 of 3  >>

Advertisement

Summary
Bjarne Stroustrup talks with Bill Venners about many aspects of software design, including growing small applications into larger ones, avoiding class distinctions between designers and users, the dangers of premature generalization, and the essence of elegance.

Bjarne Stroustrup is the designer and original implementer of C++. He is the author of numerous papers and several books, including The C++ Programming Language (Addison-Wesley, 1985-2000) and The Design and Evolution of C++ (Addison-Wesley, 1994). He took an active role in the creation of the ANSI/ISO standard for C++ and continues to work on the maintenance and revision of that standard. He is currently the College of Engineering Chair in Computer Science Professor at Texas A&M University.

On September 22, 2003, Bill Venners met with Bjarne Stroustrup at the JAOO conference in Aarhus, Denmark. In this interview, which is being published in multiple installments on Artima.com, Stroustrup gives insights into C++ best practice.

Thinking Before You Code

Bill Venners: In an interview with Biltek, you said, "I'm not a great believer in elaborate design methods with supporting tools. I am, however, a strong supporter of systematic use of data abstraction, OOP, and generic programming. Anyone who just sits down and writes page after page of code without an overall design and without supporting classes and templates is simply wasting time and creating unnecessary maintenance problems." How much up-front design would you recommend. How much should we think before we code?

Bjarne Stroustrup: That depends so much on the size of the problem. If you have to write a little program that you need this afternoon, the design would probably would fit on the back of an envelope. If you are building a system that has to live for years and takes years to build, then clearly, you have to do more up-front design. If many people are involved in the project, you have to do more up-front design. However, the larger the system, the harder the up-front design becomes. Design tools don't give you much feedback, so therefore I tend towards the view that you should build a smaller system and grow it into a bigger one. There is a rule of thumb that says that every successful large system is a development of a slightly smaller working system. You apply that rule recursively.

Some people might think I'm talking about building prototypes. I am to some extent, but that's not all I'm talking about, because prototypes can also be a trap. If you build a prototype using a different class of developer, a different class of tools, and a totally different workload than the real application, you can get into really difficult problems. For example, you can afford much more hardware per user, much more software overhead, and much more experienced developers in the development of a prototype supporting ten users than if you have to support ten thousand users. You can usually also afford to ignore inconvenient standards issues and compatibility problems in a prototype. And then, of course, some solutions just don't scale.

Sometimes you can build part of the functionality of a system to try it out. I'm rather keen on doing very early integration tests. You decide what tools you want to use, and you write the logical equivalent of "Hello, world!" For instance, in a distributed system, you start off with the tiniest example you can of the application on the different parts of the system, and let them try and talk to each other. That's when you find that your Java ORB won't talk to your C++ ORB, or your Java virtual machine on the HP will not talk to the Java virtual machine on the Sun, or whatever. Obviously, such things that should never happen, but they do; maybe not the particular problems I mentioned here, but something unexpected always happens. I'm not just talking about prototypes. I'm talking about experiments and trying out all the things that eventually would have to work. Try them out early.

Thinking in Libraries

Bill Venners: I've often heard you state that C++ supports library design. To what extent to you think programmers who are just building applications should think of themselves as library designers? Should we partition our application into this library and that library? Or should we only think in terms of library design when we're creating a library for others to use?

Bjarne Stroustrup: I think people should mentally separate programming into building libraries and using them. Today you write a supporting library, and tomorrow you use it. Far too many times people try and build their systems as one big conglomerate. Even when I do individual work for only a short time, I tend to build some supporting functions and classes, and I design them to be supporting. I don't dive straight into building the whole thing that can do the whole job. So, whether you are by title a library designer or application designer, you should think about how you can separate logically the different parts of your system.

One of the problems with C++ is that there are too many libraries, and not any common marketplace or meeting place where people can find libraries and information about libraries. The problem with C++ and GUI is not that there's no C++ GUI library, for instance. The problem is that there are about 25 reasonable C++ GUI libraries, of which a few are rather good. But people say, "Well, there's no C++ GUI. It's not in the standard." C++ has no common meeting place like there is for Python, for example, where you know you can find libraries. It's a problem of riches, plurality, and a lack of marketing. Nobody in the C++ world seems to have any money to provide such a common meeting place.

One way you shouldn't write libraries is by taking the view that you are the great library designer. You provide the library for me. I use it, and you go away and do something else. You have to think of a library as something you yourself are using, and something that you have to live with as a support person for a longish while. You have to talk a lot to users to get the right abstractions and the right practical details. A library has to evolve. The best libraries are by people who are also users of the libraries. You can't have a class distinction between designers and users.

Page 1 of 3  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us