Fortran is back on the top 20 TIOBE index list
zdnet.com
zdnet.com
some interesting ones:
1995: "Initialization of pointers to NULL()"
2003: "Object-oriented programming support: type extension and inheritance, polymorphism, dynamic type allocation, and type-bound procedures, providing complete support for abstract data types"
2008: "Coarray Fortran—a parallel execution model"
2008: "The DO CONCURRENT construct—for loop iterations with no interdependencies"
2018: "Further Interoperability with C"
The U.S. government has been making a huge push in the past decade to downgrade as much code as possible that doesn't need to be classified and push as much development as possible into fully unclassified environments to mitigate the cost of needing a fully cleared workforce. And network connectivity is generally increasing for systems that were not networked in the past.
Trends like these could easily account for Fortran developers doing more work in the open where they can just use Google to get answers instead of checking proprietary and closed information sources.
That said, although I'm a Fortran fan and programmer I doubt its relative popularity has truly jumped so much in 1 year.
I'm told that is because the standard libraries are so optimized.
Also, there is a gigantic infrastructure of literature, algorithms and support for the language. It is also relatively easy for folks that don't code for a living to use.
I wouldn't know, from experience. The last time I had anything to do with FORTRAN was in 1987, and I don't miss it one bit.
The latest one does not even include either Fortran or Groovy, both of which allegedly and randomly got a lot more popular according to the article. I don't think either of those things actually happened.
https://insights.stackoverflow.com/survey/2020#most-popular-...
Fortran competitor, Julia is included. That might just be bias of the Stackoverflow user base of course. But, I think it's a pretty widely used tool also for Fortran developers. At least there are plenty of questions tagged with that (11K, which is more than Julia's 8K).
There recently was some HN post about Fortran, so I imagine that might have triggered a few searches.
There's no way to know if a language is becoming more popular. You can only observe if a measure of language popularity is rising, falling, or staying the same. We're almost certainly observing the "measured" part as opposed to the "actual" part.
As a single data point, I'm more and more drawn towards Fortran lately. I never used it before this year, having done all of my work in various non-Fortran languages, mostly C, C++, Matlab/Octave, lua, python+numpy, and Julia. I'm quite fed-up with limitations with all of these languages, and it seems that Fortran has actually its shit together, at least for purely numerical computation (which is all I do and all I need).
C: it is mostly alright, especially since C99 with VLA and complex numbers. Yet the aliasing rules are a bit annoying, and multi-dimensional arrays, while possible, do not really feel natural.
C++: an unholy clusterfuck... I almost ended crazy trying to use it properly. With extreme discipline maybe you can get to do some work with it. But not me.
Octave: very beautiful language with a natural, concise notation for math. Excellent out-of-the-box support for sparse matrices. Shame that loops are so slow; needs a serious effort on a JIT.
lua: my favorite general-purpose language. The luajit interpreter may be one of the fastest and easiest alternatives to Fortran. I wrote a matrix product using an explicit triple loop, and it multiplied huge matrices just slightly slower than an optimized blas. Extremely impressive! I'm very sad that the project is sort of "abandoned".
python+numpy: My least favorite, but the one that I use the most... what can I say: this is a general-purpose language where you can sort of do math in it. But it is not a language tailored for math. The base language has natively strings and dictionaries (for which I have no use) but it doesn't have native multidimensional arrays of floats. I do not understand why the numeric computing community is shifting so much to python, it makes no sense in my eyes. Also, loops are insultingly slow.
Julia: may be the best of the bunch, but launching the interpreter is excruciatingly slow, and it does not suit my usage. In the time that julia uses to compile a three-line program to plot "sin(x)", you can run one hundred times the Fortran compiler on the equivalent program (or simply call gnuplot). All in all, it keeps pretty much the promise of "matlab with fast loops", which is just what I need. But I feel that it's still a bit far from being there.
Yes, I tried it upon its release and, while much faster, the startup time is still dramatically sub-par, especially when loading packages. This means that when I call Julia scripts from makefiles, etc., a considerable amount of running time is spent in re-compiling over and over the same packages. I agree that my usage pattern is not at all representative, but still it seems that Julia is not a good "unix citizen", since it tries to force you to do everything inside its own REPL, instead of the native one. This is indeed my main point of friction with Julia. If it started instantaneously it would be essentially perfect. This is not a matter of dividing the startup time by 2, but at least by 200.
EDIT: Also, having a REPL, and a nice one, is a big deal.
OK, admittedly I also need complex numbers (two floats) and ad numbers (however they are represented, typically by two floats also). But that's it. They are numbers after all, associative and commutative. The "dispatch paradigm" that these types require seems really simple, as it is implemented by e.g. generics in C as in tgmath.h. I'm wholly unconvinced--or more honestly, wholly ignorant--of the interest of a really complicated and powerful type system with multiple dispatch, broadcasting and whatnot that is offered by Julia. Fortran really seems enough for me. [And I do not care at all for the REPL, but that is a separate issue.]
It’s not that other types are “needed”, but that they let you do some pretty powerful things with surprising ease. And the nice thing is that in Julia, you can ignore them. You can just compute with floats or doubles as if the type system doesn’t exist. But it’s there in case you would like, for example, to apply the differential equation solver that you just wrote to quaternion-valued functions with no extra work.
https://github.com/SciML/BoundaryValueDiffEq.jl/issues/52
This is how I found out it worked in the differential equation solver: users were using it. The issue was unrelated (they didn't define enough boundary conditions), so it's quite cool that it was useful to someone. It turns out the quaternions have use cases in 3D rotations:
https://en.wikipedia.org/wiki/Gimbal_lock
which is where this all comes in. Anyways, it's always cool to learn from users what your own library supports! That's really a Julia treat.
But here, I cannot resist:
> You can just compute with floats or doubles as if the type system doesn’t exist.
Except when you can't! I want to plot a stupid array of floats. Yet it takes 10 seconds because it is juggling useless types around. A complex type system may be a nice thing to have, if you really want it, but it is definitely not "free", and it always involves serious compromises that make other things impossible or very cumbersome. I would like an option like --type=float in the interpreter that assumed that all numbers are of that type and ran extremely fast.
I was particularly "seduced" by the idea of using a standard ODE solver directly on quaternions. Having worked in the smoothing of 3D camera trajectories the last year, I would have definitely loved to know that at the time!
- Forward mode automatic differentiation. Having a type system that allows `Dual` numbers to pass through your algorithm, simulation, or whatever means you can calculate derivatives, gradients, jacobians, and hessians efficiently (for small problems) and accurately without having to change any of your code. There are so many times where I say “hey, I wonder what the sensitivity of my simulation output to this input parameter is” and it’s really nice to be able to answer that question with one line of code.
- Unitful numbers. It’s really nice to be able to pass numbers with units through a simulation (little to no performance penalty!) to make sure everything checks out in that respect.
- Uncertainty. Both Measurements.jl and MonteCarloMeasurements.jl provide numbers that propagate (linear and nonlinear, respectively) uncertainty as the pass through calculations. Want to see how uncertainty in a parameter propagates through a calculation? Just change that one parameter to an uncertain number and let it run through your algorithm as-is and it will spit out an answer with uncertainty bounds on the other side.
These are just a few examples of the stuff I use it for in my everyday work. Having a full type system for numerical work is one of those things that seems silly before you use it, but once you do, you wonder how you got by without it before.
EDIT: BTW, these are just examples of numerical types. Sending specialized array types through a your code is also a thing. For example, if you have a `Diagonal` type matrix and you send it to an eigenvalue solve, it just pulls the elements from the diagonal without wasting any time trying to calculate anything. Or there are things like ComponentArrays.jl (full disclosure, I wrote this library), that let you pass arbitrarily deep structured information through a differential equation or optimization solver for much cleaner and more readable code than just indexing into a plain vector like you would usually have to do. And you can even put your weird numerical types inside of the weird array types and just send it on through.
I've also seen a confluence with the AI/ML communities. Some interesting applications of these tools to accelerate models used in weather, climate, chemistry, physics, and astrophysics require complex software interactions, usually running simultaneously with some multi-million line Fortran code base. There's been many interesting and clever marriages of classic HPC Fortran applications and novel, embedded AI/ML parameterizations.
It's well maintained and highly optimized. Before then, I had not used FORTRAN since 1983 (and it was old even then).
https://insights.stackoverflow.com/trends?tags=objective-c%2...