Should tidyeval be abandoned?

I've gotten my head around basic tidy eval and use it regularly now. The most common place I see people running into challenges is where there are competing quotation systems. Typically this means strings vs quosures.

When I store a list of parameters in open code I now store them as quosures rather than strings:

# group_by is happy to accept a list of quosures
sepaldims <- quos(Species, Sepal.Length)
iris_sepal <- iris %>%
  group_by(!!!sepaldims) %>%
  summarize(sepal_width = mean(Sepal.Width), petal_width = mean(Petal.Width))

These even allow modification without re-specifying parameters:

petaldims <- quos(!!!sepaldims, Petal.Length)
iris_petal <- iris %>%
  group_by(!!!petaldims) %>%
  summarize(sepal_width = mean(Sepal.Width), petal_width = mean(Petal.Width))

But tidyr::left_join still expects a list of strings: by = c("Species", "Sepal.Length"). If I want to supply these programatically the best solution I found was by = sapply(sepaldims, quo_text). Consider this a plug for abstracting quo_text to lists of quosures.

@stewart.ross mentioned SQL where we often pass parameters as a string with comma-separated values. In code that feeds an SQL query I try not to fight this and simply pass strings. If I read parameters from a table I end up with a list of strings. To use this in tidy eval functions I rely on syms() to convert to a list of symbols and !!!syms() within the function call.

I figured out how to write functions that accept bare expressions: col <- enquo(col) enables mtcars %>% count(!!col). But then you realize that ggplot(aes((!!col), n)) does not work (yet). One solution is ggplot(aes_string(quo_text(col), "n")) but this can get verbose if there are multiple parameters. I think this is where most people end up because aes_string was a good work-around when using lazyeval elsewhere and passing parameters as strings. It took a while before I realized that you can simply use ggplot(aes_(col, ~n)). I think once you get your head wrapped around NSE you forget to use SE.

Overall, Programming with dplyr does a great job explaining how to live within a tidy eval universe. It's both conceptual and a cookbook. It would help if the recipes included more on how to interface with alternate quoting systems. And any caveats about practices to avoid (like passing around lists of strings?).