# For whom Fortran? For what?

**URL:** <https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378>\
**Category:** Language enhancement\
**Created:** [May 4, 2022, 5:52pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378 "2022-05-04T17:52:43Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\
**Post date:** [May 4, 2022, 5:52pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/1 "2022-05-04T17:52:43Z")

</div>

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.

Best Regards,

---

<div class="post-metadata">

**Author:** ![CRquantum](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/crquantum/32/730_2.png) [@CRquantum](https://fortran-lang.discourse.group/u/CRquantum)\
**Post date:** [May 4, 2022, 6:46pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/2 "2022-05-04T18:46:05Z")

</div>

> [@FortranFan](#):
>
> Who do you think the Fortran language and its ecosystem should serve?

Serve the more people the better. With emphasis on computation.

1. 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.
2. 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.

> [@FortranFan](#):
>
> What all computing do you think should Fortran get considered?

Not very sure what does that mean. But for parallel computing, GPU computing, Fortran should get considered.

> [@FortranFan](#):
>
> What all computing accomplishments can be or should be achievable using Fortran over the next 5, 10, 15, … years?

More than 5 years may be too long. The next 10, 15 years really depend on what will happen in the next 5 years.

1. 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.
2. 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.

> [@FortranFan](#):
>
> What all facilities must the language standard include to serve the practitioners achieve such computing accomplishments?

Not sure what does that mean. But I hope

1. Fortran can have MPI built in (but of course with the option to disable it use external MPI library) just like openMP.
2. GPU computation ready.
3. Coarray ready.

PS.  
Is there a link or button or something that we can donate money to support Fortran?

---

<div class="post-metadata">

**Author:** ![Jweber](https://avatars.discourse-cdn.com/v4/letter/j/e95f7d/32.png) [@Jweber](https://fortran-lang.discourse.group/u/Jweber)\
**Post date:** [May 4, 2022, 8:10pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/3 "2022-05-04T20:10:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![conradoat](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/conradoat/32/1537_2.png) [@conradoat](https://fortran-lang.discourse.group/u/conradoat)\
**Post date:** [May 4, 2022, 8:37pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/4 "2022-05-04T20:37:16Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\
**Post date:** [May 4, 2022, 9:31pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/5 "2022-05-04T21:31:13Z")

</div>

> [@CRquantum](#):
>
> More than 5 years may be too long

> [@Jweber](#):
>
> 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.

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**](https://standards.iteh.ai/catalog/standards/iso/83193696-5ff8-40db-9bb0-7ea3ba8831fb/iso-iec-tr-15581-1998) 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. **Coarray** s, 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.**

---

<div class="post-metadata">

**Author:** ![Jweber](https://avatars.discourse-cdn.com/v4/letter/j/e95f7d/32.png) [@Jweber](https://fortran-lang.discourse.group/u/Jweber)\
**Post date:** [May 5, 2022, 3:55am UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/7 "2022-05-05T03:55:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![CRquantum](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/crquantum/32/730_2.png) [@CRquantum](https://fortran-lang.discourse.group/u/CRquantum)\
**Post date:** [May 5, 2022, 6:39am UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/8 "2022-05-05T06:39:39Z")

</div>

I recommand Dr. Fortran @sblionel 's article, I see many positive efforts towards making the Fortran standard upgrade more and more efficient.

> **[Doctor Fortran in "Forward!" - Doctor Fortran](https://stevelionel.com/drfortran/2020/04/25/doctor-fortran-in-forward/)**
>
> Welcome to the new home of the Doctor Fortran blog! Given that I have been retired from Intel for more than three years, it seemed appropriate to give my posts their own home on my web site. With Intel’s permission, I have copied here the posts I...

With regard to very long term view of Fortran, I recommend YAGNI,

> **[You aren't gonna need it](https://en.wikipedia.org/wiki/You_aren't_gonna_need_it)**
>
> "You aren't gonna need it" (YAGNI) is a principle which arose from extreme programming (XP) that states a programmer should not add functionality until deemed necessary. XP co-founder Ron Jeffries has written: "Always implement things when you actually need them, never when you just foresee that you need them." Other forms of the phrase include "You aren't going to need it" (YAGTNI) and "You ain't gonna need it" (YAGNI).
> YAGNI is a principle behind the XP practice of "do the simplest thing that...

---

<div class="post-metadata">

**Author:** ![conradoat](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/conradoat/32/1537_2.png) [@conradoat](https://fortran-lang.discourse.group/u/conradoat)\
**Post date:** [May 5, 2022, 7:15am UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/9 "2022-05-05T07:15:54Z")

</div>

I think the same: legacy code should be able to be used, but that should not be the only reason to keep/use fortran.

---

<div class="post-metadata">

**Author:** ![jeang3nie](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jeang3nie](https://fortran-lang.discourse.group/u/jeang3nie)\
**Post date:** [May 5, 2022, 3:48pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/10 "2022-05-05T15:48:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\
**Post date:** [May 5, 2022, 4:59pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/11 "2022-05-05T16:59:07Z")

</div>

> [@jeang3nie](#):
>
> … 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.

@jeang3nie ,

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

1. Fortran should only be for a “total newcomer” such as yourself?
2. 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**](https://spectrum.ieee.org/top-programming-languages/#/index/2021/0/0/1/0/1/50/1/50/1/50/1/30/1/30/1/20/1/20/1/5/1/50/1/100/1/50/) adopted by engineers in industry accepting any such **parochial** mindset.

---

<div class="post-metadata">

**Author:** ![jeang3nie](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jeang3nie](https://fortran-lang.discourse.group/u/jeang3nie)\
**Post date:** [May 5, 2022, 10:41pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/12 "2022-05-05T22:41:57Z")

</div>

> [@FortranFan](#):
>
> So per your comments, on the very first aspect of “For whom Fortran”, are you saying
> 
> 1. Fortran should only be for a “total newcomer” such as yourself?
> 2. 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”?

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_.

> [@FortranFan](#):
>
> I don’t see any other camp in the [**top languages**](https://spectrum.ieee.org/top-programming-languages/#/index/2021/0/0/1/0/1/50/1/50/1/50/1/30/1/30/1/20/1/20/1/5/1/50/1/100/1/50/) adopted by engineers in industry accepting any such **parochial** mindset.

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.

---

<div class="post-metadata">

**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\
**Post date:** [May 6, 2022, 12:14am UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/13 "2022-05-06T00:14:23Z")

</div>

> [@jeang3nie](#):
>
> > [@FortranFan](#):
> >
> > So per your comments, on the very first aspect of “For whom Fortran”, are you saying
> > 
> > > 1. Fortran should only be for a “total newcomer” such as yourself?
> > > 2. 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”?
> 
> Not necessarily … 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_ .

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?”

> [@jeang3nie](#):
>
> > [@FortranFan](#):
> >
> > I don’t see any other camp in the [**top languages**](https://spectrum.ieee.org/top-programming-languages/#/index/2021/0/0/1/0/1/50/1/50/1/50/1/30/1/30/1/20/1/20/1/5/1/50/1/100/1/50/) adopted by engineers in industry accepting any such **parochial** mindset.
> 
> 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.

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, `MODULE`s, `ALLOCATABLE` facility, etc. Again, where should be the **balance**? And for which target group of users and for what?

> [@jeang3nie](#):
>
> 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. …

Interesting that [**Go language recently introduced Generics facility**](https://www.infoworld.com/article/3646036/get-started-with-generics-in-go.html). 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**](https://github.com/j3-fortran/fortran_proposals/issues). 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.

---

<div class="post-metadata">

**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\
**Post date:** [May 6, 2022, 1:16am UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/14 "2022-05-06T01:16:12Z")

</div>

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}.

---

<div class="post-metadata">

**Author:** ![conradoat](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/conradoat/32/1537_2.png) [@conradoat](https://fortran-lang.discourse.group/u/conradoat)\
**Post date:** [May 6, 2022, 7:54am UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/15 "2022-05-06T07:54:03Z")

</div>

@urbanjost

👏 👏 👏 👏 👏 👏 👏 🙌 🙌 🙌 🙌

---

<div class="post-metadata">

**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\
**Post date:** [May 6, 2022, 2:55pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/16 "2022-05-06T14:55:39Z")

</div>

Stroustrup’s [Principles and Practice Using C++ (2nd ed) (2014)](https://www.stroustrup.com/programming.html) lists the following desirable properties of a programming language:

> 1. Portability
> 2. Type safety
> 3. Precisely defined
> 4. High performance
> 5. Ability to concisely express ideas
> 6. Anything that eases debugging
> 7. Anything that eases testing
> 8. Access to all system resources
> 9. Platform independent
> 10. Runs on all platforms, including smartphones and embedded systems
> 11. Stability over decades
> 12. Prompt improvements in response to changes in application areas
> 13. Ease of learning
> 14. Small
> 15. Support popular programming styles (e.g. object-oriented programming and generic programming)
> 16. Whatever helps analysis of programs
> 17. Lots of facilities
> 18. Supported by a large community
> 19. Supportive of novices (students, learners)
> 20. Lots of software development tools available
> 21. Lots of software components available (e.g. libraries)
> 22. Supported by an open source community
> 23. 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.

---

<div class="post-metadata">

**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:** [May 6, 2022, 3:51pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/17 "2022-05-06T15:51:21Z")

</div>

> Stroustrup’s [Principles and Practice Using C++ (2nd ed) (2014)](https://www.stroustrup.com/programming.html) lists the following desirable properties of a programming language:

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.

---

<div class="post-metadata">

**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\
**Post date:** [May 6, 2022, 3:58pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/18 "2022-05-06T15:58:42Z")

</div>

> [@urbanjost](#):
>
> … I removed ones that clearly could be handled by an external standard library or package. …
> 
> PS: It is personally disappointing none of the proposals include at least a low-level graphics capability.

@urbanjost ,

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”?

---

<div class="post-metadata">

**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\
**Post date:** [May 6, 2022, 4:11pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/19 "2022-05-06T16:11:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\
**Post date:** [May 6, 2022, 4:30pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/20 "2022-05-06T16:30:23Z")

</div>

> [@urbanjost](#):
>
> 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

> [@Beliavsky](#):
>
> One could rate Fortran by these criteria and ponder where improvement is needed and feasible.

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:

1. 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.
2. 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,
3. 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,
4. 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?

---

<div class="post-metadata">

**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\
**Post date:** [May 6, 2022, 4:43pm UTC](https://fortran-lang.discourse.group/t/for-whom-fortran-for-what/3378/21 "2022-05-06T16:43:07Z")

</div>

> [@urbanjost](#):
>
> … I feel portable support for graphics is a major feature lacking in Fortran …

@urbanjost ,

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:

1. Either intrinsic and safe support for **unsigned integers** similar to other modern languages (e.g., **Julia** ) and/or intrinsic `BIT` data type,
2. 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.
