Interview with Bjarne Stroustrup
Below, Aleksey Dolya interviews Bjarne Stroustrup, the creator of the C++ programming language.
Linux Journal: How old are you? Do you have family?
Bjarne Stroustrup: I'm 51 years old. I'm married and have two children; both are now university students.
LJ: Bjarne, can you say a few words about your youth? When and where you were born, where you studied?
BS: I was born in Arhus, Denmark. I'm not from an academic family, but I did well in school. So I continued through my local high school and then went on to the University of Arhus, where I received a Masters degree in Mathematics with [a focus on] Computer Science. Arhus is a wonderful town with about 250,000 people situated on the east coast of Jutland. Like most boys then and there, I played in "the yard" of our apartment block, delivered newspapers and milk to get spending money, played soccer, bicycled to the beach in the summer and learned to appreciate the woods near town as a boy scout. Towards the end of my university studies, I became interested in microprogramming and went to England, where they had better machines for that. I eventually ended up getting my PhD from Cambridge.
LJ: And where do you live now?
BS: I live in a suburb of New Jersey called Watchung. It's a small, quiet place with a lot of trees. When you see it from the air in the summer, almost all you see are trees. It is ten-minute drive from Murray Hill, where I used to work at Bell Labs, and about 30 minutes from Florham Park where I work at AT&T Labs. It's about 35 miles from New York City. I used to be able to see the World Trade Center towers from just around the corner by my house.
LJ: This points to a file with the proper pronunciation of your first name and surname. Are you its author?
BS: Yes, that's me.
LJ: Did you have a computer at home when you were growing up?
BS: No, it was too early for that. Computers were very expensive and lived in university departments and large companies. The first computer I saw was my university's Math department's GIER. It was an old Danish computer that filled a room and was fed programs on paper tape. I learned to program in Algol 60 on that one.
LJ: Every famous man has his beginning. Bill Gates, for example, began by writing his first program in Basic, a program his school had bought. What was your beginning?
BS: I think the key project was a distributed systems simulator that I wrote in Simula67 as part of my PhD work at Cambridge. However, much of what I did during my university years contributed significantly. For example, I financed my Masters degree by writing small commercial programs for the Arhus office of Burroughs, a company that later merged with Univac to create Unisys. There, I learned to develop programs that other people would rely on for their livelihood; that's very different from just getting a program to work for yourself or your friends. I also had to design those programs in consultation with their eventual end-users; that too was very different from simply solving a programming exercise at the university. In addition, my work with machine architecture helped me make decisions about programming languages and implementation techniques.
If you are interested in the personal aspects of the birth of C++, you might consider reading the chapter about me and C++ in Steve Lohr's book Go To: The Story of the Math Majors, Bridge Players, Engineers, Chess Wizards, Scientists and Iconoclasts who were the Hero Programmers of the Software Revolution (ISBN 0-46-504225-2). For a more technical description of the origins of C++, see my book The Design and Evolution of C++.
LJ: How did you come to invent the C++ language?
BS: After completing my studies at Cambridge in 1979, I went to the US to work as a researcher for AT&T Bell Labs in Murray Hill, New Jersey. There, I started a couple of projects related to distributed computing using local area networks. However, I wasn't making good progress because the available tools were inadequate for those projects. So, I developed something I called C with Classes to allow me to use Simula-style program organization (what is now called object-oriented programming) for simulations and close-to-the-hardware systems programming. C++ was based on C with Classes and what was learned by me and many others (mostly at Bell Labs) by using C with Classes in many application areas.
LJ: Are you proud of your C++ language?
BS: Naturally. I'm very happy with the way it allows me to write programs that are simultaneously elegant and efficient. I'm also quite proud of its widespread use. That said, I don't claim that C++ is perfect. There is a lot of really horrible C++ code out there, because many programmers haven't learned to use C++ well. I encourage people to look at my home pages, papers and books for ideas about how to improve their code. My impression is that most C++ code could have been much cleaner, maintainable and efficient than it is had the designers and programmers understood up-to-date C++ features and techniques. Standard C++ really does make possible programming techniques that were infeasible ten years ago. Unfortunately, many are constrained or feel constrained to use C++ as it stood ten years ago, or they simply use it as a better C.
LJ: How do you feel now, knowing that millions of people work using the tool you created?
BS: I'm very pleased, but as I said, I wish they'd do themselves a favor by using it better.
LJ: Do you think that creating C++ has been the most important thing in your life? Do you think you will do something more useful in the future?
BS: It has certainly been the most significant part of my working life, and it's unlikely that I could produce something that would be more significant. Many of the applications that most directly affect our daily lives are C++ programs. To get an idea, see my short list of C++ applications.
I'm sure I'll do something significant and useful in the future. It's just unlikely that I'll create something of the magnitude of C++. I have recently decided to go into academia and accepted a professorship at Texas A&M University. There, I will be able to combine research with teaching in a way I can't at AT&T Research. I see teaching as another and different way of influencing the world for the better, and academic research provides somewhat different tradeoffs from the industrial research that I have practiced so far--not better, just different. I will keep ties to AT&T Research and to industry in general, because much of the best research is rooted in problems found in industry.
LJ: Do you use C++ in your work?
BS: Yes. It's my main research tool.
LJ: What C++ compiler is the best from your point of view?
BS: The major C++ implementations now are all pretty good or better. By that, I mean they are close to the ISO C++ standard and provide good run-time performance. For a list, see www.research.att.com/~bs/compilers.html. I don't recommend compilers that have fallen way behind the standard, such as (sadly) Watcom.
LJ: What compiler do you use at work?
BS: Several; for the moment, GNU, Microsoft, Borland, SGI and Metrowerks.
LJ:If it's not a secret, what do you research at your job?
BS: I'm looking at ways of doing distributed computing, trying to apply some program transformation techniques to allow me to use standard C++ source code for a variety of distribution architectures.
I suspect that this research is better for a technical paper or technical talk than for an interview, but I can give an example. I wanted to write a small program than needed to run with parts being on several computers. Conventionally, I'd have to write that program so the communication methods were explicit in the program. For example, if I used CORBA, my code would contain CORBA calls and I'd need to write IDL for the types I wanted to communicate between the parts of my program. If, on the other hand, I wanted the communication to use TCP/IP directly, my code would be full of TCP/IP library calls. Instead, I wrote a program where the communication between the parts were represented by ordinary C++ member function calls. If the object to be called was local, I directly called members of class X; if not, I called the same members of class proxy<X>. Using a library with facilities for C++ program transformation, I then automatically converted the calls of proxy<X> into message sent across a TCP/IP connection or, alternatively, to CORBA calls.
LJ:Did any companies other than AT&T Bell Labs try to make you their employee?
BS: Certainly; several companies and universities did, but until this year they all failed.
LJ: What is your favorite OS?
BS: I use Unix and Windows2000.
LJ: What Unix?
BS: Currently, Solaris, Irix and Linux. I try not to depend on features that are not standard across systems.
LJ: Do you think they are the best OSes available today?
BS: They are good OSes, but I'm not sure what would make an operating system the "best" in general. There are serious tradeoffs among factors such as size, performance (of various forms), ability to run existing applications, availability on various hardware and so on, so that users still have to choose among good systems for one that is best for a given set of applications.
LJ: Which processor do you prefer, Pentium or Athlon?
BS: I don't have a preference, but the 8*86 isn't anyone's favorite machine architecture. The way they use hardware to map from their archaic instruction set to the internal RISC architecture it truly remarkable.
LJ: How much time do you spend working with PCs every day?
BS: I must spend more than eight hours a day with computers, slightly less on weekend days. Not all of my computers are PCs, though.
LJ: Does your heavy PC work on a daily basis cause any health problems?
BS: I occasionally get a sore right arm from using a mouse too much, and less frequently I get a sore lower back from sitting at a desk too long. I fight this by taking walks and by running. Most weeks, I run four to six miles two or three times a week.
LJ: What computer(s) do you have at home now?
BS: A Sun box running Solaris, my IBM laptop running W2000, a Linux handheld, an old Windows box running W95 and an "antique" Apple Mac. As you can guess, I'm rather keen on portability and a reasonable degree of system independence.
LJ: And at the office?
BS: A Sun and my laptop. From these computers (both at work and at home), I can reach many more systems through the internal AT&T Research Net and beyond. If people are interested, they actually can see those computers and the rest of my office in a panorama accessible from my home page.
LJ: What programming languages do you know?
BS: That depends on what you mean by "know", but I have a working knowledge of a few languages and a reading knowledge of many more. Examples are ML, PERL, Python and Ada.
LJ: What languages do you think are serious competitors to C++?
BS: That depend on the application. Sometime C++ is the best choice; at other times there are reasons to prefer a language such as Fortran, Java, C# or Python. And yet other times, one could use a more experimental language just to learn something new. There are many languages that are good for what they are designed for, and it is a mistake to rely solely on one language. On the other hand, competition is often based on marketing and perceptions rather than facts, and I'm not going to comment on that.
LJ: What do you think about the .NET-platform and its child, the C# language?
BS: I still know too little about .Net to be comfortable writing about it.
LJ: Can C# be a universal language for everything?
BS: No. It's too high level for many kinds of systems programming, too specialized to Windows for many other kinds of programming and proprietary. That, of course, doesn't mean it cannot be a good tool for the middle-of-the-road Windows applications it is designed for.
LJ: But .NET is a platform that can be designed for various OSes. For example, there are some steps available from Microsoft to make that platform for FreeBSD. Do you still think that it's too specialized to Windows?
BS: Let's wait and see how things develop. Currently .Net is a Microsoft proprietary platform for Windows, and I don't expect to see significant use of it elsewhere anytime soon.
LJ: What is your opinion about the abyss between the C and C++ languages? Those two languages seem to be becoming further and further apart from each other.
BS: I think that the current mess of C/C++ incompatibilities is a most unfortunate accident of history, without a fundamental technical or philosophical basis. Ideally the languages should be merged, and I think that a merger is barely technically possible by making convergent changes to both languages. It seems, however, that because there is an unwillingness to make changes it is likely that the languages will continue to drift apart--to the detriment of almost every C and C++ programmer.
LJ: Are you taking any steps to integrate C and C++?
BS: I'm trying to make people see the advantages of C/C++ compatibility for the C/C++ community. In particular, I have written a series of articles for The C/C++ Users Journal on that topic, which you can download from my publications page and the CUJ site. However, there are entrenched interests keeping convergence from happening, and I'm not seeing much interest in actually doing anything from the majority that, in my opinion, would benefit most from compatibility. As ever, the majority just hopes that things somehow will work out for the best.
LJ: Would you say that C++ is the best of the best, compared to other programming languages?
BS: No; that wouldn't be meaningful. There are many great programming language. C++ is one of them, but there is not and could not be a single language that is the best for every person and every problem.
LJ: Do you have any programming certificates?
BS: No. In general, I value education over training and would almost always choose someone with a broad and deep general knowledge over someone with only specific training. A combination of academic and practical skills is my ideal.
LJ: Do you think the certificate system is useful for programmers and organizations that hire programmers?
BS: I don't know of a certificate system that is really valuable for programmers. I prefer traditional degrees from universities, engineering schools, etc.
LJ: What is your opinion, is knowing assembly language useful for programmers nowadays?
BS: It is useful to understand how machines work and knowing assembler is almost essential for that. If you don't know the machine at that level, you almost certainly suffer from serious misconceptions about computers, and some parts of the system are magical to you. Currently, I'm reading the latest edition of Hennesey & Patterson to bring my knowledge of machine architecture up to date.
LJ: "Last edition of Hennesey & Patterson". What is it?
BS: Probably the best book explaining modern computer architecture. This is a book you want to read if you want to know what's really going on inside your processor. It's not bedside reading, though, at about 1,000 pages long.
LJ: Do employers need asm-programmers?
BS: Not as such, but programmers who work with DSPs at the basic level must know the architecture of their processors very well.
LJ: What is DSP?
BS: DSP is digital signal processor. The relevance of my comment is that DSP instruction sets have more special cases that ordinary general-purpose processors, and compilers are relatively less capable of generating good code for DSPs.
LJ: Is it true that programmers who understands OSes on the kernel level can get more money (30-40%) than common high level programmers?
BS: I don't know; I don't keep statistics on salaries. Knowledge of kernels is useful, so it ought to be valuable, but so are many other kinds of knowledge.
LJ: Do you play computer games?
BS: Hardly ever any more. Unfortunately, I don't have the time.
LJ: What is your favorite meal?
BS: I don't think I have a favorite meal as such. Just about any meal in congenial company is a feast. However, there's a Danish meal called a cold table that starts with several kinds of herring, moves on to fish and meat and usually ends with shellfish and cheese. Traditionally, a cold table is accompanied by beer and aquavit. My wife has an excellent recipe for pork tenderloin with watercress salad, and my favorite Italian restaurant serves a spectacular Zupetta de Peche, which is fish and shellfish over linguini with a spicy ("Fra Diavolo") sauce. Yum!
LJ: Are happy now?
BS: I'm reasonably happy, as I ought to be given my family, my friends, my contributions to programming, my career and so on.
LJ: What would you like to say to programmers who use C++ or on their way to doing so?
BS: Be adventurous in your experimentation and somewhat more cautious in your production code. On my home pages, I have a "Technical and Style FAQ" that gives many practical hints and examples. However, to really develop significant new skills, one must read articles and books. I think of C++ as a multi-paradigm programming language. That is, C++ is a language that supports several effective programming techniques, where the best solution to a real-world programming problem often involves a combination of these techniques. Thus, I encourage people to learn data abstraction (roughly, programming using abstract classes), object-oriented programming (roughly, programming using class hierarchies) and generic programming (roughly, programming using templates). Furthermore, I encourage people to look for combinations of these techniques rather than becoming fanatical about one of these paradigms because it happens to be a great solution to a few problems.
It is important to remember that a programming language is only a tool. Once you master the basic concepts of a language, such as C++, it is far more important to gain a good understanding of an application area and of the problem you are trying to solve than it is to study the minute technical details of C++. Good luck, and have fun with C++!
Aleksey Dolya is a Russian C/C++ programmer interested in network security and software protection.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide