My first experience with #chatgpt5.

I queried how to write some #python code to write out unformatted, binary files so my #fortran code could read it.

Proceeds to give me a load of #NumPy code. Completely neglects to mention the #SciPy FortranFile class that can trivially read and write, and appears on the first page of a search.

This is going to be a bumpy ride!

#FORTRAN doesn't have fork() or exec() natively. Creating a new process in FORTRAN requires either using system() function (portable but limited) or calling #C functions via ISO_C_BINDING (allowing full control). Modern FORTRAN (2003 and later) allows calling C functions directly
Via @unix-byte.bsky.social

A Gentle Introduction To #Fortran https://hackaday.com/2025/08/04/a-gentle-introduction-to-fortran/

A Gentle Introduction To Fortran https://lobste.rs/s/0l8415 #fortran
https://hackaday.com/2025/08/04/a-gentle-introduction-to-fortran/

A Gentle Introduction To Fortran via @hackaday
#fortran #programming
https://hackaday.com/2025/08/04/a-gentle-introduction-to-fortran/

I wish I could watch this (maybe they'll record it... but I'm not sure):

"From #Fortran to #Python: A Conversation Across Generations of #ScientificComputing" #PyOhio

https://www.pyohio.org/2025/program/talks/from-fortran-to-python/

Attention Fortran lawyers!

A colleague posed an interesting one to me (assuming b is a 2D real array containing values):
OK:
real, dimension(:), allocatable :: a
a = b(1, :)

Error:
real, dimension(:), allocatable :: a
a = sum(b(2:,:), dim=1)
! (can fixed by allocating a)

Is there a rule about automatic allocation requiring no temporaries? Or compiler bug (in either case?)

New #Fortran post: "Errors and error handling - Part 7 - Fatal errors" https://matthiasnoback.nl/2025/07/fortran-errors-and-error-handling-part-7-fatal-errors/

Almost everywhere in our code should we allow errors to bubble up to higher abstraction levels, until we get to the point that we'd really like to terminate the program. How to do that properly? We need to consider the process' exit code, printing the error to stderr, and adding a stack trace.

Latest #SharpMZ80K #RetroComputing post from me:

Fang, Claw and Knight’s WEE #FORTRAN - now updated with a patch for real numbers!

https://z80.timholyoake.uk/fang-claw-and-knights-wee-fortran/

New from me: Fang, Claw and Knight's WEE FORTRAN

https://z80.timholyoake.uk/fang-claw-and-knights-wee-fortran/

New #Fortran post: "Errors and error handling part 6: Guarantees" https://matthiasnoback.nl/2025/07/fortran-errors-and-error-handling-part-6-guarantees/

If we want guarantees that data in a derived type is correct, we have to use a custom constructor. But such a constructor then needs another Either return type so it can return a validated instance or an error.

Inspired by some folks who have been exploring #FORTRAN 77 programming on FreeDOS, I wanted to share these programming gems:

Arithmetic If
Computed Goto
Assigned Goto

https://www.both.org/?p=11217

They are excellent ways to add subtle bugs to your programs.

Try them out using Open Watcom FORTRAN on FreeDOS.

New #Fortran post: Errors and error handling part 5: Error propagation https://matthiasnoback.nl/2025/07/fortran-errors-and-error-handling-part-5-error-propagation/

We redesign the error value so lower-level errors can be "wrapped" inside higher-level errors.

New #Fortran post: "Errors and error handling - Part 4 - Using an Either type" https://matthiasnoback.nl/2025/07/fortran-errors-and-error-handling-part-4-either-type/

We consider a problem that involves parsing and find a solution to deal with parse errors: a parse function that returns an "Either" type, containing either an error, or the expected result of parsing.

New #Fortran post: Preventing edge cases with types https://matthiasnoback.nl/2025/07/fortran-errors-and-error-handling-part-3-non-empty-list-type/

We look at an alternative solution for calculating the average of an empty list; only offer such a procedure for a non-empty list.

Fortran: Hey, I can do object-orientation too! Just use type :: foo <stuff> end type

Me: Cool! And I can put that in a module, right?

Fortran: Absolutely! Indeed, that's best practice.

Me: And I can put particular instances of foo in a module as well, so they are accessible by multiple routines, just like I can with basic types?

Fortran, Hahaha, LOL no. Why would you want to do that?

New #Fortran post: "Errors & Error Handling Part 2 - Optional Results https://matthiasnoback.nl/2025/07/fortran-errors-and-error-handling-part-2-optional-results/

Instead of returning a success flag and use an intent(out) argument to return the actual function result, we implement an optional return value using an abstract derived type and two concrete subtypes.

New #Fortran post "Errors and error handling, part 1: Exploration": https://matthiasnoback.nl/2025/07/fortran-errors-and-error-handling-part-1-exploration/

The first part in a series about dealing with errors: we explore some common approaches and what their downsides are.

For some reason, raising a real number to some power gives a less accurate result in Fortran than does manually typing out each multiplication individually.

By which I mean T*T*T*T*... (until you have typed n Ts) is more accurate than T**n (that's T^n).

The wonders of computers.