My experience with academic code is that it's all ad-hoc software that's written to solve a single problem for a single paper. Once the final draft of the paper is peer-reviewed and published, there is no longer any reason to ever touch that code again.

From a practical standpoint, why invest in future-proofing your code if it's going to be thrown away once the current paper is finished? No need to make the code readable for the next author, no need to document it, no need to make your code non-monolithic because you're never going to build on top of it later.

On top of this, they were never educated and trained as software engineers. If you're lucky, they may have a pure CS background (and some of the worst code I've seen has been written by academic CS people who are explicitly not software engineers), but most likely they come from various academic disciplines that don't teach how to write code.

I used to work at an academia-focused NLP company, and while they did have some well-structured long-lived projects that we used across several projects, there were also large piles of code that you can tell were just intended to be used once and then forgotten about.

This also reminds me of the way Japanese console developers, such as Squaresoft, used to treat their source code in the '90s. Once the game shipped, they would just wipe the source code from their hard drives and their backups to save space. Hey, it's a pre-2006 console game, it's never going to get patched after release, and this was long before the nostalgia bug bit and publishers realized there was money in porting old games to new platforms. Hey, if you believe that code is only ever going to be used once, you are going to treat it as throwaway code, and that includes actually throwing it away at the end. As a result, many later ports of '90s console games were remade from scratch, consist of old ROMs running in an emulator (sometimes romhacked if the game had never been translated before, like Trials of Mana), rebuilt from a third-party port of the game, or if they're really lucky rescued from early beta code stored on an old computer they forgot to wipe (this is how the FF7 PC version got made in fact). There was a Twitter thread recently, and it's absolutely fascinating.

Why would scientists write good code with documentation if it is not recognized for their career?

I was talking about scientists who switched from science to writing software as a product for whatever reason. They surely produce good docs (properly documenting their work is the very basis of being scientist).

As for writing imperative code in C/C++/Whatever other language they seem to choose: nothing is wrong with that.

You're basically saying scientists can become good programmers if they become professional programmers. Of course they can be, and I doubt anyone would argue that. Some of the best programmers I know have zero college education at all, so of course it's possible for mathematicians and scientists to do the same.

But that isn't anywhere near the point of the article. It's talking about scientists that did NOT switch to writing software professionally, but continue to write it merely as a tool to accomplish their primary scientific goals.

"...It's talking about scientists that did NOT switch to writing software as a product, but as merely a way to accomplish their primary scientific goals. ..."

Sure, for this they would do what is just enough to solve their specific problem. Just as ANY sound business would do.

But the point of the article is that this isn't sustainable. If the person who wrote it leaves, or if they need to do a similar task later, or another lab is doing similar work, all the effort will be repeated. It would make a lot more sense for the community to invest in more open source tools that generalize to cover more research domains.

Writing medium-sized amounts of imperative code is wrong if it is going to be shared with any other person than a single developer writing it. And even if only a single person will ever see it, you are still better off writing it in components once the project reaches a certain size.

I don't agree.

There's nothing inherently wrong with writing imperative code, and being imperative doesn't imply the code isn't broken up into components or that it's necessarily difficult to maintain.

Imperative programming and components are 2 different things. The latter could be implemented with numerous approaches including imperative programming

That's true, but when someone mentions writing something in an "imperative style" I think it's common for that to actually just mean one huge file that executes sequentially which is not amenable to testing, having someone else working on a different part of the code without running into lots of merge conflicts, makes it very hard to refactor, etc.