Comment by jdietrich | Hacker News Reader

Comment by jdietrich | Hacker News Reader

To give the other side of the argument:

Most scientists have little or no quality training in software development, but scientific research is increasingly reliant on software. At present, software is a glaring black box in a great deal of research, because very few reviewers have the skills to thoroughly scrutinise it.

A software monoculture always has negative consequences, but fragmentation can be equally problematic in many cases. A reviewer saying "This would be better in R" usually means "I have no chance of understanding your code, because it's not in R". For better or worse, R is currently the statistical computing lingua franca in most fields.

I believe that the scientific method is in real trouble, due largely to the immense complexity of much modern-day research. Scientists have access to immensely powerful analytical and statistical tools, but most lack the training and infrastructural support to use them in a rigorous manner. Bad practices in software and statistics are the norm, rather than the exception; I'm sure most of this is just an honest shortcoming, but I'm equally sure that the lack of CS and stats experience amongst reviewers is a gift to would-be Bogdanovs and Obokatas.

Science has always been a collaborative effort, but I think most fields are in desperate need of greater support from computer scientists and statisticians. Ultimately I would like to see those professions become deeply integrated into all scientific fields, with the expectation that all papers should credit a statistician and (where applicable) a computer scientist. Likewise, editors and reviewers need far closer ties to CS and statistics professionals. Of course, these issues are intertwined with many other problems in funding and peer review.

Until then, the hegemony of R may simply be a price we have to pay for better research in the short-term. A software monoculture at least gives reviewers a fighting chance of spotting issues with software that might affect the validity of results.

I think its more like, "I have no chance of understanding your code, BECAUSE IT'S IN R." The vast majority of R users and I bet 95% of ecologists, can't read and understand R modules. Its the PHP of Data Science.

The point, then is to supply code with simple instructions so that anyone can run it. Secondary goal: write it in a language a human can actually read.

If you're doing science and you want people to understand your code, you use Python, not R.

Option 2: Make an API with a simple and well-documented interface. Forget about the language BS.

Thank you.

Well, the point here is reproducibility, which requires reading and understanding the code, right?

Also, many R packages end up being written in cpp.

Do you mean C++?

(It's a pet peeve of mine. The language is called "C++". "cpp" is commonly used as the suffix for C++ source file names, but the name "cpp" also refers to the C preprocessor.)

The common R package for integrating C++ is called "Rcpp", so calling it "cpp" isn't that strange in context.

Many Python packages are written in C. So long as there's a clean interface, I don't see it as a problem.

There's no problem here, the issue is that the journal reviewers were complaining the code wasn't written in R, which seems strange when non-vectorizable algorithms essentially force code to be written in another language (the same is true for python/numpy - sometimes you need to drop to cython).

> If you're doing science and you want people to understand your code, you use Python, not R.

Wouldn't that depend on which language "people" know?

> Its the PHP of Data Science.

Some might disagree with that statement. Some might even argue that languages where for loops are idiomatic and strongly promoted by the BDFL are the PHP of Data Science.

If so, you're the first "people" I've ever heard this argument from :)

I don't disagree, but PHP is not the canonical reference for code which cannot be understood, that would be Perl.

PHP is the canonical reference for code which can be understood but not interpreted, because you don't know the values of various obscure global flags.

See Perl seems easy to read to me, and functions work like I expect, whereas PHP has a bunch of functions where variable order is not consistent.

R isn't horrible, and if you are in the repl, you can print any function's code you can access, which is awesome.

Python is an ugly language for scientific work; any of R, matlab, or julia are far preferable for not massively obscuring the intent of your code with the programmatic hoops you have to jump through. People who are programmers I think tend to wildly underestimate the effort needed to learn and read python.

Further, the vast majority of R modules are at least partially implemented in R and tend to be very readable.

what hoops are you referring to? My phd work was all matlab, and I vastly prefer python for readability and practicality

Any linear algebra looks ugly --

   python: X.dot(Y)
   matlab: X*Y
   R: X %*% Y

It makes less difference when it's only 2 matrices, but when it's 3+ it's far more readable.

pandas has a lot of functionality, but the interface is far inferior to R's data frame, where you have

   df[row predicate, column predicate]

particularly the highly useable intermingling of column access by index or name. reshape2 and plyr are, imo, far more elegant and less wordy apis.

The api to sklearn, while definitely more consistent than R's apis, has a lot more programmer nonsense interjected: imports of random packages, the difference between pandas and numpy that still peeks through the second you step outside of statsmodels, etc.

numpy has a serialization format, while pandas uses pickle or hd5. R just uses save/load, and unlike pickle in my experience, it reliably works.

matplotlib is an ugly api, particularly compared to ggplot.

few things that do not completely address your points, but may help

- python 3 (.5?) is adding the @ operator for matrix multiply. Of course this only helps you if your company uses python3

- There are 2 packages (seaborn, ggplot(clone)) which sit on top of matplotlib and provide a much nicer interface for statistical plots

Too bad Python 3 equals Perl 6. :(

If you want people to understand your code, you need to treat it like writing: rewrite, rewrite, rewrite. The language itself is almost irrelevant: you can write horrible code in Python and beautiful code in R.

Actually, no. I have written several modules and packages in R, both native and C++, and it is impossible to write efficient R that is beautiful or even comprehensible.

Hopefully you know the parent was Hadley Wickham who has very much contributed to the readability and beauty of R. So much so that even Python data scientists are lamenting that their code is not quite as beautiful as the "hadley stack" [1]

FWIW, I've done both Python and R and they both have their pluses and minuses, but beauty is in the eye of the beholder and I've seen some R packages that do, indeed, make R beautiful, case in point, the dplyr package from Hadley Wickham. I'd love to see the future of R be inspired by dplyr and ggplot.

[1] -- http://technology.stitchfix.com/blog/2015/03/17/grammar-of-d...

True, but if you write decent or so-so Python code, it is readable to anyone who knows a C like language. So-so R code is still impenetrable.

The language matters. One is optimized for ... honestly I have no idea what R is optimized for. I don't think R works that way. It just is. Python though, its optimized for readability.

python is optimized for readability to C programmers

R is optimized for statisticians

Badly written R is impenetrable. So is badly written R. I suspect your standards for so-so R code are vastly different to mine.

R and Python really are very similar as languages. R is more functional, but that shouldn't impede your ability to understand code (once you master some of the basic idioms of FP)

I can't actually comment on what is good/bad R code, because I've never seen any R code beyond a few lines that I could follow.

"A software monoculture at least gives reviewers a fighting chance of spotting issues with software that might affect the validity of results."

If I understand it correctly, this observation shows just what a short distance we've come in programming languages and software development since the 1960s. Verifying the correctness of a program shouldn't depend on good naming or being able to execute it in your head.

> Science has always been a collaborative effort, but I think most fields are in desperate need of greater support from computer scientists and statisticians. Ultimately I would like to see those professions become deeply integrated into all scientific fields, with the expectation that all papers should credit a statistician and (where applicable) a computer scientist.

This is very true, but it will be difficult to realise within the university centred system of research composed of many small labs, none of which can really offer any sort of career path for non-academic professionals.

R is an amazing data language and ecosystem. There just is no parallel in terms of diversity of capability. Python is a second but not a close second.

Our battle should be more with SAS.

Reply on news.ycombinator.com