Almost every programmer knows his name. He's a living legend in computers. His name is Bjarne Stroustrup, and he created the world's most popular programming language, C++. I had a chance to ask him a few questions. The first three of the questions I came up with, and the remainder I selected from the numerous questions suggested by DaniWeb community members. So sit back, and listen to the words of one of the greatest programming masters ever. (My questions are noted with "JC"; questions from the DaniWeb community are noted as "DW".)DANIWEB (JC): On your home page for your teaching, I see you're doing research in scalable parallel software. I know that parallel processing is now a reality for most desktops, with multi-core processors now common. I was wondering if you might tell us just a bit about that, such as what you're exploring right now in that field, and what exciting things are going on that might spark some interest in parallel programming with our readers?
STROUSTRUP: I work on several distinct approaches to dealing with concurrency: parallel computation in the context of traditional numerical/scientific applications, standardization of conventional threads-and-locks approaches to concurrency, and lock-free programming (primarily to support the implementations of higher-level approaches to concurrency). In fact, I have worked with concurrency on and off since my student days where I did my PhD on concurrency topics.
In the parallel programming areas my main contribution aims to support Lawrence Rauchwerger's STAPL library and run-time support system. Lawrence is a fellow professor at Texas A&M University. STAPL follows my philosophy that there cannot be a single model of concurrency for all uses, so it provides one that is close to ideal for a particular application domain as a library supported by compiler tools and run-time support. My focus is on the compile-time tool support. The project is academic and there are lots of papers available from my publications page, from Prof. Rauchwerger's pages, and from the pages of our Parasol research group. You can see a variant of this approach in Intel's TBB system (which explicitly acknowledges contributions from STAPL).
Other academic work – which actually helps in the implementation of systems such as STAPL – relates to lock-free programming. Traditional locking mechanism can be very expensive to use and in the hands of average programmers (and even in the hands of great programmers in a hurry or on a bad day) leads to hard-to-detect and hard-to-correct errors including data races and deadlocks. Lock-free programming is even harder to get right than traditional concurrent programming, but helps implement high-level concurrency models, can provide better correctness guarantees, and can be essential for performance. Some of my work has been in connection with the JPL (where they program the US planetary exploration and deep-space probes) aiming at improved correctness and reliability. For papers on this topic, look at my publication pages for papers co-authored by my former student Damian Dechev.
The work that will be most visible to most C++ programmers is what I have help do for C++0x in the C++ standards committee. Here, I'm not the main designer. People such as Hans-Jürgen Boehm (HP), Lawrence Crowl (Google, formerly Sun), Howard Hinnant (Apple), Detlef Vollman, McKnight (IBM), Herb Sutter (Microsoft), and others have made significant contributions. We have standardized a memory model, a set of primitive operations for lock-free programming, a threads library (with locks, etc.), and a single example of a high-level facility. This provides a basis for systems programming.
For threads and locks, C++0x basically provides a type-safe and exception safe version of the conventional threads-and-lock style of concurrency. We no longer have to deal with void**s, casts, macros, and cryptic error codes to program with threads. The traditional way of dealing with concurrency by letting a bunch of threads loose in a single address space and then using locks to try to cope with the resulting data races and coordination problems is probably the worst possible in terms of correctness and comprehensibility. However, that's what hardware and operating systems provide and most users rely on, so a system programming language must support it. The C++0x facilities are based on decades of use of conventional use of concurrency in C++ using Linux, Windows, etc. and should be familiar to all who are familiar with concurrency in those systems.
In one case, C++0x goes beyond his conventional and necessary level. Consider an example, where I use four potentially concurrent tasks to identify elements that meet a predicate:
template<class Iter, class Pred>
vector<int> find_all(Iter p1, Iter p2, Pred p); // find all i in [p1,p2]of c for which p(c[i]) is true
void f(vector<Record>& v)
{
const int s = v.size();
auto r0 = async(find_all, v.begin(), v.begin()+s/4, pred) ; // first quarter
auto r1 = async(find_all, v.begin()+s/4, v.begin()+s/2, pred);
auto r2 = async(find_all, v.begin()+s/2, v.begin()++s/2+s/4, pred);
auto r3 = async(find_all, v.begin()+s/2+s/4,v.begin()+s, pred); // last quarter
vector<int> res0 = r0.get(); // wait for the tasks to finish
vector<int> res1 = r1.get();
vector<int> res2 = r2.get();
vector<int> res3 = r3.get();
// use the results collected
}The use of auto as a type means "use the type of the initializer" and my use of a vector as a return type is not a performance bug. In C++0x we use "move semantics" to ensure minimal copy for vectors. You can find more explanation in my C++0x FAQ.
The most important point of that example is that I achieved concurrency without say "thread" or "lock".
You might have noticed my not-so-subtle habit of naming names. I think that it is important to explicitly acknowledging contributions. Understanding of what is good work and why is the basis of professionalism and only if the individuals who do the hard work a given credit can a profession thrive in the long run. Only then, can the pioneers sustain their innovative work rather than becoming just businessmen. Obviously, we also need businessmen, but I'm more concerned with the technical innovators. Also, naming names allows you to find their work on the web.DANIWEB (JC): What do you recommend for current students pursuing degrees in computer science? In other words, when you see undergrads applying for graduate school where you teach, do you find any particular skills that many of them lack?
STROUSTRUP: Let me not dwell on weaknesses and instead try to outline ideals, but first I'll argue for a distinction between the two main degrees obtained in grad school. A PhD should not just be a slightly extended master's. A master's should imply mastery of a field beyond what is demanded for a bachelor's degree. Ideally, the holder of a master's degree should have both a broader view of the field and a deeper understanding of some specialty. I am a great fan of requiring a written thesis ("a master piece", hopefully) to ensure that the student has the ability to express his/her understanding of a chosen topic. Mastery includes the ability to communicate.
A PhD is something beyond mastery. It includes mastery of a field, but requires innovation. The key to a good PhD is the student's ability to select a research topic and then deliver new results. The old formulation "to add to human knowledge" has a suitable idealistic and ambitious ring to it. Just following an advisor's detailed instructions should not be sufficient. For at least one glorious day a PhD student should be the world's expert in a chosen (possibly very narrowly defined) topic.
What does this imply for our ideal grad student? The master's student needs to work hard to master "the fundamentals" in a greater depth than he or she did as an undergraduate. All should know algorithms, machine architecture, and "systems" (operating systems, database systems, etc.), and a bit of theory. Note that I don't mention fashionable topics such as networking, security, and graphics. I don't even mention programming languages and compilers. I consider those specializations. Everybody should have one or more areas of specialization. Also, everyone graduating in computer science and related fields should know how to program in more than one language and I would love for more to know compilers, but a study of languages beyond what is needed for expert use is a specialization. By "know how to program" I mean an ability to write idiomatic code and not just mere hacking.
I'm not keen on defining mastery in terms of long lists of topics. My ideal student has initiative, a willingness to work hard on a chosen topic, some of the habits of a scholar (read up on topics to know the state of the art and reference it appropriately), the beginnings of professionalism (doing sloppy work is unacceptable), an ability to communicate (orally and in writing), and (especially for PhD students) imagination. In addition, the ideal student shows good taste in the choice of topics and aesthetics in the expression of their solution. Needless to say, such ideal students are rare, but then ideals are not minimal requirements; they are what we strive for.
We rarely do significant work in isolation, but fortunately habits of scholarship, professionalism, and ability to communicate provides a good foundation for working as part of a team. Beyond that, we need a willingness to make a team work is a necessity and any good education in Computer Science (and related fields) must involve team projects to develop such skills. Only rarely do I teach a course that does not require a team project. In particular, even my programming course for 1st year students involves one or two team projects. Personally, I prefer for people I work with also to have a sense of humor and not to be intellectually narrow. Knowing only computer science is a bad idea.
Note that these are not necessarily the personal attribute that an employer is looking for. I don't consider willingness to bust a gut over every random topic and every deadline particularly desirable traits.
DANIWEB (JC): When do you think C++0x will become finalized? I know that the latest draft was released in March, and Wikipedia states that the final draft should be completed in March 2011. Does that sound right? Does it seem to be on course?
STROUSTRUP: I'm just on my way back from a standards meeting, in Rapperswil, Switzerland, and yes, the standard seems still to be on track for a final technical vote in Madrid on March 26, 2011. The odds are on C++0x becoming C++11 or (if you prefer hexadecimal) C++0xB.
Furthermore, the standard is on track to become a major boon to C++ programmers and the implementers are already starting to ship C++ language features and standard libraries.
DANIWEB (DW): What are your feelings on the growing trend towards teaching higher level and less complex languages in education(Python, Vb.net etc) as opposed to lower level and/or more complex languages (C++, Java etc) and how do you think this will affect the quality of future programmers?
STROUSTRUP: It will, for both good and bad. I think the newer language take people away from the machine and towards applications. I think it habituates people to huge and expensive support structures that they don't understand. Programmer who have never programmed in a language like C or C++ tends to believe in magic and have only the vaguest idea of cost. If all you want to do is web applications that may very well be sufficient.
My major interest is systems programming and the design and implementation of software infrastructure and resource constrained applications. For that, you need something like C++. That's one reason the new languages and systems tend to be implemented in C++.
If all programmers are taught only languages that keep them away from the machine, we would be headed for a dim future of even more bloated and less reliable systems. Fortunately, that is by no means a given. There are as many C++ programmers working today as there ever were and I suspect that the influx of new programmers will be sufficient to keep us going and to dismay the people who believe that all programming can be easy. I consider design and programming high-level skills, ideally done by true professionals.
I am doing my bit in education now. In particular, I can recommend my new programming textbook: "Programming: Principles and Practice using C++." You can now get it in Polish, German, Chinese, and French as well as English. More translations are on their way.
DANIWEB (DW): What will be the priority for the future C++ Standard Library wishlist ( http://www.open-std.org/jtc1/sc22/wg...2006/n2034.htm ) after C++0x comes out in about a year ?
STROUSTRUP: I really don't know. My voice is just one of many when it comes to selecting priorities for libraries. The people who actually produce new libraries have a major voice because working software "talks louder" than abstract ideas. I'd like to see asynchronous I/O and support for networking. I'd like to see a good and simple linear algebra library. I'd like to see standard XML support; in fact, we could do with much better Web development support. I'd like to see a message queue for threads.
Of course, I'd like to see some GUI foundation standardized, but that's technically as well and politically very hard. For some details, see my HOPL-3 conference paper.
Do remember that nothing will get accepted unless a well-designed library with serious user experience is presented to the committee. We have so many needs and so little time to work on them.
DANIWEB (DW): Why is there no C++ Software foundation?
STROUSTRUP: Because no one made one. I looked into that in the 1980s where we might have had a chance. However, every C++ purveyor preferred to support its own user community exclusively rather than pitching in for the common good. I suspect that may still be the case if we tried to make a foundation today, though of course that may depend on what you mean by "foundation." In this particular aspect, C++ was a victim of its own success. Each sub-community was large enough to consider itself self-sufficient (and many still do). C++ has many sub-communities that are larger than the total user communities of most languages, but the users of most languages are typically better organized than the C++ users.
DANIWEB (DW): If everything you now know about programming languages, if you could go back in time and change anything about C++ that you wanted to, what would you change, if anything?
STROUSTRUP: In general, I avoid that question because it is hard to change just one thing, hard to know what would have been possible then, and because I know how major the successes of what we did were. Remember, when C++ first appeared essentially nobody had heard of that object-oriented programming. Furthermore, just about everybody in the industry who had heard of OOP "knew" that it didn't work (too slow, too special purpose, too difficult for programmers, and impossible to integrate with other code). It is only a few years since the Java and (a bit later) C# communities "knew" that generic programming was a useless and complicated C++ perversion; then they too grew < … > brackets.
I wish I could have whispered in Dennis Ritchie's ear to make the declaratory syntax linear and to ban narrowing conversions, I wish I could have convinced the C standards committee that there is no need for two slightly incompatible languages (C and C++). I wish that I could have invented something like "concepts" in 1988 so as to make templates simpler. However, even today, that's hard to do without causing serious run-time overheads or seriously limiting flexibility. Maybe we should leave to past in peace.
