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

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

#111

Post by palata » Sat, Jan 06, 2024, 11:29 AM UTC

aragilar wrote: post #26

palata wrote: post #2

TL;DR: a counter-productive rant against software engineers, claiming that bad code from software engineers is worse than bad code from scientists. Did you consider hiring an experienced software engineer as a lead?

Bad code written by software engineers is worse than bad code written by scientists, as the former takes more effort to fix than the latter (given the pathologies mentioned). It's naturally preferable to not have bad code, but it that choice was actually on the table, then I don't know who would choose the bad code. As for hiring software devs, that's not going to change (in general, there are places where software d…

It's just comparing two different things: the average "bad code from scientist" is for simple tasks, whereas the average "bad code from software engineer" is for a complicated task (otherwise you shouldn't pay the software engineer in the first place).

My point about the rant being counter-productive is that the solution is to learn how to do the task better, not to blame people. Maybe the best way to do a task with a very low budget is to not do it at all.

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

#112

Post by ohlokkru » Sat, Jan 06, 2024, 11:30 AM 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…

[flagged]

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

#113

Post by c048 » Sat, Jan 06, 2024, 11:33 AM UTC

quickthrower2 wrote: post #104

I agree. Been doing devops recently but back at some coding at work and I wrote the function as simple as I could, adding complexity but only as needed. So it started as a MVC controller function that was as long as your arm. Then it got split up into separate functions, and eventually I moved those functions to another file. I had some genuine need for async, so added some stuff to deal with that, timeouts, error ha…

Congrats, you used design patterns.

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

#114

Post by nohuck13 » Sat, Jan 06, 2024, 11:33 AM UTC

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…

"It’s the same story, really: It is a software engineer’s job to build quality software. A scientists job is to solve problems."

That's not the distinction. Good software engineers solve problems. That's what the paycheck is for. The distinction is whether code has to be maintained.

It's the scientist's job to solve a specific problem at a specific time. Who cares if the metaphorical wood rots next winter, the paper's been published.

It's _often_ the software engineer's job to build things that deliver business value over years, evolving and expanding requirements, in a development team, without grinding to a halt under the weight of accumulated complexity.

"Quality" software engineering is just heuristics for keeping the pace of change high over time without breaking things.

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

#115

Post by c048 » Sat, Jan 06, 2024, 11:35 AM UTC

alexmolas wrote: post #105

Now I dare you to add some new functionality on a bad designed software. Ask a scientist to change a little bit the initial hypothesis and update the code accordingly, and watch them cry while rewriting all the code.

They'll be crying on the same bench as the 'one line of code' people, when they're required to finetune their code.

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

#116

Post by rileymat2 » Sat, Jan 06, 2024, 11:35 AM UTC

Xeamek wrote: post #95

rileymat2 wrote: post #78

Earlier quoted context omitted.

> Splitting some functionality across many files adds significantly to the cognitive load of figuring out what code is actually even running. This is the crux, if your goal is to figure out what code is running, if you can keep the program in your head, if you have small simple programs splitting things up is harmful. But there is this murky line, different for everyone, and even different for the same person from da…

But at some point you HAVE to be able to look at the program from above. If you abandon the hope of understanding the code in the bigger scope, how can you ever meaningfully modify it? (Ie add a big feature and not just tweak some small parameters)

One last thing to consider, if you are writing little a CRUD app, it can be very simple, you can keep it in your head.

However, Can you?

You are using black box code from a web server, a sql database, the operating system, crypto libraries, and a ton more; You don't dive into that source code except in extraordinary circumstances, if you even can. In a large program, you end up treating code owned by you or your company as the same way.

In this scenario you are still making large meaningful changes by focusing on the level of abstraction you are at.

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

#117

Post by kkoncevicius » Sat, Jan 06, 2024, 11:36 AM UTC

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 first distinction here should be what kind of "code" are we talking about. As far as I see there are two main possibilities:

  1. code for performing a scientific simulation or analysis (a script).
  2. code for solving a specific problem generally (a program).

There are different "best practices" for the two situations above. And the article primarily talks about applying "best practices" from the 2nd scenario to the 1st. Of course they don't apply.

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

#118

Post by zelphirkalt » Sat, Jan 06, 2024, 11:36 AM UTC

nohuck13 wrote: post #114

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…

"It’s the same story, really: It is a software engineer’s job to build quality software. A scientists job is to solve problems." That's not the distinction. Good software engineers solve problems. That's what the paycheck is for. The distinction is whether code has to be maintained. It's the scientist's job to solve a specific problem at a specific time. Who cares if the metaphorical wood rots next winter, the paper'…

> It's the scientist's job to solve a specific problem at a specific time. Who cares if the metaphorical wood rots next winter, the paper's been published.

Sounds a little like cargo-culting than proper reproducible research. But this is a pest in academia definitely. Many papers do not provide all required data, all required model parameters etc. to get to the exact same result. Admittedly, they might nowadays need a software engineer to get that done.

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

#119

Post by austin-cheney » Sat, Jan 06, 2024, 11:46 AM UTC

> Invariably, the biggest messes are made by the minority of people who do define themselves as programmers.

After 15 years of writing JavaScript professionally I know that is a lie. The biggest messes are made by the majority of people hired that cannot really program.

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

#120

Post by palata » Sat, Jan 06, 2024, 11:47 AM UTC

stalfosknight wrote: post #5

palata wrote: post #2

TL;DR: a counter-productive rant against software engineers, claiming that bad code from software engineers is worse than bad code from scientists. Did you consider hiring an experienced software engineer as a lead?

TFA seems to have hit a nerve.

If it's about ranting at classes of people, I can do it too: most software is shit, that's true. But somehow users like shit, and it makes profit so software engineers get paid to write it. They get valued by writing a lot of shit, not by writing little good code. Also most software engineers are juniors; junior civil engineers would not be allowed to build a bridge, junior software engineers can do all the crap they want.

But let's be fair: most scientists do bad research. Have you ever read papers in a field you know? 99% is bullshit. Not "non-conclusive good research", no. Downright useless, non-reproducible bullshit (or paraphrasing something that already exists, often making it worse). Just like software engineers, most scientists are juniors (we call them "PhD candidates") who get valued by publishing papers (any paper) in "recognized" journals (with some definition of "recognized"), by journals who make profit by accepting papers (any paper). Again not totally their fault: they have to produce recognized stuff in the time they are given, they don't have to produce good research.

I don't have a solution to those problems, of course: that's how the system works ("make profit"). I wish we tried to solve actual problems in a good way, but we don't. I don't think scientists are better than software engineers, though: we are all part of the problem. Less of all of us would make the world a better place (or would have prevented us from spoiling it, at least).

I just don't think my rant is worth publishing on HN.