Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:because - (Score 1) 793

And the funny thing is that most people who write const char* foo really want char const * const foo. You don't want either the pointer or the data pointed at to change. However, almost nobody knows that, so even those who do just use the weaker const char* so people understand the code.

You might actually want the pointer to be able to change. You may have a pointer to _some_ literal string, but want to be able to change _which_ literal you are pointing to.

Comment Re:Error in translation? (Score 2) 328

Either there's an error in translation or the MIT trained nuclear engineer has forgotten what probability theory is.

Having multiple means of cooling a reactor sounds like a good idea, but that will only reduce the probability of disaster.

But his point is that making assumptions based on probabilities calculations based on other assumptions is the problem. Anything with a physically plausible likelihood of happening is worth considering how to guard against, and nobody should settle on "good enough" without at least laying out the associated probabilities and any assumptions that went into those calculations. At least not where catastrophic repercussions are the _likely_ outcome of miscalculation.

Of course the regulators have to be willing to challenge assumptions, and ferret them out when probabilities are presented without accompanying substantiation.

Comment Re:Currency? (Score 1) 189

A few seggestions:

Try to take over the world

Try to index the world's information

They're Page-y and the Brin.

Larry and the Brin?

They're dinky, they're Page-y and the Brin, Brin, Brin, Brin,

They're cagey, they're Page-y...
They're scary, they're Larry...

They'll take over the world

They'll catalog the world

They'll overthrow the earth

They'll monetize the earth

Comment Fundamentally Analog (Score 2) 220

The summary is way off. Transistors are analog devices, so TTL may behave digitally but that's only because a lot of work was done to make that happen. All that's happening here is taking analog devices with certain characteristics and using them to model an analog process with certain other characteristics. No small feat mind you.

Comment Methodological Concern (Score 2) 352

Stack Overflow reputation is cumulative. This means that if two people are providing answers of the same quality and at the same rate over time, the folks who have been there longest will have higher reputations, and that the higher reputation will reflect only tenure. Not any kind of quality.

If you want to look at quality, you should be looking at a metric that is something like (total reputation / number of months active). Even this is imperfect of course, since if people take a hiatus or something that will present the appearance of worse quality using this metric.

I was going to say that this fatal flaw invalidated the conclusions because the correlation between reputation and age just reflected the older people being around longer. The problem with that is that Stack Overflow opened in 2008. That's not enough time to explain a linear trend that tracks from age 16 to nearly age 50, but the final conclusion "So, senior coders earn their higher reputation by providing more answers, not by having answers of (significantly) higher quality." should still be re-examined with tenure-controlled analysis to try and see whether older aged members have been members longer.

Comment Re:TDD (Score 1) 460

The problem that I've found with TDD is that it encourages people to write code that tests the wrong thing. I like using it, because I gradually grow a set of regression tests and can be reasonably confident that I haven't broken anything, but I've seen a lot of people write tests that check for specific details, so you make a 5 line change to their code and then have to modify 100 lines of tests - not because you've broken anything, but because their tests were checking for implementation details rather than valid semantics.

I don't think it's TDD per se that encourages such bad practices. It's a complete misunderstanding of the purpose of tests. I guess I'm not big on low-level unit testing because it generally ends up breaking things down so much to the level that you do end up testing implementations rather than interactions. And thus you end up with Development-Driven Testing, an anti-pattern if I ever saw one.

So the problem is again with the application of processes and best practices without any understanding of what they're for and why they work. Because the people doing the work aren't good enough to understand and the people managing them aren't good enough to explain.

Slashdot Top Deals

C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341]