Interview with Father of C ++ on New Year's Day (8 + 13 questions, about C ++ learning, use, and future) (repost)

Bjarne stroustrup is the designer and originalimplementer of C ++ and the author of "The C ++ programming language" and "the design and evolution of c ++ ". his research interests includedistributed systems, design, programming techniques, softwaredevelopment tools, and programming languages. he is actively involvedin the ANSI/iso standardization of c ++.

Dr. stroustrup is the college of engineeringchair sort sor in computer science at Texas A & M University. heretains a link with at&t labs-research as an at&t fellow. member of the National Emy of engineering. ACM fellow. IEEE fellow.

Part1: on learning and using of C ++

1. Why do you go to Tamu to teach programming? What's your favorite thing about of the university? -Xingranliuyun

It was time for a change and I felt I hadsomething to teach. I had friends at Tamu and it was one of the fewuniversities that seemed serious about growing and improving. some ofthe most enjoyable work has been designing and giving a firstprogramming course to 1st year students.

2. undeniably, the biggest problem of C ++ islearning. language-lawyer is a phenomenon that appears almost solely Inc ++. when C ++ programmers wasted so much time fighting against thelanguage details, of which some are essential and some are unnecessary. c ++ has implements traps which we have to bear in mind before we can safelyuse it; C ++ has so far pitfalls which leads to a tremendous amount oflanguage t Ricks (some might call them "idioms" or "Techniques"); they, together, lead to a very steep learning curve. confronted with so manycomplexities, how can one learn and use C ++ extends tively from apractitioner's perspective? -- Pongba & Liujiang

You may be accurate about the complexities ofusing C ++, but then you may be underestimating the trickeryinvolved in learning and using other ages. some problems onlysurface when the user population gets large and diverse. also, C ++ isused in a huge range of application areas and often the alternative TOC ++ is to learn several ages. obviusly, a professional shouldknow several ages, but this shoshould be taken into account whenestimating difficulty/complexity. also, if the complexity Isn't in thelanguage, it tends to be elsewhere, such as in the application code.

3. Of all the complexities in C ++, some areessential, some are unnecessary (Technical embarrassments, like yousaid). What're those, exactly? What's the right attitude towards themwhen learning or using the language? -Pongba

This is too big a question for a shortanswer, but I'm convinced that it wocould be possible to design a C ++ likelanguage of maybe a tenth of the size of C ++. the exercise wowould Benon-trivial, though.

Examples: both the syntax and the type rulesare too irregular. there cocould be a much simpler syntax and a farsimpler and more regular type system, but C compatibility and C ++ 98 compatibility wowould have to go out the window. also, most of thedefault are the wrong way around und or awkward: for example, constructorsshocould be explicit by default, floating-point numbers shocould not beimplicitly convertible to integers, and names shoshould not by default beaccessible from different translation units.

Attitude: Don't get stuck on details. Focus on becoming a professional (not a language laywer). Don't be too much in a hurry.

4. What's the first principle of learning C ++? -Pongba

The way to master C ++ is to focus on thefundamental concepts and techniques, rather than the language features-and in particle, not the minute details of language features.

5. What's the first principle of using C ++? -Pongba

Map ideas (concepts) directly into classes and templates.

(Pongba statement: For questions 4 and 5, the answer to Bjarne is concise, but also important. It can be said that these two problems touch on the core contradiction between C ++ learning and usage. I wrote a blog ("learning C ++: Practitioner's method beta1") about C ++ a while ago. My views coincide with those of Bjarne-actually, I raised the above two questions to verify whether Bjarne thinks so .)

6. c ++ is really hard to learn; normally one willhave to read no less than 10 books to be adequately good at C ++ programming. I really hope your new book is going to change thesituation. -Steven MOU

So do I, and the feedback from people whohave read drafts is encouraging. I think that one or two (well chosen) books will suffice for becoming a good C ++ programmer. I have knownpeople who did that. don't think that knowing the most rules andbuzzwords makes you the best programmer. A language is simply there foryou to use to express ideas. most of being a good programmer is clearthur inking and application domain knowledge.

(Pongba Press: Bjarne also mentioned in another email that his new book will provide an answer to "what is the correct way to learn C ++! Let's wait and see !)

7. nowadays, few systems are built with a singlelanguage. we tend to combine the power of different versions. in Thiscase, C ++ is often used to build parts of a system. how can we identifywhether C ++ is suitable for a specific module? Are there anyfingerprints that cocould help us make demo-on whether or not to USEC ++? -- Mike Meng

C ++'s main strengths are in flexibility andperformance. if you need neither, use something else. one way oflooking at a problem is to see if a set of classes-a small library-wocould help make the code cleaner, easier to get correct, and easier tomaintain. if so, C ++ may be the best choice for the design, implementation, and use of that little library.

8. I read your talk with Bill Venners in whichyou complained about the pervasive of object oriented programming. doesthat mean that you decide not to support this specific style ofprogramming? Generally, what kind of style in your opinion can belabeled as "good "? -- Mike Meng

It's hard to be specific. most of my code ISA combination of object-oriented, generic, small free-standing classes. "Good" is a function of the quality of the match between ideas andcode. trying to define "good" in terms of language features orprogramming style fashions is a mistake.

Part2: on future of C ++

1. What do you think of the prevalence of the "easy-learning" languages, do you think their population indicates thefuture trend? -Kamala

Maybe. the question is how your programmersthere will be, what is considered programming, And what kind ofprofessional background is considered reasonable for systems builders. I note that there may be more C ++ programmers today than there has everbeen (if not, it's close ). however, too tend to build infrastructureand is rarely heard from or noticed.

2. What's the future direction of genericprogramming in C ++ (especially after C ++ 09 )? Are there any new excitingthings (besides those already in C ++ 09) on the horizon? -Longshanksmo

I don't know. features such as concepts, auto, initializer lists, variadic templates, and rvalue references willrevolutionize the way we express generic code. we will learn from that. I think that we'll find that the integration of those features will beimperfect and lead to improvements.

3. c ++, as a general-purpose programminglanguage, is having its field squeezed by the more modern languages, where wocould C ++ be in the foreseeable future, and certainly in theconcurrency; wocould what used to be the unique advantage of C ++ still be the unique advantage? -STLF

C ++ never had a unique advantage. it hadstrengths and weaknesses, as it has today and as all ages have. c ++'s strengths include flexibility, performance, and co-existence withother languages ages (notably, C, Fortran, and Assembler ). if C ++'s fieldreally is being squeezed (and how wocould we know ?) The reason willeither be "marketing" against which the C ++ community have few directdefenses or "because we have discovered to express our designs inframeworks that do not require flexibility and are efficient enough ". the latter is objectively a good thing. c ++ is primarily a systemsprogramming language and when an application area has matured to thepoint where "one standard way" will do, the systems programminglanguage will be deployed elsewhere. I note a significant increase inthe use of C ++ in embedded systems programming.

4. c ++ was and still is designed to be efficient; In order to achieve that, there're some non-trivial Design Trade-offsmade to keep the specified action penalty as low as possible (E. g. templates ). however, they're not trade-offs without costs. for example, the static nature of templates makes it inflexible when it comes toruntime needs. in that case, Ruby's duck-typing seems to be a morenatural implementa Tion of generic-programming, although much lessefficient. however, concurrent programming will definitely bring us amuch heavier optimization means, in which case, wocould the compromisemade in the design of C ++ to keep the specified action low still make sense, when people can resort to concurrency to gain efficiency? -Pongba

Ruby is often 50 times slower than C ++. idon't think they are comparable ages. if you need performance in ascripting language, you implement your primitives in something likec ++. if you need to do ad hoc programming at an application level whereperformance doesn' t matter, you use a scripting language. it is amistake to look for "the one true programming language."

Also, I really appreciate strong statictyping and Design Based on that for correctness. There is far too muchtalk about performance and far too little about correctness andstructure.

Besides, the individual processors are notgetting any faster-in fact they are getting slower, being optimizedfor chip space and power consumption-so that low enough action penaltycocould become more important for tasks that are not easily parallelized (and that is a lot of tasks ).

Remember: It costs thousands of instructionsto start up a task on a processor and to get the result back, so thereis a huge win in being able to execute in less instructions so that nospawning is needed. it's just like inlining vs function call (thefunction call pre-And postamble costs ). also, more and more, we aregoing to measure speed in memory accesses rather than instructions-instructions are getting really cheap. currently everymultiprocessor/multicode is memory bandwidth limited-and also mostsingle processors.

5. Are there any differences between the designprinciples of C ++ 09 and that of C ++ 98 (the ones in D & E )? Is theregoing to be a change in the design principles of C ++ 1x? -Liang

Not really, at least from my perspective. myhopl3 paper "evolving a language in and for the Real World: C ++ 1991-2006. "explains the principles and the evolution of C ++ over thelast 15 years. that's the place to look for a more detailed answer. it's available from my home pages.

6. You once said that there's a smaller, betterlanguage inside C ++ dying to get out, what's that language like, specifically? Is d it? -Liang

No. Nor is it Java or C #.

7. Money has always been c ++ Committee's biggest problem, how wocould The Committee operate in the coming 10 years? -Liang

I don't know. inertia will be a majorproblem. I fear it'll operate in just the same manner, and thatwouldn't be good. however, I have reason to believe that it will moveTo a shorter release cycle (maybe 3 years ). I don't see the moneyproblems getting solved. people with money tend to prefer to spend themon proprietary solutions that they imagine will give them a competiveadvantage-even if a joint effort wocould help everybody much more.

8. What responsibilities will you take in the future development of C ++? -- Liang

Let's get C ++ 0x finished before I think too hard about that.

9. What do you think of the place C ++ iscurrently at in the Visual Studio language family? They have C # As themain static language, vb10 & ironpython as dynamic versions, whereasc ++ is the only choice when it comes to native code; do you think thatindicates C ++'s place in the real-world development? Like visual c ++ team said themselves: "We haven't forgotten C ++"; does this representthe attitude to C ++ in the industry? -Liang

C # is not a static language. it relies on thehuge. net Framework. the amount of "native code" (read: C ++) evenwithin Microsoft is increasing and accounting of Microsoft's competitors (INA variety of business fields) does not want to depend completely onmicrosoft, so they minimize their exposure. net. c ++ is a far moreportable language than anything you'll find in. net family (evenc ++/CLI ). I think that the ones that do not will see business problemsin the future as they become incapable of innovating in any way thatdoesn't fit. net and is also done (in roughly the same way) by theircompetitors. to succeed in the long run, you need flexibility at manylevels of your tool chain.

10. c ++ is a language "designed by committee"; inwhich way does the nature of the C ++ standard committee affect theevolution of C ++, for good and for bad. -abware

To the extent that C ++ is designed bycommittee, it is bad and there are parts of the language that doeSn 'tblend as well with other parts of the language as they shocould for thatreason. what the Committee seems good at is finding problems andlimitation with individual features, but then improvements ofindividual features are not often as the interaction of features. thisis definitely also true for interactions between library components andbetween library components and language features. again, read the hopl3paper.

11. How do you choose between adding new featuresto an existing language and inventing a new language? Sometimes, newfeatures added to an existing language may look unnatural or difficultto use, but those features may be made more elegant if using adifferent syntax. -- walterwalk

You look at the problem. A successfullanguage is successful because it addresses some problem better thanthe alternatives. Most new versions fail. I strongrong prefer to startby building libraries.

12. What shoshould be done in next generation of programming language from a researcher's view? -Bipengace

I don't know. I have never been a specified ageresearcher. language Research is almost always sterile. what works isusing language-based tools to address interesting problems; sometimesthe result is a new language or a new language feature. it is hard toknow exactly how many ages are supported Ted and die every year (forstarters, how do you define "new language "), but a good estimate isabout 2000 of each every decade-the specified vors can be counted on a fewhands. have a look at my paper "a rationale for semantically enhancedlibrary ages."

13. is there any chance that, by proper "Tailoring" (I. e. cutting out the obscure or normally uselessly complexfeatures), we can provide a "smaller" c ++, which is a subset of C ++ andwhose code can be compiled by any standard C ++ compiler, andstandardize this one, providing consistent Abis and standard libraries. -cloudwu

How do you decide what is "obscure anduseless "? If you do it well, you can express it as a coding standardand enforce that. unfortunately, my experience is that most codingstandards are written by people who are inexperienced and fearful anddo more harm than good by enforcing their fears. I think that Theresult of such "Tailoring" shoshould be (and if done well almostinevitably will be) domain specific. as an example see the JSF ++ codingstandard for Safety Critical embedded applications (I. e. airplanecontrol ). link on my c ++ page.