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

Research software code is likely to remain a tangled mess

shape-of-code.coding-guidelines.com

Post reply on HN
Print view View original

161–170 of 171 posts

Re: Research software code is likely to remain a tangled mess

#161

Post by unishark »

Bukhmanizer wrote: post #53
svalorzen wrote: post #3

I don't really agree with the reasons given, even though my conclusions are the same. The main reason why research code becomes a tangled mess is due to the intrinsic nature of research. It is highly iterative work where assumptions keep being broken and reformed depending on what you are testing and working on at any given time. Moreover, you have no idea on advance where your experiments are going to take you, thus…

As someone who has been on both the research and industry software end, there’s really not that much difference. Requirements change, you build that into your plans. Frankly, a lot of best practice software development that gets totally ignored by academia (e.g. OOP) can handle this exact case, and makes things way more flexible. If the problem was only unpredictability, then projects with a clear and defined end goa…

> As someone who has been on both the research and industry software end, there’s really not that much difference. Requirements change, you build that into your plans. Frankly, a lot of best practice software development that gets totally ignored by academia (e.g. OOP) can handle this exact case, and makes things way more flexible.

I've done both, and OOP can also make things worse. Now instead of just doing the calculations in a straightforward procedural fashion anyone who knows the research can understand, you've added a layer of structure to obfuscate it, and that structure may be harder to change if you guessed wrongly about what will be consistent and what won't. Research by its nature needs to be more flexible and will be more unpredictable than industry development. It is far more common to have to go back and reexamine even your most basic assumptions.

Of course a lot of researchers are doing the same things as industry (what should be described as development and not be getting research funding), and are certainly doing a much more amateur job of it.

Grant fraud is penalized severely in the US by the way. You can even get a bounty for reporting someone.

Re: Research software code is likely to remain a tangled mess

#162

Post by jonbronson »

I worked at a productive computing research institute for a number of a years. I cannot count the number of times I found research teams duplicating critical algorithms. Research Scientists not only pay the price of the spaghetti nature of the code, they pay it over and over again by not sharing and improving on what has already been built by previous research groups.

The software industry has its own share of problems, but from what I've seen the research community is still largely operating on an outdated software model that shuns open collaboration out of fear of being "scooped".

Re: Research software code is likely to remain a tangled mess

#163

Post by uhhhhhhhhhhhhhh »

realusername wrote: post #134
amelius wrote: post #119

Earlier quoted context omitted.

Makes you wonder why most languages don't come with good refactoring tools.

I don't think refactoring tools are that useful for refactoring, most of the time you are doing non-obvious refactoring tools can't help with anyways. Depends what we call "refactoring", tools are mostly useful for what I would call "housekeeping".

High confidence syntax-aware identifier renames will take you pretty far

Re: Research software code is likely to remain a tangled mess

#164

Post by mbreese »

hyperpallium2 wrote: post #109
SavageBeast wrote: post #70

I'm currently refactoring a fairly large piece of research code myself. It was written with lean startup thinking in that a little code ought to produce some value in its results. If i was able to eeek some usefulness out of this code, then Id put more energy into it. Otherwise I was perfectly happy to Fail Fast and Fail Cheap. How did it become such a mess in the first place? Simple - I didn't know my requirements w…

I like Brooks' "plan to throw one away; you will, anyhow.": This [first] system acts as a "pilot plan" that reveals techniques that will subsequently cause a complete redesign of the system. However, in practice I'm not confident enough in my understanding, and fear losing all that hard-won work, so I refactor too. A rewrite from scratch is probably more viable when the project is small enough to keep in your head at…

We are talking about research code here. And from many of the comments, it seems like the biggest hurdle is not understanding requirements the first time around. This is incredibly common.

I work in computational biology, and my normal thought process is that by default, you should expect to write the code three times (especially for less experienced developers).

The first time, you don’t know the problem.

The second time you’ve figured out the problem, but don’t know the best way to do it.

The third time, you’ve figured out the problem and a decent strategy to solve the problem.

With more experience, you can narrow that to just two iterations. But really, especially with research, you rarely have a good feel for the problem domain the first time around. And when you have the expectation that you’re going to throw the code away, you don’t get quite as hung up on implementation details for the first two rounds. And because of that, the process is easier. And you don’t have to worry about refactoring bad code. Just accept the first round as an experiment and take what you’ve learned about the problem to write better the next time.

Re: Research software code is likely to remain a tangled mess

#166

Post by hyperpallium2 »

titanomachy wrote: post #155
hyperpallium2 wrote: post #109

Earlier quoted context omitted.

I like Brooks' "plan to throw one away; you will, anyhow.": This [first] system acts as a "pilot plan" that reveals techniques that will subsequently cause a complete redesign of the system. However, in practice I'm not confident enough in my understanding, and fear losing all that hard-won work, so I refactor too. A rewrite from scratch is probably more viable when the project is small enough to keep in your head at…

Brooks has since amended this[1] to say that he really meant it in the context of traditional "waterfall" development, where the first iteration is meticulously planned and designed as a whole system before any code is written at all. Rapid, iterative prototyping, followed by refactoring, is a perfectly reasonable approach today. No need to create a fresh repository and rewrite all code from scratch. David Heinemeier…

wikiwiki seems to be having trouble moving to github. Here's wayback https://web.archive.org/web/20190821162524/https://wiki.c2.c... And the bit you referenced:

  "This I now perceived to be wrong, not because it is too radical, but because it is too simplistic. The biggest mistake in the 'Build one to throw away' concept is that it implicitly assumes the classical sequential or waterfall model of software construction."
You don't have to throw everything away. Like reusing libraries, you can reuse your modules, or whatever code you like.

It's the part that is a tangled Gordian Knot that is easier to cut than meticulously unravel.

"Starting with a clean slate" is a common idea in many contexts. One very similar to code is writing. You can hack and edit, but a fresh draft is easier (and safer) for fundamental conceptual and structural changes.

BTW "Waterfall" was a parody of processes, though the conceptual aspects (requirements vs specifications etc) are useful. People then were just as intelligent as today. Maybe more.

Re: Research software code is likely to remain a tangled mess

#167

Post by titanomachy »

hyperpallium2 wrote: post #166
titanomachy wrote: post #155

Earlier quoted context omitted.

Brooks has since amended this[1] to say that he really meant it in the context of traditional "waterfall" development, where the first iteration is meticulously planned and designed as a whole system before any code is written at all. Rapid, iterative prototyping, followed by refactoring, is a perfectly reasonable approach today. No need to create a fresh repository and rewrite all code from scratch. David Heinemeier…

wikiwiki seems to be having trouble moving to github. Here's wayback https://web.archive.org/web/20190821162524/https://wiki.c2.c... And the bit you referenced: "This I now perceived to be wrong, not because it is too radical, but because it is too simplistic. The biggest mistake in the 'Build one to throw away' concept is that it implicitly assumes the classical sequential or waterfall model of software construction…

I don't see waterfall as a product of limited intelligence but rather limited tools and history. It's natural that early software engineers would generalize processes from mechanical and chemical engineering, especially given the cost of iteration with early software tools.

Re: Research software code is likely to remain a tangled mess

#168

Post by marmaduke »

Bukhmanizer wrote: post #53
svalorzen wrote: post #3

I don't really agree with the reasons given, even though my conclusions are the same. The main reason why research code becomes a tangled mess is due to the intrinsic nature of research. It is highly iterative work where assumptions keep being broken and reformed depending on what you are testing and working on at any given time. Moreover, you have no idea on advance where your experiments are going to take you, thus…

As someone who has been on both the research and industry software end, there’s really not that much difference. Requirements change, you build that into your plans. Frankly, a lot of best practice software development that gets totally ignored by academia (e.g. OOP) can handle this exact case, and makes things way more flexible. If the problem was only unpredictability, then projects with a clear and defined end goa…

I work on a 12+ year academic (full stack Python) codebase, where there was an initial push for an OOP/DI architecture which was key to adapting to later grant requirements. The codebase is still evolving fine.

Re: Research software code is likely to remain a tangled mess

#169

Post by porker »

cryptica wrote: post #112

Math and physics are a tangled mess so it's not surprising that mathematicians and physicists write code which looks like a tangled mess. Mathematicians and physicists are trained to handle ambiguous concepts and they can work with weird abstractions which are far detached from reality. Unlike programming languages, the language of math is full of gaps - This requires the reader to make assumptions using past knowled…

Thank you. Having trained as a physicist, this matches my experience.

Re: Research software code is likely to remain a tangled mess

#170

Post by cdsousa »

gmueckl wrote: post #80
childintime wrote: post #22

Earlier quoted context omitted.

It seems Julia has the answer: https://arstechnica.com/science/2020/10/the-unreasonable-eff...

I can't quite follow what the article is trying to describe because of the heavy use of analogies. A Google search makes it look like Julia has a mechanism where you can extent the sets of overloads of a function or method outside the original module. The terminology is different (functions have methods instead of overloads in their speak). I don't see how that feature solves the problem in practice.

Julia multiple dispatch allows dynamic polymorphism.

Check https://stackoverflow.com/questions/1801216/what-is-the-diff... and https://www.youtube.com/watch?v=kc9HwsxE1OY

Post reply on HN