Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An opinionated view of the Tidyverse “dialect” of the R language

github.com

Post reply on HN
Print view View original

121–130 of 156 posts

Re: An opinionated view of the Tidyverse “dialect” of the R language

#121

Post by ImaCake »

ACow_Adonis wrote: post #117
nonbel wrote: post #102

Earlier quoted context omitted.

> "Dr. Matloff is grossly underestimating how painful it is for beginners to, eg, figure out when they are dealing with a column of strings vs a column of factors." This is just sapply(df, class)... Is this not found in R 101 material that beginners are likely to find?

Pay no attention to the myriad of other apply functions hiding behind the curtain and the difficulty in remembering what each of them does and why you can't just use map, eh? :) So to answer your question, no, its not just simply that.

Looking at the documentation; "sapply" is itself a wrapper for "lapply", and will do a number of different things depending on what arguments are passed into the function or not.

Re: An opinionated view of the Tidyverse “dialect” of the R language

#122

Post by nonbel »

ACow_Adonis wrote: post #117
nonbel wrote: post #102

Earlier quoted context omitted.

> "Dr. Matloff is grossly underestimating how painful it is for beginners to, eg, figure out when they are dealing with a column of strings vs a column of factors." This is just sapply(df, class)... Is this not found in R 101 material that beginners are likely to find?

Pay no attention to the myriad of other apply functions hiding behind the curtain and the difficulty in remembering what each of them does and why you can't just use map, eh? :) So to answer your question, no, its not just simply that.

There is nothing to remember to solve that problem besides the wrote memorization of sapply(df, class).

Re: An opinionated view of the Tidyverse “dialect” of the R language

#123

Post by c06n »

phonebucket wrote: post #85
minimaxir wrote: post #55

From personal experience, I learned R during college as a part of my stats courses, before tidyverse even existed. After doing a few personal projects using base R with complex manipulations, I would have quit using R entirely if it were not for tidyverse/dplyr. I'm a pragmatic software engineer: I prefer to get a data analysis job as fast as necessary, and IMO there isn't much merit in making things more complicated…

With regards to the usefulness of piping with dplyr: the post does express its admiration for data.table as the alternative for dplyr. In data.table, chaining operations together is standard and as simple as a set of brackets to contain the next operation. Both are preferable to pandas though (joke not troll).

I use piping in combination with data.table all the time. It works simply like this:

   my_dt %>%
      .[i, j, by]
It's a powerful combination. Fast, very readable, extremely versatile.

Re: An opinionated view of the Tidyverse “dialect” of the R language

#124

Post by laichzeit0 »

Bootvis wrote: post #5
kickout wrote: post #3

Decent critiques in my opinion. I was trained on/learned base-R myself ~10 years ago and love the "tidyverse" (although the author is correct, data.table is superior for big data and its not particularly close). Can't imagine people that only know tidyr/dplyr/etc without knowing base-R, seems like those people would get exposed quickly. I enjoy base-R solutions where I can. I use data.table when my data sets are medi…

I don’t even understand the not a real language critique, R: - is based on scheme, a HN favourite; - integrates very well with C++ through RCpp allowing you to do whatever you want. 9/10 times someone already went through the trouble for you.

The last time I tried putting a REST API in front of my predictive model, I used plumbr. I also then learned that the R runtime was single threaded, so that only 1 request could be processed at a time. I don’t know how you can overcome this, and it makes things significantly difficult to put into a real production environment.

I’m sure someone will chime in that there are different runtimes, like Microsoft’s (does this run on MacOS? If not, how can I use it to develop and test on my laptop) or some expensive RStudio solution.

The fact is you have none of those problems in e.g., Python. Although I would prefer to use Caret for many predictive modeling tasks, it is non-trivial to take the R runtime to production. That was what I walked away with.

Re: An opinionated view of the Tidyverse “dialect” of the R language

#125

Post by FranzFerdiNaN »

RosanaAnaDana wrote: post #107
hadley wrote: post #101

Earlier quoted context omitted.

You are of course free to dispute what is in the tidyverse, but I pretty strongly believe that it is part of the tidyverse

Seeing as the tidyverse is pretty much your invention, its well within your purvue to define what is in and what is out. I do think, respectfully, that both the op and the general sentiment article have the right of it. Data.table and data.table-esque notation represent such an improvement of tibble/dplyr, that within my company, we're making a concerted effort to purge all tidyverse packages from general use (less g…

Sure, with your amount of data you need data.table. But that is your specific use case. That has nothing to do with dplyr not being production ready, just that it is not the right tool for you. Separate things but somehow programmers love to consider them the same.

Re: An opinionated view of the Tidyverse “dialect” of the R language

#126

Post by kgwgk »

roenxi wrote: post #111
kgwgk wrote: post #87

Earlier quoted context omitted.

If you claim that something like the_data x) the_data is a pain to read compared to the_data % 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 b…

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 a…

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  x),
                               variable_c = variable_a/variable_b),
                    100)
All of them are equivalent, each representation has its advantages and disadvantages.

Re: An opinionated view of the Tidyverse “dialect” of the R language

#127

Post by kgwgk »

nonbel wrote: post #102
roenxi wrote: post #44

He is glossing over the major issue with base R, which is its tendancy to switch data types in a way that appears random to new users. As an undergrad I spent nights literally on the verge of tears debugging R code where the types had been mucked up by R's bizarre semantics. Claiming that data[foo] is the same as filter(data, foo) is not correct - the [] and [[]] operators have a lot of strange side effects depending…

> "Dr. Matloff is grossly underestimating how painful it is for beginners to, eg, figure out when they are dealing with a column of strings vs a column of factors." This is just sapply(df, class)... Is this not found in R 101 material that beginners are likely to find?

Or simply str(df) or summary(df)

Re: An opinionated view of the Tidyverse “dialect” of the R language

#128

Post by roenxi »

kgwgk wrote: post #126
roenxi wrote: post #111

Earlier quoted context omitted.

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 a…

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 x), variable_c = variable_a/variable_b), 100) All of them are equivalent, each representation has its advantages and disadvantages.

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.

Re: An opinionated view of the Tidyverse “dialect” of the R language

#129

Post by vincent-toups »

lispm wrote: post #99
vincent-toups wrote: post #75

Earlier quoted context omitted.

I can give you some sense of why one can compile SBCL and not R. SBCL and other Lisps these days maintain some kind of conceptual barrier between macroexpansion time and run time, so that you can _stage_ your activity appropriately. Read the code, gather the macro definitions, expand the code (repeat as necessary) until you have some base language without metaprogramming in it. Then you can optimize and compile. This…

> This is particularly true of Scheme which foregoes much of the dynamic quality of Common Lisp The idea of even the standard Common Lisp is that both is possible: a static Common Lisp and a dynamic Common Lisp, even within the same application in different sections of the program. Common Lisp allows hints to the compiler to remove various features (like fully generic code being reduced to type specific code), it all…

Its definitely the idea. I know it works well enough for a lot of people, but for me, I'm happy to just give up on the dynamic behavior in favor of a simpler universe.

The last thing I want to be thinking about is whether my compiler needs a "hint" that something can be stack allocated, for instance. That is their business, not mine.

Re: An opinionated view of the Tidyverse “dialect” of the R language

#130

Post by jointpdf »

RosanaAnaDana wrote: post #109
jointpdf wrote: post #105

Earlier quoted context omitted.

There is a new operator, {{ or “curly curly”, aimed at dealing with this. It’s part of the rlang (0.4) package and looks snazzy / easy to grasp. Check it out: https://www.tidyverse.org/articles/2019/06/rlang-0-4-0/

Yuck.

Have anything more constructive to say?
Post reply on HN