Don’t enforce R as a standard

Yesterday, I received the reviews for a paper of mine. It was rejected with an
invitation to resubmit, so far, so good. In this paper, we present a lot of new
measures to work on probabilistic networks, and it’s all in the
preprint if you really want to read more about that. To do the paper,
as in, to produce the figures and do the analysis, I wrote a package in
Julia. I’m proud of this package. It’s fast, defensively programmed, well
tested, already parallelized if you use several CPUs, and all that. It’s also
released under the MIT “Expat” license, so you are free to do with it as you
please.

It’s important to specify that this paper is not a software paper. It’s the
description of methods, and it so happens that we decided to release the package
alongside it. This is where things got complicated.

Reviewer 1 wants more practical details about the software (despite it not being
the purpose of the paper), and that we have to justify that it is indeed usable.
Some of this point is fair (I will write a short introduction, and the code used
for the figures will be published alongside the paper). Reviewer 3 states that
since Julia is not frequently used by ecologists, and therefore it’s dubious
that the methods are usable, or even useful, and a R package would be better.

The three reviews were helpful and constructive, but these two comments
infuriated me. Let me start with a bit of background. I’m not anti-R. I gave
department-wide R training for graduate students and faculty. I wrote R
packages to go with papers, and released them on GitHub, and I keep on fixing
bugs and maintaining them. I use R on a daily basis. I contributed code to
other people’s R packages. One of my lab machines runs RStudio server for
colleagues that lack computational power. But it’s a tool. It’s neither a
religion, nor a standard, nor a pre-requisite for getting your paper accepted in
an ecological journal.

Let me put things in perspective.

First, a package written in anything is better than no package at all. And as
far as I’m concerned, this should be the end of the argument. And especially
if this is not a software paper (but even then), the language a software is
written on has nothing to do with the scientific merit of the paper. Unless the
choice of language means bad performance or a significant risk of errors, or the
impossibility to run the code, it can be written in lisp or cobold for all I
care. I cannot emphasize this point enough: any code organized in a software
library and released under a FOSS License is better than no code at all.

Second, what to write a piece of software in, as the guy in charge of actually
writing the code, is a conscious decision. And knowing the type of data, and use
cases (because I’ve since used this package in a few projects), and the
algorithm used, and all that, I decided that R was not the best choice I can
make. Could I write a R version of it? Yes. But I won’t, because I don’t have
that much time, it won’t be as efficient, and I’m not interested in doing it.

Third, there is this thing in the open-source crowd, where you don’t get to be
entitled about a piece of software that is available for free. This is
extremely important. That something is released does not imply that the
maintainers will do free work for you. Especially when the message is “I don’t
like this because this is not the way I do it, so can you start again?”. The
whole point of FOSS is that if you don’t like it, you can fork it. But you don’t
get to complain about something that is given away for free. This is just rude
(see also, first point – it’s better than nothing). I don’t expect praise for
writing code (except by my continuous integration engine, that sends me
comforting Build passed emails). But if I go the extra mile of writing and
organizing and optimizing code, it’s grating that people complain because it’s
not matching their personal preferences.

Fourth, this points back to a larger issue – R is not the only computational
tool we have. Every time these is a pushback about something on the basis that
this is not R, we are losing opportunities. I’ve had discussion with people
saying that they won’t even try to publish software, because it’s not in R and
they don’t feel like fighting an uphill battle where most of their energy will
go into their language choice. And because of this “R or bust” mentality that
some people are so vocal about, cool things are not properly released. There
is a cost.

Every time you complain about the language code is written in, Ethan White has
to buy a new computer:

I know that accessibility is important – this is what picking FOSS platforms
and languages is about, and this is why FOSS licenses for scientific code
should be enforced. But beyond that, what should matter is, does it works as
advertised?. Software is not something that happens magically out of thin air.
People write it, people like me, and our choice of how to write takes precedence
over your ideal language in which to run it. Replying to reviewers is an
exercise in picking your battles – this one I’ll fight.