
Why physicists still use Fortran - urs
http://www.moreisdifferent.com/2015/07/16/why-physicsts-still-use-fortran/
======
bmh100
Fortran is an excellent choice for numerical computation. Its non-aliasing
assumption allows for compiler optimizations that dramatically speed up
computations. It is even easy to get started with concurrent code through
OpenMP. When I need to run a simulation or a discontinuous optimization
algorithm, I turn to Fortran first.

Here are some resources I have collected over the years.

"Introduction to Modern Fortran" (Fortran 2003):
[http://people.ds.cam.ac.uk/nmm1/Fortran/index.html](http://people.ds.cam.ac.uk/nmm1/Fortran/index.html)

Fortran Wiki:
[http://fortranwiki.org/fortran/show/HomePage](http://fortranwiki.org/fortran/show/HomePage)

List of Fortran tutorials: [http://www.fortran.com/the-fortran-company-
homepage/fortran-...](http://www.fortran.com/the-fortran-company-
homepage/fortran-tutorials/)

Fortran vs. C: [http://www-cs-
students.stanford.edu/~blynn/c/fortran.html](http://www-cs-
students.stanford.edu/~blynn/c/fortran.html)

Fortran's influence on C's "restrict" keyword: [http://www.drdobbs.com/the-
new-c-it-all-began-with-fortran/1...](http://www.drdobbs.com/the-new-c-it-all-
began-with-fortran/184401313)

~~~
Asooka
I have one question - if I compile and link a program written in C and
Fortran, can the linker inline Fortran functions in C? I know it can do it if
I link object files produced from C source, but can it do it if I link object
files from separate languages?

~~~
guitarbill
Having never done it with Fortran, I don't know. It should be possible,
because e.g. on Linux, everything adheres to the ABI. However, the ABI doesn't
specify how to interpret pointers AFAIK. Array ordering [0] and indexing is
different in Fortran compared to C, so I'm sure there's pitfalls you'd have to
account for.

[0] [https://en.wikipedia.org/wiki/Row-_and_column-
major_order](https://en.wikipedia.org/wiki/Row-_and_column-major_order)

~~~
dfgasfjhjhsdojj
Fortran arrays can be indexed however you like. Code that is designed to be
called from C can be written with 0 indexed arrays.

~~~
guitarbill
Sure, but you still have to remember to do so :)

------
Animats
Fortran is still better at multidimensional arrays. Other than Matlab, few
other languages do multidimensional arrays at all. C-derived languages use
arrays of arrays, and use templates, macros, or objects for multidimensional
arrays. Fortran optimizers have lots of multidimensional array-oriented
optimizations which other compilers usually lack.

I tried to talk the Go and Rust people into putting in multidimensional
arrays, but the discussion degenerated into bikeshedding, with arguments for
fancy but slower representations so you could take arbitrary N-dimensional
slices from a multidimensional array.

~~~
ryescienceguy
> I tried to talk the Go and Rust people into putting in multidimensional
> arrays, but the discussion degenerated into bikeshedding, with arguments for
> fancy but slower representations so you could take arbitrary N-dimensional
> slices from a multidimensional array.

This is the most frustrating aspect of Rust, to me, as a developer of
scientific software. Rust has great potential to challenge Fortran in this
domain, but numerics is mostly an afterthought in Rust.

~~~
throwaway7645
Agreed. I want to write numeric software, but don't want to use Fortran or
C++. Rust looked great, but I couldn't find anything in this domain.

~~~
goatlover
Julia has strong numerical and multi-dimensional array support, but it's JIT
compiled. However, once a function is JITted, it has comparable performance to
Go & Rust.

~~~
luthaf
Yep, Julia is a very nice language with very good performances. But I
abandoned it because it is not (yet?) oriented toward library development, and
more usable in exploratory style.

I ran into issues a year ago when trying to organize a library with more than
8000 loc, when the "dump everything into a global namespace" started to be
more a hassle and less a nice way to get stuff done. I am waiting for it to
stabilize a bit before giving a second try.

~~~
photon-torpedo
Could you elaborate on why you felt the need to "dump everything into the
global namespace"? For quite a long time now, you can use modules in Julia to
keep things in separate namespaces. With "import MyModule" (instead of "using
MyModule") things will not enter the global namespace, but will need to be
qualified, like "MyModule.myfunction(...)". I feel this is very much like
Python. You could even introduce abbreviations for the modules, using "const
mm = MyModule" (admittedly, Python's "import...as" is cleaner).

~~~
luthaf
Yes, but `using MyModule` is (was?) the default and preferred way to use a
module. Which is equivalent to recommend everyone to do `from module import *`
in Python.

------
srean
Guy Steele and his group had a really interesting thing going with the
language Fortress (name is a nod to Fortran of course, but fortified). It was
meant for high productivity as well as high speed (petaflops range). It got
shelved after Oracle bought Sun. It was one of the three languages seeded by
DARPA funding for high productivity computing

[https://java.net/projects/projectfortress/pages/Home](https://java.net/projects/projectfortress/pages/Home)

[https://blogs.oracle.com/projectfortress/entry/fortress_wrap...](https://blogs.oracle.com/projectfortress/entry/fortress_wrapping_up)

~~~
pjmlp
> It got shelved after Oracle bought Sun.

Actually the actual real history is little more complex than that.

JuliaCon 2016 (Keynote) | Fortress Features and Lessons Learned | Guy Steele

[https://www.youtube.com/watch?v=EZD3Scuv02g](https://www.youtube.com/watch?v=EZD3Scuv02g)

It would be good if people on HN would separate a bit the Oracle hate with the
facts.

~~~
srean
The causation was certainly not intentionally implied in my comment. I was
stating temporal ordering fact. Hold on to your oracle defense response :)

------
hzhou321
It is simply due to apprenticeship. Physicists do research, and their code is
research code. Like most other research, the research code is maintained and
used in-house. As most in-house non-shared code (in any language), it is
impenetrable unless you take apprenticeship. The masters are typically old and
FORTRAN is their language and it is the only choice for the apprentices. Once
the apprentices graduate and become masters themselves, they further developed
their own in-house code and it is inevitably in FORTRAN too. As any over-
developed code, it is too expensive to migrate even when the new master
recognize the shortcoming. The bottom line, FORTRAN is not bad once you are
familiar with (and invested in) it, so FORTRAN persists over another
generation of apprentices ...

However, there is slight change. The new generation of masters often do know
other languages, so they sometime tolerate their new apprentices to use other
language and still able to teach them. So at this point, by far, not all
physicists use FORTRAN.

FORTRAN will die out, just takes time.

One of the sticking point is the library BLAS/LAPACK. It is in FORTRAN. Or
more precisely, its interface is in FORTRAN. I don't foresee this will change
for a long time. So FORTRAN will be like COBOL, it will persist even when no-
one really use it anymore.

~~~
goerz
I think that's only party true. Physicists would probably not be _exposed_ to
Fortran if it wasn't for "apprenticeship". But the same would be true for any
other very domain-specific language (let's say Mathematica). However, that
doesn't change the fact that Fortran (in its modern syntax) is a great
language for numerics. Its abstractions are extremely well-suited for any
computation focusing on multidimensional arrays. It is certainly a more
expressive language for numerics than C/C++ (and it's not as easy to shoot
yourself in the foot in Fortran). There's not that many other languages that
can compete for high performance applications. Julia looks like it can do some
interesting things. Python is great as a glue language (but not for number
crunching, and of course it's slow). I would still (and regularly do) choose
Fortran for new projects. It's not going away anytime soon.

~~~
hzhou321
Let's see how I may clarify the argument.

First, if one is familiar with a language or invested in a language, he will
be biased to choose that language and it makes sense for him. Before you would
argue, I admit I can't prove that you are biased, but nor could you prove you
are not biased. So let's agree that some anecdotes like your case is not a
strong argument.

So let's look at it in another angle. If physicist/people choose FORTRAN not
merely due to apprenticeship, it necessarily means that there will be people
choose FORTRAN even when his master do not introduce/require him to use
FORTRAN. In another word, we need examples of people who choose FORTRAN
despite of non-familiarity to FORTRAN. There are plenty of such cases for,
e.g. rust. For me at least, I know none such. How about you? For example, how
successful have you been influence other people (other than your student) to
use FORTRAN? On the other hand, I do know people who choose other language
despite of the familiarity of FORTRAN.

~~~
goerz
Of course knowing a programming language strongly biases someone to choose
that language in a project. I also agree you will not find a lot of people (if
any) using Fortran who have not been introduced to the language as part of
their research, following the recommendation of someone senior (e.g. their
advisor). However your original argument was that Fortran was only used
because advisors were forcing their students to do so, and that Fortran would
die out eventually along with those dinosaurs. I don't think this is true, and
I don't think the fact that people generally don't just stumble into Fortran
by themselves is any evidence to the contrary. As the original article points
out, the reason that Fortran continues to be used is that it is the most
suitable language for its domain (but of course _not_ as a general purpose
language)

The prerequisite for using Fortran is that someone works in a field that
relies heavily on large scale, high performance numerical computation. Since
Fortran is pervasive in that domain, it's extremely likely the they would be
exposed to Fortran through "apprenticeship". Basically, most people who should
be using Fortran are using Fortran! I've seen a few instances where people
used C/C++ or Matlab in situations where Fortran would have been more
appropriate. Matlab has its own drawbacks, but it is also a very domain-
specific numerical language, and likewise its users are exposed to it through
apprenticeship! C/C++ is still the default language for high performance
computing outside of numerics, and thus it's not surprising that people who
have not been exposed to Fortran would attempt to use it for numerical
purposes as well.

There isn't exactly a lot of choice for numerical programming: Python and
Matlab are (partly) designed with numerical purposes in mind, but don't scale
to high performance. C/C++ are performant, but not expressive for numerics.
There really isn't any other language that would even be in consideration,
besides now Julia, but Julia is extremely new, so time will tell.

I don't know anything about Rust, but based on reading its Wikipedia article
its not a language designed for numerics, but basically something designed to
replace C++ for systems programming. Thus, like C/C++, it will be performant,
but not expressive for numerical purposes.

------
supergarfield
> Interestingly, C/C++ beats Fortran on all but two of the benchmarks,
> although they are fairly close on most.

Unless I missed something, this directly contradicts the quotes benchmark
source[1], where C beat Fortran on all tests except one (where they were
tied), and usually by a wide margin. Plus I believe gcc usually produces
slower code than Intel's compilers (at least for C), so it's not clear that
C-gcc and Fortran-Intel is a fair comparison.

But beyond that, I'm always confused as to why there is a significant
difference. I would expect two compiled languages with reasonable compilers to
perform almost exactly the same when they're doing nothing but arithmetic
operations, since those are almost entirely determined by the CPU, not the
cleverness or speed of the standard library algorithms. Can anyone enlighten
me?

[1]
[https://benchmarksgame.alioth.debian.org/u64q/fortran.html](https://benchmarksgame.alioth.debian.org/u64q/fortran.html)

~~~
CJefferson
One big difference is the rules on pointers.

In C, if you write code like this:

    
    
      void dostufftotwoarrays(int* a, int* b);
    

Then maybe b is equal to a + 3, so your compiled code has to assume whenever
it writes to an element of a, it might have changed an element of b, and so
reload b from memory. Alternatively, it can do a bunch of tests at the start
of the function, and compile multiple copies of the function for different
situations.

In FORTRAN, this isn't possible (you don't tend to pass around raw pointers),
so it is much easier for the compiler to reason about what objects might be in
the same place, and which aren't.

The restrict keyword goes some way to fixing this in C, but is tricky yo use
correctly, and also doesn't solve all problems.

~~~
greglindahl
Your Fortran summary is incorrect. F77-style arrays _are_ generally passed as
a raw pointer (under the hood.) F90-style allocatable arrays are passed as an
array descriptor containing size information, again under the hood.

This doesn't affect aliasing in Fortran at all. Aliasing is simply prohibited,
which leaves the compiler free to generate code that gets the wrong answer, if
the programmer screws up and has actual aliasing at run-time.

~~~
CJefferson
Apologises, you are right. It's so long since I did Fortran I had
misremembered that the language made it impossible to alias, as opposed to it
being undefined behaviour.

------
dfgasfjhjhsdojj
1\. A program from 30 years ago will compile and run.

2\. As a research student your first program is likely to be a F77 program
written by your professor or an older colleague.

3\. A library from 30 years ago can be easily wrapped into a modern program,
compiled and run.

4\. Arrays are really the most important thing for this sort of programming
and since F90 array level operations have been baked into the language.

5\. It is fairly trivial to write fast Fortran.

6\. Fortran is much easier to use for numerical stuff than c++

------
troymc
When I was doing my graduate studies in astrodynamics (spacecraft trajectory
design) at Purdue University circa 2003, we worked closely with the Jet
Propulsion Lab (JPL) and got to use a lot of their excellent astrodynamics
code (used for missions like Galileo and Cassini). It was all Fortran.

I heard that there was an effort at JPL to convert over to using Python. I'm
not sure how that went. Maybe they were just writing Python bindings for their
Fortran code? I know that much of SciPy consists of Python bindings for
Fortran and C code [1].

The software I used to do "nonlinear programming" (i.e. parameter
optimization), called NPOPT, was also written in Fortran.

[1] [https://www.scipy.org/scipylib/faq.html#how-can-scipy-be-
fas...](https://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fast-if-it-
is-written-in-an-interpreted-language-like-python)

~~~
mturmon
The Python replacement succeeded - I slightly know the people involved, who
got an award for the work. But I don't use the library so I don't know if the
wrapper approach was used. That would be perfectly legit IMHO.

------
ChuckMcM
_" Early Fortran (designated in allcaps as FORTRAN)"_ that would be because it
is an acronym "FORmula TRANslator".

Fortran continues to do that well. And as the article mentions scipy doesn't
run as fast.

The logical successor to Fortran was APL (Arithmetic Programming Language) but
its notation really killed it.

The properties that keep Fortran rolling (easy to start using, effective in
translating formulas into computation) persist.

~~~
thescribe
I'm ignorant about FORTRAN, have there been attempts to modernize it? Maybe
something like coffeescript/typescript?

~~~
ms013
You didn't read the article apparently. Fortran (which officially dropped all
caps in the standard in 1990) has had new versions every couple years, up to
2013. Each revision of the language brings modern features into it, and old
features go through a process of deprecation and then obsolescence. Most
people seem to be unaware that it is an evolving language that has changed
significantly since the standard most people are familiar with from 1977. I am
a bit biased though: I work on a Fortran compiler, so I've had reason to stay
on top of the standards as they come out.

~~~
thescribe
I misread that everything was backwards compatible, my bad.

------
radioactivist
The author is I think being a bit unfair to C++ when it comes to matrix/array
handling. Their example of things that would be difficult to do in C/C++:

A = B

A = 3.24 * B

C = A * B

B = exp(A)

norm = sqrt(sum(A * * 2))

Quoting:

"Similar C/C++ code simply does not exist ... Having to use libraries instead
of intrinsic functions means the resulting code is never as neat, as
transferable, or as easy to learn."

While this statement is true, I think strongly undersells how well these kinds
of libraries can be "baked" into C++ through operator overloading, templating,
etc. See for example, the Eigen library
[[http://eigen.tuxfamily.org/](http://eigen.tuxfamily.org/)].

~~~
m_mueller
here's the problem: These kind of libraries will never come close touching
Fortran's built-in features, simply because the compiler can't automatically
optimise for knowledge about the code that only the library has. Even arrays
not knowing their size is still an issue, let alone array based ops like shown
in the article.

Fortran is not the fastest language around the block, but if you don't want to
go into non-portable machine-based hand-tuned optimisations (e.g. loop
unrolling) it's hard to beat. Basically, if you optimise for both runtime and
programmer time for HPC applications I'd argue that Fortran is top of the
crop.

~~~
whyever
I don't think this is true. C++ matrix template libraries are competitive with
anything that Fortran can do.

------
pif
> If a function that takes a ‘real’ is fed a ‘const real’, it will return an
> error. It is easy to imagine how this can lead to problems with
> interoperability between codes.

What's he talking about? This is wrong!

------
spapas82
One interesting fact that supports the point of the article is that Matlab is
actually using the Fortran code for its implementation of special functions
[https://www.mathworks.com/matlabcentral/fileexchange/6218-co...](https://www.mathworks.com/matlabcentral/fileexchange/6218-computation-
of-special-functions).

The amount of existing scientific code in Fortran is huge and there's a
chicken and egg situation (new code uses/extends old code so new code will
_also_ be in Fortran) that will lead to further increasing it!

~~~
spott
Matlab also uses MKL (written in fortran, with a heavy dose of assembler) for
its blas routines I believe.

------
jstewartmobile
It's funny that someone has to write an article to defend modern FORTRAN to
people who write in _JavaScript_ , which is the best proof we programmers have
of entropy.

~~~
taejavu
It's funny that in every discussion of programming languages that have nothing
to do with Javascript, there's always some smug bastard bashing it.

~~~
jstewartmobile
Because it's really that bad, and we all have to use it because somehow,
Brendan Eich's cocktail-napkin language became the VM of the web.

~~~
andrepd
Yes, and what does that have to do with this article? If you come to a
discussion about thing _x_ to complain about thing _y_ , no matter how valid
your complaint you are out of order.

To quote The Dude: "You're not wrong, you're just an asshole."

~~~
Annatar
_Yes, and what does that have to do with this article?_

Excellent question, glad you asked! Just what do you think all the people who
are asking why Fortran is still in use are using?

My money is on the bet that they're not using Fortran. I've worked in the
finite element analysis / high performance computing fields for quite a few
years and I've never heard anyone who used Fortran complain that they were, or
had to use it. Could it be that it's because people like that they get high
performance from a language out of the box?

------
PaulHoule
Even if you are using python, R or java you are still best off linking to
matrix subroutines in fortran if you want to solve or diagonalize, get
eigenvalues and such. This is not just about raw performance but also
correctness, ecology of roundoff errors, etc.

~~~
ricree
For Python, at least, the most popular numeric computation library (NumPy)
uses a fair bit of Fortran under the hood. I'm not certain whether the matrix
operations do, but it certainly wouldn't surprise me.

~~~
nerdponx
Doesn't NumPy just use BLAS and LAPACK for matrix operations?

~~~
ThatGeoGuy
The vast majority of BLAS and LAPACK are written in Fortran (at least, the
ones provided by netlib.org). Github also reports that OpenBLAS is around 50%
Fortran, so there's quite a bit there too [1]. Usually when you call BLAS
functions from C you're really calling a cBLAS wrapper to some Fortran
function. This is generally why you see -lgfortran -lf77blas when you compile
programs that require numerical tools.

[1] [https://github.com/xianyi/OpenBLAS](https://github.com/xianyi/OpenBLAS)

~~~
simonster
At least in OpenBLAS, most (all?) of the BLAS routines are C functions that
call kernels written in assembly, but many of the LAPACK routines are the
Netlib reference Fortran versions.

------
pducks32
As a physicist please have faith in us. We don't all use Fortran. I use Ruby
as much as possible and it's fun because it forces me to write libraries that
mimic ones that are found in other languages. So I end up learning a lot.

~~~
yxhuvud
I can recommend looking at Crystal if you have some time over. Very Ruby-like
syntax, but compiles down to quite efficient native code.

------
spullara
When I was in undergrad I did some computer simulation work for my professor.
He programmed in FORTRAN while I had been trained in C/C++. I did my
simulations in C/C++ and I also wrote some libraries for his FORTRAN code so
he could have more dynamic configuration files. At the time I thought that
FORTRAN was an anachronism and was surprised that it was still being used in
physics.

This was 1992.

------
santaclaus
What ever happened to the effort to bring Fortran to LLVM (from Los Alamos I
think)?

~~~
lightsighter
Still in development (paid for by LANL, done by PGI):

[https://developer.arm.com/-/media/developer/developers/hpc/f...](https://developer.arm.com/-/media/developer/developers/hpc/files/ARM-
HPC-UG-SC16-PGI.pdf?la=en)

------
syphilis2
I've been looking for a Matlab alternative and been disappointed with either
the performance or the syntax of Octave, Python, and Julia. I'd known Fortran
had modern features and updates every few years, but never tried to pick it up
since the excitement seems to be elsewhere. This article is convincing that
Fortran is worth trying out.

~~~
Xcelerate
What don't you like about Julia's syntax? Is it more than the 1-based indexing
and "end" statements?

~~~
goatlover
Agreed, Julia syntax is very clean. Also, you can make it look more math-like
with it's support for unicode variable and function names.

------
hcrisp
FORTRAN may be faster but one graph shows Python recently overtaking it in
mentions of Astronomy papers [0].

[0]
[https://mobile.twitter.com/astrofrog/status/7870072618771660...](https://mobile.twitter.com/astrofrog/status/787007261877166080)

~~~
arcanus
A great deal of that is for post-processing, however. Very little python used
in the compute heavy pieces of scientific computation.

~~~
maus42
I know a person who works in atmospheric physics group. All the heavy physics
simulation and modeling happens in Fortran, and then they do the "lighter"
analysis, summary statistics, plots, visualizations, etc with a Python-based
stack.

------
Asooka
I have one issue with the article. The way to dynamically allocate a
multidimensional array in C is the following:

    
    
      size_t m, n;
      ... set m and n ...
      int (*a)[m][n];
      a = (int(*)[m][n])malloc(sizeof(*a));
    

Edit: and you MUST NOT REUSE OR OTHERWISE CHANGE m and n FOR THE ENTIRE
LIFETIME of the array, because bad things will happen.

And you access it via

    
    
      (*a)[x][y]
    

And you free it with

    
    
      free(a);
    

And if you want to pass it to a function:

    
    
      void do_with_array(void* raw_array, size_t m, size_t n) {
        int (*array)[m][n] = (int(*)[m][n])raw_array;
        ... do whatever ...
      }
      do_with_array(a);
    

And I'd rather do it in Fortran, but if you ever need to do it _properly_ in C
(i.e. without using array of pointers) - now you know.

~~~
SFJulie
Technically you are right.

Practically you are right, but the article is more right than you. I got into
some fights with quite a few elite teachers/coders teaching the way of doing
2D arrays exactly as described, and they wouldn't agree the method you
describe is less error prone ... because: it is tradition. (And as every
person doing research know tradition is not supposed to change and that what
science values).

It seems absurd, but so many things are absurd these days I am not even
surprised.

~~~
Asooka
Oh, the method I describe is _more_ error prone than array of arrays, because
if you ever modify the two variables you used to specify the array size, the
compiler will just use the new values for array dimensions. If I had to do
array of arrays though, I'd at least do something like

    
    
      template<typename T>
      T** make_2d_array(size_t m, size_t n) {
        // TODO: add padding for alignment,
        // but you're unlikely to need something aligned
        // on a larger extent than sizeof(void*)
        void *memory = malloc(m * sizeof(void*) + m * n * sizeof(T));
        T** array = (T**)memory;
        T* data = (T*)((char*)memory + m * sizeof(void*));
        for (size_t i = 0; i < m; i++) {
          array[i] = data + i * n;
        }
        return array;
      }
    

And you can then delete the entire array with a single free().

------
theden
My reason for using fortran (when I was studying physics) was that when going
through the university library looking for a computational physics textbook, I
couldn't find one that wasn't in fortran—actually I found one (computational
physics, Giordano & Nakanishi) but it wasn't enough to get by. Fortunately I
already knew fortran, because all the legacy textbooks+journals were written
in the language.

------
SFJulie
Just in case you want to use fortran code in python here is the scipy HOWTO

Still up to date.
[https://docs.scipy.org/doc/numpy-1.10.0/user/c-info.python-a...](https://docs.scipy.org/doc/numpy-1.10.0/user/c-info.python-
as-glue.html)

------
orionblastar
Interesting as I learned WATFIV on an IBM 370 with JCL/JECL under DOS/VSE.

There is an Openwatcom project that does C and Fortran but I think it is
Fortran 77.

I had Fortran and COBOL on my resume but most jobs I took used Visual Basic.

------
jheriko
some of the information here is a bit wrong. the idea that const is weaker
than parameter is true, but not for the reasons given. any function taking a
float, int etc. in C++ can also take a const float or const int.

its also unfair to suggest that C/C++ is as fault with not allowing a = b * c
with array types. this is a failing of the standard library and easily
fixed... operator overloading lets you create exactly this functionality, and
std::valarray already does this for a lot of what you get in Fortran...

~~~
pklausler
Good luck getting a high performance implementation of A=B+C without memory
allocation out of a library.

~~~
jheriko
rolling your own is pretty easy, it is a shame that the C++ standard library
is a dire wasteland of bad implementations. you are right that valarray will
do heap allocations and making it work on the stack is a real ballache.

------
tomw2005
In our company we still us FORTH because the timing of each command is well
known.

------
davidf18
It seems like a number of R packages use Fortran. I'm on Mac and it needs to
Fortran compiler to be installed so that at least some of the R packages can
be compiled when doing updates.

~~~
bachmeier
R (the language, originally S) was created to be a "glue language" for
compiled code, most of which was written in FORTRAN.

------
smegel
> Note that Python, which is the darling of computer scientists

Actually physical scientists love Python as much as they love Fortran. It a
lot of cases, it is the only two languages they know.

