# How to solve the same numerical Problem in 7 different Programming Languages

**URL:** <https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548>\
**Category:** Uncategorized\
**Created:** [May 25, 2022, 4:13am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548 "2022-05-25T04:13:09Z")\
**Posts on this page:** 1\
**Showing post:** 168

<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:** [June 2, 2022, 11:44pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/168 "2022-06-02T23:44:13Z")

</div>

> [@kargl](#):
>
> Your response was expected. Break standard conforming code is a good thing.

- Re: “Break standard conforming code is a good thing”, note **Fortran 202X breaks conforming code** and it was ok with the committee, why is that?

There are at least two apps in production use with a team I have worked with in industry who have conformant and functioning Fortran library code which will **break** on account of the change brought about by the standard committee with Fortran 202X. The following trivial reproducer gets to the underlying issue:

```fortran
   integer, parameter :: LENS = 10
   character(len=:), allocatable :: s
   s = repeat( ' ', ncopies=LENS )
   write( s, "(g0)" ) "x"
   print *, "len(s) = ", len(s)
   print *, len(s) == LENS
end

```

The behavior of the program per current standard is

```auto
 len(s) = 10
 T

```

With a Fortran 202X conformant compiler, the behavior will change to

```auto
 len(s) = 1
 F

```

The above apps rely on the string length not changing due to subsequent internal I/O once they are allocated to certain desired length in another part (initialization) of the library.

I brought my concerns due to this change and its implications to the committee members several times, even during the committee meeting. But to no avail. Perhaps it is because the above two apps are not of interest to the holy “they” of the @mecej4 fame, so breaking these apps is entirely ok? This is why keep asking **“For whom Fortran, for what?”**

- Re: “Your response was expected.” - a needless and useless comment again, veering again toward `ad hominem`.

I do **NOT** espouse breaking change generally. However **implicit mapping** and **implied save** are 2 aspects where the benefits to Fortran from doing away with them far exceed the status quo. With **implicit mapping** , it will be over 50 years of recognition - imagine that, 50 years! - that its use can lead to unsafe code. Few languages out there hold on to a bad feature like that.

---

_[View the full topic](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548)._