Fortran is still a thing (2017)
hackernoon.com
hackernoon.com
Could've written the same in C++, but for things like that, Fortran is more natural (its math syntax is Matlab-ish, although, of course, it's more correct to say that Matlab's syntax is Fortran-ish).
Anecdote: I'm starting to learn Rust, and just for fun, wrote a dumb single-loop Riemann sum to compute pi in Rust and Fortran (as the area of the circle) - and Fortran code ran 2x faster. When the computation time is measured in days, this kind of difference matters.
I'd love to use Rust for numerical heavy code, like Fortran Rust is no-aliasing out of the box which is great for code gen, but Rust also has many of the niceties of C++. Still no integer generics in Rust though. :(
We were only recently able to turn those no aliasing optimizations back on, so you were probably using a version of Rust that wasn’t even making use of them.
I'm wondering if the slowdown is mostly about the very mature optimizing compilers available for Fortran or if it's intrinsic to Rust's language design. (I've never written any Rust myself.)
It looks like the equivalent option is still under discussion for rust:
Yes, PGI Fortran.
>I'm wondering if the slowdown is mostly about the very mature optimizing compilers available for Fortran or if it's intrinsic to Rust's language design.
I wonder about that too. Time will tell!
Gfortran can produce reasonably fast code with array bounds checking enabled, but ifort turns off optimizations if you enable that, which means that you can't debug your code because it takes forever to run.
Gdb has trouble with both ifort and gfortran code and ends up panicking if you try to inspect variables a bit too closely. But then I rarely use a debugger.
As far as language support goes, neither ifort nor gfortran properly supports parametrized derived types, which is a pretty sweet feature that allows you to define a small number of dynamic type parameters that define things such as dimensions and precisions. This saves a lot of boilerplate regarding allocation and deallocation and makes the code cleaner.
However I got burned using that, as ifort ends up crashing as soon as the code making use of PDTs gets complex (for example, as soon as you've done implementing your module and are using it in some bigger piece of code) or produces incorrect code. Hopefully they'll fix that soon.
Both ifort and gfortran do support the object-oriented and generic features, although wrapping your head around the Fortran memory management and allocation model is difficult if your background is C.
Fortran lacks direct support for generic programming, but you can work your way out of that pretty decently with creative use of modules and the 'include' directive, without even needing to use CPP. If you're gonna use CPP, keep it simple, #ifdef's etc. are OK, for macros you need to define your own concatenation operator if you want your code to work both with gfortran and ifort.
As for PGI Fortran, it doesn't even fully support object oriention, so it's more like Fortran late nineties; but it does do fancy automatic parallelization and can target GPUs.
The reason people still use Fortran is because it supports arrays, is fast, readable and standardized.
No, C and C++ do not support arrays. Proper array support would involve the compiler knowing array rank, dimensions and eventually stride, providing standard ways of representing and indexing them, and basic functions with clear performance and memory management properties, plus bounds checks (and the ability to optimize them away).
Now let's pretend you have some C++ header library that provides some of that in the form overloaded indexing operators etc. Will that stuff compile in two years? No it won't, because the library will change, and because the compilers will change. It's not standard. Second, your C++ code is gonna be unreadable. Fortran code is readable to Joe random Engineer/Scientist, + means plus, and an array is an array is an array, and hasn't changed much in decades.
However, general I/O in Fortran is horrible, although the edit descriptors allow you to produce nice fixed-column output easily as opposed to printf. Also, you can "print , any, value, you, want" which is very handy for debugging, but C++ streams generally cover that.
But, like many others, we kept using Intel's troublesome optimizing compilers because execution time is very dear when you run compute-intensive code from several hours to a few days per run, sometimes on hundreds or thousands of CPUs.
The canceled competition would have involved running contestants’ code on a NASA supercomputer. The only logical reason I can think of for restricting the language to Fortran would be security concerns. Limiting submissions to one, well-understood and possibly safer language would limit the attack surface. But they canceled the whole thing anyway, again probably due to security concerns.
In any case, yes Fortran codes are still around. The BLAS and LAPACK libraries are implemented in Fortran, which means that Fortran code is at the foundations of a ton of numerical software (e.g. MATLAB, NumPy, R, probably Julia, probably a lot of neural net libraries, etc). Any new HPC chip always comes with an optimizing Fortran compiler, we saw this with Nvidia GPUs for example). There are two reasons why Fortran is still used: (1) decades of work has gone into implementing numerical optimizations in these libraries. I am not just talking about machine-oriented optimizations, I am referring to higher level mathematical tricks that require deep domain specific expertise in things like linear algebra as well as a very strong handle on managing floating-point error. Extensive testing has gone into those libraries, and the continued validity of that testing depends on the language standard, compiler implementation, and compiler optimization levels. There is simply no value in rewriting all of this code in another language, given the enormous cost and risk. (2) older professors just prefer Fortran because they know it, and grad students have to use it because their profs use it, and front-line experts have to use it if they want to work on making enhancements to the imoortsnt existing Fortran libraries.
Looks like the Forth loader is going to eventually be replaced by a Lua one, though [2].
[1]: https://github.com/freebsd/freebsd/tree/release/11.1.0/sys/b...
[2]: https://lists.freebsd.org/pipermail/freebsd-current/2018-Feb...
I've never seen code where you need to deal with malloc et al. You are able to create dynamically allocated arrays or let arrays be sized on evocation, but I've never needed to deallocate or free memory at the end of a function/subroutine.
It's misleading to imply you never have to free memory. The NAG compiler runtime includes Boehm's conservative garbage collector (or did, last I checked) for a reason.
> Its users are scientists and engineers; not computer scientists and software engineers, but the real ones.
Software engineers are in fact "real" engineers. Who do you think writes the compilers for Fortran.
Edit: Read the article twice. The author is Ukranian. Either it's a linguistic mistake, or he really has some sort of prejudice against Software Engineers, in which case I find that sad.
But honestly, the term “Software Engineer” is a farce at best.
So maybe the author is in the camp that worries too much about meaningless titles.
There are certain things that are very ... softwar-y, and only engineers who know how to handle software well can come up with.
Google's Percolator, the plethora of Apache data crunshing stacks, whole paradigm shifts like Object Storage, virtualization, and so on. Some of these are the equivalent of Burj Khalifa. Not anyone, or any team for that matter, can build them correctly.
Which is why I think the term Software Engineer and the concept of software engineering is very justifiable.
Yes, I think it is a form of engineering, in the sense that it a tangible discipline that produces artifacts that are useful to humans and that require very specific scientific knowledge and a minimum of academic background.
Just my two cents on the matter.
Hell, the Germans even get mad if someone claims a 'Dr.' title and they haven't completed some post-Ph.D. secondary dissertation thing from a German University.
My experience (YMMV) is that all these "Engineers" go out into the world as rookies anyways. I've dealt with rookie Civil Engineers that couldn't understand the blueprints for a two story house and "Computer Engineers" that couldn't code their way out of a React Todo List.
Experience trumps all if you ask me and if we really want to regulate the "Title" then it should be based on experience and achievements vs a paper that says you went to X or Y.
I might be biased because I decided to drop out and go build experience, but I've hired from both sides and I've come to the conclusion that raw talent and experience dictate how much of an "Engineer" you really are.
There are software engineers out there, doing engineering work, but most of the people who call themselves software engineers are not.
I am a Materials engineer I work with Chem/mech engineers on process modelling and simulation in an industrial plant.
You can kind of tell the vintage of programs around here by looking at the languages used.
There are Fortran programs from 80's to 90's.
From early to late 90's there are C++ programs.
Then from late 90's to mid 2000's there are VB6 programs (for a while our work was big on Microsoft, Visual Basic and Access was everywhere - boy did we get burned by that).
From mid 2000's to early 10's there are java programs.
Python seems to be goto nowadays.
has some suggestions. I haven't tried any but am thinking of using Doxygen as described for some old Fortran77 code with lots of gotos since Understand is well outside of our budget.
You're probably aware of this, but our biggest speed gains in some code we ported from DEC Fortran to gfortran was vectorizing loops. Best of luck.
whhich provides a beautiful high level interface to a fast neural network written in pure julia. Here's an example of how simple it as at the core: http://fluxml.ai/Flux.jl/stable/models/basics.html
I don't understand the idea behind this statement. Nobody but the specialist can produce efficient algorithms to solve a domain-specific problems, and Fortran isn't any simpler than C.
If the writer argues that the implementation of the algorithm is bad when written by non-programmers, then you might be surprised to find out that it's usually the opposite.
Computers are still incredibly simple in their basic design, so unless you hire a hardware-specialist programmer (like an x86 or CUDA/OpenCL specialist with background knowledge of the chips you'll use), knowing basic latencies in RAM operation, L-cache sizes and the ticks required for executing basic operations like floating point additions and XORs, is enough for the specialist to write better code, because he understand the algorithm, he can tailor it the hardware, and he actually cares, unlike most programmers/software engineers.
Knowing how to use hundreds of libraries might be helpful when you're writing long "consumer" applications, but this kind of expertise has nothing to do with scientific and high-performance programming.
Wouldn't this incur a performance penalty?
> (unlike C)
C is also strict in this respect.
He is currently learning R, though, and so Fortran at this shop may have its days numbered.