Very true. The rational man realizes this, and doesn't hold strong political opinions on the rest of it. We're all going to be ignorant of most science in the modern world - the time has long passed when the educated man could know all of the scientific knowledge there was. It's important to therefore set arrogance aside, and not try to tell others they're idiots, or force your uneducated opinion on others by law, unless you actually care enough to do the diligence first.

Far too many people mistake fashion for education. If you're going to call others fools for trying to stop the teaching of "evolution" in schools, call them fools because you took the time to understand the science, the counter-arguments, and why a smart, ration person could somehow not believe in evolution. Until you understand the other side, and why it's wrong, stay out of the argument. For the evolution case: if you had a solid biology class, this takes just a few days of reading the talk.origins site. It's not an undue burden, and otherwise arrogance about your uninformed opinion is just idiocy.

For newer fields like the climate change debate, it will take longer to dig up the details, as there isn't a handy website that collects all the pro and con arguments. For climate change, can read through the pro and con sites and understand where they're coming from, understand the Vostok ice core data for perspective, spend time pondering the satellite temperature data, and so on.

For any such issue, treat both sides as intelligent people who are in earnest in their beliefs and not trolling, and read enough to understand how this can be true. When you understand how intelligent people can disagree on the issue, and see where both sides are coming from, then you can act out of knowledge instead of arrogance, and stop polluting the debate with idiocy. If your only basis for argument is "everyone knows the smart people believe X, and the losers believe not-X", well, that's fashion, not knowledge. This pretty much applies to anything being debated politically, BTW, not just the science stuff.

That's not C++. That's "C with classes". (No true Scotsman uses C++ that way!) There should really be a new C standard that adds classes, C++-- or something. (BTW, a sure sign that people don't understand C++ is when they argue that the STL is slow.)

It's funny to hear game devs argue that C++ is too abstract, and then in the next breath wonder how they're ever going to get their code to use more than one core. I hope you're not that guy!

I'm in a different world. To me, performance means infinite horizontal scalability. Clarity and performance of work distribution across N machines (for arbitrary N) is where the fun is. Counting cycles and optimizing bytes got boring when machines got fast (a Raspberry Pi blows away the mainframes I started on).

Only catch exceptions that you can fix is the rule. If you can't actually do something useful about an exception, why would you catch it? There's nothing worse than Pokemon code!

catch(...) make perfect sense in one place - in main(), followed by logging the exception and terminating the process.

The whole point of this entire mindset is to stop checking for errors individually after each call. This lets you eliminate about 2/3s of your lines of code, all boilerplate, and reveal the actual business logic of each function by sweeping away the clutter. But there's a whole crowd of devs who like the clutter. They're not actually very good at coding, but mindless repetition they can do. This mindset is anathema to those guys. RAII without exceptions leaves half the clutter, and so doesn't achieve the goal.

If you don't really need to make systems calls, that's absolutely the right answer IMO. I only favor C++ if I need to do platform-specific messing around with filesystem behavior, or low-level netcode. As soon as you need to do any sort of bit-twiddling, or you care at all about asymptotically-constant-time performance improvements, Java stops being useful (and I always prefer C# to Java where practical - same functionality with half as many lines of code).

I really don't see the point of using C (or C-style coding in C++) outside of kernel-mode stuff, however.

A new hire from college is not a "beginner", at least not anywhere I've worked recently. If you choose to interview in C++, you had better know the basic STL classes (string, vector, map) as well. Sure, it's rare to see an interview question that would probe RAII/resource management for entry-level, but knowing that stuff coming in would really help. (We don't care what language someone is good in for an entry level job, but they have to demonstrate some depth in one language of their choice.)

Indeed. Should. No argument there. But half the C++ code I've ever worked on was terrified of the scary exceptions, and so wouldn't do anything useful in constructors, since that might throw, and would instead do all the work in init() so that a #defined error code could be returned (which then this caller would forget to check every so often, leading to fun bugs at some spot quite distant in code from the error).

Well, true enough, I haven't looked at anything Google in about 5 years. I exaggerate about caring that much about the style guide - the truth it, Google is a despicable, evil company, and while I might work there to avoid starving, that's only because I'm weak.

But fuck using * for out params with a cactus soaked in Tobasco sauce. The return value of the function is for returning values, which you can do if you do waste it because you're scared of the terrible exception-monster in the closet (and for multiple return values, a non-const reference is non-const). And fuck only having trivial constructors, because, you can't throw exceptions, so you can't do RAII. The 80s had fun music, but the coding style of the 80s needs to go away.

Did you know that a Bluray is a disc, holding video, in a digital format? It's true!

I know the "proton-sized black hole with a positive charge" with an electron orbiting it has been studied - but I don't know what was concluded. But you won't get "orbits" out to maybe 3x the radius of a black hole, so no danger of that for the Everest hole.

The LHC uses two beams colliding from opposite directions, so the total momentum of a collision is low. If most of the energy of collision goes into making the black hole, then the mass of the black hole would be much higher than whatever collided, and thus it's velocity would be much lower than the difference in momentum of those two particles.

DTS is CD-quality. AAC isn't - you can hear the difference between AAC and DTS. Beyond DTS is a gimmick.

TrueHD needs to die in a fire. DTS is CD-quality audio, while TrueHD and DTS HD-MA are just a waste of space. The latter is always mastered such that you can trivially rip the DTS track when you're ripping the DVD, but TrueHD leaves you with just the AAC track if you don't want to double the size of your rip. TrueHD is a copy-protection measure, nothing more.

No, no, /.ers can totally be "married for several years", or have no girlfriend at all - either way you're not getting laid. It's that in-between zone that we don't see here. (There's an old joke: put a pebble in a jar every time you have sex until your first anniversary. Remove a pebble from the jar every time you have sex after that. The jar will never be empty.)

I remember when it was spelled auto_ptr (OK, OK, they're not quite the same). But unique_ptr's just part of using RAII - you need to know shared_ptr as well, was my point.

Yeah, I've done that trick before: it's not quite the same. It's been a while since I tried, but I remember it not working for some operators and implicit conversion the way it would with a simple public data member - complexities of type inference.

There was actually a provision for this originally, sort of: by overloading the -> operator you can change what foo->bar returns, but you can't change what foo.bar returns, and since I almost never pass pointers around I rarely use the -> operator

The moon is just over 7x10^22 kg.

The hard part is determining the rate at which a small black hole would consume matter. Very small black holes simply don't have the cross-section to consume matter fast enough to live. The hole would have to live long enough (and still have a cross-section large enough) for the few seconds needed to fall through the ground and get deep enough to pass the water table and into denser crust. From that point it's a matter of its cross-section, speed, and the density of the rock its passing through.

My best estimate for the Mt Everest mass is 4*10^15 kg, which gives a radius of 6 pm - seems big enough to eat silicon and iron atoms.