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

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

#221

Post by whstl » Sat, Jan 06, 2024, 4:01 PM UTC

chongli wrote: post #67

bobmaxup wrote: post #36

Earlier quoted context omitted.

> One long, yet simple function has less cognitive overhead than spreading the function across multiple classes or functions or call hierarchies Not if you are encapsulating and naming effectively... Why read 100 lines when you can read 20 and find concerns in one routine you are concerned with? Function calls can be expensive. However, optimization can come whenever you need it, and if what you need is one call vs 5…

Not if you are encapsulating and naming effectively... Encapsulation is hard and a lot of what people call encapsulation isn’t. For example, taking a global variable and moving it to a class is not encapsulation. You have to actually do the hard work of removing the dependency on global shared state. Just changing everything to mutate the new global through an accessor to a “god” object that gets passed everywhere is…

It's funny how Singletons became such a meme pattern, and how about 80% of people in interviews only know about it when asked about patterns.

A cleverly-named way of disguising global mutable state does not make it better.

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

#222

Post by hkon » Sat, Jan 06, 2024, 4:02 PM UTC

ameminator wrote: post #194

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…

> They are also less productive when coding than the scientists because they care too much about the quality of their work and not enough about getting shit done. You can't solve the first 3 issues without having people who care about software quality. People not caring about the quality of the software is what caused those initial 3 problems in the first place.

Yeah, if only scientists would put the same care into the quality of their science...

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

#223

Post by Master_Odin » Sat, Jan 06, 2024, 4:06 PM UTC

coldtea wrote: post #174

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've found the problems that biologists cause are mostly 1. Not understanding dependencies, public/private, SCM or versioning, making their own code uninstallable after a few months That's not on them though. That's on the state of the tooling in the industry. Most of the time, dependencies could just be a folder you delete, and that's that (node_modules isn't very far from that). Instead it's a nightmare - and not…

While I agree tooling could be better, while in grad school I found that a lot of academics / grad students don't know that any of the tooling even exists and never bothered to learn if and such tooling existed that could improve their life. Ditto with updating their language runtimes. It really seemed like they viewed code as a necessary evil they had to do to achieve their research goal.

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

#224

Post by EMCymatics » Sat, Jan 06, 2024, 4:08 PM UTC

frostix wrote: post #181

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…

>They are also less productive when coding than the scientists because they care too much about the quality of their work and not enough about getting shit done. Ultimately I’d say the core issue here is that research is complex and those environments are often resource strapped relative to other environments. As such this idea of “getting shit done” takes priority over everything. To some degree it’s not that much d…

>Ultimately I’d say the core issue here is that research is complex and those environments are often resource strapped relative to other environments. As such this idea of “getting shit done” takes priority over everything.

That conforms to my experience

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

#225

Post by dahart » Sat, Jan 06, 2024, 4:08 PM UTC

In other words, programmers tend to over-engineer, and non-programmers tend to under-engineer. Despite all the arguments here about who’s making the biggest messes, that part is not surprising at all.

Both are real problems. Over-abstraction and over-engineering can be very expensive up front and along the way, and we do a lot of it, right? Under-engineering is cheaper up front but can cause emergencies or cost a lot later. Just-right engineering is really hard to do and rarely ever happens because we never know in advance exactly what our requirements and data really are.

The big question I have about scientific environments is why there isn’t more pair-programming between a scientist and a programmer? Wouldn’t having both types of expertise vetting every line of code be better than having each person over/under separately? Ultimately software is written by teams, and it’s not fair to point fingers at individuals for doing the wrong amount of engineering, it’s up to the entire team to have a process that catches the wrong abstraction level before it goes too far.

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

#226

Post by Palomides » Sat, Jan 06, 2024, 4:10 PM UTC

dahart wrote: post #225

In other words, programmers tend to over-engineer, and non-programmers tend to under-engineer. Despite all the arguments here about who’s making the biggest messes, that part is not surprising at all. Both are real problems. Over-abstraction and over-engineering can be very expensive up front and along the way, and we do a lot of it, right? Under-engineering is cheaper up front but can cause emergencies or cost a lot…

it's exclusively because engineers are more expensive than grad students

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

#227

Post by LeonardoTolstoy » Sat, Jan 06, 2024, 4:12 PM UTC

mazelife wrote: post #198

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'm a software engineer working with scientist-turned-programmers, and what I've experienced is also exactly the opposite of the author. The code written by the physicists, geoscientists and data scientists I work with often suffers from the following issues: * "Big ball of mud" design [0]: No thought given to how the software should be architected or what the entities that comprise the design space of the problem ar…

> Lack of familiarity with common data structures and algorithms

This part I 100% agree with. I adapt a lot of scientific code as my day-to-day and most of the issues in them tend to be making things 100x slower than they need to be and then even implementing insane approximations to "fix" the speed issue instead of actually fixing it

>"Big ball of mud" design

Funny enough this was explicitly how my PI at my current job wants to implement software. In his opinion the biggest roadblock in scientific software is actually convincing scientists to use the software. And what scientists want is a big ball of mud which they can iterate on easily and basically requires no installation. In his opinion a giant Python file with a requirement.txt file and a Python version is all you need. I find the attitude interesting. For the record he is a software engineer turned scientist, not the other way around, but our mutual hatred for Conda makes me wonder if he is onto something ...

>I think the appearance of "I'm just getting shit done" is often a superficial one, because it doesn't factor in the real costs: other scientists and engineers can't use their solutions because they're not designed in a way that makes them work in any other setting than the narrow one they were solving for.

For the record my experience is the exact opposite. The crazy trash software probably written in Python that is produced by scientists are often the ones more easily iterated on and used by other scientists. The software scientists and researchers can't use are the over-engineered stuff written in a language they don't know (e.g. Scala or Rust) that requires them to install a hundred things before they are able to use it.

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

#228

Post by dahart » Sat, Jan 06, 2024, 4:13 PM UTC

Palomides wrote: post #226

dahart wrote: post #225

In other words, programmers tend to over-engineer, and non-programmers tend to under-engineer. Despite all the arguments here about who’s making the biggest messes, that part is not surprising at all. Both are real problems. Over-abstraction and over-engineering can be very expensive up front and along the way, and we do a lot of it, right? Under-engineering is cheaper up front but can cause emergencies or cost a lot…

it's exclusively because engineers are more expensive than grad students

Can you elaborate? What is answered by engs vs grad students? What grad students are we talking about?

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

#229

Post by esafak » Sat, Jan 06, 2024, 4:14 PM UTC

chongli wrote: post #75

9dev wrote: post #62

Oh look, another tiring craftsmanship debate that other disciplines long figured out! A, say, physicist writing bad code could equally well be building a pergola for his garden. He doesn’t really know woodworking but god be damned if he couldn’t calculate the forces acting on the beams, and then add some screws - how hard can it be! And probably, he’ll even get the thing up, and it doesn’t look too bad even. Now get…

The real difference here is between hobbyists and mere workers. Programming happens to be one of the disciplines which has a lot of hobbyists. But that doesn’t mean you won’t find hobbyists in other disciplines. Look at machining for example. Long dominated by people working in machine shops making tools and parts on the clock. But in the background there’s a strong hobbyist contingent and there you’ll find endless d…

I don't know about that. Pros obsess over it too, but they don't bother to endlessly talk about it; they just do it. But if a better tool comes along, they'll consider it.

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

#230

Post by lynndotpy » Sat, Jan 06, 2024, 4:15 PM UTC

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 file! (For Python, at least.)

Second, two anecdotes where not following best practices ruined the correctness of research code:

- Years ago, I was working on research code which simulated a power-grid. We needed to generate randomized load profiles. I noticed that each time it ran, we got the same results. As a software engineer, I figured I had to re-set the `random` seed, but that didn't work. I dug into the code, talked to the researcher, and found the load-profile algorithm: It was not randomly generated, but a hand-coded string of "1" and "0".

- I later had the pleasure of adapting someone's research code. They had essentially hand-engineered IPC. It worked by calling a bash script from Python, which would open other Python processes and generate a random TCP/IP socket, the value of which was saved to an ENV variable. Assuming the socket was open, the Python scripts would then share the socket names of other filenames for the other processes to read and open. To prevent concurrency issues, sleep calls were used throughout the Python and Bash script. This was four Python scripts and two shell scripts, and to this day, I do not understand the reason this wasn't just one Python script.