Learning Fortran (2024) • Hacker News Board

Re: Learning Fortran (2024)

#81

Post by pklausler » Thu, Dec 18, 2025, 4:35 PM UTC

adrian_b wrote: post #75

Luminary099 wrote: post #54

Earlier quoted context omitted.

Huh, I remember actually being taught this at school, but they never bothered to give (or I never bothered to remember) an example of a programming language that actually named void functions differently or indeed why it couldn't just be a void function. Looking at it now, it seems to be a difference inherited from mathematics, which would also explain why it's in Fortran too.

The main difference between functions and subroutines in Fortran and other ancient programming languages is not the fact that subroutines do not have a return value. The functions of Fortran are what would be called pure functions in C (which can be marked as such with compilers that support C language extensions, like gcc). The pure functions cannot modify any of their arguments or any global variable, and they must…

This is complete misinformation and you should stop posting it.

One can explicitly declare a function (or subroutine) to be PURE in Fortran, but it is not the default and never has been.

Re: Learning Fortran (2024)

#82

Post by atrettel » Thu, Dec 18, 2025, 5:30 PM UTC

adastra22 wrote: post #64

atrettel wrote: post #55

Earlier quoted context omitted.

They are pretty similar, but they are definitely used differently. For one, you have to "call" a subroutine in one statement, but you can use multiple functions on the same statement (since they can return values). Functions (usually) do not change their arguments, but subroutines often do. In some sense, functions are closer to how mathematical functions work but subroutines are closer to labels for certain procedur…

So they are used differently, but there isn’t a language enforced difference (other than return value)?

The language enforced difference is that only functions can return a value, but other than that, they are quite similar and just called "procedures" generally. In my experience, Fortran programmers use them differently in practice, and that is more of a guideline than something enforced by the language itself.

Re: Learning Fortran (2024)

#83

Post by foxglacier » Fri, Dec 19, 2025, 4:22 AM UTC

lioeters wrote: post #74

Joker_vD wrote: post #73

Earlier quoted context omitted.

> If you didn't have vectors, Maxwell's equations would spill all over the place. What do you mean, "would": they did! :) The original equations had 20 separate equations, although Maxwell himself tried to reformulate them in quaternions. But if you look e.g. at works of Lorentz, or Einstein's famous 1905 paper, you'll see the fully-expanded version of them. The vector form really didn't fully catch until about the m…

This sounds like an interesting thread to follow. From a cursory search, it seems vector calculus was being used by the early 1900's to reformulate Maxwell's equations, then later with notations like differential, integral, and matrix forms. I'll read more and see if I can understand the gist of each major step of the process over the years, how the notation affected the way mathematicians thought about the equations…

It goes even further. Einstein also simplified the writing of tensor equations involving sums (big sigma sum) with Einstein notation by basically dropping the sigma because it's redundant so undefined indices automatically get summed over all their applicable values. It works with nested sums too to make them deceptively simple looking. Add to that the comma subscript for differentiation and you get formulas with just a couple of terms but huge piles of subscripts. I've seen equations in text books that have both subscripts and superscripts on both the left and right of a variable.

Re: Learning Fortran (2024)

#84

Post by thatjoeoverthr » Fri, Dec 19, 2025, 1:49 PM UTC

3uruiueijjj wrote: post #30

thatjoeoverthr wrote: post #19

I actually had a fantastic experience with Fortran lately. I ported a compute kernel from python/numpy to Fortran 2018, partially due to the GIL and partly so I could use Intel's compiler. The performance improvement was tremendous. Several times faster per core, then multiplying further because I could take advantage of threading. In all, the 3 day project increased actual throughput 450x. (I considered JAX, but the…

I've never found anything to back this up, but my impression was that both the Python / Numpy and Fortran 90 slicing operations were directly inspired by MATLAB (although most of the ideas go back to at least Algol 68). It also helps that Fortran compatibility is a must for pretty much anything that expects to use BLAS.

I'm learning just now how old MATLAB is. Wow!

Re: Learning Fortran (2024)

#85

Post by semi-extrinsic » Fri, Dec 19, 2025, 10:26 PM UTC

adrian_b wrote: post #77

semi-extrinsic wrote: post #52

Earlier quoted context omitted.

Functions return a value, subroutines do not. So functions can, at the whim of the compiler, cause an extra copy. Style wise, many prefer to reserve functions for things that resemble mathematical functions (i.e. only intent(in) and pure). In some sense a little bit similar to how people tend to use lambdas in python.

In a well designed programming language, the compiler should always decide at its whim, whether input or output parameters need an extra copy or not, i.e. if they should be passed by value or by reference. The programmer must only specify the behavior of the parameters, i.e. if they are input, output or input-output parameters, like in Ada. The fact that a parameter is the result is just a matter of syntax, not of se…

Functions, the way we use them in mathematical equations, have a particular syntax. The point of functions in Fortran is to mimic this as closely as reasonably possible (consider it is a language with a long history).

Giving the user low-level control of how memory is used can be very useful for writing fast code. The compiler is not omniscient. Providing the choice is not bad language design.