
50 years of Fortran at CERN (2007) - atilev
http://cerncourier.com/cws/article/cern/30873
======
todd8
My first programs were written in FORTRAN II. The language was really quite
terrible; I wish I still had some of those programs I wrote, I'd like to see
how they looked written before Dijkstra's "GOTO considered harmful".

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.

~~~
kjs3
Err...minor nit...since Alphard was never implemented, it's not really a
competitor. Couple of pretty interesting papers came of it tho.

~~~
todd8
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.

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

~~~
brudgers
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.

~~~
mmarx
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...](http://portalparts.acm.org/1280000/1279941/fm/frontmatter.pdf)

~~~
brudgers
Both IBM and Cray had nearly all the features implemented per "Data
enhancements and object orientation" on page 6.

~~~
mmarx
Yes. That document is from 2007, which is three years after Fortran 2003 was
standardized.

------
dj-wonk
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.

~~~
tanderson92
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.

~~~
CyberDildonics
> 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++?

~~~
RogerL
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'.

~~~
CyberDildonics
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++.

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

~~~
hebdo
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.

~~~
tanderson92
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.

~~~
rootbear
And in C11, I believe they are now optional. EDIT: Oh, and kudos on the day 1
vs day 0 comment; very funny!

------
mhd
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…

~~~
forinti
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.

~~~
nickpsecurity
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.

------
thorin
Fortran is still big in our company, an engineering consultancy with lots of
old gas calculations to support. There's also a variety of old basic programs
which I've been asked to support and update.

~~~
kjs3
Ask for a raise. :-)

------
viola11
This should probably have a (2007) in the title, its only two more years until
it turns sixty!

~~~
dang
Missed that one. Thanks!

------
todd8
I just noticed
[http://arxiv.org/pdf/1507.03989v1.pdf](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.

~~~
dekhn
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.

~~~
ced
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.

~~~
dekhn
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.

~~~
agumonkey
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.")

------
nemoniac
"Today, Fortran 95 provides all desirable object-orientated and structured
programming features"

...for some values of "desirable"

~~~
kjs3
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.

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

