On 06/02/2013 05:53 PM, Roy Obena wrote: > You're making this up. I'm sure they do a lot of data-driven > tests or simulations that make most errors detectable. They may > not be savvy programmers, and their programs may not be > error-free, but boat-loads of errors? C'mon.
I don't think he's making this up. I would not want to make any assumptions about any particular institutions, and I would like to believe that institutions with large-scale, long-term computational projects have better practices, but I think that most people in maths and physics research have very limited experience of good code design and testing practices (working with D, and its unit-testing framework and contract guarantees, has certainly been an eye-opener for me). Generally speaking it's true that in maths and physics there are often either theoretical calculations or empirical data points for you to compare your computational results to, so you can usually confirm that your program is doing what it's supposed to, but not always. There may not be boat-loads of errors in terms of output, but I bet there are boat-loads of loopholes that will result in insane mistakes if the input were to step outside the use-cases or parameter constraints the researcher has considered. I don't exclude my own code from that criticism, and the reason it's tolerated is because it's often the quickest way to get to working code; you know that you have to constrain parameters in such-and-such a way for it to work, and you know that you _will_ constrain yourself accordingly. But of course it's easy to shoot yourself in the foot when you start tweaking things. D's assert() and enforce() functions, and contract checks, are very useful here.