Backwards compatibility in different programming languages

They see code as in LAPACK and associate this with Fortran. Even enforcing the 2008 standard allows to write code that fits on a punch card.

I didn’t say that compiler vendors should not support compiling old code. I just say that it would make sense if old code is compiled with a compiler or a compiler flag for old code while new code needs to be compiled with compilers for newer code. Speaking in terms of the example: If you want to use an old screen with VGA connector, go ahead and attach it to your 2000s PC. But don’t expect that your 32" 8K screen supports it. This is because the screen industry realized that sticking old standards hampers progress.

The Fortran attitude of “write once, compiles forever” gives IMHO the wrong impression that code ‘just’ needs to run. In reality, it needs to be adopted to new requirements. Again, LAPACK is the prime example:

  • on a modern monitor, there is space for speaking names and the restriction to cryptic, 6-letter long abbreviations is not needed.
  • letting the compiler check whether one calls a routine with the right arguments is less error prone than cross checking manually with the documentation.
  • checking for EBCDIC encoding (see Resistance to modernization)
  • not to miss the obligatory implicit none: saving a few statements might have been beneficial for punch cards, but explicit is better than implict does not only hold for Python.

I totally agree that LAPACK is still useful, but it would be much more useful if it would have been modernized. In my opinion, continuous modernization is the best approach because it divides the work in small, manageable packages. An evolving standard that is always based on the best approach known at the time of writing instead of sticking to old approaches that have been proven wrong supports IMHO this modernization process.

3 Likes