F'77 added arbitrary lower bounds on arrays, including explicit-shaped and assumed-shaped dummy arrays. It is a useful and portable feature, though somewhat confusing to newcomers when they try to pass an array with non-default lower bounds as an actual argument and they don't work as one would expect.
F'90 added arbitrary lower bounds on assumed-shape dummy arrays, as well as on allocatables and pointers. Still pretty portable, though more confusing cases were added. F'2003 then added automatic (re)allocation of allocatables, and the results continue to astonish users. And only two compilers get them right, so they're not portable, either.
Ada's array indexing is part of its type system. Fortran's is not (for variables).
I didn't say that they were not helpful; I said they have dangerous pitfalls. Also, they're not perfectly portable. My testing shows that only two compilers get lower bounds right in all the tricky cases that I know of.
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.
However, I have read enough Fortran and C++ written by scientists, to fervently wish that their code had been written in Julia instead. In Julia, I don't think they could manage to write code so debauched. If you just do things the naive way, usually life is good and code is both readable and fast.
The pitfall is type instability and memory allocation, but I think with a few basic tricks, people can learn to avoid this, especially for simpler tasks. (edit: also, if people do mess this up, they notice because their code is slow. whereas people don't notice if their code is fast but incomprehensible and impossible to maintain or extend.)
there exist many high quality criticisms of Julia's type system, but this article does not contain them if I'm being totally honest. I think this writeup here https://viralinstruction.com/posts/badjulia/#the_type_system... contains more valid gripes about the type system than the one you linked.
Using Union as an example is more understandable than using abstract types. I can also explain why abstract types are broken, but that would involve a complex interaction of subtyping and abstract interpretation.
In addition, I believe that abstract types are not that horrible since in industry we use OOP any way (https://github.com/Suzhou-Tongyuan/ObjectOriented.jl). I coworked with the author of this package several years ago. Currently, he is developping a different branch of Julia compiler. Since OOP makes eveything easier to design (from linter to static compiler), and programmers prefer OOP over abstract types, I personally don't think they will cause huge problems.
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. Arrays in Fortran can start from any index; the default choice is 1, which can be overridden with literally one keystroke: 0.
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 multithreading. Set OMP_NUM_THREADS environment variable to 1 before running your benchmarks. You will still see a significant performance difference due to a few factors, such as extra hard-coded information in OpenBLAS implementation.
I ran with OMP_NUM_THREADS=1, but your point is well taken.
As for the original post, I felt a bit embarrassed about my original comments, but I think the compilers actually did fairly well based on what they were given, which I think is what you are saying in your first part.
