Hello Fortran! - Code for Thought (podcast)

Announcements
1

A new episode of the Code for Thought podcast is out on the topic of Fortran!

The speakers featured are Thomas Clune (NASA, US), Wim Vanderbauwhede (Uni. Glasgow, UK), @milancurcic (Uni. of Miami, US) and Ondrej @certik (GSI Technologies, US)

Listen at the link below:

The podcast is also available on Apple Podcasts, Spotify, Google Podcasts, Overcast and Amazon Music.

Here is a rough breakdown of the episode:

Section 1

0:00 Introduction of episode and the speakers
1:45 History of Fortran
3:00 Fortran 77
4:00 How punch cards influenced terminals
4:44 First Fortran experiences of Tom Clune
5:58 First Fortran experiences of Ondrej and Milan
7:00 First Fortran experiences of Wim Vanderbauwhede

Section 2

08:15 Type safety and legacy Fortran with Wim Vanderbauwhede
09:30 Proving type safety – Fortran vs C
10:30 Type safety in Fortran 90 and later

Section 3

12:15 Fortran 90
13:00 New features (F90, F2003) introduced by Milan and Ondrej
14:17 Ondrej introduces F2008 features including co-arrays
16:12 Ondrej introduces F2018 features
16:36 Changes coming in F2023

Section 4

18:35 Tools for Fortran development (compilers), platform and hardware support
20:05 Development tools and package manager
22:17 Package ecosystem and language community

Section 5

23:35 Test-driven development, unit testing and pFUnit
27:04 Fortran [container] template library (gFTL)

Section 6

30:36 Machine learning and Fortran
33:40 The story of Neural Fortran
35:35 Fortran for everyday applications
36:33 FortranGPT
37:20 Reflections on general purpose programming in Fortran

Section 7

38:55 Commentary from Peter Schmidt (podcast author)

17 Likes
2

A project of Wim Vanderbauwhede is

3

I found the section with Wim very interesting. According to Wim, legacy Fortran code written in a type-unsafe way can be automatically transformed into type-safe code automatically, and this is provably correct.

The details are in the paper linked under the podcast:

1 Like
4

Re: “provably correct”, yes indeed - anyone can notice this empirically when they work on refactoring effort to modern Fortran with existing codebases.

That is also why the standard committee shouldn’t hesitate to finally eliminate implicit mapping from the standard.

Please note any change will come into effect officially next decade anyway. On top of this, every processor will continue to support the legacy semantics by default. Additionally, automated transformation is very much feasible, as illustrated by Vanderbauwhede, and smart processors such as LFortran may start providing such transformation as built-in options even, if not already doing so (attn: @certik).

So with this ground reality, the risk of any adverse impact is minimal.

On the plus side, coders will be free to author modern Fortran codes where they will need to apply current semantics anyway with most other aspects of their code e.g, -standard-semantics flag with Intel processor. Then for these authors - who are the ones we strive for in industry - there will be no need for implicit none anywhere - that will be the default. That is the kind of vision we seek with Fortran.

1 Like
5

Hats off to all of you! Amazing work guys. Things like this are what inspires me to stick to the language despite some inconveniences :slight_smile:

3 Likes
6

It was a pleasure to listen to this podcast this morning. I have announced it on a few media, especially Mastodon (FLOSS instance) and LinkedIn (Fortran programmers group).

3 Likes