None, but nice!
Ada's mechanism is what Fortran has been using and doing for decades.
I strongly disagree. Arbitrary bounds are tremendously helpful in dealing with arrays whose starting point must be offset.
That is simply not true. An educated person with minimal programming exposure can readily pick up modern Fortran programming in 1-3 days at a pragmatic level.
We must disclose that @adgjlsfhk1 works for JuliaComputing. Sometimes they forget to do so on their own.
The comments further above on the inherent limitations of the Julia language as a replacement for Fortran or C++ seem to contradict your opinion.
Did you mean, "Julia never found any widespread adoption and remains an obscure, niche language"? Fortran was the world's top programming language until the new millennium and is still among the top ten most popular.…
Fortran cannot be placed with C in the same category of low programming productivity.
All of them inherit their syntax from the amazing Fortran array syntax.
No, you can still trust compilers: 1) The hand-tuned BLAS routines are essentially a different algorithm with hard-coded information. 2) The default OpenBLAS uses OpenMP parallelism, so much speed likely originates from…
And first of all, Fortran.
Fortran has officially had the concept of modules for 35 years, which just made its way to the C++ world in 2020. It's the people who cannot update and sync with contemporary technology and remain stuck to COMMON blocks.
As someone who has been using about a dozen programming languages over more than two decades, I completely disagree with your experience, some of which appear to be due to incomplete knowledge of the Fortran programming…
I believe the NAG Fortran compiler does check for some aliasing scenarios if not all. The argument intent is irrelevant.
and MATLAB was entirely influenced by Fortran's array-based syntax.
I guarantee, the answer is "no experience".
The "Hiring Fortran programmers is risky" argument is incorrect. This is, in fact, the whole point of Fortran, that anyone as dumb as a rock "would" (not "could" or "might") write performant code. There is currently no…
This process of language love and hatred over a short period is what's called language fad. Ten years ago, people wrote articles praising MATLAB over established languages. I do not recall any of those writings ever…
The hard line limit length is at 1,000,000 characters not 10,000. Also, all major compilers currently have flags to significantly extend the line limit length.
Numpy's vectorized syntax is inspired by Fortran.
The petroleum industry and academia have codebases dating back to FORTRAN66, which are still actively developed, albeit in modern Fortran.
All Julia codes are arbitrarily extensible. Any Julia code can always be readily extended to silently yield incorrect results. That is the whole point of the blog post shared above. Justifying the indefensible is…
That "always" holds for the Julia language almost surely as long as interfaces are missing in the language. It is just a matter of time to find newer issues.
Well said. Now replace "Rust" with "Julia" in your first sentence for a moment of enlightenment for everyone.
Except for the fact that your Julia code will always suffer from correctness problems, something that would rarely if ever happen in Fortran. https://yuri.is/not-julia/
None, but nice!
Ada's mechanism is what Fortran has been using and doing for decades.
I strongly disagree. Arbitrary bounds are tremendously helpful in dealing with arrays whose starting point must be offset.
That is simply not true. An educated person with minimal programming exposure can readily pick up modern Fortran programming in 1-3 days at a pragmatic level.
We must disclose that @adgjlsfhk1 works for JuliaComputing. Sometimes they forget to do so on their own.
The comments further above on the inherent limitations of the Julia language as a replacement for Fortran or C++ seem to contradict your opinion.
Did you mean, "Julia never found any widespread adoption and remains an obscure, niche language"? Fortran was the world's top programming language until the new millennium and is still among the top ten most popular.…
Fortran cannot be placed with C in the same category of low programming productivity.
All of them inherit their syntax from the amazing Fortran array syntax.
No, you can still trust compilers: 1) The hand-tuned BLAS routines are essentially a different algorithm with hard-coded information. 2) The default OpenBLAS uses OpenMP parallelism, so much speed likely originates from…
And first of all, Fortran.
Fortran has officially had the concept of modules for 35 years, which just made its way to the C++ world in 2020. It's the people who cannot update and sync with contemporary technology and remain stuck to COMMON blocks.
As someone who has been using about a dozen programming languages over more than two decades, I completely disagree with your experience, some of which appear to be due to incomplete knowledge of the Fortran programming…
I believe the NAG Fortran compiler does check for some aliasing scenarios if not all. The argument intent is irrelevant.
and MATLAB was entirely influenced by Fortran's array-based syntax.
I guarantee, the answer is "no experience".
The "Hiring Fortran programmers is risky" argument is incorrect. This is, in fact, the whole point of Fortran, that anyone as dumb as a rock "would" (not "could" or "might") write performant code. There is currently no…
This process of language love and hatred over a short period is what's called language fad. Ten years ago, people wrote articles praising MATLAB over established languages. I do not recall any of those writings ever…
The hard line limit length is at 1,000,000 characters not 10,000. Also, all major compilers currently have flags to significantly extend the line limit length.
Numpy's vectorized syntax is inspired by Fortran.
The petroleum industry and academia have codebases dating back to FORTRAN66, which are still actively developed, albeit in modern Fortran.
All Julia codes are arbitrarily extensible. Any Julia code can always be readily extended to silently yield incorrect results. That is the whole point of the blog post shared above. Justifying the indefensible is…
That "always" holds for the Julia language almost surely as long as interfaces are missing in the language. It is just a matter of time to find newer issues.
Well said. Now replace "Rust" with "Julia" in your first sentence for a moment of enlightenment for everyone.
Except for the fact that your Julia code will always suffer from correctness problems, something that would rarely if ever happen in Fortran. https://yuri.is/not-julia/