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

51–60 of 333 posts

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

#51

Post by _the_inflator »

bearsnowstorm wrote: post #3

Read this on mobile and the identifier longWindedNameThatYouCantReallyReadBTWProgrammersDoThatALotToo overflowed into the margins - I regard this not as a bug but a feature which helped make the author’s point :-)

That’s why I fell in love with Objective C. The libraries used a lot of those expressive descriptions for attributes and methods.

I never understood nor understand people who nest their inner loops in an entangled mess of hardly distinguishable digits, which is error prone.

Same for method names.

I try to use speaking out loud to some of my methods: What do you do? And if the answer is getValue I believe it needs renaming.

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

#52

Post by jusssi »

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 then processing them one at a time.)

Also the engineers' tab has a strong smell of junior in it. When you have spent some time maintaining such code, you'll learn not to make that same mess yourself. (You'll overcorrect and make another, novel kind of mess; some iterations are required to get it right.)

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

#53

Post by galaxyLogic »

gregopet wrote: post #22

Sounds like the non-programmers are good at what they are supposed to be good at (solving the actual problem, if perhaps not always in the most elegant manner) while the programmers should be producing a highly maintainable, understandable, testable and reliable code base (and potentially have problems with advanced algorithms that rely on complicated theorems), but they are not. The OP has a case of bad programmers…

Right and I think "scientists" simply are more intelligent than average Joe Coder. Intelligent people produce better software.

It is easy to learn some coding, not so easy to become a scientist.

To becomes a scientist you must write and get your PhD-thesis approved, which must already be about scientific discoveries you have made while doing that thesis. Only people with above average IQ can accomplish something like that, I think.

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

#55

Post by Faark »

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…

> as the former takes more effort to fix than the latter

Disagree. Well, maybe still acceptable if the software is small / limited to a single paper. Having worked on a code base the people writing it learned programming on that job, guessing their intention is like archeology. And each iteration tended to add some complicated interdependence. Or like when int errorCode came from other, overlapping error ranges.

A part of the "new" code base is exactly as described by TFA. Including most interfaces having only one implementation. But while annoying, I am more able to work on it without things breaking...

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

#56

Post by bobmaxup »

thorncorona wrote: post #42
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…

I like long simple functions because it makes them easy to reason about when debugging. Rarely does having more functions solve “does this do what I expect.”

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 through a deeply modular code base it can quickly become difficult to keep track of anything.

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

#57

Post by dang »

Related:

Why bad scientific code beats code following “best practices” (2014) - https://news.ycombinator.com/item?id=12377385 - Aug 2016 (261 comments)

Why bad scientific code beats code following "best practices" - https://news.ycombinator.com/item?id=7731624 - May 2014 (168 comments)

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

#58

Post by cnewey »

While I think there are a couple of valid points, in general my feeling is that the author is setting up a straw man to attack.

Most of the “programmer sins” are of the type that more seasoned engineers will easily avoid, especially those with experience working with scientific code. Most of these mistakes are traps I see junior developers falling into because of inexperience.

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

#59

Post by cjfd »

galaxyLogic wrote: post #47
__loam wrote: post #28

Earlier quoted context omitted.

There's a happy middle path here I think. Long functions are hard to grok. Spreading the logic across 20 files also increases cognitive load. There's a balance to strike.

Right, but the article seems to imply that all code should be in a single file. It seems the author indeed is not a SW Engineer and thus does not really grok the benefit of "modules". This of course depends on the size of the program. Small program "fits" into a single module. And I think that scientific programs are basically small and simple because they don't typically need to deal with user-interaction at all, th…

"It seems the author indeed is not a SW Engineer".

This is a pretty ridiculous notion if you just cursorily glance over the page. It is quite clear that this guy is more of a software engineer than most with that title will ever be. Hint: a blog that contains a post with a title like 'Coroutines in one page of C' is a software engineer.

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

#60

Post by locallost »

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…

To be honest it's mostly not their fault. Most people want to do the right thing and that's what they're taught. Doing things differently is frowned upon, and most people don't want to stick their neck out and say the emperor is naked.

Recently at work some people argued "things" (methods, classes, even files) should have a limit in size. I think that's valid thinking because you want to strive to having smaller components that you can reuse and compose, if you are able to do that. But what happened is that people started creating dozens of little files containing a function each and then importing those. To be it's obvious that this is now a lot worse because the complexity is still the same, just spread out across dozens of files. But most people were somehow convinced that they're "refactoring" and that they're doing best practices of keeping things small.

Post reply on HN