<p><div><div><div><div data-show-faces="false" data-height="21" data-width="100" data-layout="button_count" data-send="true" data-href="https://www.r-bloggers.com/dplyr-0-7-made-simpler/"></div></div><div></div></div><div></div></div>
<div>
(This article was first published on <strong><a href="http://www.win-vector.com/blog/2017/07/dplyr-0-7-made-simpler/"> R – Win-Vector Blog</a></strong>, and kindly contributed to <a rel="nofollow" href="https://www.r-bloggers.com/">R-bloggers)</a> </div>
<p>I have been writing <em>a lot</em> (<a rel="nofollow" href="http://www.win-vector.com/blog/2017/07/better-grouped-summaries-in-dplyr/" target="_blank">too much</a>) on the <a rel="nofollow" href="https://www.r-project.org/" target="_blank"><code>R</code></a> topics <code>dplyr</code>/<code>rlang</code>/<code>tidyeval</code> lately. The reason is: <a rel="nofollow" href="https://blog.rstudio.org/2017/06/13/dplyr-0-7-0/" target="_blank">major changes were recently announced</a>. If you are going to use <code>dplyr</code> well and correctly going forward you may need to understand some of the new issues (if you don’t use <code>dplyr</code> you can safely skip all of this). I am trying to work out (publicly) how to best incorporate the new methods into:</p>
<ul>
<li>real world analyses,</li>
<li>reusable packages,</li>
<li>and teaching materials.</li>
</ul>
<p>I think some of the apparent discomfort on my part comes from my feeling that <code>dplyr</code> never really gave standard evaluation (SE) a fair chance. In my opinion: <code>dplyr</code> is based strongly on non-standard evaluation (NSE, originally through <a rel="nofollow" href="https://cran.r-project.org/package=lazyeval" target="_blank"><code>lazyeval</code></a> and now through <a rel="nofollow" href="https://cran.r-project.org/package=rlang" target="_blank"><code>rlang</code>/<code>tidyeval</code></a>) more by the taste and choice than by actual analyst benefit or need. <code>dplyr</code> isn’t my package, so it isn’t my choice to make; but I can still have an informed opinion, which I will discuss below.</p>
<p><span></span></p>
<p><code>dplyr</code> itself is a very powerful collection of useful data analysis methods or &quot;verbs.&quot; In some sense it is a fairly pure expression of how you organize data transformations in <em>functional programming</em> terms. (By the way: <a rel="nofollow" href="https://cran.r-project.org/package=data.table" target="_blank"><code>data.table</code></a> is probably an equally fundamental powerful formation in <em>object oriented</em> terms.)</p>
<p>In <em>my opinion</em> there are only two places where <code>dplyr</code> truly benefits from or actually needs the (often complicated and confusing) full power of non-standard evaluation: in the <code>dplyr::mutate()</code> and <code>dplyr::summarize()</code> verbs.</p>
<p>I admit: a system that can’t accept an arbitrary functions or expressions from the user lacks expressive power. However, the only place you truly need this power is when creating a new derived column in a <code>data.frame</code>. If you can do this then you can drive all of the other important data wrangling functions (row selection, row ordering, grouping, joining, and so on).</p>
<p>When I teach <code>R</code>, I teach you are going to have to copy your data at some point. You are fighting the <code>R</code> language if you try to completely avoid copying as you would in other more reference oriented languages. This is likely one of the reasons <a rel="nofollow" href="https://github.com/rstudio/Strata2016/blob/master/solutions/02-Big-Data.Rmd" target="_blank">Nathan Stephens and Garrett Grolemund define &quot;Big Data&quot; as</a>:</p>
<blockquote>
<p>Big Data ~ ≥ 1/3 RAM.</p>
</blockquote>
<p>Once you accept you are going to make copies (which is not part of all systems, but in my opinion is a part of <code>R</code>) then you should take advantage of the fact you are going to make copies. In particular you should land, materialize, or reify the results of complicated user expressions as actual data columns (i.e., propagate data forward, not propagate code forward). Doing this wastes some space, but can actually be easier to parellize, potentially faster, easier to document, and much easier to debug.</p>
<p>There is no reason to shun code of the form:</p>
<div>
<pre><code><span>suppressPackageStartupMessages</span>(<span>library</span>(<span>&quot;dplyr&quot;</span>))

starwars %>%<span> </span>
<span> </span><span>mutate</span>( <span>want_row =</span> height ><span> </span>mass ) %>%
<span> </span><span>filter</span>( want_row ) %>%
<span> </span><span>select</span>( -want_row )</code></pre>
</div>
<pre><code>## # A tibble: 58 x 13
##                  name height  mass    hair_color  skin_color eye_color
##                 </code></pre>