2 ms·

If there are reasons that are beyond "I already know Fortran" then please share. As my comment has pointed out the reasons mentioned above are incorrect. Modern

If there are reasons that are beyond "I already know Fortran" then please share. As my comment has pointed out the reasons mentioned above are incorrect. Modern C++ compilers, Rust, and Julia all have the edge on Fortran in their use case. Also, people are now moving away from Fortran. There's a huge push in my field to use python and many students (like me) are't using Fortran.

rspeer 10y ago
These are some pretty naive suggestions for how to uproot an entire domain of computing. Julia is a JIT language. Whatever edge you get in pretty code is going to be paid for in speed. Also, it's pre-1.0 and breaks compatibility frequently. 40-year-old Fortran code runs fine; 2-year-old Julia code is a syntax error. Rust is a nice language, but all of its numerical computing is experimental 0.x stuff. You'll probably end up wrapping another library to do your number crunching. It's probably written in Fortran. C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran. I have seen a couple of projects that tried to port Fortran libraries to C++. They came out slower, buggier, and less readable. The only reason you'd want to do that is a specific hatred for Fortran -- which you are not the only one to have, but over the decades it hasn't proven to be a good motivation for redesigning software. Of course people like to use Python, but you don't get to use Python instead of Fortran. That would be incredibly slow. You use Python and Fortran. For example, you use NumPy and SciPy, which make Python a great high-level platform for numerical computing because they wrap large amounts of Fortran code. If you use Python for numerical computing, you are not "moving away from Fortran", you're embracing its success. I don't actually know Fortran, but I have huge respect for the people who do. They're the reason most of the things I do are possible and fast.
- one-more-minute 10y ago
  Julia is JITed, but not in the same sense that (say) JavaScript is. It's more like a very lazy AOT compiler – and it can certainly hold its own against Fortran. That's not to say it has every optimisation it could, but the JIT is not the bottleneck there. 1.0 will be out around midway through the year, so that will ease the growing pains.
- gravypod 10y ago
  > Julia is a JIT language. Whatever edge you get in pretty code is going to be paid for in speed. That is incorrect. This nonsense that JIT is slow is an old belief that's hung around because it sounds nice. The fact is that the numbers don't line up [0]. > Rust is a nice language, but all of its numerical computing is experimental 0.x stuff. You'll probably end up wrapping another library to do your number crunching. It's probably written in Fortran It's new and it's growing. It's also a single example for a single case. But it even still have a comprehensive numeric library [1]. > C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran I don't know how this could be the case (especially with the addition of shared pointer) but you shouldn't be writing code with huge shared memory dependencies. Use constexpr, use inline, and use functions. There's no need for 20 functions to have shared memory access to a piece of data (which I have seen scientists do). > I have seen a couple of projects that tried to port Fortran libraries to C++. They came out slower, buggier, and less readable. That is on the programmers who wrote it, not the language's fault. There's no magical reason that Fortran should be faster then other programming languages. That's like me saying "Some of my friends tried to design a new car engine. Their car came out slower and buggier then my Ford Model T which still runs perfectly". It's anecdotal evidence that doesn't say anything about C++. > The only reason you'd want to do that is a specific hatred for Fortran -- which you are not the only one to have I don't have a hatred for Fortran. I just don't see any job where I'd prefer using Fortran over a more-sane alternative. Fortran was great for 77 but isn't great for 17. > over the decades it hasn't proven to be a good motivation for redesigning software. Comparability with modern software, improved performance from modern language features, pool of developers, further abstraction of your implementation to remove cruft from the code base using modern language features, and easier deployment are the reasons why we shouldn't be using Fortran. I mean... when people use Fortran they usually don't even make use of Fortran 90's abstraction features. It's insane. > Of course people like to use Python, but you don't get to use Python instead of Fortran. That would be incredibly slow. You use Python and Fortran. For example, you use NumPy and SciPy, which make Python a great high-level platform for numerical computing because they wrap large amounts of Fortran code. You are mistaken. NumPy does not contain Fortran in it's code base. SciPy does but it only makes up 25% of the SciPy code base. I have no doubt that within the next 20-50 years that will slowly be removed bit by bit. Wrapping a legacy library is the first step to replacing it. Once you remove the hard dependancy you will remove > If you use Python for numerical computing, you are not "moving away from Fortran", you're embracing its success. No you are definitely moving away from Fortran and towards better tools. The old cruft may still be there but as time moves it will slowly be replaced. You'd never need to use Fortran to get Fortran style speeds with modern software architecture using just python and C [2]. I've seen some crazy projects use this approach and outperform some native C applications. [0] - https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ [1] - http://rust-num.github.io/num/num/index.html http://rust-num.github.io/num/num/index.html [2] - http://cython.org/ http://cython.org/

rspeer 10y ago

These are some pretty naive suggestions for how to uproot an entire domain of computing. Julia is a JIT language. Whatever edge you get in pretty code is going to be paid for in speed. Also, it's pre-1.0 and breaks compatibility frequently. 40-year-old Fortran code runs fine; 2-year-old Julia code is a syntax error. Rust is a nice language, but all of its numerical computing is experimental 0.x stuff. You'll probably end up wrapping another library to do your number crunching. It's probably written in Fortran. C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran. I have seen a couple of projects that tried to port Fortran libraries to C++. They came out slower, buggier, and less readable. The only reason you'd want to do that is a specific hatred for Fortran -- which you are not the only one to have, but over the decades it hasn't proven to be a good motivation for redesigning software. Of course people like to use Python, but you don't get to use Python instead of Fortran. That would be incredibly slow. You use Python and Fortran. For example, you use NumPy and SciPy, which make Python a great high-level platform for numerical computing because they wrap large amounts of Fortran code. If you use Python for numerical computing, you are not "moving away from Fortran", you're embracing its success. I don't actually know Fortran, but I have huge respect for the people who do. They're the reason most of the things I do are possible and fast.

one-more-minute 10y ago
Julia is JITed, but not in the same sense that (say) JavaScript is. It's more like a very lazy AOT compiler – and it can certainly hold its own against Fortran. That's not to say it has every optimisation it could, but the JIT is not the bottleneck there. 1.0 will be out around midway through the year, so that will ease the growing pains.
gravypod 10y ago
> Julia is a JIT language. Whatever edge you get in pretty code is going to be paid for in speed. That is incorrect. This nonsense that JIT is slow is an old belief that's hung around because it sounds nice. The fact is that the numbers don't line up [0]. > Rust is a nice language, but all of its numerical computing is experimental 0.x stuff. You'll probably end up wrapping another library to do your number crunching. It's probably written in Fortran It's new and it's growing. It's also a single example for a single case. But it even still have a comprehensive numeric library [1]. > C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran I don't know how this could be the case (especially with the addition of shared pointer) but you shouldn't be writing code with huge shared memory dependencies. Use constexpr, use inline, and use functions. There's no need for 20 functions to have shared memory access to a piece of data (which I have seen scientists do). > I have seen a couple of projects that tried to port Fortran libraries to C++. They came out slower, buggier, and less readable. That is on the programmers who wrote it, not the language's fault. There's no magical reason that Fortran should be faster then other programming languages. That's like me saying "Some of my friends tried to design a new car engine. Their car came out slower and buggier then my Ford Model T which still runs perfectly". It's anecdotal evidence that doesn't say anything about C++. > The only reason you'd want to do that is a specific hatred for Fortran -- which you are not the only one to have I don't have a hatred for Fortran. I just don't see any job where I'd prefer using Fortran over a more-sane alternative. Fortran was great for 77 but isn't great for 17. > over the decades it hasn't proven to be a good motivation for redesigning software. Comparability with modern software, improved performance from modern language features, pool of developers, further abstraction of your implementation to remove cruft from the code base using modern language features, and easier deployment are the reasons why we shouldn't be using Fortran. I mean... when people use Fortran they usually don't even make use of Fortran 90's abstraction features. It's insane. > Of course people like to use Python, but you don't get to use Python instead of Fortran. That would be incredibly slow. You use Python and Fortran. For example, you use NumPy and SciPy, which make Python a great high-level platform for numerical computing because they wrap large amounts of Fortran code. You are mistaken. NumPy does not contain Fortran in it's code base. SciPy does but it only makes up 25% of the SciPy code base. I have no doubt that within the next 20-50 years that will slowly be removed bit by bit. Wrapping a legacy library is the first step to replacing it. Once you remove the hard dependancy you will remove > If you use Python for numerical computing, you are not "moving away from Fortran", you're embracing its success. No you are definitely moving away from Fortran and towards better tools. The old cruft may still be there but as time moves it will slowly be replaced. You'd never need to use Fortran to get Fortran style speeds with modern software architecture using just python and C [2]. I've seen some crazy projects use this approach and outperform some native C applications. [0] - https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ [1] - http://rust-num.github.io/num/num/index.html http://rust-num.github.io/num/num/index.html [2] - http://cython.org/ http://cython.org/