Hacker News Reader

Comment by InfinityByTen | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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).

> 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.

Developer? Which developer? Who developer?

A lot of graduate students write their own code and how did they learn to write code? Anything that works from University courses. I was taught C in university as a mechanical engineer. That's why all my python and C++ code was dreadful. I wrote them like I'd write C.

I don't want a test coverage because I want them to write some fancy industry level code. You can look my Master thesis code up on github (hint, it's the same user name) and it's in Python. Hit me up and we can both sit and roast "me from 4 years ago". Scientists who write code as the basis of what they are claiming... computational scientists, statisticians, physicists, chemists and all those people for whom getting the results are because it showed up on their computer screen and they made graphs for them to testify their claim should know how to deliver code that can be read, understood and reviewed. It should not fail on edge cases and give basic results that keep getting verified each time their work goes from "something is working" to a full fledged beast that's going to claim something.

PS: I found (and of course fixed) bugs in my code in both publications on my name before I submitted. I'll be surprised if I was the only one in history to have been through that.

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.

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?

Reply on news.ycombinator.com