Actually, I am a big fan of C++ code. Smart code may cause problems and I agree with that. You know what else causes problems? Tool churn and language churn. At any time of the night and day I very much prefer figuring out somebody elses smart code than figuring out yet another tool that we apparently need. It may not necessarily be that one thing wastes more time than the other but I am 100% sure where my preference is as far as what kind of problem I like to work with.
C++ is notorious for each new version introducing a new way of doing things, so I don't think it's a good anti-churn language (plain C is more defensible for that, though I wouldn't use it for other reasons). And there's certainly tool churn in the C++ world. And frankly C++ has been a poor choice for long enough that I don't think "churn" is a good reason to keep using it - I'm not exactly thrilled when I pick up a TCL codebase from 1996, but you can do it and it'll work.
Comments
Actually, I am a big fan of C++ code. Smart code may cause problems and I agree with that. You know what else causes problems? Tool churn and language churn. At any time of the night and day I very much prefer figuring out somebody elses smart code than figuring out yet another tool that we apparently need. It may not necessarily be that one thing wastes more time than the other but I am 100% sure where my preference is as far as what kind of problem I like to work with.
C++ is notorious for each new version introducing a new way of doing things, so I don't think it's a good anti-churn language (plain C is more defensible for that, though I wouldn't use it for other reasons). And there's certainly tool churn in the C++ world. And frankly C++ has been a poor choice for long enough that I don't think "churn" is a good reason to keep using it - I'm not exactly thrilled when I pick up a TCL codebase from 1996, but you can do it and it'll work.
Doesn't C++ have a lot of churn recently? The transition to C++11, best practices evolving, new features in C++14/17/20?