What are Fortran and Cobol used for today? | Hacker News Reader

What are Fortran and Cobol used for today?

stackoverflow.com

I believe we should think of Fortran as a domain-specific language for handling multidimensional arrays, rather than a normal programming language. It might be terrible for other things, but it's great for array computations, and that's what people use it for in big simulations. Since it has a well-defined C FFI nowadays, it's easy to connect it to other languages that can do other things (parsing data files, etc.).

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.

Given the right tools[1] you can have as much templating/macro support as in C++ while keeping everything both performant and user friendly. The key here is to wrap Fortran in script languages to make it do exactly what you want.

[1]https://github.com/muellermichel/Hybrid-Fortran (I'm the maintainer.)

> while keeping everything both performant

Good luck beating the performance of a Fortran optimizing compiler.

Why? Any objective reason?

One thing that for years made Fortran stand out is that the language explicitly assumes all arrays passed in to a subprogram have no overlaps.

Thus a Fortran compiler doesn't have to do anything special to make sure it preserves order when storing and accessing from two different arrays. Therefore the compiler can be much more aggressive about unrolling loops and changing the order of operations.

By contrast, given a loop like

  for( i=0; i<N; ++i ) {
    y[i] = 2*x[i];
    }

a C compiler has to assume that y[i] might be the same memory location as x[i+1], for example. Thus it has to ensure that the load into y[i] is complete before accessing x[i].

This is one reason you see a lot of C code that does numerical work hand-unrolled, with explicit stores, like this:

  for( i=0; i<N; i+=4 ) {
    xi = x[i];
    xip1 = x[i+1]; xip2 = x[i+2]; xip3 = x[i+3];
    y[i] = 2*xi; ... y[i+3] = 2*xip3;
    }

Now that C provides the "restrict" keyword, a smart C compiler can do many of the same optimization tricks that Fortran has had since day 1.

One thing that for years made Fortran stand out is that the language explicitly assumes all arrays passed in to a subprogram have no overlaps.

There's a HUGE number of languages that don't allow aliasing in this way. I wasn't thinking about "how to improve C", I had APL, J, K, Q etc. in mind, as well as languages that implement mass array processing with similar semantics in terms of a more conventional syntax.

Fundamentally I agree with you. In my original comment, I was just trying to give a historical view of why people took the view that "optimizing Fortran compilers are hard to beat," rather than to defend it.

Personally, I think that idea is hard to justify these days, especially when, in my experience, finding 20-30% speed differences between optimizing Fortran compilers isn't all that hard.

That's a compiler flag in C and has been for ages. :\

I don't really get your post. I never said that I want to 'beat' the performance of x86 Fortran. This particular framework is designed to make Fortran GPGPU compatible while not loosing any CPU performance. It was used to speed up the next generation Japanese weather physics by 3.5x (compared to six core Westmere) doing exactly that.

My apologies, I misread your post.

I'm not sure by now the language's merits are the number one reason Fortran is used, but rather the amount of proven and super fast libraries for number crunching and array/matrix manipulation such as LAPACK.

It's the only language that has quality, actively-developed compilers, excellent support for multidimensional arrays and can be very effectively optimized. The libraries are a bonus, but support for proper multidimensional arrays (i.e. not arrays of pointers to arrays) in other widely-used high-performance languages it either crippled or non-existent. It's a bit baffling that something better hasn't come along, but I think the wealth of Fortran libraries and amount of work on compiling it would make it hard for a new language to get traction.

why is FORTRAN "terrible for other things" given that it has a lot of useful features for technical programming that more modern languages lack.

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.

Fortran's string support is optimized for easily logging or outputting the numbers you've just crunched. For everything else it's just way too clunky, which is CS people tend to move everything not very performance critical into non-Fortran wrappers. I find Python to be particularly well suited for that task. I've also found a nice and simple module to give Fortran executables a unix style CLI[1]. Putting all this together with GPGPU acceleration makes a pretty mean combination for scientific computations.

[1] http://home.comcast.net/~urbanjost/CLONE/KRACKEN/krackenhelp...

In general, I agree with you. However, modern Fortran also has a strong module system, and some nice looping constructs (like explicitly-labeled loops that let you control "breaking" and "continuing" in nested loops quite easily), that made me like using it for even non-array-oriented programs (for other reasons, I don't use Fortran so much anymore).

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.

Yep, I/O in fortran is kind of a pain. I really like the rest of the language, though.

The fancy array stuff (which honestly isn't anything particularly special these days) was added in F90. I can assure you that there's still F77 code being actively used in the scientific community.

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.

I was surprised to see when I installed R for the first time, that a large amount of the libraries it makes use of are written in fortran.

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.

Fortran is far from extinct, because scientists often prefer it to C/C++, and it's often faster.

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.

Some discussion here - http://stackoverflow.com/questions/146159/is-fortran-faster-... - my takeaway is it's possible to write numerical code in C in a way the compiler can optimize it, but Fortran does it by default, and the Fortran culture is about making numerical code as fast as possible.

Part of the reason is that Fortran passes arrays by value, while C passes them by reference.

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.

A lot of NumPy/SciPy (Python's scientific computation libraries) are written in Fortran too: http://docs.scipy.org/doc/numpy/user/install.html

Yup, mostly because they are the same libraries that R uses. I really feel like I may need to learn Fortran at some point, given its ridiculously good numerical capabilities.

Even matlab uses those libraries (http://en.wikipedia.org/wiki/LAPACK )

I actually think that LAPACK will outlive us all, as I can't see anyone ever rewriting (and re-testing) the software that essentially runs science (and a large proportion of "Big Data" approaches).

And, also Octave

I really like the top two answers.

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

Scaring baby programmers.

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.

My first programming experience was with FORTRAN (for a task that did not require any sort of high performance computing), and this scared me away from programming for six years. I realize the language isn't really to blame, but I'm definitely a little bitter.

And the main use of Python is scaring fogey programmers?

Python's main utility is finding who amongst your coworkers is incapable of giving attention to whitespace.

The best-paid freelance programmer I ever knew was a man older than my dad who was the only guy left in the country that could code Cobol for certain kind of industrial equipment.

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.

I cut my teeth as a professional developer in 1996 writing fortran77. We used it to test wire bundles on airplanes. Important stuff actually (unlike the Web apps most of us make today!)

This SO answer has interesting comments on Fortan performance: http://stackoverflow.com/a/13079021

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

I use Fortran every day for fluid dynamics research. Fortran is the abusive partner you keep going back to. If C had array operations and aliasing restrictions I would switch in a heartbeat. As it is the syntax "a=b" is a lot better than four nested for loops and hence 4 opportunities to fuck up the indices.

C99 added the `restrict` keyword http://en.wikipedia.org/wiki/Restrict

COBOL & RPG = your paycheck or the managing the bank account your money is in.

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.

I have a friend who is a physics major, one of the primary reasons he was learning to program was to use MPI & OpenMP languages, and presuming fortan has a very high performance / robust compiler for using MPI, this would probably be the soul reason it's used for large super computer & cluster computations because it's designed for distributed computation. I think this guy has the best answer: http://stackoverflow.com/questions/2266643/for-what-are-fort...

As an ex-COBOL programmer, I did some research in this area and I uncovered the following (from a 2009 blog post of mine).

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.

> * People are still writing COBOL constantly, but usually on existing systems.

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.

> COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually

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.

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.

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.

>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).

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.

> but wait, he's over 60.

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?

> The one area where age discrimination should rationally favor older programmers and they still get the shaft.

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.

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.

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.

"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."

A significant percentage of Freshers joining Indian it services companies like Infosys,tcs etc (who maintain such legacy systems) are trained in COBOL.

In the 2000s in college I was working with a gas turbine simulator written in FORTRAN whose file format reflected its origins as something using punchcards.

I used to script FORTRAN back when I was in nuclear engineering. I didn't know of Fortran's particular advantages other then that the software we used was built in FORTRAN and all our scripts to date that we used were built in FORTRAN and the general attitude in the uber-safe world of nuclear engineering is if it works, and works well, why in god's name would you mess with it :)

I work in a bank and we're currently looking for a new all-encompassing loan and leasing system. The primary candidate, from Sopra, is written in COBOL and runs on an IBM mainframe.

... 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 :)

I'm kinda blown away that this question hasn't been closed on stack overflow already. The mods are usually so aggressive about discussion-type questions.

(nota bene: I supplied the accepted answer)

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.

> protected by Pascal Cuoq 2 hours ago

Protection is ok. Whenever a question gathers that much publicity there are many who are not aware of how the site works and try commenting by answering the question with a comment. Which is unwanted on SO/SE. It doesn't prevent people from commenting, it doesn't take the question away, it doesn't prevent established users from giving a better answer, so I feel that's not as drastic as migration or deletion.

I have a friend studying meteorology who is learning Fortran. I believe it is still heavily used for weather systems.

I would guess all climate models and weather prediction models are in Fortran.

A friend of mine used to work at PG&E in San Francisco. He told me that there is an ancient server in the basement running COBOL code that no one quite understood, upon which was a hand lettered note to never touch that machine for any reason, ever.

I ran into someone who worked at the IT department at Mass Gen Radonc, and they use Fortran for the software delivering the radiation doses.

I just left a major UK retail bank where I was managing the remediation of their debit card authorisation system that was written in COBOL.

I loved the answer "Keeping older programmers rich ;)", to which someone wrote "You write that as if it were a bad thing!"

Where is the Pascal love?

Is it dead and buried at this point?

I threw out the box to Turbo Pascal only a decade ago.

I used to work someplace that used a lot of Delphi, but they made the top-down decision to standardize on C#.

Compared to Cobol and Fortran, Pascal always was a blip on the radar. Some success as a teaching tool (UCSD etc.), then DOS (Turbo) and Windows (Delphi) programming. Small niches, not that much of legacy code (especially if you can keep the database and just e.g. exchange the Delphi frontend with an ASP.NET one).

I used to be a member of the Association of Shareware Professionals (ASP), and Delphi was popular among small shops making Windows desktop applications. I never was a Delphi programmer, but it's adherents loved that it produced fast code with a small footprint. It combined a RAD environment let developers easily do low level coding when needed. When VB6 was canned by Microsoft, I think Delphi had an opening that they could have taken advantage of, but the various owners (Borland, Embarcadero) have always seemed to mis-manage the product. The latest Delphi has multi-platform support, but the pricing is still too high to get wide spread traction in my opinion.

I was always impressed by the Delphi Components ecosystem. There seemed to be a lot of useful code available at good prices - something I miss working as a web developer now.

Completely agree witht he product being mis-managed; it's still viable if they'd only make it competitive...

I took a few programming classes in Germany, and they were all taught in Delphi. It seemed to occupy the same place as VB does/did here in the US.

Physicists, or at least the ones I know, tend to use FORTRAN almost exclusively.

I was a physics major for most of my undergrad and I can confirm this.

Reply on news.ycombinator.com