I've been doing nothing but modern C++11 for a year solid and I have to also agree. C++11 and its standard libraries are a huge improvement but is still difficult to iterate and prototype with. Templates, lambdas, and generic programming are great additions but still very difficult to deal with and debug at times. By using Intel's compiler performance can really scream, but the time it takes to get things done is very tough to deal with.
Contrasting this to Julia/lighttable/Juno is like night and day. Programming in a canvas/all REPL style is unbelievably freeing since each little piece can be tested and iterated on quickly and easily. Then the program can be organized in a continuous matter while it is being made. The mental energy needed at any one point in time is massively decreased since classes, inheritance, types, memory, and data flow don't all have to be dealt with in an interwoven manner like C++.
The performance won't be equal immediately, but being able to prototype, then optimize, then only have to replace minimal parts with native code after they have been shown to be bottlenecks is amazing (and calling C is even super direct because of strong typing)
So after a solid year, I agree with the idea of using C++ only if there is no other option.
My biggest complaint about C++ is all of the non-intuitive "gotchas" and corner cases hidden all over the place that seem to change with every new release. A lot of times the obvious code is either subtly broken and/or less efficient than one would expect.
Reading through "Effective Modern C++," I was constantly thinking, "How is anybody supposed to remember all of these corner cases?"
I remember working on a small in-house C++ library with a colleague.
Being mostly a C programmer, my code in C++ was basically (as he coined it) fancy-C. Then he rewrote my code in "the C++ way," after which the code became completely opaque to me.
My initial mistake was that I expected C++ to be like (or similar to) C, a mistake I believe many of us make. C++ is a lot more complex in scope (not necessarily in a bad way, either) and requires proper learning.
I came to the realisation that C and C++ are not even similar languages. Yes, you can write proper C code in C++ (with a bit of added strictness), but that's not how one should write C++. Also, I think that lot of the "anger" towards C++ is that the the names makes you think it's like C, but then you start learning the language and realise that in fact it is nothing like C on the outside, just on the inside.
Anyway, I'm not hating on C, I actually haven't taken on the quest to learn it properly, and I still rely mostly on C.
I think you're right there about the differences between C and C++ and the root of the anger towards it. C is completely alien to me - I wouldn't be able to competently write a decent program in it. But C++ is a different matter.
I have worked with people who write C++ in "fancy C" style too.
I concur with this. I use C++ daily and have been for about 20 years, and I still run into gotchas and things I misunderstand all the time.
I feel it's even worse than that, though. There seems to be a culture among C++ programmers to do things in overly clever ways and to push the limits of readability and understandability. Just look at the headers for the standard C++ template library, for example. (I'm currently looking at the ones shipped with gcc.) They don't even use consistent indentation, and have single letter variables that are meaningless to all but those who wrote it. It's pretty frustrating to deal with.
Looking at the headers is not the way to learn about the library. Anything that you learned that wasn't documented in the standard or any of the many books, articles, and videos available would be an implementation detail that you couldn't rely on in portable code or even in the next version of gcc.
These files are only intended to be seen by the compiler and it doesn't complain about indentation or single letter variables.
That was my impression when I took a course in C++ as a grad student. The course emphasized C++11, so I assume it represented (at the time, early 2013) modern usage. But 80% of every lecture consisted of presenting some example code, and explaining how what you think this code should do (if indeed it's obvious at all) is probably wrong. So many gotchas. It made me terrified to think of trying to write/test/debug a large and sophisticated C++ code base.
Well, you have to think in each case what makes sense to you, look at the requirements of the project, team skills, candidates pool, etc and pick the best fit.
Choice of programming language is an architectural decision with a big impact and it can't come down just to preference or how nice a language feels, although that plays a part too.
One can also do quick prototyping in one language and the real thing in another one, although prototypes have a nasty habit of surviving into production.
Julia is one example of an alternative, but the real point of course is that even modern C++ requires a lot of extra mental energy that just isn't needed in almost any other language. It has its strengths, but I do agree with not using it unless it is completely necessary. Because of its massive language and compiler complexity it is becoming something of a black art the way assembly language has been in the past. Very powerful but very complicated.
Contrasting this to Julia/lighttable/Juno is like night and day. Programming in a canvas/all REPL style is unbelievably freeing since each little piece can be tested and iterated on quickly and easily. Then the program can be organized in a continuous matter while it is being made. The mental energy needed at any one point in time is massively decreased since classes, inheritance, types, memory, and data flow don't all have to be dealt with in an interwoven manner like C++.
The performance won't be equal immediately, but being able to prototype, then optimize, then only have to replace minimal parts with native code after they have been shown to be bottlenecks is amazing (and calling C is even super direct because of strong typing)
So after a solid year, I agree with the idea of using C++ only if there is no other option.