Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:because - (Score 1) 793

by tigre (#40519657) Attached to: What's To Love About C?

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

by tigre (#39591271) Attached to: World Is Ignoring Most Important Lesson From Fukushima

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

by tigre (#39197125) Attached to: Schmidt: Google Once Considered Issuing Currency

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

by tigre (#38074602) Attached to: MIT Creates Chip to Model Synapses

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: Re:TDD (Score 1) 460

by tigre (#36094514) Attached to: Is Process Killing the Software Industry?

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.

Comment: Re:TDD (Score 4, Insightful) 460

by tigre (#36092694) Attached to: Is Process Killing the Software Industry?

TDD is a painful waste of time that at best serves as a crutch for unskilled or insecure coders and at worst a smokescreen behind which serious bugs remain unfixed because they aren't picked up by any test cases.

No, TDD is painful, but it's a long-term investment. If you code once and never have to touch it again, you can get away with making it work right without tests. But if you want to be able to grow your system, you want something to make sure that you don't kill the old functionality in the process of building the new. And sometimes it's just helpful to spell out the expectations of new functionality ahead of time so that you know when you've achieved it.

Process for the sake of process is pointless. And if you have good reason to work around or jettison a given process, go for it. As I told the other programmers at my job, the only piece of our process we would probably consider an absolute necessity is source control. Code review is highly recommended, tests are very strongly pushed, formatting standards are there for good reasons, but there are times when they are not helpful.

The problem always comes down to whether or not your developers are adults with good decision-making capabilities. Process is too often employed as a way to allow you to get stuff done with people of average or less ability, but process also hurts them because they can't figure out when the process is unhelpful. And if process is imposed by fiat, those who could figure that out are frustrated by having to go through the motions. But if you have trustworthy people and you actually trust them, you institute the process for their benefit, and when it's not useful they know not to use it.

When you don't know what to do, walk fast and look worried.