Live data from Hacker News

The State of Fortran

arxiv.org

11–20 of 113 posts

Re: The State of Fortran

#12

Modern Fortran is beautiful and I love coding in it. However, my understanding is that its main focus is on array computations. Now with hierarchical data structures and graphs becoming ever pervasive, I wonder if Fortran will ever try to compete in this space (when these higher-order concepts are integrated into domains of Fortran's past dominance in numerical simulation).

Fortran is the ideal language for data-oriented programming. Ultimately that’s where performance is. I don’t see it trying to compete by creating a kind of graph-oriented language (besides pointers and somewhat barebones generics). You probably want a fancy higher-level language for this anyway.

It is evolving towards a great language for parallel HPC, integrating neatly both shared-memory and distributed computing in a very nice framework. Much better than the usual hodgepodge of OpenMP and MPI (or whatever API du jour NVIDIA or Intel happen to be pushing).

Re: The State of Fortran

#13

Please note there's been some uptick in the intensity of discussion on generics lately [0]. Generics are necessary to bring performant data structures to Fortran, and yet they are nowhere near Go's generics. For the usual naysayers doubting Fortran's place in a modern world: whenever you are reading or watching a weather forecast, that's decades of Fortran staring at you. Whenever you drive past a nuclear power plant…

That's not to say the code quality is any good, only that it still runs and everyone has their reasons to avoid a rewrite.

True, the fact that it is still running says something, but not overmuch about whether it would be pleasant to maintain, extend or otherwise modify.

Re: The State of Fortran

#14
Technically, all programming languages are constrained by what a machine can do (the cpu architecture), to me all programming languages are transpilers, just chose the language that fit best your usecase, and that will allow you to write correct code easly, but always keep in mind that regardless of the language you’re using, you’re still constrained by same machine architecture,

Re: The State of Fortran

#15

Please note there's been some uptick in the intensity of discussion on generics lately [0]. Generics are necessary to bring performant data structures to Fortran, and yet they are nowhere near Go's generics. For the usual naysayers doubting Fortran's place in a modern world: whenever you are reading or watching a weather forecast, that's decades of Fortran staring at you. Whenever you drive past a nuclear power plant…

For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness.

The way I see it, Fortran exists today because of inertia, not because it still has technical superiority.

These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite.

And so today, new code is bolted on, with a prayer that nothing breaks, may god have mercy on your soul.

Re: The State of Fortran

#16

The fact that “The State of Fortran” is a paper on arXiv instead of a blog post actually says a lot about the state of Fortran.

What do you mean? It’s a paper written by several people on the standard committee of who contributed to the draft standard, on which blog would they put it?

Traditionally, these things were published in ACM SIGPLAN Fortran Forum (or on NAG’s servers for historical reasons). Arxiv is really natural, given the direction scientific and technical publishing is taking. This is a heavy duty language used by scientists and people like mechanical and nuclear engineers. Not the latest JavaScript framework or full stack doodad from Google.

Re: The State of Fortran

#18
post #4

What kind of editor support does Fortran have? I think a language is more than just a language as such, and the surrounding environment is at least as important if not more. I've used things like Mathematica, RStudio and Matlab, as well as Java IDEs, and these make all the difference.

The tooling around Fortran is very similar to C. The debuggers are the same, you can typically use ctags of some sort for navigating between subroutines etc. across all files, and then you can add in a compiler-editor integration that checks for syntax errors at every save.

There are also a couple of Fortran REPLs out there, the most promising is probably LFortran which is only in alpha stage of development but has Jupyter integration and will be the next cool thing I think.

Re: The State of Fortran

#19
post #4

What kind of editor support does Fortran have? I think a language is more than just a language as such, and the surrounding environment is at least as important if not more. I've used things like Mathematica, RStudio and Matlab, as well as Java IDEs, and these make all the difference.

I tend to use TextMate on Mac or SublimeText on other platforms. Fortran also is usually very close to C, and most standard debuggers like ten or lldb (even when LLVM had no Fortran front-end) can be used without problems. It’s a bit barebones compared to recent IDEs, sure. What I would like in particular is better refactoring and static analysis tools (though the lack of the latter is mitigated by the strong type system and some very good compilers like NAG). There is no real equivalent to RStudio or Matlab.

Re: The State of Fortran

#20

Please note there's been some uptick in the intensity of discussion on generics lately [0]. Generics are necessary to bring performant data structures to Fortran, and yet they are nowhere near Go's generics. For the usual naysayers doubting Fortran's place in a modern world: whenever you are reading or watching a weather forecast, that's decades of Fortran staring at you. Whenever you drive past a nuclear power plant…

For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness. The way I see it, Fortran exists today because of inertia, not because it still has technical superiority. These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite. And so today, new code is bolted on, with a pray…

When we cannot re-make the things we made before is a sign of a slow decline.
Post reply on HN