> If Bjarne had been able to keep C++ his own creation ... C++ might have avoided becoming the over-designed language its become.

My impression is that this is wrong - the language owes essentially everything that it is (including the over-design) to Bjarne. I wrote my first C++ program in 1992 (or perhaps even earlier? I can't find copies of anything I wrote in C++ earlier than 1992), and I've been following the evolution and standardization.

Bjarne is definitely the person that started the "Oh, it's useful! Let's add it to the language incoherently introducing redundancy, duplication, and corners, and we'll sort it out later" mess that is C++.

I campaigned (unsuccessfully) in 1993 with my employer at the time to switch from C to C++ because I saw the benefits. Back then, C++ was already a mess in the making, but it was still small and elegant, and if you stayed within the subset supported by Turbo C++, g++ and Cfront, life was good.

Since 2005 or so, I've been campaigning against C++ and for C (or Python if performance is not critical). That was after I was brought in to fix a C++ monstrosity of a project (and not the first project like that), and realized that the problem actually IS with the language and culture.

Some developers need tools that offer better performance than the languages you enumerated. Not that I have anything against those languages or more abstract languages in general. Quite the contrary, if it was up to me we'd all be writing lisp. Outside of serving as a prototyping tool, a role that Python and Matlab admittedly fill pretty well, I don't believe using Javascript or Ruby or any other (interpreted/high level/more abstract) language would bring much to the problem domain I do most of my work in, realtime computer vision.

It may be a shock to some on HN, but there are other applications for computing than web development. I doubt Scala is going to be penetrating triple-A game development any time soon, although I do think it's neat that Javascript has become popular for game UI work. I really like that C#/Unity is going strong and I'm really itching to do something cool with WebGL, asm.js, and/or emscripten.

But despite all the progress these languages have made, some problems still haven't been overcome and it's disingenuous to imply that they have. I doubt many would make the argument that C++ is suitable for web development, and I would expect most people to realize that native code still has its place, at least for now. The day I can use Python, Ruby, F#, Haskell, Erlang, or something cool, I will officially be the happiest person on the planet. It hasn't happened yet. Maybe Rust (oh yes) or Go will set everyone free.

With all that being said, C++11 is a very welcome addition to the language. While adding more bulk to the language, it ends up reducing the complexity of your code. Auto and decltype have been fantastic for eliminating redundant typing info and boilerplate by making code more generic. Smart pointers, unique_ptr particularly, have been great. For Lambda functions combined with STL algorithms like for_each have eliminated a substantial amount of code on their own. Move semantics have had the effect of reducing the amount of line noise by reducing the frequency of seeing things typed const& and the double whammy of bringing performance gains for little or no effort in many cases. I don't think anyone can deny that C++ is a bit heavier than any language ought to be, but it's what we have and I'll welcome any attempt to make my life easier.

Software and programming languages are not zero sum. The use and existence of C++ doesn't preclude the existence or use of another language. Don't try to convince yourself and others that all problems are nails just because you really like hammers.

edit: for the record, I mostly do Python and Clojure outside of work when I'm not doing something graphics oriented

> I would expect most people to realize that native code still has its place, at least for now.

Native code has always had a place and will always have a place. New applications will be written in C++, 20 years from now, when all the inefficient, fadish languages (and the inconsequential websites that they power) have long been forgotten.

Any language can be native, it is just a matter of providing a native code compiler implementation for it.

Inconsequential ole' google

Agreed. I recently started working in C++ after spending a lot of time with more traditional web application languages like Ruby, Python and Clojure. It was shocking to see how grotesque and overbuilt the language was compared to the tools I was used to.

I don't think I was just having sticker shock due to the relative lack of power and expressiveness of C++. I expected to spend time managing memory, recasting objects, etc -- that didn't surprise me. Instead, I was surprised by how badly different parts of the language play with each other, and how many more parts C++ has. ANSI C has about 30 keywords. C++98 had about 30 more. C++11 adds even more. All of these language constructs have complicated relationships with each other, often filled with gotchas and traps. Compare this with the ~30 keywords in Python (and even less in Clojure).

If I'm bound by CPU performance nowadays (which doesn't happen often), I'd use Go or a JVM language. If I absolutely had to, I'd consider C. But never C++.

I am currently doing a small performance intensive project in C++, and my take is that C++ has been a good fit for this.

But you have to consciously decide at the start what set of features that you will use. And no more. Because C++ has multiple usable subsets. Find one. Stay within one. Avoid confusion. (Particularly if, like me, you're not a C++ programmer and don't wish to become one. Then you can have a clearly defined boundary of what needs to be learned for the project.)

I recommend anyone using C++ to do this exact thing. It's the sanest way to use it without driving yourself mad when something no longer works because X causes issues with Y.

Any Rubyist or Python developer will be caught off-guard with C++. Dynamically typed languages are intrinsically easier, and languages like Python and Ruby do garbage collection for you, resulting in a lot less work for the developer.

C++ does none of that. It's a slightly higher-level modification of C with object-oriented features, and C is still a lower-level language closer to, say, ALGOL or Simula rather than higher-level like Java or Smalltalk. Adding OOP still retains the hardware control and all of the bad stuff that comes with it (segfaults, buffer overflows, etc.), but adds complexity.

C++ is complex. Twisted. Mangled. But it's powerful, and you can do things in it that you could never dream of doing in C, Java/Jython/Mono, Python, Ruby, or Go.

It's like a Mitsubishi Lancer Evolution. It's a pain in the ass to deal with on a daily basis, but its potential is simply unmatched by any other vehicle in its price range. There are others that are more comfortable. But none reach the capability and sharpness of the Evo.

C++ is the Evo.

>Dynamically typed languages are intrinsically easier

I don't think this is necessarily true. Dynamic typing moves an entire class of bugs from compile time to run time. And, I am not aware of what benefits it brings (other than minor expressiveness) that can not be had in a static type system. For the most part, you will right code assuming a variable has a given type. If that is not the case, you will get a runtime error instead of a compile time error. In the cases where the variable can be multiple types, doing so in a static type system can be as simple as declaring the type to be polymorphic (or as horrible as java generics, or as hacky as void*). The other advantage of dynamic type systems is that they often come with autocasting.

While both of these do provide some expressiveness, working around them in statically typed isn't really complicated, just a minor amount of boiler plate.

The main awesomeness of Python's type system (and maybe Ruby's, I've never used it) isn't dynamic typing, but duck typing. The idea hear is that you almost never care what type an object is, only if it supports a given method. For example, if I define a new object, and define a method 'read()', I can pass it into a function that was expecting a file, so long as it only calls the 'read()' method.

Of course, avoinding garbage collection is still a big advantage.

I'd be hard pressed to name a popular dynamically typed language that does not offer duck typing. Technically there may be a distinction, but it is not one that matters.

The thing that I find creates the most boilerplate for me with static typing is useless helper classes that only exist to get around the fact that class A owns object of type B, so you don't want to allow an object of type B have a method that requires its parent A. Instead you create a class C owned by A which everything that B needs for that call can move into, and then let B know about C. (It does not much matter whether you make A inherit from C, or make C owned by A. Though I stylistically strongly prefer the second.)

Yes, you can set up mutual recursion between two classes in C++, but this involves some gymnastics and is frowned on.

In a dynamically typed language you'd just pass objects of type A into a method for type B.

Refactoring out a whole new class out of an existing one is not "a minor amount of boiler plate" in my books. But that is what C++ pushes you to do.

I'm not entirely sure I understand your example. You have a class A, with a member of type B You want B to have a method which takes an object of type A as a parameter.

I do not see why static typing causes difficulty with this. The only gymnastics I have seen in C/C++ do accomplish this is forward declarations. These are not needed because of the type system, but rather because C/C++ requires things to be defined before they are used. For example, java does not have this requirement.

Also, I believe that Go has something simmilar to duck typing, and its a static type system.

Go's "duck typing" is basically Java-style interfaces that don't have to be explicitly declared: if a type has all the properties to fulfill an interface, it automatically fulfills it.

This sounds similar to duck typing, but it's significantly less powerful because you pass values into functions with a particular declared type, and you can only access methods available to the declared type of the value.

For example:

  interface MyInterface { Bar() }

  struct Foo {}

  func (this Foo) Bar()

  func (this Foo) Baz()

  func MyFunction(arg MyInterface) {
    arg.Bar() // Fine, because MyInterface has this method.
    arg.Baz() // Compiler error because MyInterface does not have this method.
  }

In this example, you could use reflection or the unsafe package to call arg.Baz() despite the fact that arg isn't guaranteed to have that method, but it takes some work and you're basically breaking the way the language is meant to be used.

This isn't a problem in Python or Ruby because they don't have a notion of declared type in function arguments -- the "type" is resolved at run-time by method lookup.

You can use duck typing (without losing the compile time type checking) in C++ using templates. Somehow they get a lot of bad press, but for me they're one of the key features of C++.

I've never worked with templates. Do they require you to write the function for use with templates, or can you use templates to pass an object into a function which was designed for another specific type of object. Based on my limited understanding of compilers, I do not see how you could efficiently implement duck typing without some type of JIT compiling.

They require you to write the function for use with templates; as long as the callee is ready to use templates, you can pass anything that fits the interface needed. Everything is done at compile time.

You can use a generic type as argument (template <typename T> void method(T arg) ), or a templated one (template <typename T> void method(MyObject<T> arg) ). In both cases the method will fail to compile if the body requires a missing field or method, but in the second one you get a standard "type mismatch" error, while in the first you'll get a "type X doesn't support method Y".

C++ is the 1980's Lancer with the same frame and same engine and the rest kept up to date with the latest performance tech. Fortunately for it, all the high performance cars which have been built since then can't reuse the same parts which are currently dominating the market.

The problem isn't really the number of people on the committee, but rather the inability to remove and revise features without breaking backwards compatibility.

> Today we're focusing more on expressing solutions in code that are much closer to the way that we think. Whether it's Ruby, F#, Scala, or Javascript, the tools we're using allow for more powerful solutions in far less code and complexity than C++.

If you compare the amount of code to the ease of abstraction then I'd say C++ scales much better than languages like JavaScript. It's just that C++ gets multiplied by a huge constant: http://i.imgur.com/WxU2oLy.png

"[const const {star}], [const {star} const]"

This is the reason why I hope I never program in C++ again: you can't learn it (or re-learn it) by inspection.

Yeah, I suppose your example has something to do with the spiral rule (it's been many years), which comes from C (and C has its excuses). But if you come at that cold, it's impossible to reason it out.

No language is entirely learnable by inspection, it's a scale, and C++ is way on the wrong end.

Waaa, programming is hard, waaa, I don't want to worry about const correctness of pointers, waaa I don't want to know what pointer is at all, waaaaaa let me keep making my HTML programs in Visual Clojure BASIC.

The particular example of the language could have been done with distinct words, not a single overloaded word that depends on order of placement. More decorator-like, for example.

int * - pointer to int.

int const * - pointer to const int.

int * const - const pointer to int.

int const * const - const pointer to const int.

I'm not sure what type of grammar could have been used to make this easier. Nobody said that indirection is easy, but indirection IS essential.

Everything on the right of the dash in your example, or something like it.

If you have to use other words to describe what something is, why not use the other words in the first place?

All he did was reverse the order of the types. Right-to-left parsing really isn't that complicated, and mimicking English grammar is not as good an idea as you think it is.

Because it requires too much typing, especially for something you use all the time. Seriously, the syntax is not that difficult to understand and remember.

COBOL++, hey it still has a C in it.

ADD 1 TO COBOL GIVING COBOL

(well to be fair, 'add 1 to cobol' should be enough)

Your username really suits your childish attitude.

Dude, "const const" is not even valid C++. Come on.

He's thinking of C, which allows all kinds of dumb crap in declarations.

    const typedef;

is my favourite.

for the record, const const * is redundant. I think const is only so confusing because you can write it two different ways (char const * vs. const char *); if only the former was allowed, it would seem a lot more logical.

int* - pointer to int.

int const * - pointer to const int.

int * const - const pointer to int.

int const * const - const pointer to const int.

Is that so hard? Those people posting here who think that THIS is the hardest problem in computing should perhaps find a new line of work.

Exactly: if 'int const * ' were common, it would be relatively clear that const goes after the type of the thing that is const - but the overwhelming use of the alternate form, 'const int *', makes it more confusing what to do.

const int * - pointer to const int

I see this is as

(const int)* foo;

which is the same as

(int const)* foo;

And people prefer

const int foo;

over

int const foo;

So it all makes sense in terms of the grammar. Admittedly, it can be difficult to remember, but pointers and const correctness are complicated and combining them is going to be complicated to write out no matter what grammar you use. Even if the grammar was restricted, it's difficult to remember this type of thing and if you encountered such code in the wild and had any doubts about its semantics then you would look it up on Google before modifying it (right?)