Coming from a more traditional CS background, I always thought that Fortran was archaic until I actually had to learn it for some scientific computing. I found it awkward to use, but at the same time, it had array capabilities that I've never seen in any other language.
The only thing I absolutely hated about Fortran for parsing data files is that, according to the standard, a text file has to end with what amounts to an empty line. Many Fortran environments break this rule intentionally, but occasionally you'll find one that follows the rules. It inevitably bites people who forget that their last line of data must be followed by a newline, or else the line may never get read.
[1]https://github.com/muellermichel/Hybrid-Fortran (I'm the maintainer.)
Good luck beating the performance of a Fortran optimizing compiler.
When I was at uni (10 years ago) I worked with libraries written in FORTRAN 4. Those that used F77 were ported only because it was necessary for use with the HP-FORTRAN compiler. The only F90 code in the department was my own.
You could always look at ratfor if you need to do a lot of character based stuff.
Back in the day I even wrote billing systems and a device driver for PDP's using fortran.
[1] http://home.comcast.net/~urbanjost/CLONE/KRACKEN/krackenhelp...
--
Do a little research into COBOL and a few interesting things jump out at you. Some of this information is from Gartner Group and the rest can easily be verified by doing even a brief survey of the field. Taking the following bits of information:
* 75% of the world's business data passes through COBOL (Gartner Group estimate)
* There is possibly up to a fifth of a trillion lines of COBOL code out there (Gartner again)
* People are still writing COBOL constantly, but usually on existing systems.
* The industry is struggling to find new COBOL programmers because few young programmers love the thought of maintaining decades-old enterprise systems where all data is global and GOTO is often the first choice in flow control.
* Many companies want to move from COBOL, but can't do so easily because too much code is written in COBOL (and the source is often lost).
People really, really underestimate these problems. For example, I've seen several companies express a desire to move away from Perl but find out they can't because they don't realize quite how reliant on the language they are.
Now imagine a multi-national corporation with several million lines of COBOL code. What are they going to do?
COBOL salaries, from what I've seen, are trending upwards. Older programmers are sometimes being enticed out of retirement to maintain legacy systems (this is rather hit or miss as there appears to still be some age discrimination here). There are companies out there offering software to allow COBOL programmers to write NetBeans, integrate with .NET code or simply translate the COBOL into other languages (the latter appears to have mostly been a disaster, but I don't have enough hard data on this).
So let's summarize the above:
* Trillions of dollars flow through COBOL. * Trillions of dollars flow through systems that businesses want to replace. * Current mitigation strategies involve supplementing COBOL, not replacing it.
You come up with a strategy to allow COBOL systems to naturally migrate to a new language and you stand to make millions of dollars. By the way, I said "naturally". There are things like COBOL to Java translators (e.g., http://opencobol2java.sourceforge.net/), but COBOL is procedural and all variables are global. It doesn't even come close to mapping to an object-oriented paradigm (and any experienced OO programmer will understand why).
I actually have what I think is a decent migration strategy for COBOL, but that's a story for another day.
Dear Lord. The one area where age discrimination should rationally favor older programmers and they still get the shaft. How does that conversation go in HR?
"Here's a candidate who knows COBOL... but wait, he's over 60. Ewww, it's so depressing looking at old people [i.e., those over 30] who aren't management track. And we'd have to pay him good money to do something that isn't focused on giving orders to underlings. How yucky. Welp, guess that mission critical piece of software can wait."
Perhaps I've been channeling Michael O. Church a bit too much for my own good, but sometimes it looks as though he's nailed it.
The reason older workers are employed only grudgingly for vacant Cobol jobs is most of those jobs require after-hours standby support that older people generally don't want to do. Not wanting to be woken up at 3:00am anymore was why I left my last job doing such stuff. Younger workers are less likely to get a doctor's certificate saying they're no longer able to do standby work, soon after they're employed.
But he didn't say which way the age discrimination works. Are they only taking ancient programmers because "young people can't possibly have any experience on COBOL/Fortran-loving mainframes" or is it the more familiar form of age discrimination?
I'm a big fan of MOC's stuff as well, but just to give you one different datapoint... I'm pushing 40 (will be 40 in July) and I haven't seen any evidence of age discrimination yet. I did get laid off from a programming job about 2 years ago, but, to be quite honest, I had mentally "checked out" a good year or so before along with about half of the other stuff, most of whom left voluntarily or also got laid off. It was a shit job with shit management, and we all groused about it and start making it clear to management that we felt that way, so no big surprise there. OTOH, I had a new job lined up within < 8 hours of the layoff announcement. That goes mostly to the fact that I network a lot and knew exactly who to call, but still...
Now, working in a slightly different role as a traveling consultant type, as opposed to a "sit in the same office day after day after day working on the same product" I find that my age sometimes actually helps. I've been sent to help some of the younger consultants because, as my boss put it, the customer "wants to see somebody with some grey in their beard". And, unfortunately, a little bit of grey is starting to show in my beard. :-(
Anyway, it's just one bit of anecdotal evidence, and I don't mean to claim that age discrimination doesn't happen. But it's definitely not universal. At least in the Raleigh / Durham, NC area.
A significant percentage of Freshers joining Indian it services companies like Infosys,tcs etc (who maintain such legacy systems) are trained in COBOL.
I'd say that's an underestimate. You can make huge sums simply by knowing COBOL + having financial expertise. If you can actually migrate COBOL systems in a natural way that's likely a multi-billion dollar problem at this point.
From what I've seen (somewhat limited honestly) it's less "writing" and more like "patching". Minimal maintenance features like adjusting tax rates, accepting 4 digit years, updating country names etc. I wouldn't even call them minor features enhancements, more like routine maintenance.
Yeah, almost all of those 5 billion new lines are first copied from those existing 200 billion, then patched.
My last job had a big system where they wanted to enable a new country to be processed. The IT staff started to analyze how to modify it, but an executive for the user department gave the order: "Copy the entire codebase of the existing system, add XYZ- to all the program names, then make the changes". No-one dared disobey. Happily the existing codebase wasn't impacted, but there was now twice as much maintenance, operations, and standby support to do. I'm guessing that executive's gone now, and maybe the systems are now being supported overseas.
To complete the installation required me to choose from one of several current and compatible fortran compilers even.
So at least for fortran, the answer is scientific computing.
Part of the reason is that Fortran passes arrays by value, while C passes them by reference. It's very hard for compilers to optimise a pass-by-reference array, because it might have the memory altered by another part of the program. If it's pass by value, then you know it's safe. It's kind of like threads vs messages.
I think C has some recent work done to close the gap, but even if it's already as fast, it will take a while to port 50 years of legacy numerical code.
Actually, the reason is that Fortran arguments may not alias (passing big arrays by value would be horribly inefficient).
Btw, one of the main goals of C99 was making C a better language for numerics (ie catching up to Fortran): The restrict qualifier was introduced (mainly to mark non-aliasing parameters) as well as complex numbers, variable-length arrays and type-generic math functions.
Is it dead and buried at this point?
I threw out the box to Turbo Pascal only a decade ago.
Completely agree witht he product being mis-managed; it's still viable if they'd only make it competitive...
Oh, and lots of scientific computing is done in Fortran - eg. the sorts of work my brother does on atomic structure as a computational chemist at ITU, running on grid or supercomputers.
On the flip side, there's lots of very large, poorly documented programs which are effectively "mission critical" Fortran. Until someone ponies up a LOT of money to re-write and revalidate them, Fortran ain't going away.
This isn't a discussion-type topic. It's a question that has a non-subjective answer that doesn't depend on one's opinion. That being said, it might be migrated to programmers.SE and now that the question made it to HN the mods might notice it and actually do so, but I hope they won't.
A few points, when I was in school and that was only 5 years ago, I learned Fortran. I learned it because I was starting as a Mechanical Engineer, and one of the heat transfer classes involved solving differential equations via programs. If you wanted to get help from the egg head professors you had to take Fortran because that's what they knew. The Fortran class was Mechanical Engineers and Nuclear Engineers. I believe we were working in Fortran 77 & 90.
One of my friends from college is working on his PhD in physics. He spends his summers and breaks in Los Almos labs, and uses particle accelerators. Anyway - he told me that they use Fortran for their calculations purely because it was easier to translate to the language and it's all math.
Anyway that's just my $.02
For the companies that hired him it was cheaper than changing that equipment, and by cheaper I mean the guy was able to buy an Hacienda with what he made coding Cobol, nuff said.
And this appropriately grumpy rebuttal from a JPL guy to the 2004 "Petition to Retire Fortran" makes some good arguments for not retiring it (and also gives some Ada love): http://www.fortranstatement.com/Site/responses.html
There is a huge amount of COBOL / RPG processing flat files to do various financial transactions. It works and has worked for decades, so not many folks really have the willpower and cash to rewrite it.
... yup, people buy new COBOL software even today.
PS: I won't have to touch the thing, thank god. I made it pretty clear to my boss I would rather find a new job than to dedicate myself to supporting this monstrosity :)
