Questions about R in production

[spiritus87]

@nwerth

As for R's poor performance, this is often the "fault" of the code writer. If you want faster calculations, use an array or sparseMatrix . Use basic indexing or assignment instead of filter and mutate .

Most R code is written to be easy to understand and modify. It presents the steps in an analysis like the methodology section of an article. Performance isn't always a concern. So there a lot of R coders who don't know how to write efficient or fast code. But that doesn't mean it's impossible or even difficult. They just need to learn how it's done.

I think this is as interesting point. It seems to me that even within R (i.e., without comparing R to other languages) there is a tension between performance vs clarity of the code. I'm not saying this is an either-or, but often it seems like one. My guess is that most R coders emphasize clarity because when you develop an analysis or a model, well, you want to make sure all the complicated steps you apply are as transparent as possible. Which makes sense.
On this point, I agree with Hadley Wickham's maxim that you should first write code for clarity, and then refactor parts for performance when you see you need it. I think it's a good approach.

@nwerth

I will agree that some packages are just reinvented wheels. I think of purrr as a repackaging of base higher-order functions with a uniform style for names and arguments. I'm perfectly happy with vapply , mapply , lapply , Reduce , and Negate .

But what would be the base R equivalent of something like purrr::map_df?