5 ms·

I really wish this trend of using pseudo-pipes in R would stop.

• bsg75 9y ago
  "pseudo-pipes"? As in %>% ?
  • lottin 9y ago
    Yes, it's horrible.
    • minimaxir 9y ago
      Why?
      • curiousgal 9y ago
        I like it but it makes it hard to take R as a serious programming language (thankfully it's not in standard R) because where else would you actually use a coding pattern like: a = "foo" a = "bar" reusing variables is silly.
        • minimaxir 9y ago
          The alternative is to use a different variable for each data transformation, which has costs for both system memory and code readability. And modern data analysis has a lot of transformations.
      • lottin 9y ago
        Because combining an argument with a function call doesn't make sense. They have to do some voodoo under the hood to make it work and this reduces code understandability. The analogy with Unix pipes doesn't work either: one is passing an argument to a function while the other involves writing & reading a file. Finally, it's plain ugly and un-Lispy.
        • mpweiher 9y ago
          Unix pipes don't read/write files. There also isn't any reason why other implementations of pipes have to do buffered byte read/writes, passing objects is perfectly acceptable. The structurally distinguishing aspect of a pipe-and-filter style is that the individual processing elements don't "return" to their "caller", but rather pass their result on to the next processing element. Without involving the caller.
        • sin7 9y ago
          This particular pipe comes from F#. Let's say I have a table called dat. dat %>% filter(col_a == 'Good') %>% group_by(col_b) %>% summarize(n = n(), sum_c = sum(col_c)) To do this in traditional R, I would have to: dat <- dat[dat$col_a == 'Good'] dat_n <- aggregate(col_a ~ col_b, dat, length) dat_sum <- aggregate(col_c ~ col_b, dat, sum) merge(dat_n, dat_sum, by = "col_b") I think the piped version is more readable. At least there are less variable to track.
          • extr 9y ago
            That's because you're comparing to base-r. The data.table way would be: dat[col_a == 'Good', .(Length = .N, Sum = sum(col_c)), col_b]
            • jcheng 9y ago
              That's all well and good for operations that are built into data.table; pipes can be used with anything that's a function call (like ggpage).
            • nerdponx 9y ago
              Data.table is great for SQL-style code but it imposes some annoying limitations, namely that the output is always coerced to a data.table.
            • jhbadger 9y ago
              The problem with data.table is that in practice your data gets converted to something else when you pass it through packages -- many functions will return a data.frame or matrix, others in the Hadleyverse will return a tibble, and so on. So you have to constantly force your data back into a data table. R has so many datatypes that basically represent a spreadsheet/database table.
    • coetzeesg 9y ago
      I don't agree that it's horrible, but it really doesn't work particularly well in the context of the S4 objects in, for example Bioconductor.
• mdlincoln 9y ago
  I find that a fascinating reaction given how rapidly %>% have been taken up across a large segment of the R universe, to great excitement! Personally, I find it far MORE legible than endlessly-nested function calls. It results in code that more closely resembles executed order of operations (e.g. filter -> mutate -> group -> summarize). Context is also key: it's most often used for data processing pipelines in specific analytical scripts or literate-code documents - less so used when defining generalizable/testable functions in packages (again, just a personal perspective - YMMV of course)
  • extr 9y ago
    you nailed it. dplyr is better the further you are from doing heavy duty data analysis or creating production code. if you're writing some simple transforms to put data into a report, fine. someone is probably going to want to look at that at some point and it's much, much easier to understand. but for anything else i stick with data.table.
• confounded 9y ago
  Death to the Pyramid of Doom!
• jgalt212 9y ago
  Maybe R needs transducers. https://clojure.org/reference/transducers https://clojure.org/reference/transducers https://stackoverflow.com/questions/26317325/can-someone-explain-clojure-transducers-to-me-in-simple-terms https://stackoverflow.com/questions/26317325/can-someone-exp...
• bsg75 9y ago
  https://github.com/hrbrmstr/rstudioconf2017 https://github.com/hrbrmstr/rstudioconf2017