Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Fortran

arxiv.org

Post reply on HN
Print view View original

71–80 of 113 posts

Re: The State of Fortran

#71

Post by Asooka »

leephillips wrote: post #33
zozbot234 wrote: post #30

Earlier quoted context omitted.

I don't think there's much in Fortran that's still unique or "specifically designed" for numerics compute. General purpose languages reached parity with Fortran a long time ago. And "general purpose" typically wins anyway because it has the larger and more diverse ecosystem.

Most of them did not reach parity, at least not in performance. The fast languages are C, C++, Fortran, and Julia. Those are the only ones used for teraflop computing. Fortran is a great tool for scientific computing, but for new projects, where you are not extending an existing code base, Julia will be much more fun in every way.

If only Julia didn't index arrays starting from 1, rather than the more natural 0.

Re: The State of Fortran

#72

Post by socialdemocrat »

ivan-pi wrote: post #35
leephillips wrote: post #33

Earlier quoted context omitted.

Most of them did not reach parity, at least not in performance. The fast languages are C, C++, Fortran, and Julia. Those are the only ones used for teraflop computing. Fortran is a great tool for scientific computing, but for new projects, where you are not extending an existing code base, Julia will be much more fun in every way.

Depends on your needs. Sometimes you just need a hammer. Michael Wirth had a few comments about Julia recently: https://craftofcoding.wordpress.com/2022/03/14/why-i-have-gi...

Seems highly subjective and not in line with the experiences a lot of the rest of us have. Stuff just suddenly breaking in old code with new compiler?!

No, that is not a common thing post Julia v1.0.

A lot of newer libraries are not well documented in Julia, but the core stuff is much better documented than Python IMHO. So his view on Julia documentation lacks nuance. It is both good and bad depending on what you look at.

The post talks about the complexity if importing stuff with using and include. Yes, if you start from scratch it is more complex, but the benefit is that it scales better. I have helped compete beginners with Julia who had totally given up on Python due to the complexity of package management, modules and environments. Julia has a beautiful solution to this which is far easier to get right and manage.

A novice will find it easier to import packages they want to use with Julia compared to Python. But very often people evaluating this stuff are experienced Python developers and they don’t see the Python hassle easily. If you take somebody who is a beginner in both languages then experienced will be quite different.

The “multi paradigm” comment makes zero sense. Sure Julia is multi paradigm but it is far more streamlined than the common OOP-functional mess you see in other mainstream languages today such as Python , Java, C#, Swift.

In Julia it is all functions. You don’t distinguish between free functions and methods. For a beginner this is much easier to deal with.

Re: The State of Fortran

#73

Post by bayindirh »

noobermin wrote: post #60
necheffa wrote: post #15

Earlier quoted context omitted.

For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness. The way I see it, Fortran exists today because of inertia, not because it still has technical superiority. These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite. And so today, new code is bolted on, with a pray…

Man, why is inertia considered a bad thing? "new code is bolted on, with a prayer that nothing breaks" is literally all of software development. How many times do things break because some fool decided we need to use js framework 2022.04.07 when 2022.03.05 worked fine but new, shiny etc thus break. "Old" does not mean broken automatically, people seriously need to excise this assumption in software development becaus…

HPC administrator, researcher and scientific software developer here.

Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. First of all, programming languages and software design has a symbiotic relationship. They feed each other. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities.

Moreover, technology changes with every generation. Hardware change, capabilities change, requirements change, designs and languages change. More importantly mindset change. So you're bolting modern designs over "vintage" designs. Inevitable shims get coded (sometimes implicitly), and thing get complicated, even with best documented designs and developers with well intentions. The code pushed down solidifies, knowledge fades, and documentation get lost unless it's bundled with the code repository.

As a result, legacy code becomes something of a monster, where developers don't want to see, touch, or work with.

My research was coded with C++11 in the beginning. If I want to modernize with C++14 or add new parts with C++14, these parts will probably look so different that it'll look like two different languages glued together with black magic. It's the same thing with long living FORTRAN code. Only with longer legacy.

The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account.

Re: The State of Fortran

#74

Post by cycomanic »

leephillips wrote: post #33
zozbot234 wrote: post #30

Earlier quoted context omitted.

I don't think there's much in Fortran that's still unique or "specifically designed" for numerics compute. General purpose languages reached parity with Fortran a long time ago. And "general purpose" typically wins anyway because it has the larger and more diverse ecosystem.

Most of them did not reach parity, at least not in performance. The fast languages are C, C++, Fortran, and Julia. Those are the only ones used for teraflop computing. Fortran is a great tool for scientific computing, but for new projects, where you are not extending an existing code base, Julia will be much more fun in every way.

I don't think Julia belongs into the same list as C++, C and Fortran. It is true that for some algorithms it is almost the same speed as C++ out of the box, but for many others it is still factors of 10s or 100s of. Also it often requires significant tweaking to get to it's best performance (e.g. don't use abstract types), so it is almost like saying Python is the a fast language, because you can use Cython or Pythran. I really wish Julia fans would stop overstating the language capabilities, it really does a disservice to an otherwise great language.

Re: The State of Fortran

#75

Post by denisrosset »

bayindirh wrote: post #73
noobermin wrote: post #60

Earlier quoted context omitted.

Man, why is inertia considered a bad thing? "new code is bolted on, with a prayer that nothing breaks" is literally all of software development. How many times do things break because some fool decided we need to use js framework 2022.04.07 when 2022.03.05 worked fine but new, shiny etc thus break. "Old" does not mean broken automatically, people seriously need to excise this assumption in software development becaus…

HPC administrator, researcher and scientific software developer here. Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. First of all, programming languages and software design has a symbiotic relationship. They feed each other. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities. Moreover, te…

> The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account.

I'm currently teaching modern scientific Python programming, if that's a thing.

You raise an excellent point, the software development life cycle is quite different in academia. Do you have resources in mind on that topic?

I was thinking of dividing academic code in 3 "Ps":

- Playground: throw-away scripts for data analysis, fast moving code where any rigidity slows the process. Internal use by a single researcher usually.

- Prototype: code that serves as a foundation to the above, or is reused frequently, but is otherwise not shared outside a research group.

- Product: code, often open source, that is shared with the community.

Most tutorial about "good coding practices" do not make distinctions between these three stages.

For Python, there are practices that work at any level: auto-formatting code and sorting imports, gradual typing. But things like tests, API documentation, dependency management only apply to steps 2 and/or 3.

Re: The State of Fortran

#76

Post by GoodbyeMrChips »

RandomWorker wrote: post #49
throwawaybutwhy wrote: post #2

Please note there's been some uptick in the intensity of discussion on generics lately [0]. Generics are necessary to bring performant data structures to Fortran, and yet they are nowhere near Go's generics. For the usual naysayers doubting Fortran's place in a modern world: whenever you are reading or watching a weather forecast, that's decades of Fortran staring at you. Whenever you drive past a nuclear power plant…

For what it’s worth the nuclear power plant I worked at ran mostly on LabView. We compiled the code on PCs onto dedicated LabView boxes. No Fortran was ever used.

> the nuclear power plant I worked at ran mostly on LabView

Jesus wept!

-Signed, a physicist with 20 years LabView and Fortran experience.

Re: The State of Fortran

#77

Post by NGRhodes »

denisrosset wrote: post #75
bayindirh wrote: post #73

Earlier quoted context omitted.

HPC administrator, researcher and scientific software developer here. Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. First of all, programming languages and software design has a symbiotic relationship. They feed each other. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities. Moreover, te…

> The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account. I'm currently teaching modern scientific Python programming, if that's a thing. You raise an excellent point, the software development life cycle is quite different in academia. Do you have resources in mind on that topic? I was thinking of dividing academic c…

Not only are software development life cycles different, but also the attitude to development. Which is not a surprise when in most cases, the output is not the software (or system), but research or learning; the code is merely a side effect.

Re: The State of Fortran

#78

Post by NGRhodes »

necheffa wrote: post #15
throwawaybutwhy wrote: post #2

Please note there's been some uptick in the intensity of discussion on generics lately [0]. Generics are necessary to bring performant data structures to Fortran, and yet they are nowhere near Go's generics. For the usual naysayers doubting Fortran's place in a modern world: whenever you are reading or watching a weather forecast, that's decades of Fortran staring at you. Whenever you drive past a nuclear power plant…

For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness. The way I see it, Fortran exists today because of inertia, not because it still has technical superiority. These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite. And so today, new code is bolted on, with a pray…

One of the people in my team has a PHD in weather forecast modelling and it was only a few hours ago we were talking about the Met Office having a decade(s ?) old Fotran core with lots of stuff bolted on.

Re: The State of Fortran

#79

Post by zozbot234 »

denisrosset wrote: post #75
bayindirh wrote: post #73

Earlier quoted context omitted.

HPC administrator, researcher and scientific software developer here. Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. First of all, programming languages and software design has a symbiotic relationship. They feed each other. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities. Moreover, te…

> The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account. I'm currently teaching modern scientific Python programming, if that's a thing. You raise an excellent point, the software development life cycle is quite different in academia. Do you have resources in mind on that topic? I was thinking of dividing academic c…

With the increasing expectation that academic research results should be reproducible, there's really no such thing as throwaway "playground" or "prototype" code. Everything is potentially a "product".

Re: The State of Fortran

#80

Post by xioxox »

hatmatrix wrote: post #5

Modern Fortran is beautiful and I love coding in it. However, my understanding is that its main focus is on array computations. Now with hierarchical data structures and graphs becoming ever pervasive, I wonder if Fortran will ever try to compete in this space (when these higher-order concepts are integrated into domains of Fortran's past dominance in numerical simulation).

As a comparison, I have to program in Fortran in my day job, and I really hate it. On the negative side, text handling is really horrible (even with the new variable length strings), there are very few good libraries outside of numerics, a lack of type-safe generic data structures (like C++'s STL), buggy compilers (my code has some horrific pointer hopping to work around gfortan's bugs), the C-Fortran interface is horrible to use and there's little good documentation on the language. The positive things are the multidimensional arrays and slicing, and the modules.
Post reply on HN