It's a cool feature which enables some really nice APIs, but it also has the potential to break your mental model when reading code. For example:

    x <- f(a)
    y <- g(x, z)

vs

    y <- g(f(a), z)

It would be extremely unexpected if the result `y` was different for these two expressions, but you can't know for sure without reading `f` – since it could be using NSE. This applies to any innocent-looking function in any library you use – imagine trying to debug an issue caused by something like this.

It's also awful for performance. Allowing functions to peek at their arguments at any time is one of the things that makes R virtually impossible to optimise effectively.

Of course, libraries like dplyr also show that it can be used to great effect in the right hands.

I think this is a big part of why R is such a success amongst data analysts.

A lot of R libraries have a really good human interface which you can play around with and it will successfully DWIM a lot of the time.

Once you start trying to drive R in a more automatic way with your own programs, though, it starts to get really messy. I wouldn't want to make even a medium-sized program in it (10,000 lines would be too, for example). Then it's time to switch to Python with numpy.

I wonder if Julia will be able to cover both types of program effectively. There's definitely a niche for it if it can.

I don't know if this is a _general_ downside of NSE, but in the specific context of dplyr, I've found that the focus on NSE has made it a pain to do things in a standard-evaluation way, like if you're writing general functions that use dplyr under the hood.

Dplyr provides SE versions for most all functions, but you frequently need `lazyeval::interp` when building expressions that do work (e.g. for `mutate_`): https://cran.r-project.org/web/packages/dplyr/vignettes/nse....

Notice that document avoids full examples of se-dplyr + lazyeval; I suspect this is purposeful because it tends to look horrid compared to the usual NSE approach. That said, dplyr is still an amazingly productive paradigm shift and I'll keep using it.

Yes, they're isn't really any dedicated syntax in R for manipulating unevaluated expressions, which makes it difficult to write comprehensible metaprogramming code.

Most people don't know that R has a OO and a Functional side to it. After I learned Racket my R programming changed. After hunting down why I found out that the authors of R wanted to add scheme into the S language when they created R. So you can do some very functional style writing that looks very elegant.