You left Intel off the vendor list. Your point remains valid - users outnumber vendors on the US committee. The imbalance is even greater on WG5.
Right you are! The Excel filter I used for counting looked at Participant Class == Principal && Membership Class == (Voting || Advisory) && Role == Member. Intelâs Principalâs Role is âSecretaryâ⌠(Lorri)
The overall listing doesnât reveal the true picture. This meeting minutes is more indicative and the voting history in it is more reflective of reality:
- 6 out of 11 in attendance during most votes were vendors; in addition, at least 3 of the remaining largely vote as the vendors do showing their tremendous influence,
- one nonvoting member is a vendor who carries perilous and outsized influence on how others vote, especially other vendors, and has multiple roles which is extremely unhealthy,
- an appreciable percent of non-vendor voting members on the committee tend to be not only absent or silent in the meetings, their orgs have a massive sustainability risk in terms of continued support for Fortran (a fair number of readers here have seen the white paper from LANL on the future of Fortran in their org).
- the real heart of the users, the global community of Fortran practitioners, really donât have a seat at the table when in fact they should be dictating how the language evolves and the vendors should be guiding them along wholeheartedly to do in the right way. But instead it is the exact opposite.
There is no denying there is deep-rooted problem for the users when it comes to the committee because the vendors simply do not care enough for them.
This thread is a simple, straightforward illustration: it shows users calling out at least since 1984 (see the paper shown upthread by Metcalf back then) to this date for a string type.in Fortran. That is around 40 years or more! The number of instances when a practitioner online - whether at this forum, or Intelâs, or comp.lang.fortran, or StackOverflow - has expressed a need that can be readily met with an intrinsic string type in Fortran is countless.
Yet the poor, persevering practitioners of Fortran can bet their last dollar none of the voting members will go to âbatâ for the users; will not resolve to get this done in Fortran 202Y or 203X or 203Y or 20XY, that itâs high time, we will âjust do itâ and complete the work which is mostly with Edits to the standard document, a task that can be readily crowdsourced but for the sheer failure of imagination of these committee members. At best, a proposal will be condescendingly tabled, the nonvoting member of outsized influence will shout it down proclaiming there is no need for this in the standard, and all the vendors will vote in unison to not add the type, the countless users online who asked for it be damned.
The fact is there is absolutely no vision on the committee as to the possibilities with Fortran in scientific and technical computing, especially considering the challenges globally as the energy needs of the world call for a massive paradigm shift away from fossil fuels, possibly requiring >US$100 trillion dollars of investment over the next 100 years. It is beyond shameful the hidden figures mostly think of budgets in their orgs and balk at the one-time cost which is mostly word-smithing an absolutely silly document in the standard but fail entirely to see the forest for the trees when it comes to long-term benefits yielded by said features via more productive application of Fortran in computing where working with strings is also crucial.
So no, the point by @gak isnât valid, neither in letter but especially not in spirit.
Wasnât this about arrays and strings?
3 Likes
Thank you @ivanpribec for pointing to stdlib string_type module. Unfortunately this contribution to strings from the Fortran community seems to be often forgotten/neglected (and to be honest, I am tired to always remind it to almost the same people in the always same kind of discussions).
As mentioned by @ivanpribec (or, e.g., here), I believe that stdlib_string_type module could be used as a starting point as it proposes a string_type and most of (all?) the intrinsics are overloaded for this string_type , as well as IO operations.
@FortranFan: we got your points. While I may agree with some of them, repeating them in all the threads usually result in deviating them, which does not help the discussion on the real topic (like here: strings)
Suggesting that these users do not have their freedom of vote or that they donât honestly vote is a serious and insulting accusation, unless you have evidences.
I agree with this sentiment. It may be untrue, but this is how the committee seems to have worked over the past years and decades from my perspective as an outsider. I thought adding Milan Curcic to the committee meant a step toward giving the community a seat and a voice to be heard (This is what I took away from a comment by Certik in this forum). Aside from the national labs, each of which appears to have a seat, I am still looking forward to seeing the positive effects and impacts on the communityâs needs at a faster pace.
This apparent lack of committee action is partly due to the rapid change in the landscape of HPC, which is now dominated by data science and machine learning. These new disciplines require new tools and features in the language, which do not seem to have been the committeeâs priorities. This means adding features to the language, which may seem too trivial or easy to implement by the programmers or may have nothing to do with HPC number crunching directly but are a true time saver when we look at the big picture, an example of which is being discussed in this thread (another example, multiline strings similar to Python docstring). Fortran can be a leader in these emerging disciplines or a late follower, depending on how the committee sets the priorities.
1 Like
I have neither the time nor the energy to do a point-by-point rebuttal.
From my perspective watching languages evolve for the past forty years, Iâm not sure that the standards body itself is the right place for innovation in the programming language. I believe standards (usually) best serve by codifying largely-agreed-upon directions for the language, and common behavior across implementations. Speculative language development is a real gamble. For Fortran, Part 2 (Varying Length Character Strings; not required) has been dormant since 2000, and Part 3 (Conditional Compilation) was withdrawn. FORALL is obsolescent. Etc.
I believe the Fortran vendors do listen to their customers. They like to keep the ones they have, and get new ones. I have not seen the vendors collude to avoid adding the (e.g.) AI or HPC features that AI and HPC practitioners say they need. Not in the market, and not in the committee.
So,
- Lobby your favorite vendors to implement features you need.
- Write cogent papers for the committee that highlight tangible benefits worth adding to the language forever.
- Understand the costs of implementation to ensure that the change is worth adding to every implementation.
6 Likes
This is actually a major concernâŚ
Whenever I encounter the split() functionality in the new standard, I ask myself why split()? What made splitting a string more exciting or more important than other string operations like replace() or remove() or ranked select() or sort() or � What is the origin or the necessity of this piecemeal approach to adding new features to the language? Why could not we have all these essential functions in the language along with split()?
While reading or responding to these questions, please remember that I do not mean to blame or undermine the committeeâs efforts, which we all appreciate, with such discussions. What I hope everyone can take away from these discussions is either cogent answers to usersâ questions and, perhaps, confusion or improvements to the standardization process by resolving the gaps identified.
2 Likes
split was brought into the language from ISO_VARYING_STRINGS, an intrinsic module that was an optional part of the language starting with Fortran 95. There was a canonical implementation using pointers, but that had memory leaks. A rewrite with allocatables was created later. It never really solved the problems people wanted to solve, and the creation of deferred-length allocatable character, eliminated most of the need for the module. The only part still absent was split.
An early specification for split had two different interfaces for differing use cases. The second interface was split (!) out into tokenize.