Bad scientific code beats code following "best practices" (2014) • Hacker News Board

Re: Bad scientific code beats code following "best practices" (2014)

#261

Post by jayd16 » Sat, Jan 06, 2024, 6:08 PM UTC

aragilar wrote: post #31

jayd16 wrote: post #8

If the non programmers commit correctness bugs and the programmers are just using patterns you don't like, maybe try to understand the patterns instead of balk at them.

Define "correctness bugs". Does the code leak memory (which is not ideal)? That's only an issue for the scientist if it prevents/invalidates the science. But if the pattern hides how something is expressed, or someone unfamiliar with the science tries refactoring the code, that's more likely to cause issues with the science than the memory leak.

> Access all over the place – globals/singletons, "god objects" etc. Crashes (null pointers, bounds errors), largely mitigated by valgrind/massive testing Complete lack of interest in parallelism bugs (almost fully mitigated by tools)

Re: Bad scientific code beats code following "best practices" (2014)

#262

Post by [deleted] » Sat, Jan 06, 2024, 6:09 PM UTC

_Wintermute wrote: post #177

galaxyLogic wrote: post #53

Earlier quoted context omitted.

Right and I think "scientists" simply are more intelligent than average Joe Coder. Intelligent people produce better software. It is easy to learn some coding, not so easy to become a scientist. To becomes a scientist you must write and get your PhD-thesis approved, which must already be about scientific discoveries you have made while doing that thesis. Only people with above average IQ can accomplish something like…

In my experience getting a PhD doesn't require above average intelligence, it does require a lot of perseverance and a good amount of organisation though. I honestly think most skilled tradespeople are more intelligent than me and my PhD holding colleagues.

[deleted]

Re: Bad scientific code beats code following "best practices" (2014)

#263

Post by jayd16 » Sat, Jan 06, 2024, 6:11 PM UTC

InSteady wrote: post #14

jayd16 wrote: post #8

If the non programmers commit correctness bugs and the programmers are just using patterns you don't like, maybe try to understand the patterns instead of balk at them.

The author states they are primarily a software engineer and have also been guilty of following these patterns, so the clear implication is that they understand the patterns. The author isn't making the case "I don't like it," they are making the case that these patterns actually lead to more and bigger problems in the field of scientific computing than the usually simple errors of ignorance committed by non-programm…

They state clearly that they can't follow the call structures and often give up on understanding them.

Re: Bad scientific code beats code following "best practices" (2014)

#264

Post by chaxor » Sat, Jan 06, 2024, 6:14 PM UTC

dijksterhuis wrote: post #236

chaxor wrote: post #207

Earlier quoted context omitted.

> * Not understanding dependencies, public/private, SCM or versioning, making their own code uninstallable after a few months This is definitely true, but I've searched * far and wide* , and unfortunately it's not a simple task to get this right. Ultimately, if there were a simple way to get data in the correct state in an os-independent, machine independent (from raspberry pi to HPC the code should always work), con…

What you’re describing sounds like DVC (at a higher-ish—80%-solution level although my brain switched off at the mention of IPFS). https://dvc.org/ See pachyderm too.

Of course, it's absolutely DVC. The problem is that I've never seen a DVC solution that solves the problem by making the hosting decentralized. So all of the huge problems I listed still exist even with these DVC packages. What's more is, even in addition to the cost of the hosting, some of the DVC packages cost money on top of that. So, when a researcher deletes a file to make room for others on their storage provider and/or moves institutions and their account gets deleted, the data is gone. The only way around this is to use torrent or ipfs.

Also, I'm not sure what your issue with ipfs is; If it's 'I saw something something crypto one time' - it's a really poor argument. IPFS works completely independently of any crypto - it has nothing really to do with it. The solution can also be torrent - I don't care too much - it's just possible that IPFS can run with far less resource usage on lower power, etc because it's more modern (likely uses better algorithms in the protocol, deals with modern filesystems better, with better performance, hopefully have better security, etc) and it's likely easier to implement. But it doesn't matter if it's torrent because it would work essentially the same way.

Re: Bad scientific code beats code following "best practices" (2014)

#265

Post by jayd16 » Sat, Jan 06, 2024, 6:16 PM UTC

astrobe_ wrote: post #73

This is partly because, in my opinion, some "best practices" are superstitions. Some practice was best because of some issue with 80s era computing, but is now completely obsolete; problem has been solved in better ways or has completely disappeared thanks e.g. to better tooling or better, well, practices. e.g. Hungarian notation. Yet it is still passed down as a best practice and followed blindly because that's what…

Such as what? I don't really know of any such superstitions that are based on nothing.

I see a lot of opinion/taste presented as something more, but I really can't think of superstitions.

Re: Bad scientific code beats code following "best practices" (2014)

#266

Post by pennomi » Sat, Jan 06, 2024, 6:22 PM UTC

lynndotpy wrote: post #230

Scientist and programmer here, and my experiences are the opposite. I value keeping things "boringly simple", but I desperately wish there was any kind of engineering discipline. First is the reproducibility issue. I think I've spent about as much time simply _trying_ to get the dependencies of research code to run as I have done writing or doing research in my PhD. The simple thing is to write a requirements.txt fil…

Absolutely my experience as well. Scientists write code that works, but is a pain to reproduce in any sort of scalable way. However it’s been getting better over time as programming is becoming a less niche skill.

Re: Bad scientific code beats code following "best practices" (2014)

#267

Post by ruszki » Sat, Jan 06, 2024, 6:30 PM UTC

nox101 wrote: post #256

ruszki wrote: post #252

Earlier quoted context omitted.

Is there any metrics which proves that making maintainable code is slower? Because in my experience there is no difference.

I have tons of examples of code where I did the simplest thing to solve the problem. Then later needed a change. I could refactor the entire thing to add this change or just hack in the change. Refactoring the entire thing takes more work than the hack so hack it is unless I forsee this is going to matter later. Usually it doesn't

That’s just anecdote, just like mine. Even simple lack of experience or lack of skills can cause that (which were definitely in my case). Also, I’m quite sure that a terrific coder can create maintainable code faster than an average one bad code. That’s why I asked some statistical data about that.

Re: Bad scientific code beats code following "best practices" (2014)

#268

Post by leptons » Sat, Jan 06, 2024, 6:37 PM UTC

astrobe_ wrote: post #73

This is partly because, in my opinion, some "best practices" are superstitions. Some practice was best because of some issue with 80s era computing, but is now completely obsolete; problem has been solved in better ways or has completely disappeared thanks e.g. to better tooling or better, well, practices. e.g. Hungarian notation. Yet it is still passed down as a best practice and followed blindly because that's what…

Today's "best practice" is tomorrow's worst practice.

Re: Bad scientific code beats code following "best practices" (2014)

#269

Post by civilized » Sat, Jan 06, 2024, 6:44 PM UTC

mannykannot wrote: post #191

civilized wrote: post #164

Earlier quoted context omitted.

These patterns appear in many fields. I take it as a sign that the tooling in the field is underdeveloped. This leads to a split between domain problem solvers, who are driven to solve the field's actual problems at all costs (including unreliable code that produces false results) and software engineers, who keep things tidy but are too risk-averse to attempt any real problems. I encourage folks with interests in bot…

Unreliable code that produces false results does not solve the field's actual problems, and is likely to contribute to the reproducibility problem. It might solve the author's immediate problem of needing to publish something. Update: I guess I misinterpreted OP's intent here, with "unreliable code that produces false results" being part of the field's actual problems rather than one of the costs to be borne.

I meant that the drive to solve problems at all costs can be self-defeating if you overextend yourself by making unreliable code that produces false results.

Re: Bad scientific code beats code following "best practices" (2014)

#270

Post by Regic » Sat, Jan 06, 2024, 6:44 PM UTC

MrJohz wrote: post #240

jakobnissen wrote: post #141

I'm a scientist programmer working in a field comprised by biologists and computer scientists, and what I've experienced is almost exactly the opposite of the author. I've found the problems that biologists cause are mostly: * Not understanding dependencies, public/private, SCM or versioning, making their own code uninstallable after a few months * Writing completely unreadable code, even to themselves, making it imp…

I only worked briefly in software for research, and what you described matched my experience, but with a couple of caveats. Firstly, a lot of the programs people were writing were messy, but didn't need to last longer than their current research project. They didn't necessarily need to be maintained long-term, and therefore the mess was often a reasonable trade-off for speed. Secondly, almost none of the software peo…

> There were a lot of people who were just reciting the best practice rules they'd learned from blog posts, without really having the experience to know where the advice was coming from, or how best to apply it

This is exactly my experience too. Also, the problem with learning things from youtube and blogs is that whatever the author decides to cover is what we end up knowing, but they never intended to give a comprehensive lecture about these topics. The result is people who dogmatically apply some principles and entirely ignore others - neither of those really work. (I'm also guilty of this in ML topics.)