Fortran (Was: The "does Python have variables?" debate)

[Chris Angelico]

On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola <rtomek at ceti.pl> wrote:
> Given that Fortran is here for almost 60 years and lot of effort has
> been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
> breath. Something may look like cool and great, but wait ten years and
> see if after major language revision you can still (more or less)
> easily run your existing huge projects with it.

The Unix pipe system is still working beautifully, and will continue
to do so for the next few decades. Build your system as a number of
separate processes that pipe data from one into another, keep your old
interpreters and compilers around, and you'll be fine.

But retaining that backward compatibility is a huge cost. Sixty years
ago's hardware wasn't the same as we have today. You can't simply run
the exact same compiler and get the same bytes of output and run them.
Someone has to maintain that old compiler, make sure it works with the
latest toolchain and hardware, etc. Probably make sure it's
bug-for-bug compatible with the original, too. How long do you want to
keep that up? It's a huge trade-off.

If a language basically says "That code you wrote two years ago? Not
gonna work now", then I'd see that as a big blinking red light. But
"Ten years ago's code will probably work on today's interpreter,
unless it uses as identifiers what's now a keyword, or it might be
unintentionally treading on now-fixed bugs in which case it might have
to be fixed", that's not as big a problem. Yes, you'd need to 2to3
that old Python 2.3 code to get it to run on Python 3.4, but chances
are it'll run mostly-unchanged on 2.7 (modulo string exceptions,
maybe). I'm cheating a bit by citing Python 2.7, given that it's now
four years old, but it's also going to be supported for a good few
more years. Not sixty, presumably, but a good while.

ChrisA