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.
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
- HN score
- 0
- Mentions
- 3
- Readers
- 3
- Months
- 3
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
The article is more concerned with "open development" than with "scientific software". Those interested in more specifically science-oriented advice might like the following, which is referenced in the OP: http://arxiv.org/abs/1210.0530. For example, this one mentions version control and testing against data.
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 & researchMore from the same topics.
Dissolving the Fermi Paradox
Anders Sandberg, Eric Drexler, Toby Ord
The Fermi paradox is the conflict between an expectation of a high {\em ex ante} probability of intelligent life elsewhere in the universe and the apparently lifeless universe we in fact observe.
The Surprising Creativity of Digital Evolution: A Collection of Anecdotes from the Evolutionary Computation and Artificial Life Research Communities
Joel Lehman, Jeff Clune, Dusan Misevic +50
Biological evolution provides a creative fount of complex and subtle adaptations, often surprising the scientists who discover them.
xVal: A Continuous Numerical Tokenization for Scientific Language Models
Siavash Golkar, Mariel Pettee, Michael Eickenberg +11
Due in part to their discontinuous and discrete default encodings for numbers, Large Language Models (LLMs) have not yet been commonly used to process numerically-dense scientific datasets.
Dissecting the NVIDIA Volta GPU Architecture via Microbenchmarking
Zhe Jia, Marco Maggioni, Benjamin Staiger +1
Every year, novel NVIDIA GPU designs are introduced.