Skip to content
Back to the collection

Best Practices for Scientific Computing

Greg Wilson, D. A. Aruliah, C. Titus Brown

Show all 13 authors

Neil P. Chue Hong, Matt Davis, Richard T. Guy, Steven H. D. Haddock, Katy Huff, Ian M. Mitchell, Mark Plumbley, Ben Waugh, Ethan P. White, Paul Wilson

2012 · arXiv

Read the paper
HN score
0
Mentions
3
Readers
3
Months
3
What’s in a score?

From the abstract

Scientists spend an increasing amount of time building and using software. However, most scientists are never taught how to do this efficiently. As a result, many are unaware of tools and practices that would allow them to write more reliable and maintainable code with less effort. We describe a set of best practices for scientific software development that have solid foundations in research and experience, and that improve scientists' productivity and the reliability of their software.

Metadata: arXiv. Abstracts retain their original authors’ rights.

In the conversation

Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels

3 selected excerpts · 3 total mentions

dubya
Neutral mention · rule
This sounds like a gap in the curriculum that could be filled by grad students. I'm not in CS, but I know that the bioinformatics students have organized a course that covers some basics of the unix command line tools, probably because data conversion is a big part of most projects. There's also "Best practices for scientific computing" (http://arxiv.org/abs/1210.0530) that covers some of the same ground, and physics departments usually have a scientific computing course as well. Also, if it's really a one-off use of something, the department IT person could probably do it for you.
johnx123-up
Neutral mention · rule
Recent version is v2 http://arxiv.org/abs/1210.0530v2 Summary: 1. Write programs for people, not computers. 2. Automate repetitive tasks. 3. Use the computer to record history. 4. Make incremental changes. 5. Use version control. 6. Don’t repeat yourself (or others). 7. Plan for mistakes. 8. Optimize software only after it works correctly. 9. Document design and purpose, not mechanics. 10. Conduct code reviews.

Keep following the thread.

More in Science & research

More from the same topics.