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

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

#71

Post by Asraelite » Sat, Jan 06, 2024, 9:50 AM UTC

jusssi wrote: post #52

Two more to the scientists' tab: 1. No tests of any kind. "I know what the output should look like." Over time people who know what it should look like leave, and then it's untouchable. 2. No regard to the physical limits of hardware. "We can always get more RAM on everyone's laptops, right?". (You wouldn't need to if you just processed the JSONs one at a time, instead of first loading all of them to the memory and t…

Agree with those two problems on the scientist side. I would also add that they often don't use version control.

I think a single semester of learning the basics of software development best practices would save a lot of time and effort in the long term if it was included in physics/maths university courses.

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

#72

Post by Nursie » Sat, Jan 06, 2024, 10:05 AM UTC

Yeah nah.

There was the flawed model out of Imperial College (IIRC) during the early covid days that showed up how wrong this attitude is.

It was so poorly written that the results were effectively useless and non-deterministic. When this news came out, the scientists involved doubled down and instead of admitting that coding might be hard, and getting in a few experts to help out might be useful, actually blamed software engineers for how hard it is to use C++.

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

#73

Post by astrobe_ » Sat, Jan 06, 2024, 10:05 AM UTC

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 they teach in schools. But nobody can tell why it is "good", because it is actually not relevant anymore.

Scientific code has no superstitions (as expected I would say), but not for the best reasons; they didn't learn the still relevant good practices either.

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

#74

Post by 59nadir » Sat, Jan 06, 2024, 10:07 AM UTC

Roark66 wrote: post #64

>Multiple/virtual/high-on-crack inheritance 7 to 14 stack frames composed principally of thin wrappers, some of them function pointers/virtual functions, possibly inside interrupt handlers or what-not Files spread in umpteen directories Scientific code? You just described 99% of "enterprise" java code above.

That's from the list of software engineer sins, yes, so that tracks with your opinion.

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

#75

Post by chongli » Sat, Jan 06, 2024, 10:12 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 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 debates over whether a beginner should buy a decades old Bridgeport milling machine or a brand new Chinese-made one.

Similarly I find endless debates about what sort of frying pan to use (nonstick, stainless, carbon steel, or cast iron) among amateur chefs, but you’ll never see people working in a restaurant waste time on that.

In other words, it’s hobbyists who really obsess over tools and craftsmanship. They do it because they love it. Programmers just happen to be among the odd sort who can get paid to practice their hobby.

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

#76

Post by DragonStrength » Sat, Jan 06, 2024, 10:14 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…

Actually, when I’ve followed those guidelines, it’s because the tech lead graduated in the 1980s, almost certainly learned it all on the job, but has always done it that way. Others just do what they’ve done before. School talked about those things, but not in a “this is the right way” sort of thing.

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

#77

Post by Spiwux » Sat, Jan 06, 2024, 10:21 AM UTC

I really do not understand these memes about overengineered FactoryFactoryFactories. I have 10 YOE, did I just get lucky? I've worked at enterprise Java shops as well, but even there I'd call the software pragmatic. Are these overengineered monstrosities REALLY still a thing, or is it "just" people suffering in legacy projects? Even the juniors I worked with were following KISS and YAGNI.

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

#78

Post by rileymat2 » Sat, Jan 06, 2024, 10:24 AM UTC

oivey wrote: post #66

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... No, and this is one of the reasons inheritance has lost popularity. Splitting some functionality across many files adds significantly to the cognitive load of figuring out what code is actually even running. After you trace that information out, you need to keep it all straight in your head while debugging whatever you’re working on. That’s even more problemati…

> 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 day to day, where even with the best intent, no matter how good you are, you can't keep the program in your head.

At that point, you need to give up the idea that you can. Then you change perspective and see things in chunks, split up, divide and conquer, treat portions as black boxes. Trust the documentation's, pre and post conditions. Debugging becomes verifying those inputs and returns; only diving into the code of that next level when those expectations are violated.

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

#79

Post by dash2 » Sat, Jan 06, 2024, 10:24 AM UTC

Ulp. As a scientist who is a hobby "programmer", this struck close to home. I've got one project[1] with a huge mess of functions calling each other. It started out with good intentions, but then gradually descended as I wrote more and more hacks to add new analyses & robustness checks. I swear I meant well!

I think there's a genuine tension between writing good code and "shipping" a paper. At least, when I program "as a programmer" I think my code is mostly higher quality.

[1] https://github.com/hughjonesd/why-natural-selection/blob/mas...

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

#80

Post by zeraholladay » Sat, Jan 06, 2024, 10:25 AM UTC

I think a lot of developers naively rely on "software design" principles. They often can't state their reasons for adopting these principles and assume these principles are self-evident. This can be a problem when these principles conflict with external priorities, or when a complex "principled" design is used instead of an obvious, intuitive design. There's also a certain amount of trendiness to software design, so trends can be applied haphazardly.

That being said, I've also seen plenty of "scientific code" that's totally incomprehensible even to the point where the scientist who wrote the code can't debug it. So there's an extreme in the other direction.