Hacker News new | ask | show | jobs
by bayindirh 20 days ago
Developing scientific software is disproportionately hard though. Making it usable, useful and keeping it updated is even harder.

There's two reasons for that. The math is generally very unorthodox and alien for a seasoned developer, and software development practices are equally alien for the scientist who can understand and evolve the math behind it.

I have written a boundary element method evaluator for my Ph.D. not only math was alien, the required coding techniques for making it fast is very different for a standard developer. You have to have the perseverance and interest to do that. I chose that path intently and I do not regret a millisecond of it.

The problem is, if you don't have a dedicated team to continue that codebase (e.g.: like the Eigen team), your code is basically done and done. If somebody doesn't share the same passion, it's almost impossible for someone to take and carry it forward.

Oh, due to the math and optimizations, the code's structure need to be both documented and the next batch of developer(s) have to be tutored by the person who's giving the code to them.

2 comments

In some fields the scientific software is actually simple, no crazy math. But rather than esoteric math knowledge there are say baked in assumptions and context from the domain that is hard to gleam from the outside without steeping yourself in the field to the point you might as well earn a PhD from it. And of course the same issues where there is no funding for long term support. Not necessarily as big an issue as with general software on that though, because the tools are generally complete in the “does what it says on the tin” sense, no new features are planned nor needed per say, no security considerations, it is probably written in a decades old language that will be around for decades still, etc.
> If somebody doesn't share the same passion, it's almost impossible for someone to take and carry it forward.

True, five years ago.

The advent of coding agents has changed everything, and often make modifying somebody else's bespoke software practical

If your software is CRUDe or has many alternatives/examples on the web, altering it with an LLM is easy, since the model already knows what you're working on.

When the math you're working on bespoke, and the optimizations you do are intricate, these models and agents fall flat on their face, because there's no "a set of widely used optimizations" (i.e. an open repository of very nicely optimized code for cases X, Y and Z) to apply on top of the codebase.

By bespoke, I mean, there's only one academic paper written about it, and it's written by me and my supervisor.