3 ms·

Some would argue that no OO use is a good thing (assuming you are referring to object oriented programming). Expanding on this, writing research code is quite

by tensor 11y ago

Some would argue that no OO use is a good thing (assuming you are referring to object oriented programming). Expanding on this, writing research code is quite a bit different than writing production code. In particular, requirements can change quickly and drastically. This means that very open designs where you don't hide data (e.g. as is common in OO programming) are often the best designs.

wtf23737 11y ago
just no.
- camkego 11y ago
  This.
pathelectronica 11y ago
> requirements can change quickly and drastically the implication that this threat is not present for production code is completely ridiculous.
mbreese 11y ago
Research code is production code and should be treated as such. It doesn't matter if requirements change quickly, you still need to treat it like it's production code... you document, test, and deploy it. And you should include the ability to adapt the code to flexible requirements in your initial design. Just because you may only use the program once doesn't mean that you can neglect good software engineering practices. I run into bad code all of the time (some of it mine!) in our research, and it's very frustrating.
Retric 11y ago
If your research code is a big ball of mud then all it's results are meaningless. And all your research should be rejected by any competent journal. Sadly, journals tend to ignore such huge issues. But, hey it's not like reproduceable results are important in science or anything.
- mbreese 11y ago
  The more computational journals are keeping track of this. I've had a manuscript returned for revision because I didn't have enough unit testing in the code. Wet-lab journals, on the other hand, probably let a lot of stuff go on the computation and statistics than they should.
magicbuzz 11y ago
Any significant dataset should be wrapped with an object. Especially so if multiple scientists/programmers are pulling data from the dataset. Ever tried multiple algorithm variants? Wrapping an algorithm in an object and then passing it to the data provisioning code means you can be 100% sure that the only thing that has changed in your code is the algorithm.

by tensor 11y ago

wtf23737 11y ago

just no.

camkego 11y ago
This.

pathelectronica 11y ago

> requirements can change quickly and drastically the implication that this threat is not present for production code is completely ridiculous.

mbreese 11y ago

Research code is production code and should be treated as such. It doesn't matter if requirements change quickly, you still need to treat it like it's production code... you document, test, and deploy it. And you should include the ability to adapt the code to flexible requirements in your initial design. Just because you may only use the program once doesn't mean that you can neglect good software engineering practices. I run into bad code all of the time (some of it mine!) in our research, and it's very frustrating.

Retric 11y ago

If your research code is a big ball of mud then all it's results are meaningless. And all your research should be rejected by any competent journal. Sadly, journals tend to ignore such huge issues. But, hey it's not like reproduceable results are important in science or anything.

mbreese 11y ago
The more computational journals are keeping track of this. I've had a manuscript returned for revision because I didn't have enough unit testing in the code. Wet-lab journals, on the other hand, probably let a lot of stuff go on the computation and statistics than they should.

magicbuzz 11y ago

Any significant dataset should be wrapped with an object. Especially so if multiple scientists/programmers are pulling data from the dataset. Ever tried multiple algorithm variants? Wrapping an algorithm in an object and then passing it to the data provisioning code means you can be 100% sure that the only thing that has changed in your code is the algorithm.