The skill: "willingness to accept the system, even when it's wrong, and game it for your benefit" is central to engineering, accounting, law, and finance. Almost all of the goof jobs outside of medicine.

Children expect life to be fair. Adults accept that the world is imperfect, and work for success within it (not to say it's not also worth trying to change the bad parts, but in the mean time do something useful with your life).

Just no.

You are confusing Solar radiation with cosmic radiation... and they are largely very different things.

The "solar wind" is largely photons and other, relatively low-energy charged particles from the sun. (Note the word "relatively".) Which is GOOD for us here on Earth. Because cosmic radiation has a much larger component of HIGH energy particles. The solar wind interacts with Earth's magnetic fields in such a way as to shield it from the cosmic high-energy particles.

But it's the cosmic high-energy particles that penetrate far enough into the atmosphere to ionize particles of matter, which form nuclei around which clouds form. So... high sunspot activity generally means fewer clouds, which in turn means it gets hotter. When "solar storm" activity is low, more cosmic rays leak in, forming more clouds, cooling the weather.

Unfortunately, it is these high-energy particles which require the most shielding. And in general, cells are more prone to damage than radiation-hardened silicon chips.

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.

100% irrelevant to the topic I was discussing, which was ownership of U.S. uranium interests by Russia. Not only is Australia a completely different continent, its politics are also completely different. Similar in some ways, but definitely not the same.

Again, completely irrelevant to the topic under discussion. If I lived in Australia, I'd object to sales to China OR the U.S.... but especially China.

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.

How do you claim absence of side effects?

Solar farms are already observed to fry birds and blind pilots. Not to mention the huge amount of landscape they consume. And in high latitudes, not only to they take up even more (and more ecologically sensitive) area, they aren't even usable a good part of the year. In my area, they don't even come close to competing with other sources for cost.

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.

This causes me to think you haven't understood what the Butterfly Effect actually is. It says that slight differences in the initial conditions of some nonlinear systems can have a profound effect on later outcome. It doesn't apply to all chaotic systems by any means, nor does it necessarily mean a persistent change... just a big one. Nor, just off-hand, would it seem to apply to your windmill example at all.

You might be interested to know that the Butterfly Effect has made a profound contribution to weather and climate modeling. Without it, we would not know even the relatively small amount that we do know.

The name "Butterfly Effect" was intended as an analogy to how it works... it isn't to be taken literally. But it does work, and is observed in the real world. If you doubt that, I strongly suggest you avoid flying in a modern jet.

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.)

I disagree with others here. If they say they don't know if their organization has the talent to succeed, then indeed they don't know what they're doing.

Especially those who think their IT dept. is incompetent. What that means is (A) they are wrong, or (B) they are right... which in turn says they made bad hiring decisions and should clean house.

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.