# "Samples in Fortran are not acceptable." **URL:** \ **Category:** Uncategorized\ **Created:** [April 27, 2021, 10:58am UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110 "2021-04-27T10:58:23Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![R\_cubed](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/r_cubed/32/263_2.png) [@R\_cubed](https://fortran-lang.discourse.group/u/R_cubed)\ **Post date:** [April 28, 2021, 6:26pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/23 "2021-04-28T18:26:58Z")
> 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). ---
**Author:** ![R\_cubed](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/r_cubed/32/263_2.png) [@R\_cubed](https://fortran-lang.discourse.group/u/R_cubed)\ **Post date:** [April 28, 2021, 6:43pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/25 "2021-04-28T18:43:01Z")
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. [https://wiki.dlang.org/Building\_LDC\_from\_source](https://wiki.dlang.org/Building_LDC_from_source) Just for completeness: You don’t have to build from source to use LDC – there are binaries available: [https://wiki.dlang.org/LDC](https://wiki.dlang.org/LDC) ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [April 28, 2021, 6:57pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/27 "2021-04-28T18:57:26Z")
> [@vmagnin](#): > > > [@certik](#): > > > > We have made great progress in the last 2 years, but our goal should be in the next 3 years to completely fix the tooling and community around Fortran and bring in on par with other modern languages. > > A thought came to me recently: > as far as I know, there are currently three new Fortran compilers in development: Flang, Intel ifx, LFortran. Isn’t it a lot for a language that some people see as doomed to disappear? Three seems too many. How many languages have three new compilers simultaneously developed? 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 ---
**Author:** ![billlong](https://avatars.discourse-cdn.com/v4/letter/b/71e660/32.png) [@billlong](https://fortran-lang.discourse.group/u/billlong)\ **Post date:** [April 28, 2021, 7:00pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/28 "2021-04-28T19:00:16Z")
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.) ---
**Author:** ![billlong](https://avatars.discourse-cdn.com/v4/letter/b/71e660/32.png) [@billlong](https://fortran-lang.discourse.group/u/billlong)\ **Post date:** [April 28, 2021, 7:12pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/29 "2021-04-28T19:12:36Z")
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 - ?? ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [April 28, 2021, 9:43pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/32 "2021-04-28T21:43:08Z")
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. ---
**Author:** ![Ashok](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@Ashok](https://fortran-lang.discourse.group/u/Ashok)\ **Post date:** [April 29, 2021, 5:06am UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/33 "2021-04-29T05:06:31Z")
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): 1. Libraries and Frameworks 2. Easy interfacing with some high level programming language like Python which enables library and framework writers to easily port Fortran to Python 3. 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. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [April 29, 2021, 12:43pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/34 "2021-04-29T12:43:53Z")
> [@Ashok](#): > > … Support one plotting library. If this website supports one plotting library (GNUplot or PLplot or Matplotlib…) … Note this announcement: [Gtk-fortran 4.0 released](https://fortran-lang.discourse.group/t/gtk-fortran-4-0-released/1115) GTK-Fortran page by @vmagnin states: > Note that gtk-fortran goes beyond programming GUI: > > - GTK includes the crossplatform GLib library which offers a lot of generic functions (regular expressions, hash, strings, hash tables, input/output…), > - and gtk-fortran offers also an interface to PLplot. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 29, 2021, 12:55pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/35 "2021-04-29T12:55:01Z")
And as far as I know, in our Discourse we have also @Arjen who is a PLplot developer: [https://sourceforge.net/p/plplot/\_members/](https://sourceforge.net/p/plplot/_members/) ---
**Author:** ![Arjen](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@Arjen](https://fortran-lang.discourse.group/u/Arjen)\ **Post date:** [April 29, 2021, 1:12pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/36 "2021-04-29T13:12:19Z")
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. ---
**Author:** ![Ashok](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@Ashok](https://fortran-lang.discourse.group/u/Ashok)\ **Post date:** [April 29, 2021, 4:08pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/37 "2021-04-29T16:08:45Z")
@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()” ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [April 29, 2021, 4:19pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/38 "2021-04-29T16:19:31Z")
I [suggested addling plotting to stdlib](https://github.com/fortran-lang/stdlib/issues/401), with the backend, which could be PLplot, specified as an optional argument. For example `call plot(x,y,backend="gnuplot")` There are so many plotting libraries for Fortran that I don’t think stdlib, much less the language itself, should pick one. ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [April 29, 2021, 5:21pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/39 "2021-04-29T17:21:37Z")
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. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [April 29, 2021, 6:16pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/40 "2021-04-29T18:16:01Z")
> [@certik](#): > > 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. 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. ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [April 29, 2021, 7:25pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/41 "2021-04-29T19:25:04Z")
@Beliavsky yes I agree that having an interface API for plotting that we all agree upon would be beneficial, whether part of stdlib or elsewhere. ---
**Author:** ![Ashok](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@Ashok](https://fortran-lang.discourse.group/u/Ashok)\ **Post date:** [April 30, 2021, 4:26am UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/42 "2021-04-30T04:26:14Z")
Yes. This was what I wanted to convey. ---
**Author:** ![lkedward](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/lkedward/32/72_2.png) [@lkedward](https://fortran-lang.discourse.group/u/lkedward)\ **Post date:** [April 30, 2021, 4:07pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/43 "2021-04-30T16:07:27Z")
> [@certik](#): > > We should make all Fortran plotting libraries readily available via fpm, so that projects can depend on them and use them. It is now possible to use the [`ogpf`](https://github.com/kookma/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. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 30, 2021, 4:17pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/44 "2021-04-30T16:17:38Z")
> [@lkedward](#): > > It is now possible to use the [`ogpf`](https://github.com/kookma/ogpf) package with _fpm_ . ogpf seems a beautiful and impressive project! And fpm is a real pleasure! \<=30 seconds to test the project 🚀: ```fortran $ cd /tmp $ git clone https://github.com/kookma/ogpf.git $ cd ogpf $ fpm run --example ``` Really wonderful! We can now test Fortran projects at the speed of light… ---
**Author:** ![milancurcic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/milancurcic/32/2_2.png) [@milancurcic](https://fortran-lang.discourse.group/u/milancurcic)\ **Post date:** [April 30, 2021, 4:47pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/45 "2021-04-30T16:47:53Z")
> [@vmagnin](#): > > We can now test Fortran projects at the speed of light… Next step: faster than light! ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 30, 2021, 5:09pm UTC](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110/46 "2021-04-30T17:09:25Z")
> [@milancurcic](#): > > Next step: faster than light! fpm = tachyon > **[Tachyon](https://en.wikipedia.org/wiki/Tachyon)** > > A tachyon (/ˈtækiɒn/) or tachyonic particle is a hypothetical particle that always travels faster than light. Physicists believe that faster-than-light particles cannot exist because they are inconsistent with the known laws of physics. If such particles did exist they could be used to send signals faster than light. According to the theory of relativity this would violate causality, leading to logical paradoxes such as the grandfather paradox. Tachyons would exhibit the unusual property In the... [Previous page](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110.md?page=1) [Next page](https://fortran-lang.discourse.group/t/samples-in-fortran-are-not-acceptable/1110.md?page=3)