What are your 3 favorite and least favorite things about Fortran?
I’m curious to learn what other like and dislike about Fortran, and it may be a useful exercise to understand why the community uses Fortran and what are some common pain points.
Here are mine.
Favorite:
Arrays and built-in whole-array arithmetic
Native syntax for parallel programming (coarrays)
Type system (static, strong, manifest)
Least favorite:
Lack of a mature Fortran interpreter
Lack of a mature package manager
Lack of built-in collections like linked list and dictionary
I like how easy it is to handle multidimensional arrays and pass arrays to procedures without needing to worry about pointers to pointers etc. like in c.
Fast
Simplicity: doesn’t over-complicate the task of programming so I can focus on the functionality rather than worrying about choice of implementation
Also a fan of submodules now that f2008 has good compiler support.
Least favourite:
No quick and easy way to plot directly from Fortran
Limited generic programming support
I dislike that implicit save exists and that I can’t declare + initialise in one line.
Very minor and specific, but I have always hated the use of percent (%) for derived-type components (I find dot (.) much more readable)
Simplicity: easy to learn, standard set of types makes most numerical tasks simple enough, static type system and the “intent” attribute make it easy to track down mistakes.
Arrays: built-in and easy to use. No need to rely on any kind of external library. Possible to use them also for derived types.
Interfaces: while verbose, they make dealing with call-back routines or interfacing to C routines safe and simple. Also great in combination with submodules.
Least favorite:
Lack of intrinsic string handling routines (simple things like numerical to string conversion or parsing command line arguments and input files is more complicated than really necessary).
Lack of other forms of containers (tuples, dictionaries, lists) besides the default arrays.
Lack of a good package manager (having to fight with Make, CMake, FoBis, and meson, just to call a few functions from some community libraries is tiring).
I also find it much easier to use object-oriented features compared to C++ (no need for the header guards, lack of templates makes it easy to reason about things), although there are a few quirks.
OO features that are relatively easy to understand and use
ISO_C_BINDING – always need to interface with C/C++ packages
Edit: how could I forget my most favorite – deferred-length allocatable characters!
Least favorite:
Compiler quality isn’t what it should be, and there is no reliable free compiler. I spend an inordinate amount of time isolating and reporting compiler bugs.
Lack of some form of templating or better generics – aka no standard container libraries (that aren’t hacky)
Can’t declare and initialize objects (in-place) in one statement (RAII)
Its simplicity, you can teach programming 101 with Fortran and within a week to cover everything. While an experienced programmer could take up Fortran and start writing production-level code within a couple of days.
Multidimensional array handling and the many intrinsic related functions.
Off the self optimized compilers. Just understand what is row- vs column-major and what is the correct order in loops and for most of the people is all they will ever need to write optimized (speed-wise) code.
Least favorite:
Lack of a complete, well-documented, easy-to-use (OS independent), package manager.
Lack of templates.
I hate the percentage ‘%’ symbol for OOP. The dot ‘.’ symbol is much more intuitive as well as faster to type.
simple language, but very robust (types, modules, …)
easy to write highly performing code
mathematics and arrays in the language
Bad:
Does not run well on modern hardware (such as GPUs)
Compilers should do a much better job than they do
Must be very robust
Support the latest standard
Show you how they optimize the code, and be able to beat any other language in terms of performance
Better error messages and more warnings, better Debug runtime checks
Interpreted as well as compiled (two modes)
…
the ecosystem is non-existent: we need a package manager, we need new small and medium size Fortran projects, not just large legacy systems, and a large community of users, developers, and we need a central website for the language
I didn’t bring this up at our J3 GitHub repository yet, as some people unfortunately react negatively to such “controversial” proposals, but it might be time for me to post there. I would really like to see this one fixed.
Hi @certik, I just read the open issue about dot. I agree with your reasoning, but I have more reasons to dislike it. Let me elaborate. When we write Fortran, we usually do not care about coding speed, ie. for every hour of coding we usually spend days if not weeks defining our physical problem and its equations with pen and paper, a few milliseconds gained when typing for me is insignificant (shout out to all of you vim/emacs evangelists…). Therefore, what I meant when I said in my last point that dot is faster to type, is that dot being within the range of your finger (when blind typing) does not require to take your eyes from the monitor to look it up, while in case of the percentage symbol you rely on muscle memory and half the times betrays you, e.g. hitting “enter” instead of “shift” etc., and this mistyping results in attention destruction. It happens to me and some times I lose my line of thought.
My second reason is more of a personal taste. The percentage symbol has no place in any modern language unless it is to operate as modulo. It’s non-intuitive, ugly and certainly doesn’t help with people coming from other languages.
What I suggest:
Comming the new standard, replace percentage symbol with dot for OOP, and deprecate all text relational operators, their mathematical equivalents already exist and are valid in Fortran. Also, replace the logical operators .and. with && and .or. with || , while .True. and .False. with True and False. (We do have nullify without dots surrounding it, why can’t we have true and false in the same way).
Deprecate all text operator overloading. I find this feature unique to Fortran and absolutely useless, nothing that you can’t express with a simple function or subroutine. Not to mention that I have never seen it implemented in production code (I have only seen examples in tutorials).
When compiling your code make it the default way to be with dot with all the changes I suggested in 1. and 2. However, in order to keep backward compatibility give the option with a flag to use the old-style e.g. -fnodot then the compiler assumes percentage symbol for OOP along with all other styles that were valid before. The only restriction should be that you can’t have a mixed style code.
Note1: I am no expert when it comes to such technical details, therefore excuse my ignorance if what I am suggesting makes no sense.
Note2: Having said all these, I still consider it a minor issue compared to other features that are missing altogether.
@stavros, thanks for the comment, yes that is roughly along the lines of what would need to be done. Do you want to post your comment into that issue https://gitlab.com/lfortran/lfortran/-/issues/84 ? So that we don’t pollute this discussion too much.
Syntax that’s easy to understand, even for non-programmers.
The mix of programming styles that are possible.
The fact that the old and the new can live together in one project.
Least favorite:
The limits of the generic programming support.
Outside the Fortran community, there’s a lack of awareness of the current state of the language and what it has to offer.
Dealing with character variables and text input/output.
There aren’t many built-in tools.
The performance of user-defined output to file is low, at least in my implementation.
There are minor missing items, e.g. the option to write a leading zero on numbers less than 1.
Commas can be used to terminate reading a field, but the final field isn’t handled in the same fashion when a line ending is encountered.
Having worked with Fortran for many years, what I appreciate came to mind faster than what I was frustrated with. I appreciate all the activity surrounding the new fortran-lang site.
Favourite:
-> All things arrays. Easy to pass and operate on arrays and array sections.
-> Default non-aliasing of arrays which helps performance.
-> Modules
Least Favourite:
-> Lack of a standardised runtime. (and non-standardised module format, array descriptors, name mangling)
-> No generic programming.
-> Wide presence of obsolescent features (like multiple entry) in existing code and their existence with new versions of API (like OpenMP).
everything with array expressions … close to mathematical/physical formalism, gives compiler enough information to do optimization
named dummy arguments
Least favorite:
missing RAII (the number of issues with accidental SAVE attributes and unitialized values was just too high in the last couple of weeks), missing constructor (last time I checked the compiler didn’t optimize away the extra temporary copy from the constructor function)
I/O and strings … Fortran should be at a higher level, having to maintain my own string buffer when reading unformatted from a file is just cumbersome
missing generic containers
pointers (but the problem here may be that many newcomers already know C/C++ and assume that pointers in Fortran are similar, so, not necessarily the language’s fault
Some common tasks require a lot of boilerplate (reading configuration files for instance) that could be automated. Of course this could happen in stdlib
Lack of generics. No need for “full generics” but containers + ability to reuse code that would be 100% identical except for kind (all reals for instance).
No interactivity or other “exploration” mode.
Some features actually slow down the code (allocatable arrays make it harder for compiler to vectorize) and it is hard to refactor arrays of structs to structs of arrays (or vice versa).
Simple syntax and ponctuation, not too many { ; && ||
Standardized language
Perennial: programs written when you begin your career will still compile at the end !
ISO_C_BINDING
Can be used with OpenMP
Strongly typed
Modules
Least favourite:
Nothing in the standard to plot or draw, on screen or in a file ! Not even a pixel… (that’s why I am happy with iso_c_binding and launched gtk-fortran) It was so easy in BASIC or TURBO PASCAL on 8 bits…
Backward compatibility (although this is mostly due to the compiler);
Intrinsic array features.
Intrinsic mathematical and scientific functions.
Modules and Sub-modules.
Least favourite:
Lack of a standard library.
And therefore lack of a “standard” way to install those great Fortran libraries (you cannot install open-coarray, gtk-fortran conviniently, at least not like “pip install”).
New features from Fortran2008/2018 are not fully supported by many compilers.
No standard plotting libraries. I am pretty confident with coarray features it is possible to write a parallel plotting library (sounds so cool is it?!) that might be very helpful for plotting massive data.
Hi @han190, thanks for the feedback and welcome! The good news is we have a fix in the making for your least favorite 1. (https://github.com/fortran-lang/stdlib/) and 2. (https://github.com/fortran-lang/fpm/). Both need a lot more work, but at this point, it’s just a matter of time, and if you are interested in helping us with any of those efforts, please definitely do, as it would help get us there faster.
Hi, @certik, thank you for your quick reply! I skimmed over the website you mentioned and found this. This is exciting. I know everything is still experimental but, hey you guys are making good progress! I am not very familiar with the fypp package (This is yet another exciting thing because as far as I knew there is no Fortran preprocessor exist!) but it looks very intuitive. I am looking forward to the FortranCon and more announcements to see what I am able to contribute!
