Hah, tell that to my cat! I was having a problem with mice, and wasn't getting good results with traps, so I adopted her from the local shelter. Now, in return for the cost of a bag of cat food every few months, she's kept the house and yard rodent-free for the last 12 years or so. I'll take that any day over having to muck around with traps and poison.
D sounds like a neat language that I'll probably never be able to use. I'm a game developer, and C++ has a native compiler for every machine I would ever need my code to run on, as well as an already mature ecosystem (engines, code libraries, sample code, all in C++). In fact, C/C++ is pretty much the only option I have if I want my code to be broadly portable.
It's interesting how a lot of languages don't seem worry too much about backward compatibility, because they want to focus on a clean and better language. Unfortunately, in the real world, there are always massive amounts of legacy code that need to continue to work alongside whatever new whizbang features are introduced, even at the expense of a cleaner or more elegant language.
If I had to give any one reason for C++'s success, it would be the standards committee's stubborn (and in hindsight, wise) refusal to "clean up" the language by removing crufty features and syntax, a lot of which were leftover from C. C++ code from 20 years ago still compiles today mostly unchanged, and that's incredibly important when trying to build up or maintain a large ecosystem. You can see what a huge split it causes in the community when a language breaks compatibility like Python did (2.x vs 3.x), and ultimately, I wonder if it's more damaging than C++'s more conservative approach. As a developer, I'd be hesitant to heavily invest in a language that is more likely to break compatibility and leave me stranded.
I ran into an issue not too long ago with a custom stateless unique_ptr deleter, when one of the interfaces I derived from (in a third party library) was placed ahead of my own interface class in the derived class declaration. My own interface had a virtual destructor, while the library interface did not (which I didn't notice at the time). The deleter was blowing up, and only after I noticed it was off by one was I able to figure out why it was happening: the code was unable to cast properly, so ended up at the wrong address in memory because of the v-table layout.
This was fixed by switching the order of the two interfaces which corrected the in-memory layout so it would work. Alternatively, a shared_ptr would have worked as well, albeit with unnecessary extra overhead in that case. It's not exactly a new gotcha, but the unique_ptr + deleter put enough of a new wrinkle on it to throw me off for a while.
C++ gives you a lot of power and speed, but it definitely comes at a price in terms of issues like this. No one who knows C++ would seriously claim the language doesn't have sharp edges that still trip up full-time professional C++ programmers. Still, I love the power and speed the language gives me, while still affording me protection from the sort of mistakes that crop up in C code. For me, C++11 has been an amazing win so far in terms of overall productivity and code safety.
From someone in the trenches using C++, I can definitely tell you that C++ 11/14 has made a massive difference, along with the adoption of better programming practices that have occasionally been eschewed by game programmers because of speed concerns. I describe the new C++ as feeling like C#, except with far uglier syntax. It's fantastic to be able to almost completely eschew the use of raw pointers (at least ones which I have to use to manage memory). It almost feels like the language has garbage collection, except that RAII + smart pointers work wonderfully on resources as well as memory.
I've been working in what is essentially a version of C++ 98-compatible style for nearly my entire programming career. Modern hardware has really reached a point where game developers can effectively take advantage of some of the real advantages of modern C++. It's remarkable how much more productive you can be when you're not worrying about having to carefully manage memory, tracking down a ref-counted leak, or (worst of all) spending hours or even days searching for some memory stomp.
Best of all, a some of the newer features don't even require a significant amount of overhead, but really just put more work on the compiler instead of the programmer. And there are ways to mitigate some of the downsides of ubiquitous RAII-type design (the cost of creating lots of small object), though custom memory managers optimized for those sorts of scenarios.
I have to say, I agree with Bjarne's answers, especially his answer to the notion of dropping compatibility with older features. While it does make the language more complex to keep that cruft around, it's equally important to allow programmers to wrap up older libraries with newer interfaces, for example, and make sure the codebase still compiles cleanly. Since I started out on my own just a year and a half ago, I had the advantage of starting my game codebase from scratch, so I could use the most modern techniques, but I've worked at places with 10 to 15 year old codebases. There's just no way all of that is going to get rewritten in the near future, so backward compatibility is hugely important for the C++ community.
Overall, C++ gets a lot of grief for it's ugly syntax and nasty gotchas, but modern techniques have really eliminated a huge percentage of those. Personally, I tend to view C++ like an extremely sharp kitchen knife. It can be a dangerous tool for novices, and you certainly don't want to use it when a butter knife will do, but there are some jobs that simply demand it.
3. and they're great for keeping rodent populations under control.
You must get really confused when you look up the speed ratings on tire side walls, what with how you seem to think cars can't safely exceed 70 or 80 mph.
Take an aggressive driving course; "normal" cars are capable of some really impressive driving manoeuvres if you know what you're doing.
If a semi can do a given speed without going off the road, your properly maintained vehicle most certainly should be able to with its much lower center of gravity and better suspension.
We have quite a few municipalities in the area that reside in valleys, so the speed limit drops by nearly half part way up or down a hill in each direction. Its incredibly annoying to be going down a hill at 80 and have to drop to 50 while accelerating (gravity).
Actually here in Ontario you can be pulled over for impeding traffic if you're in the way, no matter how legal your speed was, as it should be.
Drive in the right lane, let people pass on the left. Its their business to go faster, not yours. Your responsibility as a driver is partly to stay out of everyone else's way, you're not an island out there.
A low speed limit is dangerous when it is obvious to everyone with a basic level of driving skill that they should be driving faster. Those people will then suddenly run into people driving the 'limit' around a corner or over a hill.
You could argue that nobody should ever exceed the speed limit, but that's just irrational stupidity. People will for the most part drive what seems like a safe speed for them, not accounting for over-aggressive or over-cautious drivers of course, but those are rare enough. On a given stretch of the 401 here in Ontario, you can be assured everyone is doing 120-130 even though it's posted at 100. At another point on the same highway, everyone will be driving no more than 115 because its too narrow and unsafe to go faster.
People adjust because we almost all realize that speed limits should have been updated aeons ago, when most cars now have seatbelts, air bags, ABS, traction control and high grade tires but the limits were set before all those things.
You mean the 95% of drivers who are speeding on highways without accidents? Yes, they must be stupid.
You do realize that settlements are basically private contracts right?
There is no such thing as a "private contract". A contract, by nature, is an agreement that the state will enforce. State actions are not private. If two people make an agreement and will never disclose that agreement to anyone else under any circumstances, then a court will never see it, and it is in no meaningful way a contract.
Of course that only goes double when one of the parties is a government agency. Nothing a government agency does is private.
But I shouldn't be forced to hire them or make them my friends.
No one is forcing you to make anyone your friend.
Commerce, on the other hand, by its nature involves the state. (At least beyond the trivial. Your lemonade stand generally flies under the radar here.)
If you want the state to issue a charter for your corporation or register your partnership, if you want to call the cops to use force against people your want removed from your place of business, if you want the government to enforce your business contracts, if you want to engage in interstate commerce and use the economic infrastructure that the state has created, you don't get to complain that the state is interfering with your "private choices" when it requires that your business not be racist, sexist, etc.
1. Censorship only applies to governments.
Please stop spreading the mis-definition that claims that private interests with control over information flow cannot engage in censorship.
A website or a store deciding that they do to carry a product is not.
If they decide "we won't carry this because our customers won't buy this", it's not censorship. If they decide "we won't carry this because we object to it", it is censorship.
There are two ways to write error-free programs; only the third one works.
