The reason why this opinion is popular is probably because portability has always been highly considered in the Fortran world. We tend to forget that, now that the x86 platform is super-dominant, but 25 years ago it was common to have the same code running on 3 or 4 different (and often proprietary) platforms, each with its own hardware architecture. Tuning codes with platform dependent instructions was pointless, and we had to rely on the compilers to do the best possible optimizations (and some compilers were indeed incredibly good at that).
2 Likes
Times have changed, and at this point not even SIMD but simply highly multi-processing devices (like GPU and other accelerators) are skyrocketing. One example is SYCL, a framework that allows you to execute your code on the device transparently. It is C++ based. OpenCL does not have any solid bindings (I have yet to found a project which is up to date enough). With CUDA you are locked to one vendor.
The fact that Fortran can multiply arrays on CPU slightly faster is not any advantage in 2023. The ease of development and flexibility is, but the rigidity of Fortran makes it very hard to implement many things. Fortran is far from being the language choice for high-performance solutions, and provides very little in terms of development. It is heartwarming to see discussion about new features (like strings or lists) in recent threads here, and it is only hope that these good changes are blocked, like it used to be in the past.
1 Like
Oh you’re talking about easily interfacing to GPU or other accelerator… Yeah I completely agree. I know CUDA sticks you with Nvidia, but have never looked into OpenCL enough to realize there’s no good C library. That kind of sucks.
I also agree that Fortran and “ease of development” do not go hand in hand together. I forget where I read it but I’ve seen the sentiment before that Fortran is really best for small, simple, read the data in - chunk some numbers and do some math - write the data out type work. Despite its age, Fortran does indeed lack a surprising amount of features one might expect from a “mature” language. Maybe I’m thinking about it wrong, and it shouldn’t be “despite age,” but rather “due to age…”
1 Like
Can you please elaborate on what you mean by,
- “it is only hope that these good changes are blocked, like it used to be in the past.”?
I’m interested in learning more of your message with that last sentence but as stated, it’s unclear to me.
Thanks,
1 Like
Thanks for letting me know 
…
Actually, I totally agree about the weakness of the Fortran “ecosystem” on GPU (or other accelerators), and this is a major concern. IMO this is even THE most critical concern about Fortran as of today, much more than a string or bits type, or than any other why-dont-we-have-this-cool-feature among the ones that are regularly discussed about.
And “unfortunatly”, nobody can be blamed for that.
3 Likes
Imagine a Fortran language version, say Fortran 95 - a version for which quite a few relatively bug-free, stable, and highly optimizing compilers were/are available, and that already included (not true, but imagine so) about 10 or so features, some that were introduced in later revisions:
- intrinsic
STRINGtype that, in addition to jagged arrays, could be used with character data processing with the intrinsic procedures in Fortran 2023 forCHARACTERtype includingSPLIT, etc. including the methods envisioned with erstwhile Part 2 of the standard withISO_VARYING_STRING(now deleted), - intrinsic
BITStype, - and a companion unsigned integers - see proposal(s) by GCC FOSS volunteer Thomas Koenig here,
- Good support for Generics which allows generic procedures, generic containers, and accessors to “contained” data
- Proper enumeration type facility
- Interoperability with C - already included in current or upcoming standard
- Enhanced OO support with the ability to author inextensible types
- IEEE support - already covered reasonably in current or upcoming standard
- Improved error handling, say similar to floating-point handling introduced with signals and methods with
IEEEsupport in #8 above but which extended to error scenarios generally. Meaning, KISS principle and not the challenges and cons withtry..catch..type of exceptions - Enhanced functional programming - mostly covered by the upcoming standard with its
SIMPLEprocedures but which also includesCONSTEXPRfunctions for enhanced compile-time programming.
All 10 of above were within reach of Fortran by the 1995 revision given its rich legacy boosted by the brilliance of Backus and team with the optimizing compiler breakthrough back in the 1950s and high-level language improvements and advances in CS since.
Alas, many of the above facilities never made it in to Fortran and many were late by decades.
But anyway, with such a Fortran language and stable compilers for it, the Community could have far more readily developed a boot-strapping compiler for Fortran in Fortran itself toward additional important features of this decade such as support for GPUs.
Consider most of the Fortran compilers now - it’s evident the number of Fortranners willing to work on the compiler development is grossly inadequate. The front-ends for most or all of them are in some variants of C or C++ and that is a massive barrier, too daunting or insurmountable for most Fortranners perhaps. However, consider many of the newer attempts such as the LLVM-based ones using modern C++. Starting with parsers, so much of the effort toward “lowering” the instructions to the LLVM level involves use of standard C++ containers, overwhelmingly - guess what!! - std::string, and some std::vector.
With a bit of vision, Fortran could have natively provided the facilities and which would INDEED have been used by both the language practitioners and processor developers including toward boot-strapping. That is the missed boat.
There is a part 2 to the notion of Turing-complete languages. Ideally one would want to hang one’s hat on a Turing-complete language or close to it for any serious coding endeavor. Similarly, a simple measure of the easy-of-use and productivity of a programming language is how feasible it is to author a boot-strapping compiler with the language itself. Fortran currently fails miserably in this regard and that is the root of the problem.
It is still not too late for Fortran is my contention. Accomplish a few basic extensions to the language and great things will happen.
And it is NOT a “zero-sum game”. This notion that “oh, Fortran really needs good portable support for GPUs - that’s the pressing need of the hour - and all this about string, bits, and implied save, and implicit none is a distraction” is entirely inane. Things go hand-in-hand. And it should be possible to do simple things simply using a tool and that’s when sound solutions for demanding challenges such as GPU programming shall become viable.
And with some vision and intent, advances can be worked on at the same time, or nearly concurrently.
2 Likes
Thanks. But it’s not at all what I’m saying. What I’m saying is that none of these features will change the face of Fortran, while a good GPU support would. And this is mostly not in the hands of the committee: Cuda, or any other successful langage/library for GPU computations, has not been formalized or developed by the C++ committee AFAIK.
1 Like
I think the inability to write a Fortran compiler in Fortran is an absolutely massive barrier to improvement of the language that really cannot be overstated. Better support for strings, bits, and unsigned integers would go a long way towards breaking down that barrier. Lack of any good enum system is also rather perplexing, and just results in lots of magic number or at best long lists of global named parameters.
One advantage of having waited so long is that by now, there are many successful languages that have demonstrated good implementations of all these systems Fortran currently lacks. So there is no shortage of inspiration.
2 Likes
I remember following some feature proposals that I found highly interersting that have been rejected during votings, after which I kind of gave up hope that anything can be changed. I think it is all public knowledge available in the J3/WG5 websites, nothing secret.
Besides better accelerator support, and all the annoyances I mentioned, I really would appreciate lists and dictionaries in Fortran. Annoying having to implement poor, sub-optimal replacements in a language that has zero support for generics. I recently got back to coding in C++, and while it has its own annoying issues, it is awesome to not have to reivent the wheel every time a new project is started.
1 Like
I kind of disagree. First it takes the language to reach some basic level of functionality, before it can really surpass its competition. Only after the obvious atrocities (like the one I and others mentioned) are fixed, we can speak about how can we make it excel in contemporary computing.
“Can this language do anything besides multiplying numbers?” - a random stackoverflow comment regarding Fortran I encountered the other day. Unfortunately, very true.
3 Likes
Where I’m working, Fortran is gradually abandonned in favor of C++ for the new codes. To schematize, the young use C++, the old still use Fortran. Still, there is a huge base of Fortran code in the software, so that the support for Fortran sources won’t be dropped any time soon, so it’s still possible to write new code in Fortran with recent version of ifort. However, when I suggest that more support could be brought for those willing to use GPUs from Fortran (it could be OpenMP offload, better than nothing), the answer is something like “Cuda is the de facto standard internally, we clearly won’t allocate resources for other approaches”. And because of Cuda, even the ones that would otherwise stick to Fortran sometimes move to C++.
When I ask to C++ writers here (most of them are not computer scientist or software engineers) what does refrain them using Fortran:
- there are the ones who have been taught C/C++ and not Fortran, so they obviously just use what they already know (I would do the same)
- among the ones that can write both C++ and Fortran, the major reason is about GPU : once you have a C++ code that runs on CPU, porting it to GPU with Cuda is quite straightforward, if needed. Another reason is the availabilty of many libraries.
None is answering “I definitely need these sophisticated data structures or features that C++ offers”. And as matter of fact, when I look at some C++ codes that we have, they generally don’t use sophisticated C++ features (and when do, it often looks like a mess): remember, they (we) are mostly scientists/engineers but not software engineers.
Concurrency is not enough, we need parallel processing to do the work!
Here are some lovely cartoons from a book by physicist Sauro Succi that explain the concept:
GPUs are performant because of the number of cores, not clock speed. If everyone makes a small contribution, we can enjoy our work, and make big changes!
But just posting all our gripes to Discourse won’t change a thing. To the contrary, the volunteers who currently contribute their time will burn out or be discouraged to continue.
10 Likes
I must say that, although I am not contributing to any community project related to Fortran, I am sometimes tired by the overhelming negativity that is present in too many opened discussions, whatever the initial topic.
4 Likes
We have to acknowledge problems and talk about them. Certainly Fortran has quirks, just like other languages do. If C++ and Python were perfect, there would be no need for D, Rust, Go, Carbon, Zig, Julia, or Mojo.
Quoting the computing legend Alan Kay again:
Once we start learning something, it’s very hard for us to see what else is going on.
[…]
Probably the most disastrous thing you can ever learn is your first programming language, even if it’s a good programming language. And the reason is it tends to become [what you see as] computing. So it might be better to learn two or three programming languages at the same time even though that’s a different kind of struggle. But it would at least relativize what people think computing might be.
1 Like
It’s the Law of the instrument or “if all you have is a hammer, everything looks like a nail”. The Wikipedia page mentions this anti-pattern is also known as the “golden hammer” in computer programming:
Software developer José M. Gilgado has written that the law is still relevant in the 21st century and is highly applicable to software development. Many times software developers, he observed, “tend to use the same known tools to do a completely new different project with new constraints”. He blamed this on “the comfort zone state where you don’t change anything to avoid risk. The problem with using the same tools every time you can is that you don’t have enough arguments to make a choice because you have nothing to compare to and is limiting your knowledge.”
It works in both directions, Fortran is not always the best solution, and vice-versa.
I agree without any doubt. It’s just that at some point one can even be discouraged to raise some topic, knowing that the discussion will likely turn to “how bad the situation is”, “how culprit J3 is”, “how wrong almost everybody is”, etc…
That’s right, “the right tool for the right job”.
But the limit of the hammer analogy is that learning how to use a hammer takes less time than learning a language. It can take years to really master a language (I can write naive code in C, I do not master C), and when it’s not your core job you don’t have the luxury to learn many of them. So, sometimes the right tool can also be a tool that you master, even if it’s not the absolute best one for the task. Or, the right tool can be the one for which you can easily get support if needed.
1 Like
I know you were speaking specifically to @FortranFan, but I want to make another point:
For me, there are several reasons why it is very unattractive to contribute to gfortran, even though I really like gfortran and it is my main compiler.
I’m used to GitLab and GitHub, because I more or less know what I’m doing there. GFortran and GCC have a very confusing and ugly website. I appreciate the simplicity, but it makes it hard for me to understand how and where to start. By the time I get to the point where I’m asked to join mailing lists, I’m completely lost. Maybe it’s because I’m “too young”, but mailing lists just scare me. Also, I don’t know anything about Subversion, except that it has been de facto irrelevant by today’s standards for at least 5 years.
Also, it would be a lot easier to contribute if I could do it in the language I like: Fortran. I wish there was a Fortran compiler written in Fortran, as many have pointed out before. This is exactly why the founders of this community decided to rewrite fpm in Fortran. Look at how many contributors fpm has.
The question is, what could (realistically) be done, to improve this situation?
4 Likes
Manually rewriting gfortran in Fortran does not make sense, but given that the interoperability of C and Fortran has been standardized, would the current gfortran developers accept new Fortran code contributions that come with C interfaces? That could make sense for implementing things like special functions. My understanding is that LFortran is primarily written in C++ but that Fortran code contributions are allowed.
I wasn’t aware of the transition. All I found yesterday was this page GFortranSource - GCC Wiki pointing to subversion:
You can access the GCC source tree under development from the subversion repository.
Interestingly, following this link takes you to GCC: Anonymous read-only Git access - GNU Project 
The mirror doesn’t serve the purpose I expect from a github/lab repository: Active discussion on issues and pull requests. Issues are completely disabled and pull requests are useless if it’s read-only, and as someone mentioned in a comment on the mirror, it’s not even an official one.
Finally, it’s not a “two-step process”:
-
You have to find the right links. This is easy for projects hosted on github/lab, but for gfortran you have to find your way through lots of links on unformatted/plain websites.
-
You have to “study” how to contribute. Many people know how to contribute to GitHub projects, but submitting patches to GCC isn’t as trivial for new people as one would hope.
-
Submitting is complex compared to opening a pull request on github/lab: you have to find the right mailing list, write an email with the right information to a list, and you cannot see what happens to the mail. (Where does it go? Who can read it? What if I want to change my submission?) This may all be trivial to you, but to me, and I’m pretty sure to all young computer scientists (I’m 26, for reference), this is “new” territory.
-
Before submitting, I like to read other people’s submissions, so I like to browse the github/lab repositories. I like all the tools the hosts offer (search, easy comparison of changes, links between issues and pull requests). The GCC mailing lists do not offer these tools.
So what could be improved? Firstly, I think a user-friendly interface to the git repository is a must. I grew up with a formatted www, so when I open a website that looks older than I am, my first instinct is to close it.
This is my opinion, others may disagree, but I think I speak for many young potential contributors.
I really hope to see GCC, and with it gfortran, in new splendour.
PS: Perhaps a moderator could split this discussion about gfortran into a separate topic?
4 Likes
I think this is a big problem for any old software project.
For example, I work on a project whose origins are older than Fortran 90.
On the one hand, you have experienced developers who are used to passing tarballs around. The only “VCS” they’ve done are comments at the top of the source file, because that was “good practice” back then.
On the other hand, you have young developers who refuse to adapt to these practices because they are now bad practices.
The ratio of experienced to young developers is gradually decreasing. Eventually, there will only be young developers with little experience, and they will have to decide whether to continue with outdated practices, try to modernise the project (which would be a mega-project), or abandon it.
In my case, we took the first step by setting up a git repository. And for gfortran, from what you said, there is movement as well. I don’t know how connected you are to the GCC community and what efforts have been made or are planned, but maybe it would be possible to get more movement into the project with GSOC students. For example, they could build a nice front end for the mailing lists and git repository.