3 ms·

If you claim that something like the_data <- read.csv('/path/to/data/file.csv') the_data <- subset(the_data, variable_a > x) the_data <- transform(the_da

by kgwgk 7y ago

If you claim that something like the_data <- read.csv('/path/to/data/file.csv') the_data <- subset(the_data, variable_a > x) the_data <- transform(the_data, variable_c = variable_a/variable_b) the_data <- head(the_data, 100) is a pain to read compared to the_data <- read.csv('/path/to/data/file.csv') %>% subset(variable_a > x) %>% transform(variable_c = variable_a/variable_b) %>% head(100) I thinks it’s fair to mention how by making things more complicated by using pipes you expose yourself to other issues. (In my opinion the first variant is not less readable, and it has the advantage of allowing any of the operations to be removed by commenting the corresponding line, while in the second case to remove the last operation you also need to remove the piping operator in the preceding line.) [Edit: I’m not sure I understand your “out of scope” remark. You don’t mean that magrittr is outside of tidyverse, do you?]

cwyers 7y ago
Because the pipes are at the end of the line, you can comment out a line and it will still work fine unless you're removing the last line of the chain.
- kgwgk 7y ago
  That’s precisely what I said.
roenxi 7y ago
They are roughly equivalent to read; but the reason for that is that the first code sample is clearly someone unwinding something that they are conceptualising as a piped statement. If you aren't conceptualising the code as an unwound pipe, you'd have to actually inspect the code and think about what each function argument means rather than being confident it is a set of chained transforms as you can be by glancing and seeing a %>%. I'm a bit suspicious about that coincidence - after I met the pipe operator, a lot of my code looks like that. Before I met the pipe operator, not very much of my code looked like that. As long as people are thinking in pipes then they can choose if they value making commenting code cheap vs making reading/typing code cheap. But it is quite important that beginners are introduced to pipes as a concept as they learn R. The semantics are critical, using the syntax is optional.
- kgwgk 7y ago
  One could also say that the second code sample is someone unwinding something that they are conceptualising as a set of nested operations: the_data <- head( transform( subset( read.csv('/path/to/data/file.csv'), variable_a > x), variable_c = variable_a/variable_b), 100) All of them are equivalent, each representation has its advantages and disadvantages.
  - roenxi 7y ago
    Well, yeah, if anyone wants to write their pipes that way that is also an option. They aren't going to though, that isn't really human readable when there is a sensible option like using a pipe operator.
    - kgwgk 7y ago
      If you find that the example above is not "human readable" then the following code will make your head explode because it cannot be transformed into a pipe representation (or at least it's not so straightforward): the_data <- transform( subset( rbind( read.csv('/path/to/data/file1.csv'), read.csv('/path/to/data/file2.csv')), variable_a > x), variable_c = variable_a/variable_b)
      - roenxi 7y ago
        Maybe consider: the_data <- read.csv('/path/to/data/file1.csv') %>% rbind(read.csv('/path/to/data/file2.csv')) %>% filter(variable_a > x) %>% mutate(variable_c = variable_a/variable_b) You've thrown out a few variations on a theme here, but I'm not sure where you are trying to angle towards. There are a lot of ways to format code, and I can't tell you what works best for you. But this isn't shaking the paradigm of having an initial block of data (here separated a little awkwardly into two files) that is being subjected to a series of functional transformations, which is sorta pipe-like. Being able to talk about this as a 'pipe' is hugely useful, and having a pipe operator really standardises how people can talk about it. In my experience, selling this as a concept to a beginner is a lot easier when it has syntax support so they know they are doing the 'right thing' and get error messages/uncomfortable looking code when they try to cheat. I don't really care how you nest the brackets, if you want to write something that isn't a pipe go with (edit obviously a non-buggy version of...): for i in 1:nrow(df){ if(df[i,'variable a'] > df[i,'x']) continue; df[i,'variable ac'] = df[i,'variable_a']/df[i,'variable_b'] } If someone shows me that and I can tell them to 'go rewrite it using pipe operators, it will be better' they will naturally start seeing that that horrible block of mixed ideas can be separated out into a few basic composable operations, and that is funnily enough easier for a beginner to grasp in my experience teaching people to use R. Plus, they can tell that a statement is going to be a series of composes on top of raw data if they see a pipe operator. This is a useful thing that makes it easier to read the code.

by kgwgk 7y ago

cwyers 7y ago

Because the pipes are at the end of the line, you can comment out a line and it will still work fine unless you're removing the last line of the chain.

kgwgk 7y ago
That’s precisely what I said.

roenxi 7y ago

They are roughly equivalent to read; but the reason for that is that the first code sample is clearly someone unwinding something that they are conceptualising as a piped statement. If you aren't conceptualising the code as an unwound pipe, you'd have to actually inspect the code and think about what each function argument means rather than being confident it is a set of chained transforms as you can be by glancing and seeing a %>%. I'm a bit suspicious about that coincidence - after I met the pipe operator, a lot of my code looks like that. Before I met the pipe operator, not very much of my code looked like that. As long as people are thinking in pipes then they can choose if they value making commenting code cheap vs making reading/typing code cheap. But it is quite important that beginners are introduced to pipes as a concept as they learn R. The semantics are critical, using the syntax is optional.

kgwgk 7y ago
One could also say that the second code sample is someone unwinding something that they are conceptualising as a set of nested operations: the_data <- head( transform( subset( read.csv('/path/to/data/file.csv'), variable_a > x), variable_c = variable_a/variable_b), 100) All of them are equivalent, each representation has its advantages and disadvantages.
- roenxi 7y ago
  Well, yeah, if anyone wants to write their pipes that way that is also an option. They aren't going to though, that isn't really human readable when there is a sensible option like using a pipe operator.
  - kgwgk 7y ago
    If you find that the example above is not "human readable" then the following code will make your head explode because it cannot be transformed into a pipe representation (or at least it's not so straightforward): the_data <- transform( subset( rbind( read.csv('/path/to/data/file1.csv'), read.csv('/path/to/data/file2.csv')), variable_a > x), variable_c = variable_a/variable_b)
    - roenxi 7y ago
      Maybe consider: the_data <- read.csv('/path/to/data/file1.csv') %>% rbind(read.csv('/path/to/data/file2.csv')) %>% filter(variable_a > x) %>% mutate(variable_c = variable_a/variable_b) You've thrown out a few variations on a theme here, but I'm not sure where you are trying to angle towards. There are a lot of ways to format code, and I can't tell you what works best for you. But this isn't shaking the paradigm of having an initial block of data (here separated a little awkwardly into two files) that is being subjected to a series of functional transformations, which is sorta pipe-like. Being able to talk about this as a 'pipe' is hugely useful, and having a pipe operator really standardises how people can talk about it. In my experience, selling this as a concept to a beginner is a lot easier when it has syntax support so they know they are doing the 'right thing' and get error messages/uncomfortable looking code when they try to cheat. I don't really care how you nest the brackets, if you want to write something that isn't a pipe go with (edit obviously a non-buggy version of...): for i in 1:nrow(df){ if(df[i,'variable a'] > df[i,'x']) continue; df[i,'variable ac'] = df[i,'variable_a']/df[i,'variable_b'] } If someone shows me that and I can tell them to 'go rewrite it using pipe operators, it will be better' they will naturally start seeing that that horrible block of mixed ideas can be separated out into a few basic composable operations, and that is funnily enough easier for a beginner to grasp in my experience teaching people to use R. Plus, they can tell that a statement is going to be a series of composes on top of raw data if they see a pipe operator. This is a useful thing that makes it easier to read the code.