4 ms·

I've written code in academia in applied mathematics. If I look at it today after 4 years of professional coding, I cringe. I know how horrible my code is. I kn

I've written code in academia in applied mathematics. If I look at it today after 4 years of professional coding, I cringe. I know how horrible my code is. I know how poorly I understood oop and how none of the things were tested. Zilch. Nada. If I were to go back to academia ever again, the one course I am going to take is coding standards and practices for researchers. They should know basics about git, testing, ideally even a review and CI system. Given my experience in how code is handled in academia, I'm very skeptical about the quality of it and I expect to find critical bugs in them if it's written in a non-cs department. It's actually sad that we depend on the code so much for our publications, but how little attention we pay on how to do it properly. My trust went down in academia more and more when I saw how well defined practices were in industry and how it actually helped maintain a reasonable quality of code.

hvidgaard 6y ago
Learning git, refactoring, testing, CI, ect. is going to be way too many "credits" spent on that. It's important, but certainly not what they should be spend their time on if they could avoid it. The universities ought to have a CI system in place with guidelines, and preferably staff that can help with it. Ideally there should be some collaboration between the SE students and researchers worth credits for the CS students.
- GauntletWizard 6y ago
  Every bit of Git, Testing, CI, etc - These are experimental skill. They directly translate into good experiment design. They help you figure out where you went wrong, what you assumptions were, and condense them down into a precise, succinct and yet fully-formed thesis.
  - hvidgaard 6y ago
    It's a mindset, and absolutely not necessary for researchers. If they do not learn that as a part of their PhD, they're not going to learn that with programming.
- l0b0 6y ago
  I would love to see this sort of thing facilitated. Get someone on board who is familiar with something like GitLab CI/CD and at least a couple popular languages, and let them set up and maintain template repos with all the good stuff: in-repo configuration (not snowflake CI systems like Jenkins), tests, idiomatic project structure, commit hooks for linting/formatting, simple Markdown documentation, maybe even some popular IDE configuration. Anyone used to learning by example will just need to know about the readme to get a head start.
mtmsr 6y ago
All of this. However, the issue is that coding the paper is only _one_ (and often not the biggest) step from idea to published paper. Worse, once the paper is published typically nobody cares for your code and whether its test coverage is x% (at least here in the social sciences). I'm not saying that I support this (quite the opposite), but that's the outcome of our publish-fast-and-frequently-culture to get tenure. Nota bene, I observe an increasing number of exceptions to this rule in my field, but still a minority.
ensiferum 6y ago
Yup for example the h.264 reference codec is full of compiler warnings of ill defined behavior. What's one to interpret about that with regards to standards compliance? That Undefined output is basically ok?
GuB-42 6y ago
BTW, I think Python really did a great job here. As a developer, I am not a big fan of Python. This is a personal opinion and you can disagree. However, what is great about Python is that it is hard to write code that is completely messed up. The most obvious is that code is always indented correctly, but more generally, the philosophy is that there is one "pythonic" way of doing things. It is not always the "best" way, but when you are not an expert, it is better to have something good enough and consistent than to mess things up with tools you have trouble using properly. Python is also a high level language with good libraries for the tasks where performance typically matter most. I'm saying that because I've seen code written in C++ by scientists that's absolutely terrible. I don't blame them, C++ is incredibly complex, requiring both low level (pointers, memory management, ...) and high level (objects, generics, ...) skills. Scientists are not software engineers, they have science to do first. Python code written at the same level of skill, by comparison, looks quite decent. As for the basics of "git, testing, review and CI", yeah, why not, but I don't think that's the right approach. It is not up to scientists to adopt a developer mindset, it is up to developers to provide the right tools to scientists (like Python did, IMHO). Git, IMHO, is a bit too developer centric. I love it, but I am a developer. There are other VCS, and they are often preferred by non-developer when given the chance. I am not deep into the scientific world but testing and review processes is something scientists should be particularly good at, so if anything, maybe we have to learn from them more than they have to learn from us. CI sounds like overkill.
- sofixa 6y ago
  I heavily disagree here. Python is a very flexible language that allows you to do all sorts of things, even if there's a preferred, pythonic way. Reading it can be very hard depending on who wrote it ( it's even worse if the person is very good with Python, because then they'd take non-obvious shortcuts ) Case in point, Golang. One of its raison d'être is because Python was too complex to control and make readable, hence a language that doesn't give you much choice and enforces good practices ( refusing to compile when you have unused variables or imports for instance).
  - GuB-42 6y ago
    > it's even worse if the person is very good with Python, because then they'd take non-obvious shortcuts Yes, I noticed that, and that's one of the reasons I am not a big fan of Python as a developer, but I still think it is good for less experienced developers. I didn't do Go, but it doesn't seem to serve the same purpose. My understanding is that Go is for developers, and big, maintained projects, especially in corporate environments (particularly Google) where consistency is important. Scientific code tends to be much smaller in scale.

hvidgaard 6y ago

Learning git, refactoring, testing, CI, ect. is going to be way too many "credits" spent on that. It's important, but certainly not what they should be spend their time on if they could avoid it. The universities ought to have a CI system in place with guidelines, and preferably staff that can help with it. Ideally there should be some collaboration between the SE students and researchers worth credits for the CS students.

GauntletWizard 6y ago
Every bit of Git, Testing, CI, etc - These are experimental skill. They directly translate into good experiment design. They help you figure out where you went wrong, what you assumptions were, and condense them down into a precise, succinct and yet fully-formed thesis.
- hvidgaard 6y ago
  It's a mindset, and absolutely not necessary for researchers. If they do not learn that as a part of their PhD, they're not going to learn that with programming.
l0b0 6y ago
I would love to see this sort of thing facilitated. Get someone on board who is familiar with something like GitLab CI/CD and at least a couple popular languages, and let them set up and maintain template repos with all the good stuff: in-repo configuration (not snowflake CI systems like Jenkins), tests, idiomatic project structure, commit hooks for linting/formatting, simple Markdown documentation, maybe even some popular IDE configuration. Anyone used to learning by example will just need to know about the readme to get a head start.

mtmsr 6y ago

All of this. However, the issue is that coding the paper is only _one_ (and often not the biggest) step from idea to published paper. Worse, once the paper is published typically nobody cares for your code and whether its test coverage is x% (at least here in the social sciences). I'm not saying that I support this (quite the opposite), but that's the outcome of our publish-fast-and-frequently-culture to get tenure. Nota bene, I observe an increasing number of exceptions to this rule in my field, but still a minority.

ensiferum 6y ago

Yup for example the h.264 reference codec is full of compiler warnings of ill defined behavior. What's one to interpret about that with regards to standards compliance? That Undefined output is basically ok?

GuB-42 6y ago

BTW, I think Python really did a great job here. As a developer, I am not a big fan of Python. This is a personal opinion and you can disagree. However, what is great about Python is that it is hard to write code that is completely messed up. The most obvious is that code is always indented correctly, but more generally, the philosophy is that there is one "pythonic" way of doing things. It is not always the "best" way, but when you are not an expert, it is better to have something good enough and consistent than to mess things up with tools you have trouble using properly. Python is also a high level language with good libraries for the tasks where performance typically matter most. I'm saying that because I've seen code written in C++ by scientists that's absolutely terrible. I don't blame them, C++ is incredibly complex, requiring both low level (pointers, memory management, ...) and high level (objects, generics, ...) skills. Scientists are not software engineers, they have science to do first. Python code written at the same level of skill, by comparison, looks quite decent. As for the basics of "git, testing, review and CI", yeah, why not, but I don't think that's the right approach. It is not up to scientists to adopt a developer mindset, it is up to developers to provide the right tools to scientists (like Python did, IMHO). Git, IMHO, is a bit too developer centric. I love it, but I am a developer. There are other VCS, and they are often preferred by non-developer when given the chance. I am not deep into the scientific world but testing and review processes is something scientists should be particularly good at, so if anything, maybe we have to learn from them more than they have to learn from us. CI sounds like overkill.

sofixa 6y ago
I heavily disagree here. Python is a very flexible language that allows you to do all sorts of things, even if there's a preferred, pythonic way. Reading it can be very hard depending on who wrote it ( it's even worse if the person is very good with Python, because then they'd take non-obvious shortcuts ) Case in point, Golang. One of its raison d'être is because Python was too complex to control and make readable, hence a language that doesn't give you much choice and enforces good practices ( refusing to compile when you have unused variables or imports for instance).
- GuB-42 6y ago
  > it's even worse if the person is very good with Python, because then they'd take non-obvious shortcuts Yes, I noticed that, and that's one of the reasons I am not a big fan of Python as a developer, but I still think it is good for less experienced developers. I didn't do Go, but it doesn't seem to serve the same purpose. My understanding is that Go is for developers, and big, maintained projects, especially in corporate environments (particularly Google) where consistency is important. Scientific code tends to be much smaller in scale.