101–110 of 255 posts
I'd like to hear some thoughts as to why one would choose FORTRAN over R, JMP, Excel, Python... other than for fun or familiarity?
Like some many-angled Lovecraftian horror, it spites reality, sanity and common sense merely by existing.
It seems the home page is down (sub-pages are working) and I coincidentally visited this site several months ago and it wasn't working back in the day either.
Getting a standard Nginx error "502 Bad Gateway nginx/1.10.3 (Ubuntu)". Are they slashdotted[1]? [1]: https://en.wikipedia.org/wiki/Slashdot_effect
Looks vulnerable to SQL injection attacks. ( https://fortran.io/static/model.html )
It's definitely not a dead language – a new Fortran front-end has recently been accepted into the LLVM project, joining Clang. So LLVM's only in-tree supported languages (excluding the various IRs) will be C, C++, Objective-C, and Fortran. It had been scheduled for merge into the LLVM monorepo 2 days ago, but has been delayed pending some additional architecture review.
Lots of number crunching code relies on Fortran libraries even today. Install numpy, it will pull in Fortran stuff.
Scipy is a different story.
The need for a fortran compiler was a big part of the original rationale for the divide of numpy and scipy when they replaced numeric. Numpy was meant to be the lighweight/core version of things, and scipy was the full-fledged environment. (I think numpy was even scipy-min, or scipy-core, or something along those lines for a bit.) A key differentiator for what when into numpy vs scipy was whether or not it needed a fortran compiler. That's still true today -- numpy explicitly doesn't depend on anything fortran related, and anything that uses it is optional.
(I'm not authortative on any of this, I'm just someone who's been doing scientific computing in python (and fortran) since the numeric days.)
On a different note, modern fortran (e.g. F90 and above) is actually a really nice scientific software language. It's _still_ really hard to beat, and modern fortran is pretty maintainable and easy to read in addition to being performant. I've dealt with highly optimized fortran codebases and highly optimized C codebases for the same scientific tasks. The fortran ones were usually a lot easier to read, more maintainable, and were still faster. Fortran is not really a general purpose language, but if you're doing lots of number crunching on large arrays, it's damned nice.
The more I look at Fortran, the more I appreciate its beauty. I think some of its infamy is unjustified.
"The March of Progress
> * 1956: Fortran I:
> PRINT 1, X
> 1 FORMAT (F10.2)
* 1980: C
printf("%10.2f", x);
* 1988: C++
cout * 1996: Java
java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance(); formatter.setMinimumFractionDigits(2); formatter.setMaximumFractionDigits(2); String s = formatter.format(x); for (int i = s.length(); i * 2004: Java
System.out.printf("%10.2f", x);
* 2008: Scala and Groovy
printf("%10.2f", x)
"
The reference and the details (2012):