Hacker News Reader

Comment by supergreg | Hacker News Reader

What about not spending time and money and just keep using python 2 for software that already uses it. And only use python 3 for new code bases.

View on HN

This is how you end up still running fixed-format Fortran code in 2016.

If your software is being actively maintained, it's time to move to Python 3.

And the differences between F77 and Fortran 2008 are monumental. It's like they're 2 different languages.

This is how you keep using those efficient, numerically-stable subroutines written by a smart guy who retired 20 years ago in your new code. Unlike Python, Fortran has managed to add significant new features without breaking old code.

Unlike Python, Fortran hasn't seen an increase in usage and hasn't brought the joy(?) of programming to thousands of new programmers in the last 10 years. So sticking to Fortran or backwards compatibility blindly doesn't solve all the problems, either.

Maintenance is key. Most people don't stick around for 20 years anymore either. I know I'm going to have an easier time finding a new hire for a Python codebase. And he's going to have a far better chance at understanding said codebase. Code which nobody knows how to maintain will hurt us either with a fiendish bug, or limit out growth. So for me, slowly moving away from legacy stuff is good business value in the long run.

Remember, you can never be sure that Fortran code is 100% bug free. The test of time is as good as any other test, but not perfect.

Fair enough. But having worked with Fortran code that was designed in pen on yellow legal pads, typed in, and run on a suite of standard test problems chosen to expose subtle bugs, I have learned to respect an archaic engineering style of which few people are capable nowadays. Sometimes code is essentially "finished;" you'd be amazed at how rarely it has bugs. It should be changed only with care and for good reasons, not because the programming language changed to conform to some new fad.

(FWIW, I'd probably write most new numerical code in Julia rather than Fortran 20xx, and either call into existing Fortran via FFI, or drive it from the command line with some scripting language.)

> Unlike Python, Fortran hasn't seen an increase in usage and hasn't brought the joy(?) of programming to thousands of new programmers in the last 10 years.

SciPy has Fortran code under the hood: https://github.com/scipy/scipy/search?l=FORTRAN&utf8=%E2%9C%...

Both SciPy and NumPy use LAPACK - a Fortran library. SciPy also uses BLAS - another Fortran library.

So every time you praise Python for being useful for scientific work, you're actually praising Fortran and C libraries/modules wrapped in Python.

Reply on news.ycombinator.com