What are your favorite and least favorite things about Fortran?

[certik]

@Niceno

String (character) manipulation leaves a lot to be wished for. I am never quite sure what is in a string, where does it start, where will it end, are the blanks included. Maybe I still have to get used to it, but Fortran strings are a twilight zone for me.

We should have a tutorial how to use strings in Fortran. I used to struggle with that a lot too. And still do a bit.

@Niceno

Case insensitivity. Being case insensitive, I find it much harder to enforce coding standards among my team members. I know it is needed for backward compatibility , but I really don’t like it.

The solution is to have a compiler option that would warn if you declare a variable as Am and use it as am and vice versa. That way it’s easy to enforce in your team.

@Niceno

No argument checking for procedures outside of modules. Like the previous one, I believe it is a feature ensuring backward compatibility, but it always leaves me with a splinter of doubt in my mind if I sent the right arguments or not?

Again, I think should be possible to implement in a compiler.

@Niceno

I also don’t fancy the % in OO Fortran a lot, but I thought it was introduced because the dot was already taken by: .ne. , .eq. , .not. and other logical and comparison operators.

I also don’t like it, see this issue: Idea: Support dot (`.`) as an alternative to the `%` operator (#84) · Issues · lfortran / lfortran · GitLab

[certik]

@hsnyder

The % sign. So, so bad.

Ok, please give a thumbs up to Idea: Support dot (`.`) as an alternative to the `%` operator (#84) · Issues · lfortran / lfortran · GitLab. So far all the feedback I got was rather negative. But I see that people would want this. I would.

@hsnyder

The open source compiler ecosystem is limited.

Will take some time to fix, but it will get fixed with GFortran, Flang and LFortran.

@hsnyder

I wish I could just use the C preprocessor, without the quirks of “traditional mode”. I’d rather have this than actual templates, even.

Can you be specific what you mean by “quirks of traditional mode”? We’ll have to support the C preprocessor in LFortran, but it poses all kinds of challenges, such as how to format the code automatically, since the preprocessor is run before the parser, so it is not part of the AST that is used for formatting.

[nshaffer]

@certik

I also don’t like it, see this issue: Idea: Support dot (.) as an alternative to the % operator (#84) · Issues · lfortran / lfortran · GitLab

I half-remember a conversation on comp.lang.fortran that the % sign was chosen to avoid clashing with DEC structure/record extensions that use . for selecting fields. I don’t remember the technical reasons for why derived types could not use the same syntax.

[Beliavsky]

@certik

@Niceno

No argument checking for procedures outside of modules. Like the previous one, I believe it is a feature ensuring backward compatibility, but it always leaves me with a splinter of doubt in my mind if I sent the right arguments or not?

Again, I think should be possible to implement in a compiler.

Intel Fortran does this with the -warn:interface option, so that for the codes

function twice(x) result(y)
real, intent(in) :: x
real             :: y
y = 2*x
end function twice

program main
print*,twice(2.1d0)
end program main

you get

c:\fortran\test>ifort -nologo -warn:interface twice_single.f90 xtry_twice.f90
xtry_twice.f90(2): error #6633: The type of the actual argument differs from the type of the dummy argument.   [2.1D0]
print*,twice(2.1d0)
-------------^
compilation aborted for xtry_twice.f90 (code 1)

Is there a comparable gfortran option?

[wclodius]

I believe the big problem was that Fortran 90 also allowed user defined operators with the syntax:

operator-name : “.” name “.”

so that expressions like

… an_id .cross. another_id …

can be ambiguous. The “DEC” extension was defined before user defined operators were available, and originally only had to deal with a few ambiguities, e.g., .OR., .AND., .LT., … Note also that most “DEC” extensions actually originated in other compilers. I believe that this extension, in particular, originated in Livermore’s Fortran compiler where it was used along with “DEC” pointers to write operating systems for super computers.

[hsnyder]

Despite emphatically disliking %, I’m not sure that . is the best thing to replace it with for the aforementioned reasons. While I’d definitely be in favor of something else being added to the language standard, I’m unsure about the wisdom of making a compiler-specific extension for a purely aesthetic issue (note unsure, not categorically against).

But with that said, I’d be curious to hear any other ideas people have about alternatives to both % and .? I like -> from C, personally. There are also unicode symbols like → that could be added as optional, without any risk of breaking existing language features (but that said I know nothing about the status of unicode in Fortran source files or even in strings for that matter).

[certik]

@hsnyder

But with that said, I’d be curious to hear any other ideas people have about alternatives to both % and . ? I like -> from C, personally. There are also unicode symbols like → that could be added as optional,

I like -> also. In C and C++, that means the variable on the left is a pointer. In Fortran this is unspecified, but it might very well be a pointer underneath (depending on the compiler), so -> is actually very natural to use. I added it to the above issue.

[adenchfi]

Favorite:

1. Self-documenting-code features (naming constructs, associate construct, intent(in/out)
   – These features, including the necessity of including all variable definitions at the top of subroutines/programs, seems oddly verbose. However, as a programmer who sometimes has to dive into a large Fortran codebase but who doesn’t want to know the entire codebase, these idiosyncrasies of the language are immensely helpful. Not saying I see large codebases use associate or name constructs, but I personally plan to if I ever make larger codebases.
2. Native multidimensional array support
3. Simple language but fast and robust (with recursion, modules, derived types, interfaces, etc)

Least favorite:

1. Writing to file in binary; the format isn’t specified enough and so one has to use an external library for cross-platform file communication. My ideal would be an intrinsic numpy-like easy interface for saving multidimensional arrays compactly, that is guaranteed to be readable by any standard-compliant Fortran compiler.
2. Can’t think of anything else right now!

[simong]

In the interests of balance I like % and don’t see any point in trying to change it for something else. Using ‘.’ instead (on compilers that support it) causes strange compiler problems when making method calls inside compound ‘if’ statements.

Favourite:

• native array support
• structure (modules / submodules)
• oo

Least favourite:

• the amount of code that has to be written to get round the lack of templates
• the general verbosity - I’d much prefer to declare a dummy variable where it’s used (like C++) than having to give it a line at the top of the procedure
• not really the fault of the language but the lack of a decent IDE on all platforms can be a real problem, perhaps a tutorial on the options somewhere?

[certik]

@adenchfi

Writing to file in binary; the format isn’t specified enough and so one has to use an external library for cross-platform file communication. My ideal would be an intrinsic numpy-like easy interface for saving multidimensional arrays compactly, that is guaranteed to be readable by any standard-compliant Fortran compiler.

We should add this functionality to stdlib to be able to save in binary and load in numpy (and Matlab):

• Save and load in binary, compatible with NumPy/Matlab and others · Issue #486 · fortran-lang/stdlib · GitHub

Go ahead and upvote the issue.

[alozada]

Save and load in binary, compatible with NumPy/Matlab and others ·

Nice!

others: some common image and sound files.
xtc file (portable format for trajectories), maybe.

[certik]

@alozada

others: some common image

Reading and writing common image formats, ppm, tiff, jpeg, png · Issue #45 · fortran-lang/stdlib · GitHub

@alozada

and sound files.

Add some common sound files (wav, flac, ...) · Issue #487 · fortran-lang/stdlib · GitHub

@alozada

xtc file (portable format for trajectories)

This is a good idea, but should probably first start as a separate package.

[adenchfi]

Upvoted!

[zaikunzhang]

(Sorry for revitalizing this old post)

Favorite:

1. Native support for matrices (I mean automatic arrays in particular; allocatable arrays are OK but automatic arrays are closer to mathematics).

2. Intrinsic support for matrix/vector operations: matrix addition/multiplication, transpose, slicing, broadcasting, …; without such intrinsic functionalities, a language should not be called a “formula translator”.

3. High performance.

Least favorite (sorry, I have more than three):

1. The robustness and performance of automatic arrays and intrinsic matrix/vector operations can still be improved (largely).
   Speaking about robustness, automatic arrays and intrinsic matrix/vector operations can lead to stack overflows (segfaults) under the default settings of some major compilers; this kind of major failure seems to be weirdly permitted by the Fortran community (e.g., see this 13-year old report to Intel and the latest experiment reproducing the same failure); this is unimaginable in other popular languages with the same functionalities, e.g., MATLAB/Python/R/Julia, unless you are encountering a bug that has to be fixed.
   As for performance, the intrinsic matrix/vector operations in Fortran normally cannot achieve the same performance as the intrinsic matrix/vector operations in MATLAB under default settings unless you are capable enough to make your compiler link to the correct library, which may be nontrivial as discussed in another post on this discourse. I know, MATLAB achieves high performance only because of the Fortran code underneath, but it is difficult to understand why Fortran itself does not optimize its intrinsic matrix/vector operations (under the default settings, without the need for particular options) in the same way.
   As mentioned in many posts above, the native support for matrices (arrays) and matrix/vector operations is one of the core strengths of Fortran. I do not see any reason why the community should be indifferent to its robustness and performance in this regard.

2. Lack of support for functions with multiple returns. True, we have subroutines that can return arbitrarily many results, but functions are less error-prone and often more intuitive.

3. Lack of interactivity. Fortunately, LFortran @certik is solving this problem.

4. Lack of support for logical indexing of arrays, which exists in all other popular modern languages used in scientific computing, namely MATLAB/Python/R/Julia.

5. Implicit mapping.

[mfurquan]

@zaikunzhang

Lack of support for functions with multiple returns. True, we have subroutines that can return arbitrarily many results, but functions are less error-prone and often more intuitive.

But, functions that only return a single result are closer to mathematics

[oscardssmith]

Tuples are a thing in math. Multiple returns are just returning a tuple.

[Beliavsky]

With the ability to return a scalar derived type or an array of derived types, possibly allocatable, Fortran functions are already pretty flexible, although returning multiple values would be nice.

[Harper]

Favourite thing that I don’t think was already mentioned: complex arithmetic as part of the language rather than a library having to be fetched, with many complex intrinsic functions (though I had to roll my own for some that have real but not complex intrinsics)

Least favourite: nncarlson complained of no reliable free compiler. My experience of reporting over 100 compiler bugs is that free and commercial compilers have both had bugs, but gfortran fixed them faster. Once I complained about a commercial compiler’s bug and was told the standard was ambiguous; the next version of the standard removed the ambiguity.

[JohnCampbell]

My least favorite feature about Fortran is that the linker has not been defined in the standard, especially a minimum functionality.
I think that INTERFACE should be automatic and reviewed at the link stage, especially for the count of subroutine and function arguments. The report should not be errors, but warnings that can be over-ruled, as in the case of F77 wrappers with mixed variable types.

[awvwgk]

@JohnCampbell

I think that INTERFACE should be automatic and reviewed at the link stage, especially for the count of subroutine and function arguments. The report should not be errors, but warnings that can be over-ruled, as in the case of F77 wrappers with mixed variable types.

This is actually available in the NAG Fortran compiler. It will produce an error if any argument mismatch is found, the check is actually global to all files linked. GFortran has a similar feature since version 10, limited to a single file.