<p><div><div><div><div data-width="100" data-show-faces="false" data-send="true" data-layout="button_count" data-height="21" data-href="https://www.r-bloggers.com/evolving-r-tools-and-practices/"></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/02/evolving-r-tools-and-practices/"> R – Win-Vector Blog</a></strong>, and kindly contributed to <a rel="nofollow" href="https://www.r-bloggers.com/">R-bloggers)</a> </div>
<p>One of the distinctive features of the <a target="_blank" rel="nofollow" href="https://cran.r-project.org/"><code>R</code></a> platform is how explicit and user controllable everything is. This allows the style of use of <code>R</code> to evolve fairly rapidly. I will discuss this and end with some new notations, methods, and tools I am nominating for inclusion into your view of the evolving “current best practice style” of working with <code>R</code>.<span></span></p>
<p>
<h2>Background</h2>
<p>Let’s place <code>R</code> (or the <code>S</code> programming language) into context.</p>
<h3>Strict Languages</h3>
<p>Often computer programming language semantics are effectively described by use of analogy that separates the user-observable behavior from the implementation.</p>
<p>For example it would make sense to say in <code>C++</code> the decision as to which implementation is used during a method call is implemented <em>as if</em> a search were made at runtime across the <code>C++</code> object type hierarchy until a match is found. Whereas in practice the <code>C++</code> compiler implements this <a target="_blank" rel="nofollow" href="https://en.wikipedia.org/wiki/Dynamic_dispatch">dynamic dispatch</a> as a reference to a hidden data structure (that is not visible to the programmer) called a <code>vtable</code>. This leads me to say that languages like <code>C++</code> and <code>Java</code> implement strong object oriented programming as these languages work hard to enforce meaningful invariants and hide implementation details from the user.</p>
<h3>Tolerant Languages</h3>
<p>In the <code>Python</code> programming language we also see object oriented semantics, but the implementation details are somewhat user visible because the programmer has direct access to the implementation of the object oriented effects (such as: <code>self</code>, <code>__dict__</code>, <code>__doc__</code>, <code>__name__</code>, <code>__module__</code>, <code>__bases__</code>). The object oriented semantics of <code>Python</code> are defined in terms of lookups against these structures, which are user visible (and alterable). So in some sense we can say <code>Python</code>‘s object semantics somewhat rely on convention (the convention being the users don’t mess with the “<code>__*__</code>” structures too much).</p>
<h3>Wild Languages</h3>
<p>Then we get to the case of <code>R</code> where everything is user visible. In <code>R</code> almost nothing is implemented “as if” a given lookup is performed; the described lookup is almost always explicit, user visible, and alterable. For example <code>R</code>‘s common object oriented system <code>S3</code> is visibly implemented as pasting method names together with class names (such as the method <code>summary</code> being specialized to models of class <code>lm</code> by declaring a function named “<code>summary.lm</code>“). And to invoke dynamic dispatch there must be an explicit base function itself calling “<code>UseMethod()</code>” to re-route the method call. </p>
<p>Further, under <code>R</code>‘s “everything is a function” rubric, things you would think are language constructs controlled by the interpreter are actually user visible (and modifiable) functions and operators. For an example see the “evil rebind parenthesis” example found <a target="_blank" rel="nofollow" href="http://adv-r.had.co.nz/Functions.html">here</a>.</p>
<p><code>R</code>‘s user visible semantics are wholly convention, as they stand only so long as nothing has been tinkered with yet.</p>
<h2>So Why Does <code>R</code> Work?</h2>
<p>Language extensions that would require cooperation of the core development team in most languages can be implemented through user definable functions and packages in <code>R</code>. This means users can re-define and extend the <code>R</code> language pretty much at will. Given this extreme malleability of the <code>R</code> runtime it is a legitimate question: “why <code>R</code> hasn’t fractured into a million incompatible domain specific languages and died?”</p>
<p>I think <code>R</code>‘s survival and success stems from four things:</p>
<ol>
<li>Most <code>R</code> users are have the same goal: analyzing data. So they are mostly working in the same domain.</li>
<li>The open nature of the <code>R</code> ecosystem allows competitive evolution of notations and language extensions. We retain the winning ideas and paradigms, regardless of their original source.</li>
<li><code>R</code> is probably a lot less constant than we choose to perceive it to be. Package maintainers work hard so “things just work” and continue to do so over time.</li>
<li>The amazing efforts of open-source non-profits such as: <a target="_blank" rel="nofollow" href="https://cran.r-project.org/"><code>CRAN</code></a>, <a target="_blank" rel="nofollow" href="https://www.r-project.org/foundation/">The R Foundation</a>, and <a target="_blank" rel="nofollow" href="https://www.r-consortium.org/">The R Consortium</a>. </li>
</ol>
<p>Some relevant examples that help illustrate how the <code>R</code> ecosystem works include:</p>
<ul>
<li>Konrad Rudolph has <a target="_blank" rel="nofollow" href="https://github.com/klmr/functional#a-concise-lambda-syntax">a very clever re-binding of <code>-></code></a> as function abstraction or lambda introduction allowing code like the following:
<pre>
modules::import('klmr/functional/lambda')
sapply(1 : 4, x -> 2 * x)
## [1] 2 4 6 8
</pre>
<p>Unfortunately this is incompatible with any code that uses either of “<code>&lt;-</code>” or “<code>-></code>” for assignment (you lose both as the <code>R</code> parser perversely aliases both symbols together). This incompatibility is why, even though this is a neat effect, we don’t see a large sub-population coding in this style.

<li>Stefan Milton Bache and Hadley Wickham’s <a target="_blank" rel="nofollow" href="https://cran.r-project.org/package=magrittr">magrittr pipe</a> rapidly rose to prominence as it didn’t break previous code (using a previously uncommon operator glyph “</ul>