The article seems to assume that there is something "wrong" with running on 25M lines oF Fortran. It does not provide any technical reason why Fortran is not the right tool for the job. Why does this need to be "Web 2.0"?
This is just my experience with it. Somewhat to my surprise I really ended up liking Fortran, and the new code doesn't look at all like the old code. For what we did it was also slightly faster than C. If I were to write a numeric program I wouldn't think twice about what language to use. I feel like Fortran is an undervalued language for calculations. But then again, I am by no means an expert.
Now, if Bloomberg's code is a spaghetti monster (I have no idea), that is a problem. But that is a problem of legacy code, not a 'Fortran' problem.
I think it is a bad article based on hearsay by one ex-bloomberger.
This I think is the key point: lots of time when I've seen people mistake a practices problem like this (that result in expensive-to-maintain "legacy" code) with implementation language problems, they end up doing a conversion to a new language (often doing the worst thing you can do with a poorly specified, poorly documented, but basically working codebase, a "big-bang" replacement rather than an incremental one) without fixing the process issues, and so end up creating a new poorly-specified, poorly-documented, often less-well-working "instant legacy" codebase that just happens to be in a currently-fashionable language.
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.
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.
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.
What? There was exactly one breaking point, from Python 2 to Python 3. Which "monthly breaking changes" are you talking about?
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.
That Fortran gets bashed and Lisp is worshiped seems quite incongruous.
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.
"Gurer jnf rknpgyl bar oernxvat cbvag, sebz Clguba 2 gb Clguba 3"
Bar oernxvat cbvag?
Gur znwbevgl bs gur yvoenevrf gung V hfr qba'g rira jbex cebcreyl va Clguba 3. Gur fgnaqneq Zlfdy yvoenel sbe vafgnapr, juvpu vf hfrq va gur znwbevgl bs BEZf (vapyhqvat FDYnypurzl) vfa'g vapyhqrq va Clguba 3, juvpu zrnaf lbh arrq gb znxr znwbe punatrf/gel gb hfr n qvssrerag yvoenel.
Gur pnfr bs znal fgnaqneq yvoenevrf jrer punatrq, oernxvat ybgf bs pbqr. Rknzcyr: PbasvtCnefre gb pbasvtcnefre.
Rira fvzcyr guvatf yvxr cevag 'grfg' vf abj cevag('grfg')
Gurfr ner bayl n srj rknzcyrf. Gurer ner ybgf bs bgure znwbe punatrf gung oernx 2.K pbqr.
V unir orra hfvat Clguba 2.K sbe nyy bs zl cebwrpgf naq jnagrq fb onqyl gb punatr gb 3.k sbe zl arj cebwrpgf. Ubjrire, orpnhfr bs nyy vapbzcngvovyvgvrf, V pna'g.
V qba'g guvax V'z nybar ba guvf rvgure. Clguba 3.K fgvyy vfa'g orvat hfrq ol gur znwbevgl bs qrirybcref.
Is there some reason you ROT13'd it?
I rot13ed it in case there's a dead-comment-reposting-killing algorithm on the loose.
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.
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.
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.
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
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.
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.
Most Fortran hate is actually F77 hate.
Fortran 90, on the other hand, is basically C with a different syntax. F90 (and newer: F95, F03, F08) really isn't a worse language than C, and there's no reason to hate on it when you wouldn't hate on C, but a lot of people don't know it exists because they equate Fortran with F77.
Do you know FORTRAN? Do you know any programmers who know FORTRAN? Do you know anyone who wants to learn FORTRAN? Unless you're in the community the answer to all of those is no. And I can't imagine it's a big or growing community. The obvious consequence of this is FORTRAN will become more and more expensive to run a business on as time goes by because fewer and fewer people will have experience with it or any desire to use it. It's going to be harder to find people to port it and even harder to find people to maintain it.
That's why it's a problem.
If you know SQL or anything about databases SAS is very easy to pick up. My background from University was Java and C I had few difficulties.
My House-mate is a statistician he works in finance and uses R my understanding is R is a bit more difficult as it doesn't have anything like SAS's Proc SQL never used it myself though.
Coincidently Fortran is used very heavily in models here as well.
As to it becoming "more and more expensive to run it", that kind of depends. Most of that Fortran code isn't touched very often. The cost of swapping it out is huge.
Swapping it out piecemeal isn't as expensive money-wise, but it carries large risk. Should it be ported out? Sure. Can it be, in any reasonable way? That's a harder question, and it's not as cut-and-dry as you make it sound.
a little
> Do you know any programmers who know FORTRAN?
many
> Do you know anyone who wants to learn FORTRAN?
many
> Unless you're in the community the answer to all of those is no.
Fortran is still widely used in mathematics and science. So if that's the community bubble you're referring to, then yes, there's definitely a niche there in my experience (but not purely for legacy reasons).
There are a million different versions of the same function each with a minor tweak to get the "right" behaviors labeled func_name_1 down to func_name_1000000 because everyone is too scared to fix the original function as they don't know what depends on it.
It's not that Fortran is the right tool for the job it's that it has terminal momentum.
> There are a million different versions of the same function each with a minor tweak to get the "right" behaviors labeled func_name_1 down to func_name_1000000 because everyone is too scared to fix the original function as they don't know what depends on it.
Sounds like a problem with development practices, documentation, and overall code lifecycle management -- and also employee management in terms of skill development priorities.
Those issues aren't particularly tied to implementation language.
Fortran code isn't inherently technical debt, any more than code in any other language is.
> Do you still have a VCR? Isn't it a bad idea to assume VHS is a good medium to archive?
I fail to see the relevance of the analogy; its not exactly as if there is a shortage of -- F/OSS and commercial -- Fortran toolchains maintained and available.
Sure, you may be able to find tools to use Fortran in the near term. But how do you protect the future. Does it play well with emerging systems/protocols? Do you have developers to maintain it? Is there a clear path to upgrade to newer platforms and frameworks?
My own take on that was: "Wow, they surely must do a lot of performance sensitive stuff to use the fastest language available for number manipulation. Kudos to them."
More concerning is the bit where the author says that they have "1500 coders firefighting, just keeping that legacy monster alive."
I wonder if that has gotten any better since 2006.
There may be challenges getting the talent you want with legacy systems and I believe you're building a technical debt as you'll hit a wall with your infrastructure and have to upgrade/migrate one day anyway.
The top comments on this posting are ex-employees talking about how they've been migrating many (most?) parts of the system to C++, so yeah, even Bloomberg management agrees staying on FORTRAN is probably a bad idea.