141–150 of 170 posts
Earlier quoted context omitted.
I shudder to think that such a "company" could be developing health-related software.
You should see the shit they design pharmaceuticals with.
(Disclaimer: my background is in materials physics, and it may be different in other fields. But I doubt it.) Unfortunately there is very little direct incentive for research scientists to write or publish clean, readable code: - There are no direct rewards, in the tenure process or otherwise, for publishing code and having it used by other scientists. Occasionally code which is widely used will add a little to the p…
Don't forget that a particular code might have 2 or 3 paper's worth in it, so releasing the code after 1 paper could mean getting "scooped" on another paper. I'm left a little cynical after a Master's in computational science, and I still can't believe that open code is not part of the repeatability doctrine. I suppose my goals are not aligned with most grad students since I have no interest in an academic career (at…
I don't believe in the private model, so I release code when it's ready, regardless of where it fits in the publication cycle. It's pretty neat from a reproducibility perspective to submit a paper based on code that is runnable as a tutorial example shipped with a library that the reviewers stand a good chance of already having installed.
For all the talk of "best practices" and "training" the depressing truth is that guaranteeing correct software is incredibly difficult and expensive. Professional software engineering practices aren't nearly sufficient to guarantee correctness with heavy math. The closest thing we have is NASA where the entire development process is designed and constantly refined in response to individual issues to create the checks…
the depressing truth is that guaranteeing correct software
is incredibly difficult and expensive
One of the main problems is convincing, especially young, scientists that their code sucks. Young programmers, you can coach. You review their code, teach them what works and what doesn't and they get better. Scientists that happen to write progams, they don't learn to become better programmers: they've got other things to worry about. There's nobody to help them and since they're usually highly intelligent and overestimate their capabilities in things they don't want to spend time on (which is a way of justifying for yourself not to spend time on it), they need all the more guidance to become good.
My girlfriend is a PhD student in a pharmacology lab. I'm a software engineer working for an industry leader. Once, she and the lab tech were having issues with their analysis program for a set of data. It was producing errors randomly for certain inputs, and the data "looked wrong" when it didn't throw an error. I came with her to the lab on a Saturday and looked through the spaghetti code for about 20 minutes. Once…
Not sure how your anecdote relates to the conclusion. Forgetting, or even knowing why, to transpose a matrix is not an example of a problem that can be solved by "a basic understanding of software development". Hell, I'm sure there are many decent hackers that don't know what a matrix is, let alone spot such errors within a long sequence of computations.
Your code should look like this:
angle = acos( ( a . b ) /
(|a|*|b|) )
angle2 = Math.acos((a.x*b.x + a.y*b.y +
a.z*b.z)/Math.sqrt(a.x*a.x + a.y*a.y +
a.z*a.z)*Math.sqrt(b.x*b.x + b.y*b.y +
b.z*b.z))
Bad code compiles. Good code works right. Great code is so obviously right you don't have to wonder.
*Those are the same formula, though the second one is missing some critical parentheses. I use the example because I have done exactly this and been bitten by exactly this, and now am fanatical about keeping my mathematical formulas clean and obvious.
I know of a company, made up of scientists from academia, that develops software by writing the code (or "codes" as they call it) in Microsoft Word documents and e-mailing them to eachother. Some how, they are still in business. True story.
It's funny how this exact same mistake is made in the linked paper. For some reason, people outside of IT can't get it into their minds that "code" is an uncountable noun in this context.
Earlier quoted context omitted.
"he attempted to correct a code analysing weather-station data from Mexico." This annoys me, and it is everywhere. It indicates the writer has no idea what they're writing about and presumes that it's not a process but a matter of getting the right answer. "Hold on a sec, let me get out my Little Orphan Annie's Secret Decoder Ring." (sibling deleted and moved here)
The biggest howler I saw was "The SSI unites trained software developers with scientists to help them add new lines to existing codes , allowing them to tackle extra tasks without the programs turning into monsters."
That said, at least (some kinds of) EEs seem to have it better - the basic Spice simulator was released under a permissive license a really long time ago, and there are people like Fabio Somenzi who make available things like CUDD (it's also used commercially.) Mind you, these have a significant overlap with CS, where the culture is different. I would be very happy to see a good open-source EM field solver, for example.
(Disclaimer: my background is in materials physics, and it may be different in other fields. But I doubt it.) Unfortunately there is very little direct incentive for research scientists to write or publish clean, readable code: - There are no direct rewards, in the tenure process or otherwise, for publishing code and having it used by other scientists. Occasionally code which is widely used will add a little to the p…
I wrote probably around 3000 lines of code on 4 separate projects (mostly MATLAB, C and Java). This code was never shared with anyone, my advisors were not interested in the code, all they cared about were the results. To be honest it wasn't very good code, I would have a hard time understanding it now (although I could probably figure it out eventually).
And after I graduated I took the code with me and I am the only person who ever verified the working of the code.
This bothers me on some level, since no one can really verify and inspect the results of my publications (unless they tracked me down to ask me for the code some of which has been lost) - but it is pretty much the norm in my field.
There was an interesting discussion about this on the Theoretical Computer Science Stackoverflow a while back:
http://cstheory.stackexchange.com/questions/5361/code-in-aca...
Bottomline: Yes, we should probably do it (especially in areas where the research is simulation and the code encapsulates all the results) but we probably won't unless we're pushed.
For all the talk of "best practices" and "training" the depressing truth is that guaranteeing correct software is incredibly difficult and expensive. Professional software engineering practices aren't nearly sufficient to guarantee correctness with heavy math. The closest thing we have is NASA where the entire development process is designed and constantly refined in response to individual issues to create the checks…
the depressing truth is that guaranteeing correct software is incredibly difficult and expensive There is a world of difference between the correctness of industrial programs that follow 'cargo cult best practices' and the correctness of scientific programs. This is achieved without incurring incredible expenses. That we can't go all the way by (practical) definition doesn't mean we shouldn't try to get further. One…
Maybe we can do an outreach program? Hackers adopting scientists?
(Disclaimer: my background is in materials physics, and it may be different in other fields. But I doubt it.) Unfortunately there is very little direct incentive for research scientists to write or publish clean, readable code: - There are no direct rewards, in the tenure process or otherwise, for publishing code and having it used by other scientists. Occasionally code which is widely used will add a little to the p…
Of course, the problem with this is that it's a large amount of work and in most cases probably doesn't have a good ROI.
I have recently started to try this approach of better documenting everything, mostly because I have found it hard to go back to work I did 6 or 7 years ago and understand it (e.g. a bunch of one-off, poorly documented data processing scripts that could, if properly done, save me some time today). I haven't yet published anything like this yet, but it looks promising.