2 ms·

> How much are software engineers judged by the code quality? And how much by the end results (shipped features/projects)? Many differences: 1. Everyone can t

> How much are software engineers judged by the code quality? And how much by the end results (shipped features/projects)? Many differences: 1. Everyone can tell if the SW is doing what it should. Ensuring correctness in the long run can lead to seeing gains in maintaining code quality. With a lot of scientific output, many people will just trust the output of the program. Crappy code quality is not easy to perceive. 2. In many code bases, backwards compatibility is important. Hopefully you'll have many users. With most scientific computation code bases, the user base is tiny (often 1). So no one cares if you break something when you add a feature. Couple it with bullet 1 above, no one even notices if you broke something. With regular SW projects, the need for backwards compatibility can once again drive good SW practices. I'm not saying all Fortran programmers are bad. Just that it is very tolerant of bad ones, and so they are highly overrepresented. > I'm happy we have stable libraries for it. As someone who couldn't stomach Fortran, as far as numerical work goes, plenty of other languages can utilize those same libraries. Having stable numerical libraries is not unique to Fortran. In fact, a colleague wasted way too much time during his PhD taking his group's 40K Fortran code base and porting it to C++.

robocat 4y ago
> Everyone can tell if the SW is doing what it should I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody. > Fortran code base and porting it to C++ I once tried to counsel a PhD friend to use Mathematica to model their engineering problem, however instead she listened to other people in the civil engineering department to use C++, and she spent most of her time learning C++ and not enough time on her models.
- lmm 4y ago
  > I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody. Plenty of banks don't understand how their software works. But they can see that at the end of the day it calculates the right amount of money. (If it doesn't, eventually the client complains, or eventually your manager complains, depending on which direction it was wrong in). For a lot of these scientific modelling systems there's no such sanity check.

robocat 4y ago

> Everyone can tell if the SW is doing what it should I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody. > Fortran code base and porting it to C++ I once tried to counsel a PhD friend to use Mathematica to model their engineering problem, however instead she listened to other people in the civil engineering department to use C++, and she spent most of her time learning C++ and not enough time on her models.

lmm 4y ago
> I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody. Plenty of banks don't understand how their software works. But they can see that at the end of the day it calculates the right amount of money. (If it doesn't, eventually the client complains, or eventually your manager complains, depending on which direction it was wrong in). For a lot of these scientific modelling systems there's no such sanity check.