Hacker News Reader

I disagree, the STL being efficient was essential for the success of C++ since the standard from 1998.

In fact, those parts of STL that can be improved significantly are available from other libraries and are widely used in the industry (like some parts of Boost, some hash tables, etc).

Nowadays C++ is mostly used in environments where efficiency is crucial, and this have been the case for many years already. If you take this away, C++ is wildly inferior to several languages.

C++ in practice has evolved a lot. With modern C++ programming style and techniques, it's actually usable and very practical. If you see code from the 90's though... it's a complete mess. All in all I think it's worth knowing inside out, like C (but they are very different languages and trying to use C++ in a C-ish way will only lead to a 90's style mess).

the biggest problem with C++ is that you can't really use it correctly without knowing it inside out, because as soon as you make a simple mistake that compiles without a warning you're in undefined behavior territory. to efficiently debug such problems you need to know both the language and the debugging tools, which, cough, aren't simple.

costs of performance?

Yes, and what is interesting, the need for efficiency haven't faded away, despite the computers being more powerful every year. I am a veteran C++ coder, and I still find C++ a viable choice. You are getting native compiled objects, which is also efficient due to C legacy, AND, what is important, you are getting this efficiency also in the very abstract code.

This I consider one of the main powers of C++ - you can basically choose which level of abstraction do you want; the language will not limit your choices here.

But I agree the learning curve is quite steep, it takes years to really benefit from the language. What I found is a good practice is to define which paradigms/language constructs will be used in a project, and then to stick with those.

"you can basically choose which level of abstraction do you want; the language will not limit your choices here."

The language absolutely limits you in terms of choosing your abstractions. You can only redefine the operators already in the language. Adding a feature like continuations or dependent types would require a rewrite of your compiler. There is no notion of a metaobject protocol. At best, you can get some of the power of these abstractions by using a brittle mess of templates and objects, and you'll be left with code that is almost unreadable as a result.

If you want to see a language that actually allows you to choose any abstraction, even those that were unknown when the language was developed, look at Lisp and its macro system.

I think there is a different kind of modularity which you are talking about. That a solution that brings different components together requires to know about the other components is obvious. It is about how the components can be designed as free standing modules without any direct dependencies. Of course, a better module system in C++ would be great and things are moving into this direction (clang already has a preliminary implementation of the modules spec).

It is not like the addition of templates broke C compatibility. This happened long before templates were talked about. Still, C code mostly (Yes, with tricky corners.) compiles with a C++ compiler which is great and is exactly what I would expect from a sub-set of a language. Funnily, first you complain about missing modularity due to headers and then you advocate being compatible with C, whereas exactly that feature is necessary for C compatibility.

As to the efficiency: You can actually know which problem you are trying to solve in generic programming by inspecting the properties of types and optimize according to those properties. See for example the different optimizations in standard libraries when it comes to optimizing copies to memcpy calls when called with appropriate types. There is certainly a lot of generic code that is quite efficient (see std::function which compares to native function calls or hand-written virtual function call operators, very fast vector implementations (llvm, facebook), std::thread). There is, of course, bad generic code as there is bad code in every paradigm.

Bjarne Stroustrup was never a huge OOP evangelist. He spend all of 1½ page in the first edition of "The C++ Programming Language" explaining why this technique would be useful in specific situations, back when it was not widely known.

Alexander Stepanov who designed STL is very critical of OOP. Stroustrup likes quoting him, mostly to annoy the evangelists.

The C++ "party line" on the Usenet groups back when the OOP craze was at its top and C++ was a hot new upcoming language reflected Stroustrup's view. OOP was a useful technique is certain situations.

"I think Go got generics much better. Pass an interface{LessOrEqual} to a Sort and you're golden."

That's not generics but interfaces. C++ has them too... Kind of, in C++ they are called abstract classes; eventhough you need to inherit them explicitely.

This is why you need to do type assertions when using container/heap, container/list... And this is why math.Min of two integers doesn't work without any extra work. :-)

Go is pretty cool, I like it a lot. But there are fields in which interfaces are way less powerful than generics.

go generics are different from abstract classes. C++ requires you to think in advance about the kind of abstract operation your class provides, and if you are adding "sort" operation later on, and you realize that in order to sort something you have to have the concept of ordering, you have to add it to all classes you want to be sortered.

Go allows you to create an interface and then to create implementations of this interface for any type that already exists.

Scala solves this problem by introducing implicit conversions, so it's core design is like C++/Java, but the net effect you get from that is like in golang.

Scala solves this problem better with structural typing, which is not that different from what Go does.

Yeah I totally agree, the Go interfaces are much more flexible than those of C++ or even Java.

But please, don't call them "go generics", they are called "interfaces". ;-)

http://golang.org/doc/go_faq.html#generics

Go doesn't have generics. It has cool interfaces, but they solve a different problem, and the lack of generics (or templates, if you prefer) is a real problem in Go.

The party line was always that C++ is multiparadym. Stroustroup said that over and over in his book.

Does the lack of being able to link against pre-compiled modules really make the language not modular?

You have to recompile javascript every time you run it, does that mean that that language is incapable of being modular?

I think you are confusing two different types of modules here.

"C++ is the OOP" is, unfortunately, a very popular stance, especially among people who put "C/C++/C#" on their resumes.

This has nothing to do with the "party line" whatever it might be, the C++ is as much "the OOP" as Scheme i.e. you can use its type system to implement some kind of OOP.

Garbage collection is not something to be proud of. I don't know where you got the idea that C++ as any thing but C with extensions. If you don't have to recompile after changing a template then what is the template even doing? Go is no replacement for C/++

I agree that Garbage Collection; +1. However, C++ is no longer C with extensions. It is now a truly powerful multi-paradigm language in its own right.

My point being that it isn't OOP specifically.