As the discussions toward new ideas and features for Fortran 202Y standard revision have commenced and interest is picking up on improving the communication and education on modern Fortran and its capabilities, it will be very useful to also pause for a moment and reflect on the big picture with Fortran.
Toward this, will it be possible for each of you to please share your own vision of the Fortran language and its applications in computing?
Who do you think the Fortran language and its ecosystem should serve?
What all computing do you think should Fortran get considered?
What all computing accomplishments can be or should be achievable using Fortran over the next 5, 10, 15, … years?
What all facilities must the language standard include to serve the practitioners achieve such computing accomplishments?
Thank you very much for your time and attention, I look forward to your responses.
Serve the more people the better. With emphasis on computation.
There are parts that Fortran are strong at such as numerical computation and array operations etc, let us keep making it as performant as possible.
There are parts that Fortran is not the most versatile at, let us keep making it possible and performant for Fortran to call C/C++, python, R, Julia, etc. So that Fortran can take advantage of other existing languages.
In short, Fortran need not confine/target itself only within academic and HPC circles. The more people can use it and love it the better.
Not very sure what does that mean. But for parallel computing, GPU computing, Fortran should get considered.
More than 5 years may be too long. The next 10, 15 years really depend on what will happen in the next 5 years.
I hope the gfortran can have a windows version with MPI integrated that is just as performant as it on Linux. This will be particularly useful for people who want to use Fortran to develop software on Windows.
Fortran standardization process perhaps need to be speedup. F202X/Y needs to be implemented as soon as possible.
If we can keep up with good ideas from other languages it will be great.
Not sure what does that mean. But I hope
Fortran can have MPI built in (but of course with the option to disable it use external MPI library) just like openMP.
GPU computation ready.
Coarray ready.
PS.
Is there a link or button or something that we can donate money to support Fortran?
I guess the main user-base of Fortran have always been computational scientists and Fortran won’t become popular for game development or customer relationship management.
However, I also think that Fortran shouldn’t become an HPC one-trick-pony. If the niche of an animal gets too small, the animal gets endangered, if a competitor arives in its niche
Even the work of computational scientists does not only consist of numerics, but also of reading files, visualizing things, using user interfaces ect.
So I think that an easy access to libraries written primarily for other languages (the user base of fortran is too small to have a large number of high-qualtity libraries outside of numerics to be developed and maintaibed) is very important.
Concerning this, stdlib and some of the packages in the fortran-lang package list showed that there was really quite a lot of progress.
At the end I think people liking to use a language is similarily important as pure performance (or legacy).
A scientist should use Fortran because it provides a convenient solution for her or his problems rather than she/he has to in order to reuse a 30-year old code of a retired faculty member.
So the scientist can concentrate on their goal instead of being busy to find workarounds for problems with their code.
I agree with CRquantum that in computing planning for the next 15 years may not really be possible and that the long-term future of Fortran depends on the next few years.
I essentially agree with @Jweber. I would like fortran to be a more general purpose language with emphasis on HPC. More libraries to do more things, covering a spectrum as wide as possible.
In addition, and again in agreement with @Jweber, at some point a debate about what features kept for retrocompatibility are to be retired from the very first line (and instead enabling them via a compiler flag, or with a special header at the beginning, or via preprocessor, or whatever) should, in my opinion, be addressed. I am writing this with the “fortran marketing” idea in mind. It is true that the retrocompatibility is one of the strengths of fortran, but only until it becomes a ballast.
Please note in the “world” of Fortran, compilers can take well over 10 years, at times longer than 20 years, to implement standard features, let alone arrive at a point of robustness and compiler optimization efficiency.
A simple case in point is enhanced data facilities and the ALLOCATABLE attribute from 1998 and which was adopted in Fortran 2003 revision in year 2004. Here we are a couple of decades later and believe me, there are teams who find the compiler implementations with this facility to be either suboptimal or buggy and who therefore either continue to code in legacy style FORTRAN 77+non-standard extensions or using the Fortran 90/95 approach, both of which rightfully finds a lot of detestation among the newer generation and/or the management. Such issues then add to the list of justifications to migrate away from Fortran.
The above is just one example; Fortran 2003, 2008, and 2018 include other facilities that are buggy or not even performant with compilers. Coarrays, part of official standard 12 years ago(!), is another case where one major compiler vendor has not even started looking at performance optimization yet.
Note many of the features in the current Fortran 202X draft will not see the light of day in terms of compiler support for years, perhaps not even by year 2030.
Thus it is imperative, I feel, for anyone interested in Fortran to start adopting the very, very long-term view of the situation and develop a vision that can help to adapt to the circumstances. Either that, or migrate away from Fortran because this is a serious, serious problem.
When I mentioned the 15 years I meant that I my opinion it won’t make a lot of sense to plan for the state of Fortran in 2037.
And, to use my example from above, the 30-year old code of the retired faculty member should be able to be used, it just should not be the only reason to use fortran.
I’m a total newcomer to Fortran and anything I say should probably be taken as an outside perspective, or at least with a grain of salt. That said, I have already found a lot to like in the language.
One of the problems that I see in software in general is a constant feature creap. I like what I see in Fortran because it does not take a lot of mental overhead to grasp the language itself. I would hate to see that change because it’s a rare and beautiful thing. I do like the push for a Standard Library and the fpm package manager, which I have tried and find to be excellent. However, I think the language is best served by keeping such things as optional third party tools.
So my two cents would be, continue to keep the core of the language small as it currently is, while continuing to expand the library ecosystem.
Welcome to this Discourse and hopefully you will continue with Fortran. And thank you for your comments.
So per your comments, on the very first aspect of “For whom Fortran”, are you saying
Fortran should only be for a “total newcomer” such as yourself?
that the base language should be “small” so that you and anyone else approaching Fortran similarly cannot and will not expend “a lot of mental overhead to grasp the language itself”?
You may know FORTRAN I circa 1957 was extremely, extremely small and FORTRAN 77 from ANSI 1978 was rather small too - many newcomers could learn it in less than a day.
You may know also it was immediately clear before even the ANSI standard terms were settled upon, the language was inadequate to do anything useful in actual scientific and engineering codes, especially if two or more engineers needed to collaborate and work on the same codes. Almost immediately the scientists and engineers turned to their compiler vendors to provide all kinds of useful but non-standard extensions to be able to write production codes.
The problems faced during the second half of 1970s continues to this day when it comes to authoring performant libraries and production programs and simulation applications using Fortran 2018 and they will persist with Fortran 202X. Simple good coding practices accepted during the 1980s thru the 2000s to write good libraries aren’t even viable with current Fortran.
It is all well and good to think someone wants something small but one then cannot have the Fortran is a big tent approach even for the rather small and limiting scientific and technical programming domains and their needs, the language becomes exclusionary.
I don’t see any other camp in the top languages adopted by engineers in industry accepting any such parochial mindset.
Not necessarily, but I can see how my comment might come off that way. It’s more about where the complexity is placed. Having a good deal of that complexity in a good library ecosystem with a tool like fpm available to easily access it is (at least to me) preferable to having it at the language level where possible.
I would actually argue somewhat on that. While it’s certainly true that the scope of a language like C++ is huge, C itself is staunchly conservative in regards to both change and to language additions.
Going just a bit further down the list that you linked, you run into Go, which I don’t think anyone can reasonably say has not seen massive success, and which is arguably a dead simple language.
I do appreciate your taking the time to go through some of Fortran’s history for me. I am, as I stressed, new to Fortran, and enjoy learning whether it be about code itself or just a simple history lesson.
It will be good if @jeang3nie and other readers can share their thoughts and vision here on where the balance should be.
I will give a simple example: Fortran introduced with ANSI FORTRAN 66 back in 1966 i.e., over 55 years ago the notion of generic functions including functions with a variable number of arguments e.g., MAX. However the language to this day has not offered a practitioner to write their own (say as part of a "library ecosystem) any reasonably good facility to author anything equivalent in Fortran itself. Now I have needs in my own domain to write such functions and so do my peers; conceivably a statistician too may want something similar starting with MEAN and so will users in other domains.
But now if one wants to something similar in Fortran, one effectively needs to resort to means other than Fortran (perhaps ASSEMBLER) to construct a non-standard extension of the language. Or manage without it, or migrate away from Fortran. But why?
Hence this begs the question, “For whom Fortran? For what?”
So again, if the view is C is adequate, or the C language evolution approach is the one desired since the standards development for this language is now mostly in maintenance-only mode, then why bother with Fortran at all? Or why have any standard revisions at all? In fact, there are those who think FORTRAN 77 should have been the end of it though these same folks immediately also seek select set of “pet” features - free-form source, MODULEs, ALLOCATABLE facility, etc. Again, where should be the balance? And for which target group of users and for what?
Interesting that Go language recently introduced Generics facility. And with this, it signals it is neither dead nor simple! Both the semantics and syntax toward generics in Go is rather involved and not all that easy to pick up. Moreover the syntax for generics in Go now reads like morse code, full of special symbols but they went for it and the users will learn, the human mind is after all truly remarkable.
Nonetheless, the point is every language has to evolve to remain relevant and usable. Where should be the balance with Fortran?
All of this calls for vision, hence my request with this thread.
The fallback option otherwise is the current plebiscite with simple majority of votes but where the votes can be devoid of any vision or passion for the language but dictated simply by where some entirely remote managers at vendors want for Fortran (even death as some wanted during the 1980s battles for what eventually became Fortran 90) or who is asking for what or who likes whom which is very much the case as noticeable by what gets upvotes at J3-Fortran proposals site. I contend this is not good for the language evolution and it largely explains the half-baked, inconsistent additions of whatever has been added to Fortran for a while now.
As regards the proposals, I wonder how others are rating them? I took the approach of looking at each proposal and considering if it had affected whether I wrote a program in Fortran or not. If that feature had been present and would have changed my decision on whether to use Fortran or another language I rated it high. Using that criteria heavily changed my initial preferences that I had from just perusing the list. Then I removed ones that clearly could be handled by an external standard library or package. The list changed dramatically (POSIX-like system interfaces are commonly a reason, for example). So a successful standard library would have changed a lot of decisions. Better support for coarrays (implying GPU support) would have made a huge change in my selection of languages. So instead of voting on specific topics,
I (too?) would like to see a rating from 1 to 10 of general categories (ease of use, access to standard libraries, parallel performance, … ) myself, which is at least a step towards looking at how important new directions are; or perhaps reaffirming that the core language should concentrate on functionality useful to HPC users, and that the community must supply and support other interfaces.
PS: It is personally disappointing none of the proposals include at least a low-level graphics capability. I think Fortran users look at more XY plots than any other group I know of, and Fortran once owned the graphics world pre {Unix,C,X11}.
Runs on all platforms, including smartphones and embedded systems
Stability over decades
Prompt improvements in response to changes in application areas
Ease of learning
Small
Support popular programming styles (e.g. object-oriented programming and generic programming)
Whatever helps analysis of programs
Lots of facilities
Supported by a large community
Supportive of novices (students, learners)
Lots of software development tools available
Lots of software components available (e.g. libraries)
Supported by an open source community
Supported by major platform vendors (Microsoft, IBM, etc.)
Unfortunately, we can’t have all this at the same time.
…
He notes that #8 and #9 conflict, as do #13 and #14 with #15.
One could rate Fortran by these criteria and ponder where improvement is needed and feasible.
Reading through this list, it seems to me that he refers to a programming language ecosystem as a whole, and not just the language itself. E.g. items 18 through 23 don’t seem to me like properties of a language itself. I only mention this because I often see the two (language and ecosystem) confused and/or conflated. Of course, the language itself and the ecosystem feedback to one another and can both thrive only in a symbiosis.
Since the proposals are for the language standard (as opposed to stdlib or some such), perhaps you can explain in this day and age how “a low-level graphics capability” might fit into the language instead of being “handled by an external standard library or package”?
I was describing the criteria I decided to use, not what everyone else did in creating the proposals; so others were free to propose graphics, POSIX-like system interfaces, … Graphics would indeed fit into an external library. I feel portable support for graphics is a major feature lacking in Fortran, and its absence is often a reason for having to use other languages.
I have thought this and felt there needs to be a better consensus and understanding and care and passion toward whom Fortran language seeks to serve for their programming needs.
Hence the question for “For whom Fortran? For what?”
Consider several fields:
A developer-user in the supercomputer domain working with code authored individually or only a few other subject-matter experts in legacy FORTRAN plus possibly non-standard extensions plus certain features since Fortran 90 and where code changes and refactoring occur over decades of planning and validation.
Developer-users of commercial/non-profit libraries and applications toward a few specific scientific/technical domains on targeted platforms (usually Windows and *UX) who need to interoperate with processors other than Fortran and who need to remain competitive (wrt whatever measures they see fit) and move rapidly with various “customer” and “market” requirements,
One-person teams of developers of all kinds who use Fortran as part of their pursuits, whether professionally in industry/research/academia or personal hobbies,
Large teams globally in industry/research/academia/intergovernmental agencies, etc. looking to build new huge applications, say massive simulation frameworks involving multiphysics architectures, to tackle big problems e.g., transform the global energy sector away from its dependence on fossil fuels and who want to use modern Fortran from the ground up.
The perspective and rating of core language features can differ considerably just among the above 4 fields. I am likely missing out on other scenarios involving Fortran.
I feel the standard development thus far has been influenced greatly by field #1 above and this includes resistance to change in several aspects.
Forums such as these tilt more toward field #3, the individual “warriors”.
But it will be useful to understand for whom all Fortran seeks to serve and for what. Are those in fields 2 and 4 above also to be served and if so, how and to what extent and at what pace? What about others?
Can this lead to a vision for Fortran and eventually mission for standard-bearers to advance the language rather than the ad hoc but somewhat minimalist approach now toward each revision?
It will help if you can be more precise here. What do you mean by “lacking in Fortran”? Is it the language standard, the external libraries, or both?
I personally think it is both. Meaning, should Fortran language standard introduce just a couple of items:
Either intrinsic and safe support for unsigned integers similar to other modern languages (e.g., Julia) and/or intrinsic BIT data type,
Improved error termination semantics toward safety and reduced vulnerabilities generally but also in interoperation with a C companion processor particularly.
then it will really greatly accelerate the advancement of modern and powerful external/stdlib libraries for graphics packages in Fortran.
@milancurcic mentioned “symbiosis”: the above 2 items in the language standard will facilitate the symbiosis for graphics capabilities.
