4 ms·

This also looks painful: https://community.rstudio.com/t/magrittr-inside-a-package/2033 https://community.rstudio.com/t/magrittr-inside-a-package/20...

• minimaxir 7y ago
  That's an interesting caveat with pipes/magrittr (I didn't know of it), although it's out of scope of this debate since this discussion is just about how tidyverse uses pipes. In my experience if there's a package that's required in a script/R Notebook outside of tidyverse, I just import the entire library at the start of the file Python-style (to make the dependency obvious), which would avoid this issue.
  • 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)