To be fair, Agile can be freaking awesome. I worked at a devotedly Agile shop and it was a developerocratic utopia. After the few meetings we had, all participants walked away with legitimate action items. You didn't just get called in to listen to something that didn't concern you - if you were invited, it's because you were specifically needed.

I've also worked in places where Agile was a stultifying cover story for "actually waterfall but that doesn't sound as cool so we'll never admit it". That might be the kind of /dev/hell you found yourself stuck in. But that's not Agile Done Right, and shops that Do Agile Right really do exist.

I know all of those words but still have no idea WTF the summary is talking about. Does this boil down to "Wikipedia teens with infinite free time are trying to build fiefdoms", which is the usual explanation for Wikidrama?

No C-style casts or any explicit casts were involved at all in this particular case. I've long since stopped that sort of dangerous style of programming and adopted a much saner and safer subset of C++ unless there's no alternative.

Disabling "unsafe" features might be useful for some, but not in my case. In my particular field (videogame programming), we often have to interop with older C-style libraries, or write some very specific low-level optimizations down in the engine for maximum performance. For instance, nearly all AAA games that I've worked on completely replace the default memory manager, which is why I was using custom deleters. When you write your own memory allocator, you obviously have to do a lot of raw pointer manipulation and unsafe casting.

Honestly, it's probably better to simply develop a personal or corporate coding standard and make sure it's followed. That way, if there's a legitimate need to "break the rules", you can do so, but only if there's no realistic alternative. That's part of what makes C++ so useful. It's a very pragmatic language.

I'm perfectly happy with the compensation of "we'll let you use the Internet connection you already had if you want to not come into the office and be distracted by a hundred meetings and other interruptions".

No, they certainly would mind, because this is something that would cause an uproar among the general population, and that would directly affect their sales, besides bringing lawsuits and very bad press.

This is why corporations care about user security at all. They care only because they want us to buy their products. It's really important to keep the profit motive in mind when talking about corporations. Most aren't inherently evil, but neither are they altruistic. They essentially neutral, wanting only to do business with us, so you can expect them to typically act in their own best interest. This occasionally coincides with their customers' interest, simply because it's good business to treat your customers well, especially in a competitive market.

DVD security was fundamentally flawed and could never work, because there was no way to keep the decryption key secret. Modern cryptography with well-vetted standards is currently (and for the foreseeable future) unbreakable if:

a) you choose a strong key
b) you keep the key secret, and
b) you implement the encryption algorithms correctly and securely

Tech companies, especially phone providers, have a lot more experience doing this than a decade ago. Is it easy to do? No, but it's not nearly as hard as it used to be either.

And of course, the ever obligitory xkcd

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.