
Show HN: Functional programming for modern Fortran - milancurcic
https://github.com/wavebitscientific/functional-fortran
======
nv-vn
Any information about the performance implications of this library? This looks
quite nice to use, but I imagine it has some performance cost versus more
traditional ways of writing Fortran code, which could (sadly) mean this won't
ever get much use in real-world code. Nonetheless, it's awesome that a
language that's been around for 60 some-odd years is still evolving and making
use of modern programming techniques. It's something to think about for people
making languages now.

~~~
milancurcic
Thank you for the kind words. I cannot comment on the performance hit yet but
this is something I plan to examine soon. Based on experience I can guess that
the performance decrease from using recursion could be about an order of
magnitude or more for large arrays. Fortran really shines performance-wise
when applied to heavy computations on very large multi-dimensional arrays - I
don't think functional techniques should be applied in such cases. However, I
think that Fortran programmers can benefit by applying functional techniques
on parts of code that do a lot of complex logic but are not computationally
heavy. Pareto principle is especially valid in HPC Fortran codes - most
compute time is spent in a small % of code base. Those should be left alone.

~~~
chm
I really like your project. I do question its usefulness however. If you get
_any_ performance hit from using these, you beat the point of using Fortran
(over say Python) in the first place :) Don't you think?

~~~
quantumhobbit
There is certainly an advantage to being able to use a single language in your
project instead of two separate languages.

~~~
chm
Yes, and having worked with Fortran code for years, we used the routines to
calculate... and Python to analyze the data. A colleague even scrapped old
Fortran routines in favor of Python + Numpy, as he could be more productive
without a noticeable slowdown in his work, as the data analysis part was the
bottleneck. So I reiterate my point: I like the project, I like the idea, but
we need more information regarding the performance of the routines. Otherwise,
using e.g. Python full-stack could be much less of a hassle.

~~~
gaius
NumPy is FORTRAN under the covers, e.g. BLAS IIRC.

~~~
greglindahl
BLAS are generally implemented in assembly these days, although they do have
Fortran interfaces.

~~~
gnufx
The important kernels (particularly GEMM) are written in assembler, but you
can see OpenBLAS, for instance, importing netlib LAPACK.

------
peter303
The creater of FORTRAN John Backus became a big promoter of functional
programming in his later years

------
photon-torpedo
Nice work. But as far as I can see this only works for the intrinsic Fortran
datatypes, i.e. the various kinds of integers and reals. Any chance for
extending this to user-defined types? Looking at the code, all functionality
has been repetitively implemented for each datatype -- I hope this has not
been done manually, but with a code generator? If so, could the generator be
extended to process user-defined datatypes?

It's really unfortunate that modern Fortran has no facilities for generic
programming. That's why I'm personally moving more and more to Julia...

~~~
greglindahl
Fortran eventually gets every useful feature, but 5-10 years after it's clear
that it's useful.

------
fdgdasfadsf
Looking at this makes me wonder if there is IDE support for handling the way
that Fortran does generic functions? So much boilerplate and repetition
required...

~~~
milancurcic
Unfortunately, Fortran standard does not provide good support for generic
programming so some level of repetition is necessary :/. I don't see this as a
major issue though - boilerplate coding happens once. In any case, pick any
language that supports generic programming, and if you dig deep enough, you
will run into boilerplate, in one form or another. :)

~~~
fdgdasfadsf
To clarify I'm familiar with how Fortran handles generic programming and my
frustration with it extends well beyond having to write interface blocks
(although these are annoying too). I regard having several versions of
functions handling e.g. different length floats as pretty tedious repetition -
that in my experience can quickly turn into a maintenance nightmare. Maybe
this is outside the scope of what an IDE could help with though. Could some
kind of function templating be possible in future versions of Fortran?

