Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment: Re:Scientists are generally trusted (Score 1) 193

by lgw (#49794189) Attached to: How a Scientist Fooled Millions With Bizarre Chocolate Diet Claims

More to the point, it's impossible to independently (& personally) verify the data and claims of everything that you would like verified. There's not enough time in the world.

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

Comment: Explaining API copyright to lawyers/judges (Score 1) 189

You're honor, you probably don't want to read the case. "Why not. It's a matter of public record". Yes, but the index is copyrighted. It's $5000/copy. Good luck finding the case without the index. "$5000 per copy? That's preposterous. Indexing is trivial compared to the arguments in the case". Why yes, yes it is...

Comment: Re:Answer (Score 1) 309

by lgw (#49792799) Attached to: How Much C++ Should You Know For an Entry-Level C++ Job?

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

Comment: Re:Answer (Score 1) 309

by lgw (#49792719) Attached to: How Much C++ Should You Know For an Entry-Level C++ Job?

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.

Comment: Re:Answer (Score 1) 309

by lgw (#49792635) Attached to: How Much C++ Should You Know For an Entry-Level C++ Job?

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.

Comment: Re:Answer (Score 1) 309

by lgw (#49792569) Attached to: How Much C++ Should You Know For an Entry-Level C++ Job?

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

Comment: Re:Not the testing, the interpretation. (Score 2) 36

by Rich0 (#49790005) Attached to: Gene Testing Often Gets It Wrong

Agree. It seems like a simple solution is to unbundle the testing and interpretation.

This is really no different from any other area of testing. A lab can assay the creatinine in my blood, or the microalbumin in my urine, or the concentration of glucose in my blood. Those results are likely to be very accurate and reproducible unless the lab is just criminally negligent.

What those results mean is an entirely different matter. A doctor will certainly utilize those results as well as the results of many other tests, history, interviewing the patient, and so on to make a diagnosis, and refine it as more data comes in.

Just make the labs, well, labs. Now you can certify them far more objectively.

Comment: Re:Answer (Score 1) 309

by lgw (#49788439) Attached to: How Much C++ Should You Know For an Entry-Level C++ Job?

init() should only ever be a thing where you need to perform some kind of init after construction.

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

Comment: Re:Answer (Score 1) 309

by lgw (#49788405) Attached to: How Much C++ Should You Know For an Entry-Level C++ Job?

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.

Comment: Re:a microscopic black hole won't hurt you (Score 1) 146

by lgw (#49787739) Attached to: Prospects and Limits For the LHC's Capabilities To Test String Theory

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.

Comment: Re: Not pointless... (Score 1) 454

by Zero__Kelvin (#49787331) Attached to: D.C. Police Detonate Man's 'Suspicious' Pressure Cooker

"It's not irrational to consider a pressure cooker and propane tank parked near the US Capitol to be sufficiently unusual as to merit further investigation"

Well though that may be you are missing a pretty important point. They didn't investigate; they blew the fucker up. If they had investigated the (non) story would have been: Cops see a crock pot, investigated, and determined that they were just paranoid morons and no actual explosive device was present!.

At least you have finally made clear the source of the problem here. You've read the entire story, and still have no idea what actually happened! That certainly explains all the idiotic ramblings you've spouted of late.

A consultant is a person who borrows your watch, tells you what time it is, pockets the watch, and sends you a bill for it.