1. 2

The best remark is actually in his previous article, which he mentions but doesn’t link, Let’s have some sympathy for the part-time R user. Emphasis mine:

There is a temptation that if you are going to only teach one system it might as well be rlang/tidyeval as “that is what now comes with dplyr”. I feel this is a false savings as while rlang/tidyeval “is already in dplyr” the rlang/tidyeval concepts and details are not “already in the user” (and in fact include a fairly number of irregular exceptions, needing to be taught and memorized).


  2. 1

    For non-R-users who are interested in the ‘Let’s have some sympathy’ article, a bit of background that will help you read it. It’s two articles in one, really.

    The outer parts, going up to ‘The Example’ (or perhaps up to and including the first paragraph of ‘Re-use’) and resuming again at ‘Conclusion’, are a discussion of keeping part-time users of a language in mind when writing code that will be re-used by others.

    The middle, from ‘The Example’ up to ‘Conclusion’, is a comparison of various available solutions that let you generalize dplyr code to take the column names to act upon as parameters. The reason this generalizing is nontrivial is that dplyr uses non-standard evaluation to capture the passed-in expressions (even though it is unquoted) and evaluate them in the context of the data frame. For example: my_data_frame %>% mutate(ratio = x / y) will return the original data frame with a new ‘ratio’ column that is the ratio of the data frame’s x and y columns. Very useful, until you want to generalize: at that point, the interactive user’s desire that names be automatically evaluated in the data frame’s context is at odds with the programmer’s desire that role-based placeholders should be evaluated in the context of a role<->column mapping, and those column names should then be evaluated in the data frame’s context.