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

I agree with the feelings of the author, most software is overengineered (including most of my software).

That being said, most scientific code I've encountered doesn't compile/run. It ran once at some point, it produced results, it worked for the authors and published a paper. The goal for that code was satisfied and than that code somehow rusted out (doesn't work with other compilers, hadn't properly documented how it gets build, unclear what dependencies were used, dependencies were preprocessed at some point and you can't find the preprocessed versions anywhere to reproduce the code, has hardcoded data files which are not in the published repos etc.). I wouldn't use THAT as my compass on how to write higher quality code.

numerical code isn't like application code. the rules of application code don't always apply. for example, i think one character variable names are totally fine if they come from equations or papers where in most applications it's generally frowned upon.

this is why i'm a little skeptical of languages that blur the lines. sometimes ideas from application programming can complicate numerical code and sometimes numerical programmers don't fully understand the systems abstractions they're building on and end up reinventing wheels to avoid simpler solutions they feared or didn't know existed.

the moral of the story is to keep an open mind, to not be a zealot and to avoid dogmatic thinking.

For every well-engineered application used by millions of users, you've got thousands of poorly-engineered, bespoke applications in use by one or two users (often internal corporate tools or expensive middleware with minimal customization besides changing the corporate branding).

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, they just need to calculate a result.

Further I think scientific programs rely heavily on existing libraries, and writing a program that relies heavily on calls to external libraries produces simple, short programs.

Scientists produce science, engineers produce code-libraries.

I'm not so sure that this claim is valid as a general observation.

Multiple times in my career, I have seen scientific code written by academics dramatically sped up by developers who used parallelisation, vectorisation using SIMD etc.

So in terms of performance, naively written scientific code is generally easy to beat in terms of performance for a reasonably adept programmer.

That said, "enterprisey" Java/.NET software engineering shops can indeed make scientific code sub-optimal sometimes. Have come across that sometimes too but I wouldn't generalize.