Dr. Dobb's TechNetcast  




dr. dobbs journal

TechNetCast @ SD'98 East

An Interview with Bruce Eckel

Bruce Eckel Bruce Eckel is in a unique position to compare C++ and Java. In this interview, he reflects on the strengths and weaknesses of both languages from a learner's perspective and focuses on the impact of adoption of a C++ standard on users.

Thousands of programmers owe their better understanding of C++ or Java to the work of Bruce Eckel. His success in explaining the complexities of programming languages can be attributed in part to the thoroughness, patience and intellectual honesty that characterize his method. Bruce is himself a patient student of these languages. An early member of the C++ standard committee, he learned the language directly from its creators, as it was being designed. This experience led to the award-winning and hugely-popular "Thinking in C++". At the onset of the Java wave, intellectual curiosity pushed Bruce to dive into Java programming. The result was "Thinking in Java". His personal work, his teaching activities and his constant contact with users, his grasp of both the C++ and Java languages give Bruce a unique perspective on programming.


This interview is part of a series of discussions with leading programmers broadcast live from Software Development 98 East, August 18-20 1998. Interview by Philippe Lourier.

Post and read comments about this interview on the TechNetCast forum.




Links
  • Bruce Eckel's website
  • An earlier TechNetCast program with Bruce Eckel
  • TechNetCast @ SD98 series interviews with leading programmers


DDJ: When we caught up with you a few months ago, at Web98, you were getting ready to start work on the second edition of "Thinking in C++". And you seemed to have some dread at that prospect

BE: The second edition, yes. It's going to be huge It's big.

DDJ: It's now a work in progress, available on your website.

BE: Yes. It's up on the Web site and I'm doing all sorts of experimentation with it, and catching up on what's happened with the standard since I was buried in Java. It's interesting to go from Java back to C++. You can compare the two and see where the real complexities are. I understand why all the complexities are there [in C++]. It's for backwards compatibility with C. But at the same time you can see how much time is lost struggling with them. On the other hand, it's still fascinating.

I'm somebody who is fascinated with programming languages and so as I pick apart each part and discover what's going on, it is still entertaining . In the front of my mind is how much time people are spending trying to figure some of these things out rather than be productive.

DDJ: Well, it is claimed that Standard C++ is easier to learn than previous versions of C++. One reason for that is that it's actually a higher level language now -- in large part because of the STL. Do you buy that?

BE: Oh, yeah. Yeah. Having the standard library is such a huge step forward. By just having strings and the cleaned-up I/O stream class you can start from the beginning and skip over all the black holes in C, using [constructs] that are much easier for the beginner to understand. Simply because you don't have to say, "Okay, we have NULL-terminated strings and we have to worry about these details". The STL certainly makes [C++] a higher-level language. It's a little bit of a hurdle to get used to it, but the basic core of it, just being able to use the containers, is a wonderful addition to have in the language. It's fairly easy to make containers of strings, for example, and there's a ton of things that you can do with containers of strings.

DDJ: But how realistic is the statement that you can program in C++ without knowing low-level details? For example, it is reasonable to expect that at some level the STL does use NULL-terminated strings to implement strings.

BE: Well, no, not necessarily. That's an implementation detail. I'd say strings in particular hide a lot of things from you and there's not much you really need to learn in order to use them. In other words, you don't really need to know much about the low-level details. For example, the strings could be a reference-counted implementation or it could be a copy implementation, and you really don't know.

DDJ: So it's not important to know how memory for strings is allocated, for example.

BE: I suppose you could say that at some point a lot of these [issues] become important if you're worried about optimization. Optimization is always important at some degree, but you will in most cases simply want to get a program working, and the strings library, for example, makes life so much easier in achieving that. When working with the STL and containers of strings, for example, there are some very weird things that are going on underneath the covers, but in general you don't need to know those.

The tricky part gets when you, when you start creating your own classes and want to put them in the containers. You tthen need to know the certain basic canonical forms that are necessary to follow in order to make sure that your classes work properly with the containers.

C++ is very much like this. There are very often things that you can do at the basic level and allows you to accomplish a great deal. And then as you need to know more, and want to know more, you need to research a little more.

DDJ: I'm just a bit skeptical because in my experience you have to know more much faster than you think you do. As soon as you hit a problem, then you really need to know what are the underpinnings beneath some of the higher-level constructs being used.

BE: For example, very rapidly you often need to know what a copy constructor is, what an operator= is.

DDJ: That fact that it actually may allocate memory to create a new copy of the object.

BE: It may. You do need to understand what's going on when you're creating your own classes and when they start being used in more sophisticated [ways].

DDJ: We had Nathan Myers on the show on a few weeks ago and he said he believed that C++ was a language for professionals.

BE: Yes. I think that's a good -- I can see teaching C++ to beginners to a certain level. And a lot of it is because we now have some of these libraries. In fact, in this book I'm planning on saying, "All right, opening files is pretty easy, it's easier than in C. Creating a vector of strings and reading in a file is pretty easy." There are many things that you could do that might compete with Perl programming, for example, and that people could pick up fairly easily. But there is also a jumping off point, when you start creating your own classes and need to understand inheritance and polymorphism, copy constructors and operator= and what we would call the canonical form of classes that you need to create in order for them to work for everything. Yeah, I would say that's a bit of a steep learning curve.

DDJ: How will the new constructs and abstractions introduced in the language influence the way you introduce users to C++? The book is very big on abstractions.

BE: Huge. I plan to introduce the step that I just mentioned actually much earlier on, and move away from the C model early. Particularly the more error-prone C concepts like C I/O and C arrays -- I plan to move away from those early. I introduce dynamic memory allocation using new and delete instead of malloc() and free() early on, in a simple fashion, and then in a later chapter go into it in more detail.

But the book is acquiring chapters on the standard library and design patterns that are making it bigger. There are a lot of additions to templates, and the templates chapter will be [beefed up].

DDJ: In what detail will you cover templates, for example? Will you mention argument deductions for function templates? And how about function objects?

BE: Well, you have to go into function objects to understand the STL algorithms -- that's later on. The templates chapter will talk about, well, I don't know... I feel like I have to cover everything that will be used by maybe 90/95 percent of [programmers]. I feel like I have to cover it in a way that it makes it easy to understand, and this means a lot of research. I'm trying to get help for this from people who are template experts, because there are a lot of features that myself and some other people that I know are having a little struggle figuring out.

DDJ: Some of this stuff is also non-trivial to implement.

BE: For the language implementor it's very hard, and we're seeing people struggle to try and

implement the language. The first compiler that I've gotten that actually seems to have some promise is the KCC compiler, which doesn't run under --

DDJ: What are the chances of soon seeing a complete, or nearly-complete implementation of the standard?

BE: Well, the Kai C++ compiler is the closest [implementation] that I have seen at this point. I know Borland is also working very hard towards implementation. I heard from Nathan [Myers] that the egcs compiler, the free one, is about six months from completion --well, actually, less than six months, by the end of the year. Some of the others are working towards it, but those, those three seem to have the most promise right now. Some of [these projects] are working with the Edison Design Group front end which apparently is the closest to compliance.

DDJ: Okay, let's talk a bit about Java What lessons have you learned about Java now that you've re-immersed yourself in C++?

BE: I'm more and more impressed with the effort that was done by the Java team. I can't read their minds, but by looking at the design, it appears more and more obvious to me that their thought was to make life easy for the programmer and solve the hardest problems for the programmer, like portability. It's

possible to have portable C++, but it requires a lot of extra work. With Java they said, "Okay, let's solve that problem. Yes, it's going to cost some extra performance but we think that the programmer productivity in the end is more important than that."

DDJ: There are a lot of implementation details that are exposed in C++ and that are totally hidden in Java.

BE: [They are exposed in C++ for] backwards compatibility with C. But the designers of Java set to do a redesign. Everywhere you look, the packages, multi-threading, you say, "Gee,

it looks like they were trying to find the simplest construct for the programmer to understand"

DDJ: Built-in concurrency primitives are an example of that. Actually, according to Stroustrup's "Design and Evolution of the C++ Language", there was thought to add that to C++ too, at some point early on.

BE: It was considered. There was a concurrent C++ library at AT&T and the decision was made

not to put it in, primarily because there are multiple models for multi-threading and if C++ chose one --

DDJ: You'd get stuck with that one model.

BE: Well, it may force people to use that one particular model, and it would reduce the

flexibility that C++ is known for. Whereas, with Java they said, "It's really important to guarantee a multi-threading model on every platform" . Some platforms don't support multi-threading. Well, if they want Java, they're going to have to come up with something to [support] it. So from the programmer's standpoint, you learn one model and you know that it's always there and that it is portable.

And then you start looking at all the libraries A telephony API library I've never used such a

thing but if I do, I know that that's probably going to be the easiest way to figure it out.

DDJ: Well, should that be part of the language? Java is a platform.

BE: Well, sort of. Java is a wrapper for a platform. You think of it as it's encroaching on the operating system but it doesn't. It doesn't do the operating system. What it does is it wraps the operating system. I don't think so much about write once, run anywhere, but I think about learn once, program anywhere. So you learn what is probably the most simple model for whatever it is that you're trying

to do, and you don't have to re-learn it.

DDJ: What if the implementation is substandard? With Java you get not only the API, but also the implementation.

BE: Well, for some things you have the implementation. For example, the telephony API should plug into operating system support. But the Swing library, for example, actually finds out the very primitive way to draw things on the screen, and then builds everything on top of that instead of using the old, and what turned out to be not so good, peer approach. So in this case you do have an implementation that comes with the GUI library, but in my opinion it's a big improvement over what we had in the

past.

DDJ: Bjarne Stroustrup has said that one important criterium in assessing a language is

the joy that it brings to the programmer. Which language do you have most joy programming in, C++ or Java?

BE: Boy, that's hard to say. You know, I think the joy comes from different places. C++ has such intense power, but you pay for it. For example, now I have to figure out templates. For the first time I've actually got my hands on a compiler that will [handle them properly]. Its full of intricacies, but of course if you do figure it out, you can write pieces of code that are pretty amazing.

DDJ: And there's also enjoyment in learning.

BE: That's a lot of it. You figure something out and then explain it. But see, of course, I'm in this little area where my goal is to figure out all these features. Once I figure them out, I really enjoy explaining them to people. But I think a lot of [programmers] get a little frustrated trying to do things and running up against walls. For me there's a lot of joy in a lot of different places, but [this may not be the case] for the regular programmer --

I cannot see [how Java will not have an important edge here], especially if the speed issue gets resolved. Allen Holub is writing a book on Java compilers and Java virtual machines, and he doesn't work for Sun, so I kind of trust him. Allen says, "Well, yes, the speed issue can be resolved," and he sees how it can be done and he understands it.

So it seems that [Java speed] will get pretty darn close to C++ speed, and when it does the issue becomes, how long does it take to develop something?, how much effort does it take for a programmer to develop a working program? Development and learning time is significantly reduced in Java. From the standpoint of both companies and individual programmers, you can't just turn away from such a economic benefits.

DDJ: Let's talk about the book, "Thinking in C++". I have it on my laptop right

here Version 6, I believe.

BE: Yeah, it's up on the Web site now. It still has some pieces that are cribbed from the Java book and there's stuff that's old, but I'm slowly working through it. [I added] a strings chapter in and the beginning of the STL and STL algorithms chapters, and some of the other stuff, so you can see it in evolution now.

DDJ: Is this the way you always work -- work out an empty structure and then fill it in?

BE: Sometimes. Sometimes it works that way. Other times the work involves rewriting and researching things. Because I'm actually expanding and rewriting an existing book, some of the process is different. With the original books, and actually with this one too, I wait for the structure to appear. At first I'm confused. Where should the strings chapter go? And then sometimes you have an epiphany and you say, "Oh, obviously the library chapters belong together here after the templates chapter," et cetera, and it becomes clearer and clearer where everything belongs.

And that's just an iterative process.

DDJ: So when can we expect to see the print version?

BE: I told my editor that I would be done by the end of the year. That's what I'm hoping.

DDJ: Okay, so probably two years from now...

BE: There's more people helping me on this project, and I'm hoping that I'm going to hit [that date]. On the other hand, I delve into C++ and sometimes run into walls and see how huge it is. Also, Stroustrup and Lippman have their books out and I'm thinking, well, what's the point of putting my book out if it doesn't --

DDJ: Well, it's a different audience, really.

BE: Well, somewhat of a different audience. What I'd like to do with my book is prepare people so that if they need to go look at Stroustrup they won't be stymied by it. In other words, they will have seen enough stuff. But I guess I'd like to be the first reference. They go to me first and then, if it's something that for some reason is too advanced for me to cover, they can go to Stroustrup and will be able to deal with

it. But I have pretty high expectations.

DDJ: Do the users you meet at conferences like this one actually care about new language features, or are they something that committee members talk about and magazines write about and that take a while to trickle down and affect working programmers?

BE: You might ask Dan [Saks] that tomorrow. I don't know if I'm the best --I focus on giving somebody a breadth of the language and understanding all the new features, because I find that all of the features do make you a more powerful programmer. I do push the STL because I feel that if you get at least the basics of that under your belt you are going to save yourself a tremendous amount of time. The people that come to my talks are expecting that kind of thing and so they're a self-selecting audience.

And actually, to some degree, Dan's audiences are going to be self-selecting too. They bring him in to consult or teach because they want to know what he teaches, and he teaches more the core language than I do. We both focus on that, but I branch out into these other things and he is really focused on the language. And so you wouldn't have him in unless you were interested in those features. But if you're a Windows programmer -- according to Microsoft, Windows programmers don't care about these features.

DDJ: Well, actually, ATL is built using templates. That's interesting.

BE: But it has to be built using a subset of the template features, because [the Microsoft compiler] doesn't support all of them.

DDJ: The word I got from Microsoft, and they participated in the program a few months ago, was that all "the template bugs were fixed"

BE: I think ATL just uses some of the very basic template features, because I've broken it. They're just not as interested as everybody else in implementing language features.

DDJ: They're interested in supporting Microsoft platform and technologies, and providing the support their customers need to write Windows applications.

BE: [VC++] is a Windows compiler. I understand that, but I'm looking for language features.

DDJ: Okay, Bruce Eckel, thank you very much for talking to us today. Good luck on your book and your other activities.

BE: Thank you very much.


Post and read comments about this interview on the TechNetCast forum
More TechNetCast @ SD'98 East Interviews

Copyright (c) 1998, Dr. Dobb's TechNetCast