31–40 of 62 posts
I'd recommend python based on the slightly-saner tooling. I've found that python with conda/pipenv/poetry results in mostly reproducible installs of the tools needed to run a computation.
R is hard to reproduce library setup. Unable to compile and static validation.
R might be a perfectly fine language, but the culture and ecosystem around R seem to produce a lot of untested, difficult to read code. Globals everywhere, mediocre requirements resolution, and a lack of forced namespacing come to mind. Maybe it's a result of being used by people who are not primarily programmers.
I'd say the R dev community was then actively hostile to a culture change to support any model other than individual contributors working at their desktop.
I run operations for a company that relies heavily on R, and I'd strongly advise against using the language. R's package management system makes reproducing work difficult. We've had to rely on using renv, a snapshot of CRAN (the default source of R packages: some FTP servers), and a bunch of Docker to get vaguely reproducible installs. However, since R installing a package involves compiling that code that you just…
This is all about tradeoffs. Fundamentally, if your package doesn't compile on the latest version of R, it gets removed from CRAN. This means that each version of R has a consistent set of packages that (mostly) work together.
Contrast with Python which does facilitate reproducible builds, because you can hack together ancient versions of Python and make them continue working. I could go into a massive rant here about pip, but it's trending in the right direction now and I don't want to discourage any of the people working on it.
R is better in terms of being able to ensure that for a given R version, any package you install will be compatible, Python is better for making sure that that one application built three years ago keeps working in the same fashion.
Also, it sounds like you're running a nix based system, have you considered (I'm sure you have) using the system packages. For example, the Debian/Ubuntu ones are pretty comprehensive, at the cost of using older versions. I believe that R-studio also have pre-built packages for Linux (but have not tested this) so that could also work.
To be fair, conda is pretty good as a package manager, because it handles the C++/C dependencies. But to your Docker point, that's how I handle the insanity that is python packaging, especially in the data science space, so it may just be an issue with the field itself.
R is far more of a Lisp than Python, and in a field that heavily relies on DSL abstractions (which definitely includes clinical laboratories), R is going to fight you a lot less than most choices.
In regards to packaging, you have MRAN snapshots, you have conda (which will give you binaries on Linux), you have renv, roughly in order of preference. The situation is not ideal, but it's certainly not worse than Python, this is not a hill I'd die on!
Julia might be an exciting and welcome alternative to both; from where I'm sitting, it hardly even enters the conversation currently (in data science where I'm at, it's all Python and R, with Python unfortunately taking by far the larger slice of the pie), but I wish it a bright future, it's a great language.
Earlier quoted context omitted.
Actually, it most probably reverse. Python, numpy, pandas, etc are cobbled together with duct tape to do what R does elegantly. There is no consistency with Python ecosystem.
Agree. One thing is very clear in the R vs. Python debate is that a lot of programmers seem to know either or, not both. They are different tools for different purposes.
That being said, R is amazing for exploratory work, while Python is better for integrating with the rest of the world.
R might be a perfectly fine language, but the culture and ecosystem around R seem to produce a lot of untested, difficult to read code. Globals everywhere, mediocre requirements resolution, and a lack of forced namespacing come to mind. Maybe it's a result of being used by people who are not primarily programmers.
It's also important to note that much of the original core of R is based on S, which was developed around the same time as C, so some baggage would be expected.
I run operations for a company that relies heavily on R, and I'd strongly advise against using the language. R's package management system makes reproducing work difficult. We've had to rely on using renv, a snapshot of CRAN (the default source of R packages: some FTP servers), and a bunch of Docker to get vaguely reproducible installs. However, since R installing a package involves compiling that code that you just…
Earlier quoted context omitted.
There are different qualities. Code quality and quality of the functionality. In R you more packages that do what you expect (mathematically) but the implementation is inelegant and slow. Written by someone who knows exactly what they need and what the package should do, but has difficulty of writing it down. In python you many well implemented neat packages where the code is well implemented and performs well, but i…
> In R you more packages that do what you expect (mathematically) I disagree with this point explicitly. Many packages are not only poorly written programmatically and systemically, they also produce bad results in common cases and fail silently. This has been discussed well before on our very own YCombinator. https://news.ycombinator.com/item?id=17308554 > is not exactly doing what user need or skips important featu…
You may be unaware, but there are vast similarities between the object system of R and Python, mostly due to their common inheritance from the Art of the Metaobject protocol. They look very different (generic functions vs classes), but they are equally extensible.
The trouble with R's systems is that there's three of them, and people use whichever works without really understanding any of them, but all the tools are there.