5 ms·
Some of the points brought up here are in fact correct, mainly legacy, testing, and awesome compilers tuned for supercomputers. However, a lot of these "why for
by noobermin 9y ago
Some of the points brought up here are in fact correct, mainly legacy, testing, and awesome compilers tuned for supercomputers. However, a lot of these "why fortran" articles (on both sides) I find are written by people who don't dabble enough on both sides of the fence, and are ignorant of what either side offers. For example, numpy implements a lot of the stuff from fortran the author listed, like broadcasting operations across arbitrarily shaped arrays, striding and negative indices, etc, not to mention the scipy library that contains leagues of the famous fortran codes...you get all that with a quick and easy to prototype language for the stuff that isn't bottle neck.
Another issue is computational people think C++ is about OOP, ffs, what a way to sell C++ short and ignore the more significant tool C++ brings to the table: generic programming. Whenever I talk to my computational colleagues, they talk about "C++ and OOP" as if they are two peas in a pod; what if I told you you didn't need to use inheritance to leverage the best of what C++ offers (what if I told you you didn't need inheritance to even leverage OOP!?). Templates have the potential to be a powerhouse for performance in codes I feel, just no one in the computational side has leveraged them because they quite simply don't understand it.
The same sort of thing is true for cs people and their critique of Fortran usage, but I'll leave scathing comments on one of those stories that are shared here.
- DaiPlusPlus 9y agoC++'s generic-programming feature still has shortcomings - I think functional-programming has more relevance to scientific computing, but C++'s functional features are "okay" but still not as capable or proven as, say, Haskell's or OCaml's - for example for tail-recursion you still depend on the compiler supporting that optimization, you can't force it or necessarily assume it will happen, with fun consequences for your stack if it doesn't.
- sidlls 9y ago> I think functional-programming has more relevance to scientific computing What do you base this on?
- beisner 9y agoFunctional languages force you to be more correct, more often. Eliminates a bunch of classes of bugs which are anathema to scientific computing, and are generally so high level that compilers can optimize extremely aggressively. Also, scientific programming is usually much more about data flow and transformation, which is FP’s wheelhouse.
- sidlls 9y agoDo you have examples where it is the case that FP code yielded a superior scientific result?
- DaiPlusPlus 9y agoOutput results would be the same - that's concerned with program correctness, regardless of whether it's written in a function, object-oriented, or procedural paradigm. It should instead be compared with how long it took to engineer and build the system or program in a particular paradigm and the qualitative engineering aspects of a particular platform. FP may be amazing for certain areas, but a difficulty in basing a large-scale project or business on it would be hampered by the small supply of developers who can comfortably program in it.
- HelloNurse 9y agoFor scientific computing, whether a language has very advanced or merely okay functional features is only a superficial style issue. Regarding more important performance issues like low level control of memory layout and avoiding pointless copying and indirection, C++ and Fortran are both at the most effective end of the spectrum, while typical functional languages lie between "don't even think about it, by design" and "it might be OK but only a fool would put a project at the mercy of what optimizations a relatively unproven compiler opts to do".
- solidsnack9000 9y ago> ...not to mention the scipy library that contains leagues of the famous fortran codes... This doesn't actually make Python an alternative to Fortran, though -- what it's saying is that no one writes the performant code in Python.
- noobermin 9y agoIndeed! But stuff like parsing input files and plotting are tons easier to code in Python than in Fortran. The point is the performant parts are not in Python, but the parts we don't want the difficult baggage can be written in a much easier and kinder language like Python.