Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

yosefk.com

Post reply on HN
Print view View original

31–40 of 333 posts

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

#31

Post by aragilar »

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.

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

#32

Post by querez »

Exoristos wrote: post #25
jurschreuder wrote: post #12

This is so true I don't think I ever read something so true. It's not even scientists vs software developers. It's people who are really into software development and clean code. They say the program needs a total rewrite and proceed to add 20 layers of inheritance and spreading out every function over 8 files. Ever since I make sure to repeat my mantra every week to developers: How maintainable code is is measured i…

Am I missing something? Opening files is not my most intensive work as a developer.

It's a decent measure of complexity: It's not that "opening files" themselves is work-intensive. But having a lot of files smells of overengineered code. One long, yet simple function has less cognitive overhead than spreading the function across multiple classes or functions or call hierarchies (themselves spread over multiple files).

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

#34

Post by Jtsummers »

__loam wrote: post #27
Exoristos wrote: post #25

Earlier quoted context omitted.

Am I missing something? Opening files is not my most intensive work as a developer.

Adding indirection makes code less maintainable.

> Adding indirection makes code less maintainable.

This is why I hated Fortran (77 in particular) as an applications language (for tasks like scientific computing people seemed to use saner portions of it). Computed go tos were the bane of my existence.

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

#35

Post by logicchains »

jurschreuder wrote: post #12

This is so true I don't think I ever read something so true. It's not even scientists vs software developers. It's people who are really into software development and clean code. They say the program needs a total rewrite and proceed to add 20 layers of inheritance and spreading out every function over 8 files. Ever since I make sure to repeat my mantra every week to developers: How maintainable code is is measured i…

>They say the program needs a total rewrite and proceed to add 20 layers of inheritance and spreading out every function over 8 files.

Anyone who in 2023 still thinks inheritance is a good idea for anything other than a few very specialised use-cases is not somebody who seriously cares about the craft of software development, not somebody who's put any effort to study programming theory and move beyond destructive 1990s enterprise Java practices. Widespread usage of inheritance inevitably makes code harder to reason about and refactor, as anyone who's compared code in Java to code for similar functionality in Rust or Go would see (both Rust and Go deliberately eschew support for inheritance due to the nightmares it can cause).

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

#36

Post by bobmaxup »

querez wrote: post #32
Exoristos wrote: post #25

Earlier quoted context omitted.

Am I missing something? Opening files is not my most intensive work as a developer.

It's a decent measure of complexity: It's not that "opening files" themselves is work-intensive. But having a lot of files smells of overengineered code. One long, yet simple function has less cognitive overhead than spreading the function across multiple classes or functions or call hierarchies (themselves spread over multiple files).

> 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, it is trivial to move that code back into a single routine.

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

#37

Post by zmgsabst »

aragilar wrote: post #19
zmgsabst wrote: post #10

Earlier quoted context omitted.

Prime Finance (at Amazon) did that. Wrote fancy math on a PhD economist’s laptop. Then when we added testing when developing a platform, we found out we’d been 5% off in allocating Prime revenue between organizations — and had the correct amount gone to Retail, the 2018 hiring freeze might have been avoided. (According to a very angry Wilke.) Whoops. Turned out we did need a team and all those guardrails, processes,…

Did no-one check the maths? There's a difference between having a full test suite, and someone trying some choice values, but I'd expect both would pick up something like that.

The PhD economists on our team looked at it.

Economists from other teams looked at it and signed off.

There was manual testing — ie, trying some “choice values”.

We discovered their error in convexity when our test suite allowed us to randomly sample the models at scale. (Actually, I had questions before that — but unsurprisingly, when it was just me questioning a PhD economist, the lowly SDE was ignored.)

Good intentions aren’t enough; you need mechanisms.

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

#38

Post by thriftwy »

o11c wrote: post #23
jurschreuder wrote: post #12

This is so true I don't think I ever read something so true. It's not even scientists vs software developers. It's people who are really into software development and clean code. They say the program needs a total rewrite and proceed to add 20 layers of inheritance and spreading out every function over 8 files. Ever since I make sure to repeat my mantra every week to developers: How maintainable code is is measured i…

Wrong. How maintainable code is is measured in how well you know where to change something, and how certain you are that it did the right thing without side effects. The fatal error of the linked article is that bad scientific code often suffers from correctness problems - not just theoretical concerns, but the "negates the main point of this paper" kind of thing.

What if a new person takes your place and they do not know it and are not certain in anything?

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

#39

Post by namaria »

nvy wrote: post #16
namaria wrote: post #6

Earlier quoted context omitted.

You know, 96% of businesses (and by extension codebases) have to get by software wise without high priced software engineers. They couldn't afford it. The vast majority of running code is produced by people whose understanding of computer systems and programming goes as deep as how much documentation they need to ctrl+f through to get some specific tasks done.

>The vast majority of running code is produced by people whose understanding of computer systems and programming goes as deep as how much documentation they need to ctrl+f through to get some specific tasks done. I doubt this very much. Surely the vast majority of running code is some chunk of Chrome, Android, or the JVM ("billions of devices run Java...") or something. All those things were produced by software engi…

Maybe by instances of the same codebase, yeah absolutely.

But there is certainly more codebases out there running some python or js written by designers, data analysts etc then those produced and curated by software engineers.

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

#40

Post by [deleted] »

thriftwy wrote: post #38
o11c wrote: post #23

Earlier quoted context omitted.

Wrong. How maintainable code is is measured in how well you know where to change something, and how certain you are that it did the right thing without side effects. The fatal error of the linked article is that bad scientific code often suffers from correctness problems - not just theoretical concerns, but the "negates the main point of this paper" kind of thing.

What if a new person takes your place and they do not know it and are not certain in anything?

[deleted]
Post reply on HN