FPM discussion at Hacker News

1

The Fortran Package Manager is being discussed at Hacker News, leading to some discussion of Fortran in general.

7 Likes
2

Here is a very good feedback that somebody gave us:

I pretty much 100% agree with that frank feedback about Fortran’s shortcomings and you can see my reply there how to fix all that. Let me know what you think.

4 Likes
3

Well, that would explain the sudden jump on the repository traffic:

image
image1000Ă—441 24.9 KB

6 Likes
4
  • Strings are pretty awful. You can now have resizeable strings but using them is very painful (and buggy in gfortran). You’ll have to constantly strip spaces off the ends of strings to even print them.

I understand the sentiment here. Concerning the buggy implementation I think it is now better. AFAIK, there have been no problems with using strings in fpm which makes heavy use of them.

  • Some of the compilers are very immature (gfortran), if using any fairly recent features (e.g. resizeable strings). I’ve hit several (still unfixed) compiler bugs and my code contains some terrible workarounds.

I think calling it very immature is an exaggeration. What could we say then about ifx, flang, or the many older compilers which only support F95 and older. But indeed, gfortran has been problematic. I know there were a few posts encouraging members of this Discourse and comp.lang.fortran to consider contributing to gfortran development.

  • Available libraries are hit and miss, particularly outside the numerical area.

This is true unfortunately, but we are doing our best to fix it.

  • Linking to C/C++ is possible, but painful with the binding support.

This is also true. There are tools to generate the interfaces automatically including shroud, swig-fortran-dev, h2m-Autofortran-Tool, and probably others, but I’ve always been afraid to use them. Another option is to use a custom Python script (I believe @vmagnin does this for the gtk-fortran bindings). For small libraries with only a few dozen routines I’ve just preferred to do it manually.

  • Documentation (including books) just isn’t good compared to what’s available for C/C++/Python, etc.

I’ve been quite happy with Fortran books recently. I think we’re still missing something like the Effective C++ series which would go deeper into design patterns, libraries, and software engineering. The closest one to this now IMO, is “Modern Fortran in Practice” by @Arjen which contains very succinct advice.

  • No templates (would come in very handy for some routines which handle different numerical types).

This can be partially realized using preprocessing and parameterized derived types (assuming support was better as it is now). Once you get a hang of fypp it’s pretty okay. Honestly I’m not sure if I want to see templates like C++ has in Fortran. In the past I had a lot of struggles reasoning about codes which relies on templates. I understand templates are very powerful, and they get easier with more experience, but I might go as far to say I like Fortran because it doesn’t have templates. When the compiler returns an error message, in almost all cases I know how to fix it.

  • Ok for numerics, though can’t use C/C++ intrinsics for AVX/SSE maths.

I don’t agree with this comment. The idea of Fortran from the beginning has been to abstract away specific hardware details. As a chemical engineering graduate I want to be largely free from understanding hardware details.

As explained in this blog post, in the forest of scientific software, Fortran programs are the sequoias. They have outlasted multiple generations of programmers, and multiple generations of hardware. I have no objections to compiler vendors offering special pragmas, preprocessor, etc if they want to, but I see no reason to put this in the language standard.

What I find more suitable for the Fortran model of programming is something like the NEC Fortran Stencil Code Accelerator: https://www.nec.com/en/global/solutions/hpc/event/sc20/tech/article04.html

10 Likes
5

Yes, I also don’t agree with the Ok for numerics, though can’t use C/C++ intrinsics for AVX/SSE maths. comment. The ideal goal would be that you shouldn’t need to use any kind of instrinsics for SIMD, as Fortran compilers should be able to generate equivalent code with the existing language.

5 Likes
6

Regarding output of character variables and trailing blanks, F202x includes the AT format that is A format with automatic Trim. Of course you can always put trim(string) in the output list and use A format or list-directed output. While this is a less performant option, performance is usually not a consideration with I/O anyway.

5 Likes
7

The reason for an at format is not performance but to avoid the hassle of

character (len=100) :: c(20)
write (*,"(100(a,','))") (trim(c),i=1,size(c))

whose second line can now be replaced with

write (*,"(100(at,','))") c

or

write (*,"(*(at,','))") c

using the unlimited format feature.

4 Likes