50 years of Fortran at CERN (2007)(cerncourier.com)
cerncourier.com
50 years of Fortran at CERN (2007)
http://cerncourier.com/cws/article/cern/30873
54 comments
That's what RATFOR was for. RATFOR was pre-processor for Fortran that improved in those areas
Err...minor nit...since Alphard was never implemented, it's not really a competitor. Couple of pretty interesting papers came of it tho.
Yes, it was a fun time for programming languages, lots of new and ultimately seminal ideas were being explored on the pages of SIGPLAN and conference proceedings. C and Pascal were practical languages and, in some programming domains, Scheme and Ada were too. If FORTRAN 77 came out in 1972 I think it might have stayed in the game, but things were developing quickly. And as you point out correctly, language features were being explored more quickly than they could be implemented.
CLU even more than Alphard is an example of an academic experiment in language design that had a profound influence on the future of real programming languages.
Exceptions -- C++ exception handling comes from the ideas found in CLU.
Object oriented programming -- The name CLU comes from cluster because Barbra Liskov recognized the importance of compound data structures (objects, but she called them clusters) that supported an explicitly defined interface of functions (methods). These ideas were inspired by Simula (an older simulation language that had support for defining the real-world things, objects, being simulated).
Immutable vs mutability -- Strings were immutable, as were other elementary types.
Iterators and yield -- First introduced in CLU are now common in modern languages.
Call semantics -- like lisp, data is passed by sharing a reference to the data, in contrast to the way FORTRAN or Algol passed parameters. Java and many other languages now use these call semantics, not just Lisp of Scheme.
Multiple assignment -- operations (methods) could return tuples that were destructured at the point of call into multiple values. Now common in modern languages.
Variable sized arrays -- as I recall, the runtime was intended to handle the autosizing of vectors. I'd never seen anything like this before 1974 (except for LISP's lists).
All these important ideas and more in a language no one programmed in.
Other languages were pushing in new directions too. The Algol68 Revised Report came out while I was in grad school. Wow, the language spec was so interesting that SIGPLAN made it a special edition of their monthly journal. Every concept was completely generalized: arrays could have multiple dimensions and any number of these could be left out while indexing an array value resulting in a multi-dimensional slice. I've still never seen anything like this in a modern language (is it supported by R or Mathematica? I can't remember.) Again it wasn't the implementation of Algol68 that was important (the language as specified was too hard to implement) it was the ideas it suggested to future language designers--in fact, Niklaus Wirth quit the Algol68 design committee with the idea that Algol ought to go in a simpler direction, which led to Pascal.
CLU even more than Alphard is an example of an academic experiment in language design that had a profound influence on the future of real programming languages.
Exceptions -- C++ exception handling comes from the ideas found in CLU.
Object oriented programming -- The name CLU comes from cluster because Barbra Liskov recognized the importance of compound data structures (objects, but she called them clusters) that supported an explicitly defined interface of functions (methods). These ideas were inspired by Simula (an older simulation language that had support for defining the real-world things, objects, being simulated).
Immutable vs mutability -- Strings were immutable, as were other elementary types.
Iterators and yield -- First introduced in CLU are now common in modern languages.
Call semantics -- like lisp, data is passed by sharing a reference to the data, in contrast to the way FORTRAN or Algol passed parameters. Java and many other languages now use these call semantics, not just Lisp of Scheme.
Multiple assignment -- operations (methods) could return tuples that were destructured at the point of call into multiple values. Now common in modern languages.
Variable sized arrays -- as I recall, the runtime was intended to handle the autosizing of vectors. I'd never seen anything like this before 1974 (except for LISP's lists).
All these important ideas and more in a language no one programmed in.
Other languages were pushing in new directions too. The Algol68 Revised Report came out while I was in grad school. Wow, the language spec was so interesting that SIGPLAN made it a special edition of their monthly journal. Every concept was completely generalized: arrays could have multiple dimensions and any number of these could be left out while indexing an array value resulting in a multi-dimensional slice. I've still never seen anything like this in a modern language (is it supported by R or Mathematica? I can't remember.) Again it wasn't the implementation of Algol68 that was important (the language as specified was too hard to implement) it was the ideas it suggested to future language designers--in fact, Niklaus Wirth quit the Algol68 design committee with the idea that Algol ought to go in a simpler direction, which led to Pascal.
From the article:
> Today, Fortran 95 provides all desirable object-orientated and structured programming features, pointers and overloaded operators, and is extremely efficient in the handling of arrays.
The object-oriented features (inheritance and type-bound procedures, for example) were added only in Fortran 2003. Also, since the writing of the article, there has been another revision, Fortran 2008, adding support for parallelism (coarrays).
The object-oriented features (inheritance and type-bound procedures, for example) were added only in Fortran 2003. Also, since the writing of the article, there has been another revision, Fortran 2008, adding support for parallelism (coarrays).
Intereting! Searching for that I found this:
Modern Programming Languages: Fortran90/95/2003/2008
https://www.tacc.utexas.edu/documents/13601/162125/fortran_c...
Modern Programming Languages: Fortran90/95/2003/2008
https://www.tacc.utexas.edu/documents/13601/162125/fortran_c...
Often, additions to a programming language standard (or for that matter, any standard) reflect vendor specific extensions to existing implementations. When standards committees decide to add new features that lack implementations, those features may be more likely to be off in the weeds or to produce unresolvable positions in regard to its specification.
That is what happened with coarrays (which was called F-- before), the object-oriented features, however, were not based on existing extensions. For example, neither the Intel compiler, gfortran, nor g95 supported any of those features at the time of the article's writing, and the NAG compiler provided only partial support[0].
[0] http://portalparts.acm.org/1280000/1279941/fm/frontmatter.pd...
[0] http://portalparts.acm.org/1280000/1279941/fm/frontmatter.pd...
I'm interested in the historical and current use of FORTRAN. However, the article wanders off topic and (in my opinion) loses credibility when it dives into opinion.
For example, "Fortran is the language of high-performance technical computing -- even if this is an increasingly smaller segment of today's computing activities."
I grow weary of this form of sentence construction. Saying "X is the language of Y" smacks of marketing, not something that I want to see in a journal such as the International Journal of High-Energy Physics. I don't mind if a writer claims something the best language for high-performance technical computing, but they should at least give some comparison with alternatives and empirical support.
Update: I see this was written in 2007.
For example, "Fortran is the language of high-performance technical computing -- even if this is an increasingly smaller segment of today's computing activities."
I grow weary of this form of sentence construction. Saying "X is the language of Y" smacks of marketing, not something that I want to see in a journal such as the International Journal of High-Energy Physics. I don't mind if a writer claims something the best language for high-performance technical computing, but they should at least give some comparison with alternatives and empirical support.
Update: I see this was written in 2007.
"Fortran is the language of high-performance technical computing -- even if this is an increasingly smaller segment of today's computing activities" is a fact, not an opinion. You can (and I'm sure CERN does) count up the lines of code in each language, map them to instructions, count the number of instructions (mapped back to the language) executed, and see that Fortran dominates. And you can also see that HPC is a much smaller slice of the market share.
The author wasn't making an opinion claim- just facts. In particular, when an english speaker says "X is the Y of Z" they aren't saying it's better, they're saying its more prevalent.
The author wasn't making an opinion claim- just facts. In particular, when an english speaker says "X is the Y of Z" they aren't saying it's better, they're saying its more prevalent.
Ok, I see that doing so is a standard usage:
> (pronounced stressing “the”) used to indicate that someone or something is the best known or most important of that name or type. "he was the hot young piano prospect in jazz"
I would tend to agree that "best known" is relatively objective (in theory -- but who really believes in an objective definition of what 'everyone' knows?); however, "most important" clearly tends towards subjectivity, as it implies value judgments into what is important and why.
> (pronounced stressing “the”) used to indicate that someone or something is the best known or most important of that name or type. "he was the hot young piano prospect in jazz"
I would tend to agree that "best known" is relatively objective (in theory -- but who really believes in an objective definition of what 'everyone' knows?); however, "most important" clearly tends towards subjectivity, as it implies value judgments into what is important and why.
The thing is, this is not marketing. Performance really does matter in HPC and in quite a few areas the workflow is to prototype in Matlab and write implementations in modern Fortran.
You can write performant code in C/C++, and many do, but Fortran is still the easiest to do so in.
You can write performant code in C/C++, and many do, but Fortran is still the easiest to do so in.
It isn't even a matter that it's "easiest". There are decades of painstakingly debugged and proven Fortran libraries that simply don't exist in other languages even if the researchers wanted to use them. Recreating them isn't generally a priority.
> Fortran is still the easiest to do so in.
Let's not get too carried away, what is an example of Fortran making speed easier than C++?
Let's not get too carried away, what is an example of Fortran making speed easier than C++?
Most Fortran compilers are also C/C++ compilers. One way to spot the best compiler engineers is that they are the ones who appreciate how Fortran makes optimization easier. Argument aliasing rules, discouraging pointer use, lack of 15 layers of templates, 1st class arrays, and so forth.
These same compiler engineers don't want to actually write any Fortran -- but I assure you, as an astronomer, I really prefer it that my Astronomy colleagues write Fortran instead of C/C++. It ends up being better code.
These same compiler engineers don't want to actually write any Fortran -- but I assure you, as an astronomer, I really prefer it that my Astronomy colleagues write Fortran instead of C/C++. It ends up being better code.
Aliasing, for one.
Plus, array's are a first class feature in Fortran. "But Eigen!" you retort. Sure, except this library I want to use uses MTL4, this other library that I need uses uBlas, and this other one uses MKL. Ouch, ouch, ouch.
Pretty much if you can write Matlab you can write very highly performant Fortran without doing anything too special. Dealing with incompatible libraries, templates, and all the other stuff that C++ subjects you to is not 'easy'.
Plus, array's are a first class feature in Fortran. "But Eigen!" you retort. Sure, except this library I want to use uses MTL4, this other library that I need uses uBlas, and this other one uses MKL. Ouch, ouch, ouch.
Pretty much if you can write Matlab you can write very highly performant Fortran without doing anything too special. Dealing with incompatible libraries, templates, and all the other stuff that C++ subjects you to is not 'easy'.
What I've learned is that when people say Fortan is faster, they mean for their specific math based usages due to good integrated libraries, and that they often doesn't really know C++.
I know that the climate models that run on the supercomputer at NASA Goddard are in Fortran. Specifically, Fortran 90/95.
I wrote FORTRAN 90/77/4 at university. It's a pretty horrible language, to be honest. While it keeps getting updated regularly, each one adds a crust of "modern" features on top of a strata of mismatched features previously designed by committee. Its redeeming feature is its native support for matrices, including its ability to transparently parallelise operations on them. It's quick for the same reason JavaScript is quick - a lot of work and money has been spent creating fast compilers.
To me the main reason for its use seemed to be 50 years of technical debt. Ancient, badly-written functions written long ago that have been thoroughly tested but no-one can remember why they work; ancient professors who refuse to learn another language or validate code written in another language. And so the technical debt feedback cycle continues.
To me the main reason for its use seemed to be 50 years of technical debt. Ancient, badly-written functions written long ago that have been thoroughly tested but no-one can remember why they work; ancient professors who refuse to learn another language or validate code written in another language. And so the technical debt feedback cycle continues.
Fortran is the language of high performance computations because it forces programmers to use static memory layout, and has real arrays. It is easier to emit (SSE-)vectorized assembly from Fortran code than from C. You can of course achieve the same effects in C as you can in Fortran, but by default it requires more knowledge. For example not many people are aware of the "restrict" C keyword, which is absolutely necessary to write vectorizable code.
JavaScript is incomparably slower than Fortran. Also, Fortran has been fast since day 0.
Edit: I've just found out that "restrict" has been added in C99. Which means that even in the 90s there was no good support for parallel/vectorized code in the C standard.
JavaScript is incomparably slower than Fortran. Also, Fortran has been fast since day 0.
Edit: I've just found out that "restrict" has been added in C99. Which means that even in the 90s there was no good support for parallel/vectorized code in the C standard.
You mean day 1, Fortran uses 1-based array indexing (by default, it is configurable for each array declaration!) ;-)
edit: Variable Length Arrays (VLAs) were also not available until C99 for C, while they were part of Fortran since 1990.
edit: Variable Length Arrays (VLAs) were also not available until C99 for C, while they were part of Fortran since 1990.
And in C11, I believe they are now optional. EDIT: Oh, and kudos on the day 1 vs day 0 comment; very funny!
I didn't mean that JavaScript is in the same performance category as Fortran, just that they've both had an above-average amount of investment in performance.
There are certain aspects to FORTRAN that naturally lend it to being fast but you still need to write it in a way that can be optimised, which isn't always the most obvious way. You need to know the language and compiler well to wrote fast code, just as you would with any other language.
There are certain aspects to FORTRAN that naturally lend it to being fast but you still need to write it in a way that can be optimised, which isn't always the most obvious way. You need to know the language and compiler well to wrote fast code, just as you would with any other language.
Apparently Dennis Ritchie was set against adding even user-optional features to address C's performance limitations versus Fortran ("If you want Fortran, you know where to find it.") I think that's (at least partly) why they started showing up in C99, after the first round of standardisation which he wasn't involved with.
Good points. I'll add that the compiler can have more difficulty understanding what's going to happen with C code compared to Fortran code. This affects how easily and much optimization can happen. Sometimes less is more.
If C++ would implement something like restrict (in the standard), we could hide it in the usual C++ way and may be a very performant library with all the benefits of C++ could become feasible.
> It's quick for the same reason JavaScript is quick - a lot of work and money has been spent creating fast compilers.
It's also quick because the language is designed to enable compilers to generate fast code. In indexed (for-style) loops, for example, the loop body cannot change the loop variable, aiding unrolling and/or vectorization.
It's also quick because the language is designed to enable compilers to generate fast code. In indexed (for-style) loops, for example, the loop body cannot change the loop variable, aiding unrolling and/or vectorization.
Fortran 2008 is actually a pretty cool language. Much better than the old versions. I get upset when people judge Fortran based on the ancient versions. Its like saying Windows is terrible because Windows 3.11 is terrible. Well, yeah, 3.11 was terrible, but if you use it nowadays its your fault.
yes, but there is a special place in my heart for it, even though it is horrible and I never use it. But like a lot of other people it was one of the first high level languages that we got exposed to, so I guess it is sort of like the first girl you kissed, you never forget her but you did not marry her :)
During parts of my career, it looked like there was a whole alternate software universe where the foundation was both legacy and spanking new Fortran code with various Tcl/Tk interfaces (often outdated custom versions).
And these days, I'm not quite sure whether they weren't better off…
And these days, I'm not quite sure whether they weren't better off…
Having worked with both Tcl/Tk (and Perl/Tk) and Java (AWT and Swing), I find Tk is better for most jobs, because it is so simple.
In fact, I am certain that all the desktop apps I've worked with would be much simpler to maintain and distribute were they written in Tcl/Tk.
In fact, I am certain that all the desktop apps I've worked with would be much simpler to maintain and distribute were they written in Tcl/Tk.
I agree. The simplicity of both made them a major contender for the agent-oriented programming trend that tried to happen in the 90's. If presentation and logic are separated, Tcl/Tk can be seen as a sort of DSL or 4GL for GUI development. That's how I used it.
Now, there's plenty of lightweight, portable, GUI toolkits to use that I can just write a wrapper or code-generator for. Tcl/TK is less necessary than before. Still among simplest, though.
Now, there's plenty of lightweight, portable, GUI toolkits to use that I can just write a wrapper or code-generator for. Tcl/TK is less necessary than before. Still among simplest, though.
The funny thing about legacy code in scientific programming is that it is not so much of a "bad smell" as it is in commercial work.
It is hard to write numerical code that consistently works correctly in the face of rounding errors and the like, and it is hard to know if you are getting the right answers in many cases. It makes sense to use the old code (which performs well) rather than write something new and take the risk of screwing it up in some subtle way.
It is not hard at all to access FORTRAN data structures from C, Python, Java or whatever your favorite "modern" language is.
It is hard to write numerical code that consistently works correctly in the face of rounding errors and the like, and it is hard to know if you are getting the right answers in many cases. It makes sense to use the old code (which performs well) rather than write something new and take the risk of screwing it up in some subtle way.
It is not hard at all to access FORTRAN data structures from C, Python, Java or whatever your favorite "modern" language is.
Fifteen years ago, the modern parts of the Pixar animation system used Tcl/Tk for the GUI. The older code looked like Tektronix 4013 displays... I didn't work on GUI code much, but what I did do was fun. Since this was an internal application only, it didn't have to look slick and modern, it just needed to have all of the features required by Production and be reasonably fast and reliable.
I have no idea what the software looks like now.
I have no idea what the software looks like now.
I just noticed http://arxiv.org/pdf/1507.03989v1.pdf (it's on todays HN). It claims that in Astronomy Python is used over twice as much as FORTRAN and even C/C++ is used more.
Nearly all astronomers who use Python are actually using Fortran and C++ - the python code is mostly wrappers on low-level libraries.
So the claim of "use" is really what the astronmer sees in their programmer- not in the measure of instructions executed.
So the claim of "use" is really what the astronmer sees in their programmer- not in the measure of instructions executed.
Yes, but from their perspective, it's an implementation detail. LAPACK could have been written in assembly language or APL, and their Python code would work just as well.
Python/Matlab/IDL are important because it is easier to quickly write correct code than in C++/Fortran.
Python/Matlab/IDL are important because it is easier to quickly write correct code than in C++/Fortran.
Right, but if you say people "use" something, it's disingenous (for a scientific paper) to imply that implementation details don't matter.
Had I written the paper (I'm a scientist, I work with astro data sets at times, and manage Python wrappers for Fortran and C++ libraries) I would have calculated this based on instructions executed, not lines of user-facing code.
After all, if the code the astro people called was Pure Python, they wouldn't use python, as it would be too slow.
Had I written the paper (I'm a scientist, I work with astro data sets at times, and manage Python wrappers for Fortran and C++ libraries) I would have calculated this based on instructions executed, not lines of user-facing code.
After all, if the code the astro people called was Pure Python, they wouldn't use python, as it would be too slow.
Reminds me of the 'made in X' fallacy.
#!/usr/bin/env python
from subprocess import Popen
Popen("/usr/bin/some-fortran-binary")
print("Once again python saves the day.")Actually, many optimized BLAS/LAPACK implementations are not written in Fortran. Many are a mix of C and assembly exposed through the standard Fortran interface.
While I see what you're saying, I doubt you would claim to 'use' assembly when writing a C++ codebase - because (unless you're doing very low-level hand optimizations of the kind that get ever rarer), someone else has done the hard work of creating a compiler to do the translation for you. Same thing with NumPy et al, except one level higher up the abstraction stack.
Actually, that's precisely what I do, except it's called machine language, not assembly. That is because assembly is an intermediate format above machine language (it's symbolic).
"Today, Fortran 95 provides all desirable object-orientated and structured programming features"
...for some values of "desirable"
...for some values of "desirable"
[deleted]
F95, forgiving a couple of faddish additions, is a pretty reasonable language. I did some fun things with it, and only hated the process part of the time. So unlike F77 in which one discovered new horrors and general unpleasantness almost continually.
Funny to see this and read some of the comments here - at my last job, where I was doing mostly C#, I was asked to help maintain/update some Fortran code that used an Excel spreadsheet with VBA glue as the UI. I didn't find Fortran to be very pleasant to work with, mostly because there seems to be very little online documentation on how the syntax works, and there seems to have been several major changes to the syntax in different Fortran versions.
I remember trying to figure out how to get an array of strings from Excel to Fortran. The farthest I got was getting the combined strings into the Fortran and getting stuck trying to figure out how to manipulate arrays in FORTRAN 90 I think it was.
I remember trying to figure out how to get an array of strings from Excel to Fortran. The farthest I got was getting the combined strings into the Fortran and getting stuck trying to figure out how to manipulate arrays in FORTRAN 90 I think it was.
To me, programming during that time, it seemed like FORTRAN's evolution stalled at a critical period between FORTRAN IV and FORTRAN 77. I'd been exposed to LISP, PL/1, SOBOL, and APL in my university programs and it was frustrating to use FORTRAN IV for non-numerical projects. The last time I did so was around 1974 when I wrote a LR parser generator in FORTRAN IV. The lack of mechanisms for handling structured data made it a messy job.
It was at that point that I came across the source for the Wirth's first Pascal compiler that ran on the computation center's CDC 6400. I learned Pascal by studying that code and I never wanted to go back to FORTRAN (or PL/1).
A few years later the greatly improved FORTRAN 77 became available, but it was too late. C and Pascal were real and gaining ground and Algol 68, CLU, Alphard, Scheme, the Red and Blue languages, and ADA had captured the imagination of the language designers.