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."
Compilers (Score:4, Interesting)
Re:What about... (Score:2, Interesting)
I think I'll just clarify that. In four or five years, what changes would you like to see happening to the language, and how realistic it is to be able to achieve those goals in that time period?
Re:Scott Meyers (Score:3, Interesting)
C++ has problems, yes; pretty unavoidable since it was the first real object oriented language.
This comment alone summarizes the posters knowledge of programming languages. For a better understanding of C++, check it out on the Computer Languages History [levenez.com] website
My reply: Cute, but it unfortunately does mean something. C++ has more features that are so easily misused (not abused), that Scott Meyers wrote 3 large volumes on the subject. Other languages have similar featuers, but not in near the quantity of C++. Java has been jokingly refered to as C++--++. The "--" refers to the stripping away of all the majority of the problems that Scott Meyers addresses in his books.
PS Object Oriented is a concept adapted from functional programming languages, i.e. LISP.
Re:Compilers (Score:5, Interesting)
Invariant/struct discussions and binary compatibil (Score:3, Interesting)
Re:Compilers (Score:4, Interesting)
I believe that MS VC++ 7.0 (or whatever it's marketed under now) and G++ are the most compliant of the bunch. IBM's compiler may be standard, but their linker is anything but -- thanks to it we can't use dbx or gdb on our code base (both simply core either while loading the core image or when you do a "where"; IBM's dbx occasionally works but never gives proper symbol names and setting break points is impossible). I don't have any experience w/ Intel's compiler so I can't say there. HP's compiler is abysmal.
One interesting place to look at compatibility is the Boost [boost.org] library -- Boost is a rather large C++ library being developed by some of the big names in C++ that may wind up in the next standard -- and how well it compiles on various platforms and compilers. Check out the compiler status [boost.org] page. It's certainly not a definitive test of what is and is not standard, but it's a data point.
You're certainly correct in that C++ compilers and their STL libraries have come very far in the past couple of years. One of the worst (Microsoft) is now one of the best -- largely due to them hiring a project lead that's a STL advocate.
C++ in the long term. (Score:3, Interesting)
The discussion of class design has nearly nothing to do with C++. I can use Java to build overly complex towers of inheritance. I can also use it to build poorly defined libraries. One think I *can't* easily do is blow myself (and the underlying OS) up do to a memory allocation problems.
I see C++ remaining for many years to build those "cycle critical" components, which are going to be consumed by languages with a guard over the chainsaw blade. Programmer efficency should always trump speed concerns until you have exhausted *algorithmic* improvement. I don't know how many times I see programmers saying "I'm using C++ for performance" while simultaniously writing something that is going to run in o(n^2) time, when a o(log(n)) algorithm is available. Yes, your C code will run your inefficent algorithm quicker than I would in a protected environment, but if my protected environment allowed me to see the abstraction that runs the fastest algorithm, my code will still be faster for large data sets.
Re:Compilers (Score:3, Interesting)
This isn't the only such article, but it's the only one I'm finding on a brief search; IIRC, I think I've also seen similar stances from Meyers and Dewhurst. Not certain, though, 'cause I can't seem to find them (yay 30 second searches.)
Which ADTs? (Score:3, Interesting)
Come on. If you're talking about vectors, lists, sets, queues, stacks, hash_maps, etc., then I think the STL does, via templates, quite a stunning job of encapsulation. Stroustrup's comment in the article concerns wider adoption of the STL as a starting point for more developers, and I challenge straightforward applications developers to disagree with that. In reviewing others' code, I'm frequently surprised to see arrays being used where vectors or lists would suit as well and be safer, and frequently disappointed to see many functions implemented without templates where they could be effectively abstracted and made much more reusable (and refactorable, if that's a word) by using templates. Please tell me where vectors, as an example, fall short in the encapsulation goal.
Where have other languages succeeded? Java provides a base int type and an Integer wrapper, and this is a fundamental data type. Is this success? I just think it's confusing. And what about operator overloading in Java? Yes for Strings but no for user types? I think operator overloading, in a dedicated OOP language of all things, is very important to encapsulation, but Java says "too dangerous"!
Rubbish. And I'm not really meaning to pick on Java. My overall point is that on an application level there is a pie-in-the-sky goal that might be feasible in terms of encapsulation and that's what I believe we should strive for. But on a library or language level, saying C++ is at fault for not ensuring "perfect" encapsulation (and I'm not sure what that is) throughout the libraries is a little naive. Please point out the language that gets anything fully correct without sacrificing something else. I mean, isn't this why we have different languages for different things?
Finally, I don't find that sentence insightful. Saying C++ is "without" safety is only illustrating a complete lack of familiarity with the STL. The programmer does have to keep track of things at times, but nothing even approaches real difficulty until you start creating your own ADTs. Mainstream types of the "Shape" or "Person" or "Animal" ilk are fine and dandy and really no more difficult or "dangerous" than Java or C#. It's not until you get into the implementation of things like "vertex_queue" or "parallel_list" that you, admittedly, start to get into much slower going territory. But there's also a lot of power there, too, power that's taken away in other languages, such as Java, because it's too "dangerous".
What is OOP? (Score:3, Interesting)
class F {
float a;
public:
F(float a0) : a(a0) { }
template<class X> X operator()(X x) const { return X(a)+x; }
}
is it OOP? It looks like OOP: it has a member variable, a method, a constructor and so on. But actually I'm defining a function closure. In Haskell you coud write an F(a) object as (a+).
My point is this: for many programmers today objects are often a(n awkward) vehicle for computing with closures. This has many payoffs: it gives the ease of functional programming but also potentially provides many performance benefits. I code like this all the time as do hundreds of others. This is how you need to code if you actually want to do anything non-trivial with the STL.
So in some sense I'm an OOP programmer. But in another sense I'm not. I'm not writing my code this way because I want to work with objects - I do it because this is the only way I know to treat a polymorphic function as a first class object in C++. Really I'm a functional programmer forced to use C++. It seems to me that many of Bjarne's remarks are way off the mark for programmers like me. We have to define classes for every damn little thing!
Read Stroustrup's Design and Evolution of C++ (Score:4, Interesting)
If you hate C++, it's unfair to suggest you read a book on it. But if you have any fondess for C++, or use C++ (even if you dislike it), Design and Evolution of C++ [att.com] is probably worth your time. You learn why C++ is the slightly confusing mess that it is, and why Stroustrup believes it's the only way it could have succeeded. Having a grasp on why C++ is C++ (and not Objective C or Java) can improve your C++ coding abilities. And understanding why behavior you don't like is there can at least help minimize the suffering ("This is stupid, but there really isn't any way to change it.").
Re:Scott Meyers (Score:2, Interesting)
I swore off C++ almost a year ago (wish I had done it sooner), and in retrospect, getting "the maximum" from C++ felt like getting blood from a turnip.
"""
Gawd bleshya for your honesty.
Fess-up time:
I was a C++ _lecturer_ about a decade ago, and would with a clear conscience recommend it for almost everything(*), but I more often than not (i.e. 90% of the time) recommend _other_ languages than C++ nowadays.
I've even heard occasional derogatory remarks from those on the national standards committees who ten years ago thought the road to programming heaven was paved with C++.
YAW.
(* I even wrote a real-time microkernel in C++ in order to prove to my students that C++ didn't have to be slow. I could task-switch 6000-times a second on a 486/33, for example (but not do anything in the tasks obviously!))
Re:What is OOP? (Score:4, Interesting)
Why is this useful? I do a lot of numerical/engineering work. Say I have a root finding algorithm that throws a bunch of methods at a function in an attempt to find roots. It might first try doing some interval arithmetic to bound the roots and then when it's close enough go in for the kill with a newton solver. So I need to be able to write a polymorphic function that can be evaluated on the types appropriate to these methods (first intervals and then maybe doubles) but also be able to hand it in as an argument to a solver routine (which in this case would be rank-2 polymorphic though people will tell you C++ can't do that!). The above is the only way I know, And the cool thing is that It can also be a partially evaluated function (ie. in the simple example I gave I'm passing in the two argument function + but partially evaluating it by giving one of the arguments 'a'). This is all routine stuff in the functional world and is beginning to be routine in C++, but not yet. It's kinda object oriented but the object oriented frame of mind really is the wrong way to look at it.
Greenspun's rule. Yes, someone said that about some code of mine recently. But I have a response. For one thing the primary function of Greenspun's rule is to provide strokes for Lisp programmers' egos but these are the wrong people! C++ is a typed language and Lisp isn't. This makes a big difference. These methods push C++ more towards typed functional languages like ML or Haskell. Secondly: The example I gave is of a closure, written as (a+) in Haskell. But look where the work is happening: I haven't written any kind of interpreter, the compiler's doing the work. In fact if you take this stuff to its logical conclusion you're not implementing a Lisp interpreter but instead twisting the C++ compiler into a Haskell compiler. And if you don't believe me, here [gatech.edu] is that logical conclusion. If you look closely very little of that code is executed at run time (the lazy lists are), instead that minor mountain of code is directives to the compiler telling it how to behave like a Haskell compiler.
As for performance penalties: yup, they exist. It's the so-called abstraction penalty. I don't really understand why it exists because it takes only simple rewriting rules to eliminate the overhead but compiler writers don't use them. Luckily people like Veldhuizen are writing papers [iu.edu] showing the compiler writers how they should be doing their job.
Re:magic programmer education (Score:3, Interesting)
The complexity doesn't just stem from having choices. It's from exposing problems to the programmer that they fundamentally don't understand yet. Dealing with templates in a world where you don't understand generic programming is going to do more harm than good. Dealing with exceptions in a world where you don't understand RAI. Dealing with multithreading in a world where you don't understand how the C++ memory model doesn't grok threads. I could go on.
I've interviewed "senior" programmers a fair bit, and I'm invariably struck by how many of them (basically all) can't do something as simple as a thread-safe getter/setter in C++, but even the more junior programmers can get it right in Java on the first try. These are the kind of mistakes that literally steal weeks of productivity.
Sure, you can simply not use all those features, as a lot of C++ programmers do, but the end result is a crippled language that has most of the disadvantages of Java, without any significant advantages over C or Java. This is exactly the scenario where C++ turns out to be a poor choice.
I think rather than hardware store metaphor, I'd suggest something along the lines of mountain climbing. Free climbing is the "cool" thing to do, and it has certain advantages over the "safer" approach, however the vast majority of folks out there shouldn't do it, as sooner or later it will do more harm than good.