State of the art doesn't necessarily mean React. Just something with unit tests and more than one giant 5000 line file.

If the requirement is that it lasts 30 years, you can choose more timeless languages like C, over say Rust.

I guess a better word for that might be "not terrible" :).

And yes, way too much research code reads like somebody's first coding project.

I'm not convinced of that. Because what I've seen (several times) on a somewhat small scale perhaps, is someone's code, sometimes written decades ago, never maintained upgraded or properly developed used for years on a system and eventually it gives out, forcing basically a rewrite. And state of the art can mean different things for differently scaled projects.

I've certainly had to resurrect research code written 10+ years before I got to it. It's usually not too hard as long as it's in C/C++/Fortran and doesn't have too many dependencies. Something like Matlab, on the other hand, is often a nightmare...

You have too look at the big picture though. How much time would have been needed to train the PhD student (might have been even the PI) to write more maintainable code 10 years ago, and maintain that code to "best practices" over the time, compared to write that it works once and need to rewrite once after 10 years?

Moreover, people tend to forget that scientific software evolves much more slowly than commercial software and the number of people who work on this are much fewer, so why always adopt the newest method, if the code is still working. Show me commercial projects that have had the stability of something like LAPACK or BLAS, those essentially had a stable API for > 50 years now, with very few bugs.

It's okay for things to start off rough, especially depending on the context. But there's often not much excuse for things to be taken seriously and evolved.

But to be honest, I've seen this in industry as well from software developers. So maybe it's just a law of software development that's amplified in scientific software.