I prefer using Rust rather than paying hundreds of thousands of dollars on a static analysis tool for C++.
Also, to quote a comment[0] of yours from 2 days ago:
What you are saying is that since you prefer something everyone should do the same.
And what you prefer is the correct choice for everyone ...
It's not perfect, but I'm struggling at finding bad things to say about it.
In this post, I make a recommendation of staying away from R. It is not even a remotely similar context.
But R also makes a lot of the tasks you do in data science far easier than it would be in a 'real language'.
Though, to be fair, I like R. It has good plotting libraries, and as much as it gets bashed I like RStudio too. In comparison, Raku's ecosystem is brand new.
Sure, most of the matrix operations and tight loops are implemented in FORTRAN or C++, but that's for performance reasons. The same would happen with Python, and I don't think it would be fair to call Python a scripting language either; it also has a ton of Lisp like qualities.
# cat /tmp/test.R
x <- 1:10
y <- 1:20
plot(x, y)
# R --quiet
> source("/tmp/test.R")
Error in xy.coords(x, y, xlabel, ylabel, log) :
'x' and 'y' lengths differ
> traceback()
8: stop("'x' and 'y' lengths differ")
7: xy.coords(x, y, xlabel, ylabel, log)
6: plot.default(x, y)
5: plot(x, y) at test.R#3
4: eval(ei, envir)
3: eval(ei, envir)
2: withVisible(eval(ei, envir))
1: source("/tmp/test.R")
R -d gdb
options(error=recover)As for the "easy iterop with other languages": [1]
So, how is R different from Python?
Also, it's not true that R wasn't designed for writing software. Even a critical "pamphlet" by Pat Burns [2] states otherwise. For writing statistical software, yes.
--
[1] https://wiki.python.org/moin/IntegratingPythonWithOtherLangu... [2] https://www.burns-stat.com/pages/Present/infernoishR_annotat...
My experience is that people who make bad R programs also make bad python programs. I don't think you should blame a tool for issues caused by the programmer.
there is no escape.
When I said "colleagues" I really meant the entire scientific field runs on untold lines of buggy R code, so obtuse, so cryptic, that the task of debugging or even tracing what is going on is practically impossible. And you can't debug it because it is this awful R code everywhere! And when the code breaks it does not break like normal programming language do, with an error or exception or even a stack dump. No! Most of the time your R code will just start silently doing the wrong thing.
>try loading up any scientific package and you'll see how, in turn loads up other and other packages, in bioinformatics you can easily add up to dozens if not a hundred of dependencies
That's not necessarily a bad thing unless you're trying to run R on embedded or some other constrained environment.
>When I said "colleagues" I really meant the entire scientific field runs on untold lines of buggy R code, so obtuse, so cryptic
I can't recall the last time I've bumped into a bug in an R library. I'm sure they exist but thankfully the ecosystem is quite stable.
>that the task of debugging or even tracing what is going on is practically impossible.
Debugging in R is easier than most languages. I'm unsure where you're getting your facts from.
>And when the code breaks it does not break like normal programming language do, with an error or exception or even a stack dump. No! Most of the time your R code will just start silently doing the wrong thing.
It's no worse than Python in this regard. R isn't particularly bad in this area, but it's certainly no C++.
I'm going back to guessing it's because R is FPP. That's R's dirtiest and most offensive part to the uninitiated.
But don’t worry about R bringing science down - the scientific community can also write terrible python code.
There are many books that cover how to develop in R in detail, and they are no less thorough than treatments of the subject in other languages (e.g. Hadley's books are as good as any I've read for python).
Many issues around inconsistency, etc, in language design (mostly how base functions / data types behave) have very clean, consistent implementations in libraries like rlang.
The main differences I see when comparing R vs python package code, that affect style are...
1. Most R operations are immutable.
2. R often uses single dispatch, rather than putting methods on a class object.
3. In R, vectorised behavior is often the norm.
4. R functions can choose to use lazy evaluation (it usually very clear when this happens in e.g. tidyverse packages).
These issues are covered in detail in books like Hadley's Advanced R.
My hat off to him though!
As for the language ... consider this: lapply(), sapply(), tapply(), vapply() each does something different. The language allows two kinds of assignment operators even: a=1 or a <- 1 that are "almost" identical ... good luck, here is a language there are two ways to even assign a value to a name.
The <- assignment is normal for functional programming languages. F#, OCaml, S, and more use this operator. This is because the arrow key used to be a physical key on keyboards back in the 70s when FPP was popular and brand new.
The = sign (function assignment operator) is function level scope and <- (assignment operator) is top level scope.
eg:
median(x = 1:10)
x ## Error object 'x' not found
median(y <- 1:10)
y ## [1] 5.5
x <- 1:10
median(x)
median(x <- 1:10)
edit: Python has the := operator which functions the same way <- does in R. I guess Python is catching up on this one.
eg (Python):
env_base = os.environ.get("PYTHONUSERBASE", None)
if env_base:
return env_base
if env_base := os.environ.get("PYTHONUSERBASE", None):
return env_basethree ways if you count a <<- 1 for writing in global variables from inside functions (of course, not a recommended practice...)
I don't see what you point is though. So there are several ways to do the same thing in a language, so it's bad? Bad in what way?
As for the lapply, sapply, tapply, mapply, it's very well documented as to when and where you should use them. Sapply applies only on a single vector, and for generalization on larger data structures you use the other "applys". Nothing very hard to comprehend, and this is well explained in the official docs.
There are many people in the R community working on this together (e.g. Jenny Bryan, Charlotte, etc).
> lapply(), sapply(), tapply(), vapply() each does something different.
The apply situation has been standardized through the purrr lib and dplyr for a long time. They are base library functions that aren't mandatory.
> two kinds of assignment operators even
Consider the custom of using <-. It reduces the kinds of assignment operators to 1. Similar to avoiding from lib import * in python. You can do it, but there are community standards against it.
The thing is, it's easy to write bug-ridden sloppy code in any language. Bemoaning R as a language because of these flaws, occurring due to rapid adoption, ignores the reasons why R has seen wide-scale adoption.
R has had an extreme democratizing effect on access to tools that facilitate data science. Previously, tools for data science were either massively expensive or had a prohibitively high price tag attached.
This means that many non-programmers are coming to R, and I maintain that the problems the parent post sees with R stem from that fact. As a result, any language that achieved that sort of layman (to programming) appeal would have the exact same bug or sloppy code fallout. That you cannot separate the momentum that led to such an accessible tool without have the same consequences. Rather than demonize the tool for this, we should recognize the positive dynamic at play and simply help guide users to better practices or improvements that would fix the issues.
None of this makes R a bad language, in my opinion. R is far from the only language with surprising edge cases like this. People say that R is designed for statistical analysis more than general programming, but I don't think that's exactly true either. Certainly it excels in writing code for statistical analysis, but I've used R a lot more than that, and I plan to continue. It's a perfectly fine general-use scripting language.
I think the real reason R gets such a bad reputation is that a lot of people writing and publishing R code aren't programmers by trade. And you know what? That's fine. Because I'd much rather work in a community that values and celebrates the publishing of code than one that shames people for releasing their code because it's "not good enough".
The vast majority of packages are written by somebody taking their interactive session and tidying it up with some functions and tests and then publishing it. But going through and weeding out all these "broken by default for edge case" aspects is a nightmare.
https://www.talyarkoni.org/blog/2012/06/08/r-the-master-trol...
https://www.burns-stat.com/pages/Tutor/R_inferno.pdf
and many others.
I have come to believe that the only people that think R is ok are those that are either:
- beginners that just passed the newbie state, learned a few tricks and feel empowered
- actual experts - that fully understand the minute details of the implementation and data models
I have been using R on and off for a decade, as soon as I stop using for a few months getting back is like a tar pit where I am continuously caught off guard by the myriad of ridiculous problems. Paradoxically as you get better with R your errors start becoming more dangerous, your code starts silently doing the wrong things.
R is unlike any other programming language that I have used before (also on an off) from Perl, C to Python and Java. None of these programming languages have such in incredibly obtuse and illogical and trippy design.
You can virtually say the same thing for every programming language that is made to be easy to learn by hiding complexity, like Python or Ruby.
What would the others be? Python is one, I guess.
Also potentially PHP?
I have no opinion on JavaScript.
I guess some people may include Perl. Others won't, either because they don't think it's ill-designed or they don't think it's popular :-)
I really hope you are not using R for anything outside data science, physics, or other analysis. It was developed to do these things, not 'actual programming', which I imagine you define as creating some framework or application.
Most of the people that don't like R seem to want to use it outside of its use cases, and get frustrated when they fail.
Yet R is a lot more expressive than Python + Pandas for data related applications. It was never made as a universal language to develop any kind of applications, but it's pretty good at what it does with data manipulation.
I thought that was what everyone was using it for. What are people using it for?
Anyway, I think it's better to make use of a small, commonly used, and well tested library instead of reinventing the wheel again and again. Libraries are not one of my concerns I have with R.
now what if I told you that the majority (perhaps all) of these libraries you loaded and are needed to run the complex analyses in life sciences were all developed by people who are oblivious to proper software engineering. These were never meant to be used the way they are used - expose myriad of global variable names, methods etc.
You say you are using a small well-tested library with R, sure - but that is not what happens in science and for those that see what is going on, we know we're completely FKDd
The tragedy is that we cannot cure cancer as long we try to do it with R - and R is not going anywhere ...
I don't know a single package that exposes global variables. I only know packages that expose certain functions and provide some configuration via options. In R, there are no really private variables though. If you want, you can access anything you want. Since everthing is packaged in its own environment, I don't see that as a problem though since the global namespace doesn't get polluted. It won't make people with a background in one of the more modern OOP languages happy but that's probably not that important.
Moreover after seeing what my colleagues publish as scientific R programs, I came to believe that science itself is bottlenecked by the large scale adoption by R and the sloppy, inconsitent and bug-infested programming practice that it encourages.
R does a few things well - cross-platform, plotting works on all platforms, packaging works well. But for actually programming it is atrocious.