3 ms·
As a long-time R user, I agree with all of these complaints. The language itself is ugly and actively tries to get in your way. I'll add that concepts like da
by andrewla 8y ago
As a long-time R user, I agree with all of these complaints. The language itself is ugly and actively tries to get in your way.
I'll add that concepts like data frames are not really intrinsic, and you get needless complexities like "length", "nrow", "dim", each of which does the wrong thing in 90% of the scenarios of interest. The confusion of lvalues is another strange quirk -- a <- 0; length(a) <- 20 is totally valid, and you get things like class(a) <- 'foo' being preferred over the equivalent a$class <- foo. It has all sorts of odd concepts between lists and data.frames -- the double-bracket syntax, etc. The object model is very confusing, though most people seem to have converged on the S3 system, which is the oldest one.
If you discipline yourself to learning "the good parts", especially by learning either data.tables or tidyverse or becoming a master of split/lapply/aggregate/ave, then it is very powerful. The modelling tools and plotting (both base graphics and ggplot2) are excellent.
I'd love to see a NeoR arise at some point that fixes the strange historical inconsistencies (like what happens when you refer to vec[0], as noted by the author) in non-backward compatible ways.
- ryanmonroe 8y agoWhat is needlessly complex about length, nrow, and dim and why would they ever give you the wrong thing? length always gives the length of an object, i.e. the number of elements in it[1]. nrow will always give the number of rows, and dim will always give the dimensions e.g. for a data.frame with 3 rows and 4 columns dim(df) is (3, 4). [1]That is, top-level elements. If a list L contains 3 vectors, each with 9 elements, length(L) is 3, not 9 or 9*3 = 27
- curiousgal 8y ago>split/lapply/aggregate/ave I always feel bad when I resort to a for loop in R. Do you have any recommended ressources about mastering those specific manipulations?
- ekianjo 8y agoUnless you do something quitec complex dplyr is faster for such operations and consumes less RAM too.
- crispyambulance 8y agoReally, it's not always worth the trouble. Sometimes a loop is vastly more performant if you count the amount of time it takes to get the "idiomatic" way working and working in a way that allows easy troubleshooting.
- buchmayne 8y agohttps://github.com/jennybc/row-oriented-workflows https://github.com/jennybc/row-oriented-workflows getting comfortable with purrr has been enormously helpful in consolidating my code and avoiding unnecessary loops
- phnk 8y ago> I'd love to see a NeoR arise at some point that fixes the strange historical inconsistencies […] in non-backward compatible ways. Microsoft (or perhaps the Apache Foundation) could pull such a trick, and win a huge user base by doing so. My guess is that several top R developers must have also thought of doing so, esp. those who write C code for R.