Post #1928613

@rupdecat On a happier note, I'm working somewhere else in possibly the best environment I've ever been in doing work that I love. Even the awful parts like trying to modify research-grade R code to run in a controlled production environment under a strict software QA program. You don't really see the value of modern C++ and Fortran code until you try building and deploying R or Python code in this sort of HPC environment. Having a single statically-linked executable file simplifies so much - no complexity of containers, no dependency pinning, no interpreters changing every few months. As a bonus, compiled codes are fast. Performance is the least of my concerns; making sure our engineering tools are dependable, easy to run, and qualifed for safety use is my main goal. So many of these tools originate in academic environments where industrial-grade software QA is basically unknown. Everyone gets a very rude surprise when research-grade code finds its way into safery-related industrial use. Problems would be mostly avoidable if there was a good way to communicate industrial requirements and practice back to labs, RSE is a good step toward that but in the end, research orgs don't work under the same standards and regulation and incentive structure as we do and it's not clear if better communication would make any difference. Software QA suffers from problem that its benefits are invisible - nobody sees the papers not retracted, the accidents that didn't happen, the work avoided because the code was dependable and trustworthy.