Interview With Bjarne Stroustrup 502
koval writes "artima.com has published an initial portion of interview with Bjarne Stroustrup.
The scope of first part is mostly about improving the style of C++ programming and getting maximum from a language."
Improvements? (Score:2, Insightful)
How to improve C++ (Score:1, Insightful)
C++ has become a massive boondoggle of poorly-widely-understood and often inconsistently implemented features, in which class reuse is mostly unheard of and different C++ APIs can rarely communicate well with each other natively due to a widespread failure to actually use the standard STL classes (String, Vector, etc).
It is time to throw out the bathwater. Unlambda combines a strict sense of simplicity with the full power of functional programming, allowing you, once you become familiar with a small set of idioms of the langage, to utilize the same patterns and strategies you used in OO languages such as C++ in a more direct and evocative manner, without the verbose clutter and paperwork OO languages force you into. Have you ever noticed with C++ you spend more time serving the syntax than actually planning your object heirarchies? No more. Unlambda cuts through the crap and lets you write "what you mean" in your code.
The benefits of Unlambda have been shown in multiple studies. Think: after all the time and energy you have invested in C++, can you really say it has delivered on its promises? Consider using Unlambda for your next enterprise-class project instead.
Re:Who is Bjarne Stroustrup? (Score:2, Insightful)
You cannot organize this (Score:2, Insightful)
Re:OOP IS FOR PUSSIES (Score:2, Insightful)
For very contorted definition of real men. OOP requires higher degree of abstract thought than assembler, and obviously not everyone can hack it. Assembler, Fortran and Visual Basic are for people whose brain can't handle abstraction, but rather just want to get their hands dirty doing stuff. People who would rather do than think what they are doing. Others take delight in creating abstract architectures and systems that Last.
Obviously many self-proclaimed C++ programmers belong in the assembler group, rather than the OOP group (where Python/Java/Smalltalk people dwell).
From the article (Score:3, Insightful)
Thank You! This is the number one java peeve. Every time I just want to make a structure I've got to make a whole class. That's a whole file. That's a whole lot of extra code. In C/C++ I can make an equivalent struct in a few lines.
This is why I like python so much. I can do all the object-orientedness I want and all the proceduralness I want and they work together perfect. And everything pops out into super efficient C code and then into executable with my gcc. And if I want it cross platform I can just use jython and get workin
Re:Why did they need to interview bjarne about tha (Score:2, Insightful)
Being that there is a large codebase out there that breaks either one of these rules I would venture a guess that is why he commented on it. He does not believe that there is a sliver bullet to solving software problems nor does he believe that C++ is one either. It is just a language he designed to solve problems he encountered while programming.
C++ is not object oriented. It has OOP support but does not mandate it. The other extreme is that it is not C. If you find yourself falling to one of these extremes in *EVERY* coding probem then there is a high probability you just might have missed his point.
Re:Weird guy (Score:2, Insightful)
He's certainly no weirder than most other programmers I know, if you make allowances for him being Danish
Duh. He may be mild mannered, but that must get irritating after a couple of years.
Re:From the article (Score:4, Insightful)
Re:From the article (Score:5, Insightful)
This is an excellent template for recognizing language bigotry. Try this as a template for recognizing language agnosticism:
"I can enumerate dozens of less-than-perfect features in my favorite language."
Until you understand the weaknesses as well as the strengths of your favorite language, you either haven't explored it fully or you don't know enough languages well enough to have a basis for comparison. (C|C++|Java|Perl|AWK|Python|COBOL|RPG|Fortran|BAS
The real trouble with C++ (Score:4, Insightful)
We went through this with Wirth. Wirth devised Pascal, which had reasonable data structures, although not objects, terrible I/O, and strings that only worked if they were short. He then insisted that it shouldn't change. From this came a whole range of incompatible Pascal dialects (Turbo Pascal, Object Pascal, Clascal...), and some successor languages (Modula I, II, III). Modula III was actually rather good, but nobody except some researchers at DEC SRL (now an empty building in Palo Alto) used it. Two decades later, few use Pascal or its derivatives, and Wirth is a forgotten and bitter man in Switzerland.
This cycle is being repeated with C++. The first version of C++, before templates and the STL, was terrible. Without templates, horrible schemes involving huge defines were used to make generic objects. Strostrup used to have great hostility to run-time type information, which led to unchecked downcasts all over the place.
Round 2 of C++ came late, and it took a long time before the compilers did templates. Then came the STL, which is wierd and unsafe, although useful.
C has little abstraction and little safety. Java has both abstraction and safety. C++ has abstraction without safety, a terrible combination. The basic problem with both C and C++ is that the language requires the programmer to obsess on storage allocation and release, yet gives no assistance in this. Attempts to encapsulate storage allocation in C++ fail miserably (look at the history of auto_ptr). Attempts have been made to fix the language by adding another layer of rote ritual ("patterns") on top of it, but compilers can't check that, so it doesn't reduce bugs.
Another area of trouble comes from the history of C++ as a preprocessor for C. Bell Labs had a tradition that "you can't change the linker". (This is probably because the original UNIX linker was written in assembler and had few comments.) Because of this, some tasks that should be deferred to link time (such as building vtables) are done at compile time.
The price paid for not changing the linker is substantial. Private function members appear in header files so that vtables can be built at compile time. That's the real reason, despite what you read. If it weren't for that, you could have much stronger separation between declaration and implementation. And you wouldn't be recompiling class users just because the class implementation changed. Ada and Modula got this right, but C++ got it wrong. And Strostrup refuses to fix it.
Yes, there are "patterns" for working around this. But they're workarounds. The programmer is doing the compiler's job. This imposes a cost on every programmer and distorts C++ programs.
Strostrup still insists there's nothing really wrong with his language. Read what he's written about the C++200x standards revision cycle. Meanwhile, C++ is being abandoned for Java, C#, C, and scripting languages.
You're kind of a chump. (Score:2, Insightful)
Java has freakin' wrappers for ints, an abysmally slow start-up, and is just getting generics. I could go on for hours on how Java is a brilliant marketing effort but a miserable, byzantine morass of hierarchies, but I'll stick responding to your comments.
C++Aaannnggghhh! Wrong. Please refer to the header in the STL, to use only when the many various STL containers somehow are insufficient for your job.
Strostrup still insists there's nothing really wrong with his language.Uhh, okay, but Sun is all too willing to discuss flaws with Java? And God knows, Microsoft is always willing to discuss anything the user is concerned about.
Wirth is a forgotten and bitter man in Switzerland.Is Wirth really bitter? I wouldn't know, but he's hardly forgotten. There's a whole school of programmers that advocate Delphi which, last I checked, was still being sold to this day. If you don't know what Delphi is, then hit borland.com and educate yourself.
Ada and Modula got this right, but C++ got it wrong. And Strostrup refuses to fix it.I'm skeptical that Ada has gotten much right, but speaking to the illusion that Stroustrup is Lord God King -- Stroustrup is only one member of a rather large team that actively develops C++ and the STL. It's a committee now, and it ain't solely up to him.
Meanwhile, C++ is being abandoned for Java, C#, C, and scripting languages.Uh, not for systems, games, or high-performance rapid development it isn't, and you can take that to church, buddy. Also, C is still in widespread use, but Java and C# are suffering the same competition, where there is competition in certain applications, from scripting languages that every non-scripting language suffers. Also, Java and C# are platforms, not simply languages, they're proprietary, and they're proponents depend heavily on making the development community believe that everyone(!) is jumping C++'s ship. Well, everyone isn't. Some developers, especially those that need to, see through the marketing spooge and use what's best for the job, not what Sun and Microsoft tell them to use. Jesus, if we all did what Microsoft wanted us to, we'd all be using VB.NET.
C has little abstraction and little safety. Java has both abstraction and safety. C++ has abstraction without safety, a terrible combination.This is just a doofy sentence. C has "little" safety but C++ is "without" safety? Dude, learn a language before you start spouting marketing crap. If you don't know why your sentence is completely wrong, then you're not qualified to comment.
Re:Scott Meyers (Score:3, Insightful)
It's not exactly clear to me whether I'm taking a joke on as if it were serious. That said, this is a genuine sentiment with many, so I feel my rebuttal to be germane to them if not nessecarily to you.
The problem with language is that its domain is inherently difficult. The more expressive a language is, the deeper and more powerful structures it can express. Conversely, because making a language more expressive involves adding new methods of control, the more expressive a language is, the more difficult it is. You need to know how to generate the syntax which wields the new expression mediums, etc.
The problem as I see it is that the professional field requires a significantly higher degree of skill in expression than the amateur field wants to put forth. At first this seems like a tautology, but think about it: it's fairly rare that an experienced c++ programmer suggests there needs to be a starting-over. Given that few other dominant-in-their-day languages can make that statement, I think it's worth considering that maybe C++ is as horrible as it is by necessity.
Bjarne suggests that there are more than a dozen languages named D (which is stupid; c++ *is* D, as well as P; don't try to extends jokes you don't understand, folks, kthxbye) and another half dozen named E or P. That some of them are backwards compatible and *still* haven't takjen over should be an indication that C++ is doing at least something right, despite hordes of popular, well supported contenders.
I too hate a lot of things about C++. But frankly, even though it's not even close to my first language, I can't think of another language I like more for a generic problem domain. Sure, when it's web apps it's PHP; when it's database toys or mostly UI apps it's Delphi; et cetera. Still, when it's difficult, it's c++, every single time.
Any profession that allows for a whole subprofessions making a living pointing out what one should not do has become satisfyingly deep. Things which one can just jump into and be the best at are shallow. Art, writing, engineering, mathematics, induction, politics, philosophy. Each of these has books, tomes on what you should *not* do in order to be effective. In some fields this study of counterexamples has become so important that it elevates to its own subfield of study (fallacies and converses;) arguably that's happening in CS with AntiPatterns right now.
What I think you're seeing is a language which is way ahead of the game in community support.
It's an education issue (Score:4, Insightful)
However, you very much can improve how a language is used by telling people how to program with it. The single biggest problem C++ has isn't dangerous pointers, or ugly template syntax, or lack of a garbage collector, it's lack of good programmer education. C++ is a power tool, and requires skill to use. When most of the C++ textbooks in the world are teaching decade-old crap themselves, and most of the university professors don't know their own subject, it's not too surprising.
I can sympathise a lot with Stroustrup here. His tool is unjustly battered by the ignorant more than perhaps any other mainstream language today, and it creates a self-fulfilling prophecy: most people who learn C++ learn it badly, and write code with buffer overflows and other kindergarten mistakes. Others pick up on this, and learn from people who themselves learned badly, and write more code with kindergarten mistakes. It's about time the C++ programming industry reached High School, but few ever seem to, and when they do, they aren't valued as much as they should be.
Chill (Score:2, Insightful)
Fully encapsulating the complexity of an abstract data type without just giving up and making many of the important decisions in the language itself is an extremely difficult problem in language design. I find the first poster's sentence, while obviously an exageration, to be rather insightful.
C++ has high aspirations in terms of giving the programmer complete control but ultimately fails due to the emergent complexity that results from the inability to fully encapsulate all of the design decisions.
Confirmed: C++'s not very object-oriented (Score:5, Insightful)
The interview is interesting in that it confirms the impression I've had from using and/or struggling to use C++. When I try to do anything object-oriented, specifically anything involving polymorphism, it seems to be fighting me all the way. After some struggling I usually emerge triumphant, but it's almost always a battle.
What Stoustrup seems to be saying is that classes should be treated as a special big deal, and shouldn't be used unless you're sure they're necessary. He seems to be recommending that there be, um, a class of elite programmers who put in the intense work to develop good, usable, well-debugged classes, and that the rank and file should, by all means use those classes but should not aspire to write new ones.
And this is not unreasonable, given the effort of writing classes and getting the storage management right and so forth.
The thing is, it's not a big deal to use classes in a truly object-oriented language. I'm not just talking about Smalltalk. Heck, they're trivial to use in REALbasic.
Well, is that good? It certainly leads to overuse of OOP. To a man with a hammer everything is a nail, and every programming language tends to encourage overuse of the things that it facilitates. Every programming language has a tendency to induce brain-warp.
C++, for better or for worse, does not induce object-oriented brain-warp.
People who try to use OOP in C++ because it's cool or because of some article they read (or some instructor they had) find that C++ punishes such behavior. And Stoustrup is right: when you are programming in C++, OOP should be used sparingly and only when it's needed.
Again, I'm not saying whether that's bad or good. That will depend on the degree to which you think OOP ought to be encouraged. If you think OOP should be just as much a part of a programmer's mental toolbox as iteration, or recursion, then it's not good. If you think OOP was the overhyped IT fad of the nineties, then it's not bad.
What I'm saying is that it has always seemed to me that C++ is not a very object-oriented language, and Stoustrup's remarks seem to me to confirm the objective validity of that observation.
Do you know what you're talking about? (Score:1, Insightful)
Oh, please. Do you realize how many optimizations your compiler is doing so that you don't have to write really frigging difficult to understand code? Do you *really* want to perform manual loop unrolling (which is easy, but looks ugly)? Find out every function that can be inlined and specify them as such? Array Value Propagation? Array Blocking?
At least in the form of optimizations, if the programmer had to take care of things like these he'd have to make a choice between good, easily readable and maintained code, and fast code. And if you work in the real world, you know that you're not the only one actively maintaining your code. If the 10 other people working on it have to work hard to understand it, this wastes time, thus companies would be leaning towards the slow, but readable code. However, since the compiler recognizes that when you have your nice little loop performing matrix multiplication, you can actually get better performance by using blocking (performing operations on a small sub-matrix instead of going through rows and columns operations and thus reducing cache misses), you get the best of both worlds.
Re:"memory allocation problem" (Score:3, Insightful)
Re:Which ADTs? (Score:2, Insightful)
What I don't buy is propaganda stating that C++ can be a productive tool for non-experts if only you avoid pointers and use the STL. That's the Microsoft mentality: everything's ok if you stay on the beaten path.
Re:Which ADTs? (Score:2, Insightful)
What propoganda ? Who is saying this ? I haven't heard AT&T saying this, or Bjarne, or anyone else. You're fighting a straw man. If you want a productive tool for non-experts, forget C++, forget java, forget C, forget any compiled language. Non-experts will do much better with an interpreted language, and even if it's 200 times as slow, it will be worth it for the programmer time it saves.
magic programmer education (Score:2, Insightful)
But for professional developers, wouldn't it be best if we just focussed on making he best tools and educating our industry to use them properly?
I mean, if you look, there are a lot of tools of convienience in the hardware store that professional builders don't use. You can duct tape something and it's good to go, but that's not what you train engineers... though they might use duct tape in a pinch.
I think you might be onto something about Java for newer programmers. I already have learned about all the things Java is to save me from, like the ins and outs of memory management, so I don't notice an speed up when I code in Java. The kinds of bugs I have to hunt in my stuff is not particularly addressed, and can't really by, by any language.
If a java program was written in a couple days, and the C equiv in a month... that implies something. There is not that much difference in the language. That sounds like library availability, the C programmer had to write something that was already available in Java, which begs the question... was there a good library available they didn't know about and could they have used C++. The 10% would still make it a better tool and worthwhile.
But where we really will probably have to agree to disagree is just on the "needless complexity" issue. That needless complexity is C++ giving you more than you need --- so you can decide what you need and have a wide range of paradigms under which you can code. That is C++ not trying to second guess for you. If C++ give an automagical solution, it also give no-solution so you can build your own automagic. If you don't like cout, there is still printf and if you don't like exceptions, it's up to you and your Coding Standards to decide is you have to use them.
It's that old choice vs. chaos. Personally, I can handle the chaos of choice.