Fortran-10 is old school, not Fortran-77.

https://github.com/DigitalMars/Empire-for-PDP-10

Fortran-77 is for young whippersnappers.

In the early 2000's I worked on some Fortran-77 code that we were parallelizing (As a babe, this was my first experience with Fortran-77). We were having strange bugs because it seemed like some MPI calls were just not happening and others were. There were no compiler errors or warnings. Everything was supposedly fine. However, certain properties were propagating across grid elements just fine and others weren't. e.g. A particle might cross a vertical boundary and be just fine in the next CPU's element, but if it crossed a horizontal boundary it would lose it's horizontal momentum but keep everything else.

Eventually we figured out that the lines that weren't working were just over 80 characters long and the ones that were working were under 80 characters long. The compiler we were using was adhering to the Fortran-77 spec of a maximum of 80 characters per line (because that's what would fit on a punch-card), but it was just ripping those lines out and ignoring them without raising any kind of warning. If a line of code was over 80 characters long, it was just silently ignored. All we had to do was split the lines over 80 characters up and that particular bug was squished.

In my humble opinion, if a language can trip you up because of how many characters fit on a punch-card, it qualifies as "old school".

If you were using Hollerith punch cards, like you were supposed to, you couldn't have had that problem.

That column of GOTOs in EMPIRE.FOR. That is the stuff of nightmares.

EDIT- Terrifying:

251 GOTO (21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37) I-20

It's basically a switch statement, but without the benefit of descriptive case identifiers. So it's basically,

  switch (I-20) {
  case 21:
  case 22:
    ...
  }

but you have to imagine "21" as the string identifier, not the integer value. `I-20` is indexing the list of labels in the GOTO statement.

The earlier column beginning with

  GOTO (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15) I

is easier to read

  switch (I) {
  case 1:
     ...
  case 2:
     ...
  }

because the integer value of I, the string labels, and their index in the list are all the same.

I've never written Fortran. I did learn to program using TI-85 BASIC, though, and am well versed in C. The GOTO in the Fortran code is possibly the easiest part for me to understand.

Shockingly Bad use of line numbers.

the convention I used was taught was always 4 digits always increasing going down the pages.

7000 and 8000 range where for input and output FORMAT statements, 6000 was used to label code 6999 was always the exit

If you look at the code, they seem to follow a similar convention. But the computed GOTO described above is using a set of labels employed for what looks like an inner state machine, related to a previous inner state machine (thus the offset by 20). It seems perfectly reasonable (preferable, even) to use an entirely different domain of numeric labels, distinguished by length, for those parts of the code.

> Shockingly Bad

<hangs head in shame>

My only question is: Which century is Empire "the game of"?

What’s the advantage of sticking to the new Fortran? Is it substantially compatible with legacy FORTRAN codebases and systems, despite having significant advances as a language?

Fortran has better aliasing rules than C. Most of the strangeness you have to do with restrict pointers in C are not a concern in high performance code. Because strides and dimensions and types are all laid out explicitly, the optimizer can really go to town. And with co-arrays the same syntax generalizes to multiple compute nodes.

I worked as lead on IBM’s ASTI component (part of xlf) 10 years ago, and kind of miss it sometimes.

Array-based syntax for distributed memory parallel computing (look for coarrays) since Fortran 2008. OOP since Fortran 2003. Whole-array operations since Fortran 90. These are a few of my favorites.

New standards mark obsolescent or deprecate a few ancient features as they come out, however compilers maintain the support for these features. I'd say that the modern Fortran is almost completely backwards compatible with legacy FORTRAN, as far back as FORTRAN IV (predecessor to FORTRAN 77).

> I'd say that the modern Fortran is almost completely backwards compatible with legacy FORTRAN, as far back as FORTRAN IV (predecessor to FORTRAN 77).

That's very impressive! I assumed the compatibility difference was akin to what Perl 6 is to Perl 5- -- that is, not compatible at all.

The rules for the lines formatting are different, but lucky you can write code in the "intersection format" that can be read by both http://fortranwiki.org/fortran/show/Continuation+lines

If useful if your coworkers are stuck to a old semi unknown machine and want to mix the new code with the old code and run it there too.

The rationale was based primarily on 2 factors:

(1) Compatibility with legacy FORTRAN. Although it's not difficult to work with legacy FORTRAN via C, it's seamless to pass data around between legacy FORTRAN and Modern Fortran.

(2) The mathematical and array syntax. It's tough to beat Fortran's mathematical notation and easy use of multidimensional arrays.

This. As someone who once did a lot of computer graphics programming in C (not C++), I would have killed for proper arrays. Modern C, with variable length arrays, helps, but still...

A long time ago, at a university far, far away, I worked with SGI's gl library, which had FORTRAN bindings. In retrospect, that seems like a very smart idea. At the time, we stuck with the C bindings.

This really doesn't look like the FORTRAN77 code I once wrote. Looks like a regular modern language.

“I don’t know what the programming language of the year 2000 will look like, but I know it will be called FORTRAN.” – Charles Anthony Richard Hoare, circa 1982

It seems every language keeps the same name as it evolves, except Algol/C/C#/Java.

Hoare also said "ALGOL 60 is alive and well and living in FORTRAN 90". I don't have the source of that, but I think it was the answer to someone asking him about it, reported in some Fortran forum.

There's a cute namelist hack that allows parsing arguments as well as serializing them to disk using old, standard language features: https://github.com/RhysU/namelist_cli

Do you know of any learning opportunities such as internships where one can learn and apply Fortran?

Come to Boulder:

https://www.ucar.edu/opportunities/careers

https://www.txcorp.com/careers-at-tech-x

http://radiasoft.net/about/careers/

Huh. Don't think I have seen NCAR here before!

Look up for jobs in weather agencies, climate research, ocean model research and computational physics.

And lots of Finite Element Analysis packages still use Fortran under the hood.

I've noticed that Fortran comes up a lot when talking to people who do fluid dynamics simulations.

Curiously, it often does so in context of Python. One specific example I can remember was a library written in Fortran, with unit tests written in Python.

Fortran and Python go together very well (they complement each other in just the right ways and there's all the bindings / data structure compatibility with Numpy that you need). Glue code / UI in Python, Numerics in Numpy + homegrown Fortran, that's how I'd implement a numerical model from scratch today.

Just out of curiosity, what do you use for calling Fortran from Python (e.g. f2py, ctypes)? Do you have any suggestion about how to combine them together (e.g., for parallel calculations)?

So I haven't yet had the chance to do it myself, but yes I'd look at f2py first and how to integrate it with Numpy.

also a lot of computational fluid dynamics modeling (naval, aeronautical, automotive, etc.)

Thanks.

It's still used at NASA. The NASA Center for Climate Simulation at Goddard does much of their climate work in Fortran.

I have a friend who writes modern fortran nearly everyday as an actuarial pension analyst in Manhattan. They hired him out of college having never written a "hello world" script. Hope that helps!

Dead language tallying the dead?

I began my career 30 years ago writing actuarial valuations in Fortran77. Glad to see the industry hasn't changed (much).

Maybe universities. My mechanical engineering program taught fortran and had beowulf clusters running what was (presumably) fortran.

At a Guess CERN and places like that

The thing with such hardcore engineering stuff is that there are very few places one can learn them at, but they are also very very cool

Dude, someone (not me because I'm super busy) make a Fortran version of docopt[0] and I and everyone else will love you forever.

[0] http://docopt.org/

Interesting, I've never seen this before. Seems like it would be easy enough for me to add this as an alternate means of initialization.

Same. Seems like a straightforward implementation. Only downside is I'm not sure there is a Fortran sys/regex analogue?

Time to dust off the Fortran!

Very cool thanks for sharing the project! I used fortran in college for meteorology, had a very oldschool professor. There was another guy who taught Matlab, i liked fortran more honestly. It was the old style fortran , reading thru your repo i think this version does look much more modern.

After writing code in fortran and running on a shared cluster with a buttload of CPU and RAM, working in a software shop doing python science stuff on a mac makes me miss the speed. I didnt give a about how big my source data was , but now with python, occasionally i miss the ol static typed compiled days. I am giddy when i get to do some numpy matrix array type stuff instead of just glueing things together with python magic!

Is modern fortran available for iOS/android?

Nice, I had fun with FORTRAN 90 and f2py in a couple of atmospheric modeling classes. Anyone tried flang for iOS?

https://github.com/flang-compiler/flang

I gather that gfortran can be built on Android, so presumably it's possible. I see conflicting information on whether or not it's actually possible on iOS. I've personally never seen it.

similarly modern COBOL is different

As long as there's backward compatibility, you can call it evolution of the language. (Otherwise I do not know what to call it.)

Fixed format was gone in the late 70's (for new developments)

I believe free format came about in Fortran 90, and that FORTRAN 77 was still fixed format--at least that's what a quick Google suggests. But even still, fixed-format F77 has stuck around in lots of legacy code bases for a long time. We only migrated one of our large codebases to free format a few months ago.

I learned Fortran IV and later Fortan 77 in the mid eighties and programmed professionally in Fortran 77 up until 2000. I was taught and programmed with fixed format. I believe that there may have been compiler switches to allow non-fixed format. I'm pretty sure that longer lines were allowed via a compiler switch.

Ah I was using Salfords f77 which I think allowed freeformat

I am still writing new code in fixed format. Because of the wonderful compatibility, I can do it while using a lot of new features from the recent standards which are both supported in GNU Fortran and Intel Fortran. You can call me old school, but I like the constraint of the line length in fixed format, it helps me writing clean code and reduce the "double" loops in my algorithms.

Fixed columns was Fortran IV

From what I gather, fixed columns was all FORTRAN versions up to F77, since Wikipedia says free format was introduced in Fortran 90 [0]. But it may have been the case perhaps that some compilers supported proprietary directives to support this in earlier versions--I wouldn't know, though.

[0] https://en.wikipedia.org/wiki/Fortran#Fortran_90

> Fortran is still a thing

> completely different

Sound like a contradiction to me...

What's the big contradiction?

A language can still be a thing after decades while looking very different.

Ever heard of the Ship of Theseus?

I understood the Ship of Theseus to have been rebuilt with new materials, not with a new design. I suppose the interpretation is somewhat flexible but I don’t think it quite applies to this case. If a modern program doesn’t compile on an older version, I would interpret that as being a significant change in the language, the referent of “FORTRAN”. I believe GP simply didn’t develop their argument effectively. 1970’s Camaros aren’t interchangeable with 2010’s. To the public they are both Camaros, but to a mechanic they are very different.

>If a modern program doesn’t compile on an older version, I would interpret that as being a significant change in the language, the referent of “FORTRAN”.

A modern C program doesn't compile in old C compilers. That doesn't mean it's not C. You can change tons of ergonomics and keep the language the same. Or you can keep the spirit the same (which in a language are its core semantics and concepts).

>I believe GP simply didn’t develop their argument effectively.

GP just casually said it's a whole new language in the casual, everyday sense, that a e.g. you can say "it's a brand new car now" after you redid the interior and did some repairs on your 10-year old car.

(And I got in with the Ship of Theseus thing to humor the objection -- not that I really consider the GP statement to have to be taken at face value).

Is the Medieval French "the same language" as the modern French? It is French after all, right?

Is a 80 year old person the same person and with the same ideas, abilities, look, as when he was a 15 year old person? He has the same name after all.

Same language doesn't mean you can necessarily speak it without learning the new words, forgetting some stuff that went deprecated, learning some syntactic sugar and new features. If you were born in 1400 and lived to today, you'd be going from speaking from Medieval French to modern French with hardly noticing the difference...

Looks like Clinton was right saying that “it depends on what the meaning of ‘is’ is.”

Well, I think that's a reasonable analogy, except that with spoken language evolution, the unintelligibility tends to be mutual, whereas with Fortran there's substantial compatibility in one direction (i.e., GFortran will happily compile anything from f77 to Fortran 2008)

Sure, from the general public standpoint, by the sound of it, Fortran is still a thing...

That would suggest that, for example, C11 should not be referred to as the C programming language, since it introduces some new features? Similarly, if I said “I have a Camaro” to you, would you expect that I have a 1970s car or something more recent?

C11 still looks like (and still is) C, despite the new features. In contrast, to say that the new Fortran is the same 'thing' as the old Fortran is disingenuous. For example, the old Fortran did not support recursion (which fact I consider a feature rather than a "bug").

ANSI C looks pretty different to K&R C, especially in the function declaration syntax. The only difference is Fortran had its facelift just a little later.

>For example, the old Fortran did not support recursion (which fact I consider a feature rather than a "bug").

So? C# 1.0 didn't support 90% of the cool features of C# whatever it is now, not even LINQ, the bread and butter of C# programmers.

Java up to 1.4 didn't have generics, closures, streams, modules, and tons of other stuff besides. Soon it will be getting many more.

Is it a different language for that?

On the other hand, C was given a different name when classes were added to it.

Thing is, adding and/or removing features may have an impact on the implementation, can potentially introduce subtle changes to the semantics of the existing constructs and therefore their behavior at run time, have general performance implications (e.g. due to a change in what optimizations are possible), etc. Is it "the same language"? Not quite. It is a "super-language," at best. If it's 100% backwards compatible, that is (which is not guaranteed).