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

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

#81

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

This might work for CERN. But a great deal of science is done by small teams who don't have a professional programmer available. Basically all of the social sciences, for a start; a lot of genetics too.

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

#82

Post by chongli » Sat, Jan 06, 2024, 10:29 AM UTC

dmz73 wrote: post #70

logicchains wrote: post #35

Earlier quoted context omitted.

>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 19…

(Ab)use of any paradigm (I'll need a shower for using that word) can result in nightmares. Inheritance has its place and it is definitely useful in more than "few specialised cases". It can get out of hand and it can become a nightmare. Composition has its place and it is definitely not better than inheritance except in "few specialised cases". It can also result in nightmare, just wait till adoption of Rust and go i…

The problem with inheritance is that no one seems to know where to use it best. Everyone just goes by feel and feelings frequently turn out to be wrong.

Composition is nice because it’s very simple and we can understand it mathematically. If you’re trying to understand inheritance mathematically then you’re basically left with using it only for algebraic structures (groups and rings and fields and vector spaces). But then you don’t really need inheritance there if you just have plain types and operator overloading.

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

#83

Post by renewiltord » Sat, Jan 06, 2024, 10:30 AM UTC

Cost is paid during development and maintenance. Value is reaped during usable life. The two periods overlap. Then subtract value from cost and integrate. Maximize that number.

Easily leads to conclusions of "you don't need this to scale" vs "build this to scale" and "you need to make this extensible" vs "just ship the hacky thing".

Just need to know what your params are and place uncertainty on it.

Once I wrote a program in a day. Did a kind of pricing. Hacky af. Just tech demo. Over time people start depending on it. One year later it breaks. Too many products priced, internal ring buffer only has few slots. Pricing stalls for all products.

"This is a company-killing issue!" Everyone yells. Sure, my mistake. I let thing get depended on without productifying but original choice was fine since it allowed iteration on something else that made money. Just when situation changes you gotta adapt.

No rules about that except just short loop on quality required and time spent.

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

#84

Post by puttycat » Sat, Jan 06, 2024, 10:33 AM UTC

OP is using a strawman caricature of a programmer to make his point. While such bad (often junior) programmers exist, there also exist many reasonable ones who won’t commit all these over the top abstractions while also not falling into the "scientific" programming pathologies.

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

#85

Post by roenxi » Sat, Jan 06, 2024, 10:37 AM UTC

dmz73 wrote: post #70

logicchains wrote: post #35

Earlier quoted context omitted.

>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 19…

(Ab)use of any paradigm (I'll need a shower for using that word) can result in nightmares. Inheritance has its place and it is definitely useful in more than "few specialised cases". It can get out of hand and it can become a nightmare. Composition has its place and it is definitely not better than inheritance except in "few specialised cases". It can also result in nightmare, just wait till adoption of Rust and go i…

Mmm. Maybe lets stop and address the question of "what are the key properties of inheritance?". Because I haven't seen a single use for it in maybe a decade or so and I'm not sure what it is you think you're defending.

Usually what people want is an interface; ie, a somewhat generic way of saying "this thing knows how to draw itself", "this thing supports printing" or "this thing can fizzle wuzzles like all the other wuzzle fizzlers". That is essential to coding.

But Java style inheritance carries a lot of baggage in excess of that; and some of it is just bad news. In practice it is a brittle assumption that a Foo is also and always a precise superset of Bar. And usually when that is true the relationship is so shallow having a dedicated concept of inheritance is wasteful, it may as well be an interface and a shared file of code.

TLDR; Inheritance is too many ideas mixed together; most useful and a couple bad. It is a better idea to present the different facets of inheritance to be selected a la carte. Mumble mumble Rich Hickey talks.

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

#86

Post by chongli » Sat, Jan 06, 2024, 10:38 AM UTC

phkahler wrote: post #63

bobmaxup wrote: post #56

Earlier quoted context omitted.

Maybe it boils down to how well you are able to navigate a code base. With a full-featured language specific IDE, it is very easy to navigate through even complicated spaghetti. It makes debugging call traces simple, with a GUI. However, many other file viewers and editors make this much more complicated, and it can be frustrating to follow code that is making heavy use of modularization. If you are grepping your way…

>> With a full-featured language specific IDE, it is very easy to navigate through even complicated spaghetti. If you need a fancy IDE to navigate around code in order to understand it, that might be crappy or poorly organized code. Not a dig at nice IDEs, just code that requires one to navigate and understand.

Yeah. This is one of those hammer cases. If you’ve got a fancy IDE then the temptation is to use it. Similar to the issue of game programmers being given top of the line gaming PCs with frequent upgrades. They then struggle to understand why the game they just released runs like crap on most people’s modest computers.

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

#87

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

[flagged]

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

#88

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

In computer science, for some reason - people struggle to distinguish between an engineer and a scientist.

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

#89

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

chongli wrote: post #82

dmz73 wrote: post #70

Earlier quoted context omitted.

(Ab)use of any paradigm (I'll need a shower for using that word) can result in nightmares. Inheritance has its place and it is definitely useful in more than "few specialised cases". It can get out of hand and it can become a nightmare. Composition has its place and it is definitely not better than inheritance except in "few specialised cases". It can also result in nightmare, just wait till adoption of Rust and go i…

The problem with inheritance is that no one seems to know where to use it best. Everyone just goes by feel and feelings frequently turn out to be wrong. Composition is nice because it’s very simple and we can understand it mathematically. If you’re trying to understand inheritance mathematically then you’re basically left with using it only for algebraic structures (groups and rings and fields and vector spaces). But…

Operator overloading leads to less readable, maintainable code IMHO, because you have to go off and figure out if the operator means a special thing in a given context.

Certainly adds to complexity in C++.

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

#90

Post by graemep » Sat, Jan 06, 2024, 10:51 AM UTC

dash2 wrote: post #81

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…

This might work for CERN. But a great deal of science is done by small teams who don't have a professional programmer available. Basically all of the social sciences, for a start; a lot of genetics too.

If you cannot model using decent code is it worth writing models at all? What if bugs mean the model is simply wrong?

It has consequences too. There has been a lot of argument about how much impact the poor code quality of the Imperial college covid epidemiology model (which was the basis of British government policy during the pandemic) had on its accuracy. I do not know how bad it was, but it cannot be good the code was bad.