I client of mine still has a fairly large piece Delphi of code in production and I must say it's a bit of a liability for them. An example of a technical problem they face is getting the particular version of Delphi they use work with TLS (and that's becoming a problem now as everyone's starting to disable SSLv2 & SSLv3). The fact is that they simply wouldn't face this kind of problems if they have ported their code to something like Python, C# or Java.
On the non-technical side of things, they also struggle with hiring developers who are capable of (or willing to) work with Delphi, especially junior developers. A significant portion of their staff also doesn't know how to work with Delphi, so reassigning resources to match the needs of the business is often a challenge.
I imagine these issues would probably apply to Fortran as well.
Fortran is entirely modern. Last standard is what, 2008? And any compiler will just eat any previous version without complaint. You can take a huge swath of '77 code, put some 2003 and 2008 in there, and it will all just compile.
Python? Good luck. Every frigging month (practically) it's a breaking change. You have to work furiously just to keep your infrastructure working, or purposefully draw a line in the sand (2.7!).
I run Fortran every day (via NumPy and other packages), and some of us are investigating just switching to it for some projects (we need the math speed, and all the C++ matrix libraries involve compromises of one form or another). There's no reason I and my peers wont be doing the same in 50 years. It works, its fast, its debugged, and it is easy to use things like Python 5000 (by then over 70% of people will have made the transition from 2.7 to the 3.x version!!!) to do all the glue work that Fortran is not optimized to do.
Fortran codes ain't ever going to be a liability[1]. Python 2.7 on the other hand...
[1] because of being Fortran. Poor coding style was endemic in Fortran77, and that can be crippling, but to a large extent that is language agnostic. I acknowledge the required short variable names of 77 doesn't help, but people would not comment what the variables mean, and that is the real problem (IMO). Poor structure is another problem (masses of gotos). Yes, 77 doesn't make your life easy there, but discipline is possible. We can quibble about all this; my point is the 'modern' languages are going to be old quite soon, and we will face real porting problems then. Move 20,000,000 lines of JS and Python? Good luck.... Get a Python 2.4 code base working with 3.9? Ah, hmm, well .....
But Fortran? We build it and run it every day, easy peasy.
Python? Good luck. Every frigging month (practically) it's a breaking change. You have to work furiously just to keep your infrastructure working, or purposefully draw a line in the sand (2.7!).
What? There was exactly one breaking point, from Python 2 to Python 3. Which "monthly breaking changes" are you talking about?
Probably not the language itself, but the quivering mass of libraries with moving APIs and bolted-on design fads. Numerics is numerics--functions, matrices, linear algebra and indexing isn't going to change any time soon.
That Fortran gets bashed and Lisp is worshiped seems quite incongruous.
I'm not a Python developer but what I've seen and find frustrating is the slow migration of libraries to Python 3. Some projects have switched to 3 and some are sticking with 2 for now. Some applications are using 2 because they have dependencies using 2, but as those dependencies switch applications have to deal with combining Python 2 and Python 3 dependencies.
I know each issue is easy in isolation, but we're talking about old 25M line codebases here. If such things exist in Python it can be a maintenance problem.
I'm in favor of languages making breaking changes occasionally but there is something to be said for languages like Java or Fortran that are intended to keep compatibility forever.
"There was exactly one breaking point, from Python 2 to Python 3"
One breaking point?
The majority of the libraries that I use don't even work properly in Python 3. The standard Mysql library for instance, which is used in the majority of ORMs (including SQLalchemy) isn't included in Python 3, which means you need to make major changes/try to use a different library.
The case of many standard libraries were changed, breaking lots of code. Example: ConfigParser to configparser.
Even simple things like print 'test' is now print('test')
These are only a few examples. There are lots of other major changes that break 2.X code.
I have been using Python 2.X for all of my projects and wanted so badly to change to 3.x for my new projects. However, because of all incompatibilities, I can't.
I don't think I'm alone on this either. Python 3.X still isn't being used by the majority of developers.
(we need the math speed, and all the C++ matrix libraries involve compromises of one form or another).
Are you using lots of really tiny matrices? I would think pretty much all the libraries could just be linked with a good BLAS distro and then it would not matter what language that you use. Personally, I'm a big fan of the Armadillo C++ library.
Delphi could be considered a proprietary language while Fortran has multiple standards. So tooling switches are not quite as big an issue.
Lifecycle of languages is a hard issue regardless of language. Unless you keep switching to the correct new shiny thing then you will have developer issues. I think their are a few more Fortran programmers than Delphi these days.
How is Python even being mentioned as a replacement for Fortran? That is like replacing C code with Python just because ...
Sorry I really love Python but I see it as a slow weighing beast that is always a good second best choice for everything it does. Great if you only know Python or only want to know Python but for production? Speed issues is the main reason why Python is not more widely used.
> How is Python even being mentioned as a replacement for Fortran?
Its probably being mentioned as such because a lot of the reason people use Fortran is because of key high-performance libraries for particular numeric application domains -- not because Fortran is necessarily the best language, aside from the existence of the those libraries, to express higher-level solutions in those domains. And because Python has convenient wrappers for those libraries, such that where that is the motivation for using Fortran, Python is a reasonable alternative.
> Speed issues is the main reason why Python is not more widely used.
Sure, and that's why you wouldn't (with the current implementations available) want to write the low-level numeric routines underlying NumPy in Python.
OTOH, once you have NumPy, a lot of time Python makes perfect sense as the language to use for higher-level solutions that rely on the functionality provided by those libraries.
The slowdown from using Numpy (or Octave or whatever) instead of Fortran can be anywhere from 100× to 1.0000000001×. It depends almost entirely on how much of your compute time is spent inside standard computations on large arrays. If your arrays are tiny, or you're doing irregular things to them and can't figure out how to vectorize them, figure 100×. But there are lots of Numpy programs that fire off a few dozen Numpy calls per second, so the bulk of the code executed is Fortran (or maybe C) in any case. The extra microsecond to interpret the Python bytecodes to fire off the call just isn't significant.
More typical is about 3× or 5×, due to iterating over the data many times (once per Numpy call) instead of once, thus bottlenecking on main-memory bandwidth.
Personally, I like to learn new languages, so I might be fairly biased.
But about 18 months ago, I took over maintenance of a small-ish Delphi application when the original developer left the company. It's not a super-fun language for me, but to me it was fairly easy to get into.
On the non-technical side of things, they also struggle with hiring developers who are capable of (or willing to) work with Delphi, especially junior developers. A significant portion of their staff also doesn't know how to work with Delphi, so reassigning resources to match the needs of the business is often a challenge.
I imagine these issues would probably apply to Fortran as well.