Blockquote
Three seems too many. How many languages have three new compilers simultaneously developed?
Common Lisp has at least 4 open source implementations as well as a few proprietary ones. Prolog as at least 4 open source of the top of my head as well, along with closed source options. C has a number of compilers if we are talking about c89. I only know of 2 open source C99+ compilers; same holds for C++
D has 3 compilers now – GDC (integrated into GCC), LDC (integrated into LLVM), and the reference DMD (Digital Mars D Compiler).
It appears I’m mistaken. The D Language community continues to develop the front end, and provides instructions on how to build with various versions of LLVM here. I could have sworn reading that D will be integrated into LLVM “soon” but cannot find that info.
Everybody and his brother had a FORTRAN 77 compiler, but Fortran has lost much relative popularity since those days. Here is a list in alphabetical order, to which people can add:
Absoft
Acorn
Alliant
Apogee
BC-FORTRAN 77
Burroughs
Concurrent
Cray
Digital
Fujitsu
g77
Harris
Hewlett Packard
IBM
Lahey
Microsoft
Microway
NAG
PGI
Prospero
Ryan McFarland
Salford
Siemens
Sun
Unisys
Univac
Watcom
In the list of free Fortran compilers still under development, don’t overlook gfortran (part of GCC). Also, in the list of Intel compilers, both ifort and ifx are now free to download. (But not open source, like gfortran is.)
In the posted list of f77 compilers above, several still exist as newer compilers, sometimes with a different name:
Absoft - ??
Apogee - ??
BC-FORTRAN 77 - ??
Concurrent - ??
Cray - still exists, now Fortran 2018 (more or less). Technically an HPE product now.
Digital - Became the Intel compiler. (DEC no longer exists.)
Fujitsu - Sill exists. That’s the main compiler for Fugaku.
g77 - Replaced by gfortran. Still going strong.
Hewlett Packard - While some legacy support exists for HP-UX, basically abandoned for the Cray compiler.
IBM - Still exists and evolving. The Summit system used IBM extensively.
Lahey - Tom Lahey retired. I think the technology got folded into Fujitsu.
Microsoft - Microsoft can’t even spell “Fortran”. If it’s not C#, it’s irrelevant.
NAG - Still going strong.
PGI - Became the NVIDIA compiler. Will eventually be replaced by F18/FLANG.
Prospero - ??
Ryan McFarland - ??
Salford - ??
Siemens - ?? (Basically no longer in the computer business.)
Sun - Became the Oracle compiler.
Unisys - ??
Watcom - ??
Donning my conspiracy theory tin-foil hat for a moment, I , being of a certain age, can see this as a way to get around potential age discrimination lawsuits. We didn’t hire you because you lacked the skill set we are looking for, not because of how old you are. In my experience, good Fortran programmers will be good programmers in any language. Plus once you know one language, becoming skilled in another one is just a matter of spending a little time devoted to self-study. As a former rocket scientist, I can safely say, it ain’t rocket science.
Fortran has the potential but it had been in the slumber for long time when all the other languages took up writing libraries. In fact C++ creator wants the language to be for library writers that’s why generics and so many features have been put into C++. Look at BOOST, EIGEN… They are linear algebra libraries for handling sparse and dense matrices, sometimes try to compete with BLAS and LAPACK in terms of speed. In the end they are just matrix libraries, which Fortran has been supporting from the beginning. In fact that is the reason BLAS and LAPACK are being used till today. But Fortran didn’t go beyond that. It came late to the party.
Even in my field, I want to work with Fortran, but the frameworks and libraries that I use (Finite Element Analysis) have been in C++. So, I am forced to learn and use it. Everybody cannot build his own framework. I really appreciate that now there is a organized effort in Fortran and I see a bright future. Hopefully some bright minds will consider to write libraries and frameworks in Fortran. Till then we have to tolerate all these bans on Fortran without finding fault with anybody. These are just a fuel for us to go forward.
Fortran has to focus on (my personal opinion):
Libraries and Frameworks
Easy interfacing with some high level programming language like Python which enables library and framework writers to easily port Fortran to Python
Support one plotting library. If this website supports one plotting library (GNUplot or PLplot or Matplotlib…) anyone visiting the website will stick to it, instead of using his own home made tooling and struggling with it. We can say you can use all these plotting libraries but formally this website or group supports this plotting library for which help is always available.
We need not compete with any other language, we just offer our best.
Quite so, one of my contributions was to modernise the Fortran interface, using the ISO_C_BINDING features. And PLplot was helped a lot by adopting CMake as the build system (even if we have encountered all nooks and crannies during the development). The original build system was okay on Linux (autotools), but for Windows we had to use handcrafted make files and batch files and stuff.
@vmagnin and @Arjen, nice.
Then it would be nice if we can make it something like Matplotlib for Python. Actually Matplotlib is written in C++, but there is so much python sugar added to make it easy for users. So we can make PLplot for fortran as is Matplotlib for Python. Python supports many other plotters (GNUplot, Bokeh…), but Matplotlib is popular. Similarly we can make PLplot identifiable with Fortran, although it interfaces many other plotters. I feel it would add a great strength to the language if we can do that provide that syntatic sugar with Fortran - just like “plt.plot()”
We should make all Fortran plotting libraries readily available via fpm, so that projects can depend on them and use them. Together with LFortran, one will be able to interactively use them in the Jupyter notebook, which is my favorite workflow in Python + plotting.
I would not pick one at this point yet, as I think we will not agree. But just like in Python, eventually one will become popular.
The possible advantage of defining generic plotting routines with backends is that the user will be able to easily switch between plotting libraries. Plotting subroutines are different from other subroutine calls in that they don’t affect the core logic of the program. So if call piechart(x,backend="gnuplot") is not implemented in gnuplot, it’s ok for the subroutine to do nothing but print a message. A first step is to get graphics libraries in FPM, and a second step could be to write interfaces so that they could be called with generic plotting routines.
It is now possible to use the ogpf package with fpm.
This package provides many common interfaces to gnuplot, which also means that it has good cross-platform support.
I would support putting together a unified plotting package with different backends.
: