> inefficient abstracted programming models where two years down the road
> you notice that some abstraction wasn't very efficient, but now all
> your code depends on all the nice object models around it, and you
> cannot fix it without rewriting your app.<p>The opposite can also be said. By re-inventing a simple data structure, you can end up 2 years later in the same position where your structure is inefficient (list vs. array, etc) and you end up having to rewrite your app. While implicit operator overload was probably a C++ mistake, it does allow to replace some kind of structures with other one without changing the code relying on them.<p>Other than that, I kind of agree that C++ is kind of terrible. So is perl, php, js or any other languages that send a barrage of features to the programmer without managing to educate them on their impact on performance and memory structure. Most C++ devs know about vTables and that's about it. I would also argue that C isn't a very good language either. It may be simpler to "get" what actually happen when you run your code, but has sub par code organization, total lack of "pointer flow" tracking, causing huge security traps and has an evil reliance on casting for any kind of structure/callback abstraction. All of those things could be "fixed" in new languages, but beside Rust, it seem there is no leverage for proper system level languages these days. OOP is probably a better choice for business programming anyway, but that's not even half of the market.
This was seemingly discussed on HN 7.5+ years ago: <a href="https://news.ycombinator.com/item?id=51451" rel="nofollow">https://news.ycombinator.com/item?id=51451</a>
My biggest problems with C++ (one of my favorite languages)
1. ABI issues.
2. Template Error messages.
3. Templates need be defined in header files (generally).
4. Object Slicing.
5. Cross platform Unicode/ASCII string encoding.<p>I understand the reasons behind these, none the less they are really annoying.
In the spirit of Greenspun's 10th Rule<p>Any sufficiently complicated C program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of C++.<p>For example:
1) Macros for data structures instead of templates
2) Virtual functions emulated with function pointers
3) goto fail instead of exceptions
I agree with Linus. C++ is too complex and overengineered, and taking in contributions in it for something like git, is a recipe for disaster.<p>However, C in all its simplicity already has its potential for abuse. Macros can go very bad. Very bad. (Just look at openSSL).<p>It is also not difficult to abuse the left-right rule in pointer arithmetic: <i></i><i></i>*x->a->c=5. It can easily become incomprehensible.<p>We did not need C++. We needed a way to further simplify C.
<i>"The fact is, git is better than the other SCM's. And good taste (and C) is one of the reasons for that."</i><p>If he likes simplicity and good taste then why did he pick Git over Mercurial? Because he did not implement the latter?
It's only this time around that I've read the sad conclusion to this thread, from the original contributor<p><a href="http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918" rel="nofollow">http://thread.gmane.org/gmane.comp.version-control.git/57643...</a><p>> Unfortunately, I haven't had any time inte the last few days to code, nor read
mail. I'm assuming that there is no point in me finishing the patch and that git
will go with the strbuf solution? /Lukas<p>... with no response.
Everything I've ever wanted to be able to do with C++, I can do with Lua. I see it as the obvious progression from C - though I still find C a highly useful language. Putting Lua on top of whatever needs to be low-level, written in C, provides the next-generation toolset that I find so very productive.
The fact that C++ is vast is well known. If a language supports some arcane things then it will end up in the code (even if its very less percentage wise). Because its arcane, most of the developers will not be able to deal with it effectively. Example of arcane: overloading comma operator.