Table of Contents
There is a whole sub-culture of food porn, the lavish coffee table books that set out to educate you to an entire culture through its food. I once saw a library of several hundred.
These are page flippers – doesn’t that look marvelous, we’ll have to try it next time we find halibut cheeks. The sad fact, though, is that any of these books are lucky if the owner actually uses one or two of its recipes and exalted if a recipe becomes a dinner party staple.
The first edition of R Cookbook by Paul Teetor, published in 2011, was, in analogy, similar in that it provided flavors with good recipes, many of which proved useful for specific needs.
The second edition, just out with J.D. Long as co-author retraces and updates much of the content of the first edition, brings RStudio and tidy tools to bear, and subverts the dominant paradigm. You flip through it and it first appears to be the cookbook equivalent of granny’s index card recipe box. But it starts off with enough new that you stop flipping pages and start reading.
It took me two days to read the 554 pages. I had the help of several airplane hours, but it would have been a page turner anyway. What captivates is the rigorous R tutorial cleverly hidden in asides, call-out boxes and brief explanations of why a particular code chunk does one thing when you might reasonably expect another.
In my childhood, Donald Duck had three nephews, Huey, Dewey and Louie who got their uncle out of more than one jam by consulting The Junior Woodchuck Manual, which somehow contained the answer to any question that could possibly arise. The R Cookbook, 2ND Ed. comes close to that standard for the beginner to intermediate user who is completely innocent, on the one hand, or who has been covertly using functions without a well-founded understanding of their requirements and limitations.
It would be an unconventional choice, perhaps, but this is the book that I would choose for the text if I were teaching a course in introductory R. Why? Because this book tells you what R does, not what it is. Any student coming to it with even an imprecise notion of $f(x) = y$ is going to be able to follow along to the point, perhaps, of wanting to write her own package. The text doesn’t cover this, but points you in the right direction, and suggests source(“good_stuff.R”) as an interim step.
In other words, its approach is like R’s, functional, not imperative, definitional not procedural. In my view, the implications in the R vs. Python wars are obvious. In one model, Professor Higgens tells Eliza bring me my slippers. In the other, he first has to declare a subject (the slippers), a possessive (my slippers), object (grammatical, me) and then, with the verb, provide detailed instructions on where they are to be found, how brought into possession and the means by which they are to be transported to their destination.
Someone once said something to the effect that assembly language uses humans as pre-processors. I’m afraid that is true of many of its do-this, then do-that descendants.
For now, their defense is the superiority of compiled programs in speed on the metal and the much more expensive wetware. And they are right for the one-off case. But as cases proliferate or become abstracted, wetware costs go up faster than throughput advantages.
It will not happen while I’m still sentient enough to follow, but a compiled R or an R to Haskell API does seem to provide the best of both worlds. Put the wetware where it belongs, in defining the problem and the appropriate solution and leave the optimization to languages that are good at implementing functional logic.
Sed ego et qui me defricatus urina contra ventum?
