2 ms·

It's a good reading but some of the complaints are hard to understand. For example, in 4.5.1: Selecting and deleting at the same time doesn’t work either. F

by kgwgk 5y ago

It's a good reading but some of the complaints are hard to understand. For example, in 4.5.1: Selecting and deleting at the same time doesn’t work either. For example, data[c(-1, 5)] is an error. What would it mean for that to work? He seems to acknowledge that "selecting and deleting at the same time" doesn't make sense in 4.11.1 Can you guess what data[-1:5] returns? I can’t either, so don’t ever try it. If you must know, it’s actually an error. Also in 4.11.1: The : operator is absolutely lovely… until it screws you. The solution is to prefer the seq() functions to using : [....] As I’ve said, seq() and its related functions usually fix this issue. Maybe the "related functions" fix some issues but seq(a,b) is not different from a:b In 4.11: Now what do you think names(foo) <- names(bar) does? Seriously, can you guess? I can think of roughly four realistic guesses. Is it even valid syntax? How is that surprising? Can the author also think of four realistic guesses about the effect of A[1,2] <- B[3,4] for example? In 4.13: The index in a for loop uses the same environment as its caller, so loops like for(i in 1:10) will overwrite any variable called i in the parent environment and set it to 10 when the loop finishes. [...] This sounds awful, but I’ve never encountered it in practice. Is it awful? The same happens in other languages like Python or C if I'm not mistaken. The plot() function has some strange defaults. For example, you need to have a plot before you can plot points [...] I have no idea what that means. You can plot points using plot() without having a plot beforehand. Edited to add: In 4.5.3: The $ operator is another case of R quietly changing your data structures. Is it unexpected that when we extract an element from a data structure we get a different kind of data structure? Is A[1,1] another example of silently changing one data structure (matrix) to another (number)?

mst 5y ago
> Is it awful? The same happens in other languages like Python or C if I'm not mistaken. It annoys the shit out of me in python. I much prefer perl's for my $x (@array) { ... } or ES6's for (let x of array) { ... } Note that given python and ruby only do function level scoping rather than block level, I can -understand- why they work the way they do even if it annoys me. R already has the necessary granular scoping to do the (IMNSHO) sensible thing so it seems like a pointless wart. My -guess- would be that if it was intentional, it came about in R because for loops are rare enough that you want to know the last index more often than you don't because if you don't care about the index presumably you'd've written something else. (also you could argue the ES6 version would be better written using 'const', but I've lisped sufficiently my fingers invariably generate 'let' when left to their own devices - caveat emptor)

by kgwgk 5y ago

mst 5y ago

> Is it awful? The same happens in other languages like Python or C if I'm not mistaken. It annoys the shit out of me in python. I much prefer perl's for my $x (@array) { ... } or ES6's for (let x of array) { ... } Note that given python and ruby only do function level scoping rather than block level, I can -understand- why they work the way they do even if it annoys me. R already has the necessary granular scoping to do the (IMNSHO) sensible thing so it seems like a pointless wart. My -guess- would be that if it was intentional, it came about in R because for loops are rare enough that you want to know the last index more often than you don't because if you don't care about the index presumably you'd've written something else. (also you could argue the ES6 version would be better written using 'const', but I've lisped sufficiently my fingers invariably generate 'let' when left to their own devices - caveat emptor)