Slashdot Mirror
Interview With Bjarne Stroustrup
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."
Speaking of C++, is there a compiler that complies with the ISO standard already? Does anyone use it?
Save your wrists today - switch to Dvorak
Where do you see C++ going as a language?
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?
I have over 70 freaks, do you?
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 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.
I used to wonder what was so holy about a silent night, now I have a child.
Stroustrup and the interviewer miss one important point in the class vs. struct and invariant discussion: binary compatibility. The reason why you should not access variables in structs/classes directly is not always that their representation may change. More often it happens that you need to add a member, but this is not possible without breaking binary compatibility (at least on the usual Linux/Unix compilers). So you need to use the private class/d-ptr pattern to hide at least future members from the public class. This does not break apps that use the class members of earlier version, but it would make the API inconsistent, as the newer version would need to offer a different way of accessing the members. And the easiest one is to have get/set methods. So if you don't want to fall into the inconsistent API trap later, you should use get/set methods from the beginning. It's the only chance to have a consistent API over several evolving but still binary compatible versions.
I programmed in C for years, mostly due to the performance of the early machines I used. Today, I wouldn't consider going back to C unless it was for time critical functions. Everything I do these days is in an environment that protects me from the gory details of memory management and pointers of doom. If I really need performance, I am going to profile my code and find the parts that really need the boost, and then recode the classes as C++ COM or more recently C++ assemblies for .NET. It is the same procedure I used to use when C was my primary language: find the performance hot spots and drop to assembly if needed.
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.
Sig under construction since 1998.
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".
Chr0m0Dr0m!C
If I write something like:
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!
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
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++ 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.").
Search 2010 Gen Con events
"""
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!))
Your head of state is a corrupt weasel, I hope you're happy.
It wasn't a library that really saved the Java project so much time. Indeed, because of performance considerations, the standard Java collection classes weren't used. No, the faster development time came from the fact that the C code had to deal with a lot of ownership and synchronization issues, much of which is quite error prone in C. Java's runtime simplifies these issues (and amazingly does it in a way that tends to be faster than what C can do without a LOT of work) such that you don't waste a lot of time on them.
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.
sigs are a waste of space