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

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

#151

Post by ben_w » Sat, Jan 06, 2024, 12:59 PM UTC

palata wrote: post #125

ben_w wrote: post #94

> Many programmers have no real substance in their work – the job is trivial – so they have too much time on their hands, which they use to dwell on "API design" and thus monstrosities are born. Definitely getting this vibe from modern frameworks and design patterns. I want to like SwiftUI, but the WYSIWYG editor doesn't even work for the default projects for me. Storyboards were great for creating everything UI exce…

> piling on layers of stuff to fill in the gaps missed (or created) by the previous layer of abstraction. I think the goal is to make if more accessible, so that more people with less knowledge can produce more crap with it. People don't learn the basics, they want to write a comment in Copilot and have it assemble code that roughly does what they want. I believe that people who got into software in the 60s actually…

> I think the goal is to make if more accessible, so that more people with less knowledge can produce more crap with it.

If so, it fails at even this: for my A-levels[0], my teacher only knew VisualBasic[1], which was very easy to work with: drag and drop widgets onto a form, (double?)-click on a widget to get right into the code block that happens when a user users the widget.

Back when JS was new and there were no extra layers of abstraction, yes the language sucks, but you could get to work with it using only what you found in a £4.99 book from WHSmith[2] and a text editor, you didn't need to `install npm` and then some library and then…

> People don't learn the basics, they want to write a comment in Copilot and have it assemble code that roughly does what they want.

Agree. Heck, I do that, and I started learning the basics when I was about 5. :)

> People don't learn the basics, they want to write a comment in Copilot and have it assemble code that roughly does what they want. I believe that people who got into software in the 60s actually liked computers. People who get into software today just want to produce stuff, they don't care about their computer.

My dad probably got into computers some time in the 60s, a one or two day corporate training program about "this new thing called 'software'". The way he talked about them, it was clear he didn't really understand them, and just wanted to get stuff done.

[0] https://en.wikipedia.org/wiki/A-level

[1] It turned out that the copy of REALbasic I had on my Mac at home was almost copy-paste compatible, the only exception I ran into was that `Dim foo, bar As Integer` has `foo` and `bar` being `Integer` in REALbasic while our version of VB had `foo` being `Integer` and `bar` being `VarType`

[2] https://en.wikipedia.org/wiki/WHSmith

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

#152

Post by dguest » Sat, Jan 06, 2024, 12:59 PM 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.

Most teams at CERN don't have a professional programmer available either. In a few of larger projects (those with a few hundred active contributors) there might be one or two more tech savvy people who profile the code regularly and fix the memory leaks. But few (if any) are professional programmers: most contributors are graduate students with no background in programming.

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

#153

Post by collyw » Sat, Jan 06, 2024, 1:00 PM UTC

Worst code I have seen has been written by self taught bioinformaticians.

But, a lot of the time these scripts are used as one offs, to generate a result, then are done with, so quality doesn't need to be the same as with a server running 24/7.(Sadly the ones I had to fix were being run regularly).

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

#154

Post by collyw » Sat, Jan 06, 2024, 1:04 PM UTC

jampekka wrote: post #126

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…

I'm an ex-software developer/engineer and current scientist. In my experience TFA makes a good point, even though it's quite strawmanish. Most scientific code is horrible from any sane software developer perspective. The quality is so bad that I think a huge proportion of published results are plain wrong due to bugs in the analysis. These apply to my much of my code as well. But a lot of "software engineering" code…

I'll add that "code reuse" was pushed as an idea too heavily (at my university at least). I think that leads to a fair bit of the over engineering and unnecessary complexity.

I saw a comment later saying not to aim for "code reuse", but rather to "avoid code duplication" which made more sense.

I also agree that a lot of best practices are great if you are a massive company with unlimited resources, but they are just overkill and add complexity for smaller projects and teams.

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

#155

Post by sseagull » Sat, Jan 06, 2024, 1:09 PM UTC

jampekka wrote: post #126

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…

I'm an ex-software developer/engineer and current scientist. In my experience TFA makes a good point, even though it's quite strawmanish. Most scientific code is horrible from any sane software developer perspective. The quality is so bad that I think a huge proportion of published results are plain wrong due to bugs in the analysis. These apply to my much of my code as well. But a lot of "software engineering" code…

I basically agree (except I will take static typing over dynamic typing any day).

I work in computational chemistry, and scientists here don’t necessarily have problems actually coding (we’ve been doing it for 70+ years). But the “other stuff” is taking more and more time.

Before, you wrote Fortran, put the files on disks or whatever, and sent them around. Now, you need to know:

C++ and Python (and maybe Fortran too)

git and github and github actions, and packaging (pypi/conda/conda-forge I guess is the standard now).

Documentation? Sphinx I guess, although mixed codebases are still a pain. And where do I host the docs again?

Also better make sure it works on all three OSs.

Wait what is docker? Suppose I better learn make images. And they have to be hosted somewhere? Got to set that up too.

Oh wait again, Python 3.12 broke something. Have to fix that.

Does all of this make “better software”?. I’m coming around to the idea that maybe it doesn’t, at least in aggregate. Either way, scientists don’t have time to really learn all this AND the science they are doing. And it all changes every few years or so.

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

#156

Post by collyw » Sat, Jan 06, 2024, 1:10 PM UTC

graemep wrote: post #90

dash2 wrote: post #81

Earlier quoted context omitted.

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

Given Ferguson's track record of being out by orders of magnitude on absolutely everything beforehand, it almost seems like he was chosen to give an over the top estimate.

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

#157

Post by collyw » Sat, Jan 06, 2024, 1:11 PM UTC

mike_hearn wrote: post #138

graemep wrote: post #90

Earlier quoted context omitted.

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

> I do not know how bad it was, but it cannot be good the code was bad. I do know because I reviewed the code and its issue tracker extensively. I then wrote an article summarizing its problems that went viral and melted the server hosting it. The Imperial College code wasn't merely "bad". It was unusable. It produced what were effectively random numbers distributed in a way that looked right to the people who wrote…

Aside from the code quality, his models have never been close to accurate on anything.

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

#158

Post by collyw » Sat, Jan 06, 2024, 1:13 PM UTC

palata wrote: post #134

flohofwoe wrote: post #130

Earlier quoted context omitted.

I guess the main problem is that many self-proclaimed "software engineers" are surprisingly bad "programmers" ;)

Just like most "research" is absolutely useless, when not counter-productive ;)

It's often very useful for those funding it.

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

#159

Post by jampekka » Sat, Jan 06, 2024, 1:13 PM UTC

collyw wrote: post #154

jampekka wrote: post #126

Earlier quoted context omitted.

I'm an ex-software developer/engineer and current scientist. In my experience TFA makes a good point, even though it's quite strawmanish. Most scientific code is horrible from any sane software developer perspective. The quality is so bad that I think a huge proportion of published results are plain wrong due to bugs in the analysis. These apply to my much of my code as well. But a lot of "software engineering" code…

I'll add that "code reuse" was pushed as an idea too heavily (at my university at least). I think that leads to a fair bit of the over engineering and unnecessary complexity. I saw a comment later saying not to aim for "code reuse", but rather to "avoid code duplication" which made more sense. I also agree that a lot of best practices are great if you are a massive company with unlimited resources, but they are just…

Code reuse was indeed the hype, especially of OOP and inheritance. In practice it just made real code reuse a lot worse. The class hierarchies become so tightly coupled that any "reuse" requires a lot more boilerplate than the actual code to use.

I know that the idea is not just not writing more code, but have a "single point of truth". But the boilerplate leads to a situation where it's very inpractical and leads to a tightly coupled mess that's really hard to change.

What actually increased code reuse was duck typing (i.e. implicit interfaces), made popular by Python. But that's becoming verboten nowadays. And I don't think current structural typing systems are gonna reach the same level of reuse.

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

#160

Post by kolinko » Sat, Jan 06, 2024, 1:17 PM UTC

9dev wrote: post #128

madsbuch wrote: post #101

Earlier quoted context omitted.

If the bad wood working would jepordize the results of his, professional salary earning, work then he should probably consider learning wood working, no?

Don’t think so, no. A physicist has other stuff to learn and spend their time on. Instead, they should partner with a carpenter to do their woodworking from a rough sketch.

It’s like saying that a scientist doesn’t need to know how to write, and they should just pair up with ghostwriters/copywriters.

Many professions have tool/skill requirements that are not related to that profession on a strict sense, but are still necessary to do the job properly.

When I learned engineering we were taught how to draw diagrams by hand and write in a technical font. Computer code, for many science fields, is like diagrams but for theories.