Bjarne Stroustrup talks with Bill Venners about raising the level of abstraction, why programming is understanding, how "oops happens," and the difference between premature and prudent optimization.

Read this Artima.com interview with the creator of C++:

http://www.artima.com/intv/abstreffi.html

What do you think of Bjarne's comments?

I like a hybrid approach these days; there are still occassions when I want to use C++ for particular focused tasks, but in general, I'd much rather be writing Java, C# or Python. JNI is kind of clunky, but the other two work quite easily with COM automation objects.

For many (if not most) applications, the largest portion of the code is indifferent to the performance of the underlying implementation langugae. That is, most of the wrapper around the core algorithms doesn't need to be done with the same kind of high-performance language (like C or C++) as the algorithms themselves. Why not do this large part of the code in a more programmer-friendly language? A good example of this would be the Numerical Python stuff (NumPy), which exposes lots of high-performance number-crunching capability which can be orchestrated quickly and efficiently (from the coding perspective) with Python.

Bjarne Stroustrup: ...I don't have to cast an Object to an Apple to use it, and I don't have to fear that you have treated my vector as a vector<Fruit> and snuck a Pear into it, or treated it as an vector<Object> and stuck an HydraulicPumpInterface in there. I thought that was pretty well understood by now.

This argument is used often in favor of static typing, but it seems to be saying that if you use a dynamic language, you will have an irresistable urge to dump all kinds of meanlingless junk in your collections. In practice, I doubt that this is often really an issue.

> Bjarne Stroustrup: ...I don't have to cast an
> Object to an Apple to use it, and I don't have to fear
> that you have treated my vector as a vector<Fruit> and
> snuck a Pear into it, or treated it as an vector<Object>
> and stuck an HydraulicPumpInterface in there. I thought
> that was pretty well understood by now.
>
> This argument is used often in favor of static typing, but
> it seems to be saying that if you use a dynamic language,
> you will have an irresistable urge to dump all kinds of
> meanlingless junk in your collections. In practice, I
> doubt that this is often really an issue.

Yeah, I agree. In theory this is a problem, but in practice I never see these kinds of errors; they must be pretty rare. A much bigger weakness of Java vis-a-vis C++ is the absence of C++ style references (which are are very good at making it hard to pass null) and the lack of stack-allocated objects (which are great for resource deallocation).

Many people seem to think that C++ is about performance and thus, you are sometimes "forced" to use it even if you would prefer Java or C#. To me, this is not the issue at all. I prefer C++ over C# and Java not because of performance but because of the way it allows you to think. I find that it offers a much more diverse set of solutions to a given problem. And as Bjarne states, the type system helps you put your thoughts into order; when you have to state the type of a container, you are forced to think through what you will actually be using it for. So even if you don't accidentally put an apple into your pear vector, once you have stated the type, you've spent some time thinking through what it is that you actually want it to do.

Furthermore, I find that C++ has a certain neatness to it which is hard to describe. For instance, I have a very small class template that adds range checking to a type. Instances of this act just like int's (if the template type is int) and youi rarely notice it in the code. Combined with RAII, you get what I find to be very nice code. In Java and C#, In Java/C#, I would probably not have made a such type. Where a class in C++ seems like a "type" to me, classes in Java and C# seem more like a combination of data and code. (I realize that both are both, it's just not the same feeling). I think that C# properties emphasizes this the best; it indicates that a class has "sub elements" which you want to access more or less directly.
Now I don't intend to start an "operator overloading is bad/good" discussion or anything. I am just saying that C++ is more than just a well performing language which can be used only when you optimizing.

when you have to state the type of a container, you are forced to think through what you will actually be using it for. So even if you don't accidentally put an apple into your pear vector, once you have stated the type, you've spent some time thinking through what it is that you actually want it to do.

I don't understand why the same can't be done in Java (and C#, although I have to assume here...). When I want a strong typed container (for Apples for example) I create a class, let's say ApplesContainer implements List (or whatever I decide). Then this class has an instance variable of type List (a Vector, ArrayList or whatever). It implements all the methods of List, but all those methods enforce type checking and forward to the variable List. Doesn't that help in your thought process?

Java will soon have Generics and auto-boxing that will replace such operations anyway... (C# already does that, I also assume). For older Java releases and if you use a lot of different strong typed containers you could use simple code generation (I've used such an approach and it has worked).

OK, you might not have made that in Java/C#, but that's possibly why you program in C++. Choice is good! ;-)

Yes, as Tasos says, generics are coming to both C# and Java (and no, C# doesn't already have them), but in the meantime, it is pretty easy to automate type safe collections in both languages. I think this is easy to find in Java and a fellow named Erick Sgarbi put together a pretty handy add-in for Visual Studio that does the trick for C# (Strongly Typed Collection Builder Addin for VS.NET 2003 on http://www.codeproject.com).

The reason I still use C++ is more often for power, not speed. That is, in instances where I need to do something that just isn't supported by Java, C#, Python, etc. I can only remember one instance where I did it for performance -- all others were in cases where a particular capability was only available through C/C++ (or at least, I already knew how to do it that way, so it was quicker to do it in C++ and provide that service via COM or JNI).

> Yes, as Tasos says, generics are coming to both C# and
> Java

Actually, in this context, I was the first to mention that. "Immitation is the sincerest form of flattery". Not that I invented parameterization, of course.

> but in the
> meantime, it is pretty easy to automate type safe
> collections in both languages. I think this is easy to
> find in Java and a fellow named Erick Sgarbi put together
> a pretty handy add-in for Visual Studio that does the
> trick for C# (Strongly Typed Collection Builder Addin
> for VS.NET 2003 on http://www.codeproject.com).

I didn't find it. Is that statically (compile/link-time)type safe or just dynamically (run-time) type safe?

> The reason I still use C++ is more often for power, not
> speed. ...

and of course the speed it there when you need it

-- Bjarne Stroustrup; http://www.research.att.com/~bs

> Yeah, I agree. In theory this is a problem, but in
> practice I never see these kinds of errors; they must be
> pretty rare. A much bigger weakness of Java vis-a-vis C++
> is the absence of C++ style references (which are are very
> good at making it hard to pass null) and the lack of
> stack-allocated objects (which are great for resource
> deallocation).

In java, any locally declared object, will have its access optimized based on usage patterns (in hotspot and probably any other Jit worth using). And, when the local reference is lost, the resources are deallocated based on remaining references.

In C++ you have the problem of

obj1 *foo = new obj1();

verses

obj1 foo;

and remembering to deallocate the first case. This is a learned behavior which may never be an issue if you learn, from the start to avoid pointers like the plague in C++, except for local data inside of other objects where you can manage the life cycle of the allocation in the cons and ~cons.

The ability to guard against passing null around by using references is really a pointer hack in C++. Java eliminated pointers to remove the whole issue of indirection. Sure, you might have

fooobj foo;

and pass 'foo' by reference, and avoid the potential for a null pointer. But, now you have the whole const issue to deal with because now everyone can change everything because your passing everything by reference.

Garbage collection in Java works fine, but there are other kinds of resources (database connections, open files), and their use is quite error-prone in Java because there is nothing so clean as "Resource Acquisition Is Initialization".

And null pointer exceptions in Java are fairly common. Other langauges (e.g., http://nice.sourceforge.net/) have demonstrated that this could be controlled through static type-checking. C++ references may not be a perfect solution, but in practice I think they work well enough. Const is another issue. In Java for a passed object to be const it must be an immutable type, designed to be const from the very beginning, under all circumstances.

> Bjarne Stroustrup talks with Bill Venners about raising
> the level of abstraction, why programming is
> understanding, how "oops happens," and the difference
> between premature and prudent optimization.
>
> Read this Artima.com interview with the creator of C++:
>
> http://www.artima.com/intv/abstreffi.html
>
> What do you think of Bjarne's comments?

I agree with the concept of abstraction as a level , but of programming.

I do not agree that the sense of abstraction is something to sweat about, reach for
or worry about.

Maybe the level is hard to see cause of the "looking for it" when striving to look for "a high level of abstraction". If the domain is looked at in a "natural sense" the abstraction is there.
What part of it is required.

The abstraction of a domain and formatting it can synq up real nice in C++ . The language suits the integration very well. Why? It is made up of very flexible semantics which format the domain in about any context with code. Take a flexible smiley face - stretch it this way or that, it covers what you need.

The mechanisms or facility of C++ cover quite an expanse of possibilities in terms of what the language can do to code them. Given the benifet of classes formatting C++ can go forward , backward , sideways
diagonally towards any collective association of a past present or future domain. Where do you want to go.

A Question to ask

What is the domain and the context of the domains abstraction at that point in time.

Using certain principles like invariants it is ready for the future without trying It just fits, and fits naturally.

Stop!!! and think!!! about it without haste , do you really see what you think you don't. If you do then maybe you got it.


Perceiving C++ in real terms, I think.


David W. Stubbs

Abstractions tend to leak. See
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

As the pile of abstractions upon abstractions gets higher, the whole house of cards gets a little wobbly. This is especially apparrent in C++. The language seems to contain about 98% of what you need to implement a good string class. This is one explanation of why there are so many different implementations of the string class.

The same problem exists with smart pointers. The C++ community struggled for years with different kinds of smart pointers until they decided that they had to put a smart pointer class into the language. Smart pointers were an invention that attempted to repair some of the problems created by the peculiarities of the C++ programming language.

The bool type has the same history. C++ tried to get along without bool but eventually discovered that the type-creation mechanisms provided by the language just weren't strong enough.

The kind of abstractions you use for generality and reusability aren't always the kind of thing you use for convenience. All large systems have parts that are cpu-intensive and parts that are developer-time intensive. There is no essential reason why different languages have to be used for these different areas. It is the weakness of current language design that flexible and powerful languages do not have the ease of use that scripting languages have. Yes, C++ tries to be a multi-paradigm language, but that is more a result of its heritage and of the limited level of understanding of object-oriented programming that existed at the time.

Abstractions can get you only so far. Sometimes you have to get back to basics.

Templates are touted as a way to get the correctness and efficiency of static typing with some of the flexibility of dynamic typing. But templates are about 8 times as complex as they ought to be. Read any book on the STL and any book on Windows ATL. Are you sure you're writing robust programs if you're writing programs with all that extra complexity?

C++ and its abstraction mechanisms are a work in progress that has been allowed to languish. Really, C++ is a research language.