4 ms·

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 proble

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.

baldfat 11y ago
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.
- dragonwriter 11y ago
  > 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.
  - baldfat 11y ago
    You are looking at a ten fold slow down to use Numpy. This is a extremely time sensitive software. Mentioning wrappers even adds to the over head. Here is NASA's benchmarks using Fortan vs MATLAB vs Numpy vs Java. pretty evident that Fortran blew everything away. https://modelingguru.nasa.gov/docs/DOC-1762 https://modelingguru.nasa.gov/docs/DOC-1762
    - kragen 11y ago
      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.
protomyth 11y ago
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.
RogerL 11y ago
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.
- icebraining 11y ago
  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?
  - anthony_d 11y ago
    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.
krylon 11y ago
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.

baldfat 11y ago

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.

dragonwriter 11y ago
> 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.
- baldfat 11y ago
  You are looking at a ten fold slow down to use Numpy. This is a extremely time sensitive software. Mentioning wrappers even adds to the over head. Here is NASA's benchmarks using Fortan vs MATLAB vs Numpy vs Java. pretty evident that Fortran blew everything away. https://modelingguru.nasa.gov/docs/DOC-1762 https://modelingguru.nasa.gov/docs/DOC-1762
  - kragen 11y ago
    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.

protomyth 11y ago

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.

RogerL 11y ago

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.

icebraining 11y ago
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?
- anthony_d 11y ago
  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.

krylon 11y ago

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.