hadley

There are few differences in performance due between the base pipe and magrittr due to the work we did in 2.0.0: https://www.tidyverse.org/blog/2020/11/magrittr-2-0-is-here/.

This release also cleaned up some edge cases so that the semantics are as similar as possible too, making it easy for folks to switch between the two.

Just a small note that R is not pass-by-value, it’s more copy-on-modify. See some of the details at https://adv-r.hadley.nz/names-values.html

Quarto will support output to typst in the upcoming 1.4 release: https://quarto.org/docs/prerelease/1.4/typst.html

I think the big different between quarto and typst is the scope. quarto is a tool for combining prose and computation to generate many different output types (HTML, PDF (via latex), PDF (via typst), PPT, ...) through the power of markdown/pandoc. typst is a typesetting system for turning plain-text markup in to beautiful PDFs.

I think you're much more likely to want to write typst by hand than latex, but out of the box it doesn't provide any tooling for combining writing and computing (if that matters to you).

A scale isn’t exactly a function because it also needs the inverse in order to draw axes and legends. And it turns out axes and legends are where most of the complexity of scales lie.

This was fun to play around with. I made some very minor changes and posted at https://gist.github.com/hadley/d54895557fbb0fe0402d2277b9011....

It revealed to me that there's a buglet in `forcats::last()` (https://github.com/tidyverse/forcats/issues/303) and made me wonder if `pivot_longer()` should be able to rename the columns as you pivot them (https://github.com/tidyverse/tidyr/issues/1338)

Have you seen https://dtplyr.tidyverse.org? It gives you the syntax of dtplyr and (almost all of) the speed of data.table.

They don't often come with code, but one of my recent sources of R programming joy is the folks posting their generative art to twitter: https://twitter.com/search?q=%23rstats%20%23generativeart&sr...

Ah yeah, connecting the dots in ggplot2 docs is hard. It's hard for us to document because, under the hood, the pieces quite decoupled and different pieces are responsible for different arguments. But since we last took a deep dive on the ggplot2 docs, we've gotten much better at generating docs with code, so maybe it's time to have another look. I've filed an issue (https://github.com/tidyverse/ggplot2/issues/4770) so we don't forget about it, but no guarantees about when it might get done.

I love the phrase "eviscerate a fresh data set" :D

100% this :)

Do you have any specific examples that illustrate the general problem? I'd love to better understand what you're looking for in docs.

Yeah, that's my current position. It's possible that we might be able to add it in optionally (by adding a new `.by` argument to summarise and friends), but just the analysis to determine how it would affect existing code is a lot of work.

From dbplyr experience, folks want to be able to do stuff like `across(which(is.numeric), mean)`, which you can't do currently because dplyr doesn't know the column types (although it does maintain a list of the column names).

acquero uses derive (https://uwdata.github.io/arquero/api/verbs#derive) which I rather like (it's better than mutate, IMO)

FWIW the separate `group_by()` is one of my greatest design regrets with dplyr — I wish I had made `by` a parameter of `summarise()`, `mutate()`, `filter()` etc.

We are in the middle of a process to systematically re-license as much as possible as MIT. More on that soon.

Could you shoot me an email? I’m always on the lookout for pandoc freelancers.

Doh - I filed an issue on our internal tracker to fix this

A lot depends on what you’re doing. Most of the time, when I’m not doing data analysis, I don’t find pipes to be that useful so I don’t use them.

Beware that apply() coerces data frames to matrices, which is time consuming and forces all columns to have the same type.

Let’s keep the discussion civil please. People have legitimately different needs, and just because a package isn’t well suited to your needs doesn’t mean that it doesn’t help people with different backgrounds and goals.

I don’t think anyone is arguing that the pipe should be the -only- form of composition. Just that it’s a useful form when you have a linear sequence of transformations. Sometimes it’s useful to force something close to being linear into a linear form for consistency, but typically you would switch to an alternate form of composition, typically assigning to intermediate variables.

It’s easy to find examples of using the pipe in ways that I would consider suboptimal. But that doesn’t affect my thesis that, on average, the use of the pipe leads to more readable code.

I was also initially quite sceptical of the pipe, since it is a fundamentally new syntax for R (although obviously used in many other languages). I think the uptake by a wide variety of people across the R community does suggest there’s something there.

Pretty much all of the individual components of the tidyverse were created before the tidyverse since it’s only 3 years old.

But there’s no reason to use only the tidyverse. That’s not something I’ve ever recommended and it would be extremely hard. I just object to people claiming that some of the most important parts of the tidyverse aren’t actually parts of it.

If you find data.table more useful, you should by all means use it.

My greatest regret about coining the word tidyverse is that for some reason people seem to think it’s a monolith. It’s not; you’re totally free to pick and choose whatever parts of it you find useful.

It doesn’t hurt my feelings if packages that I have help write aren’t the perfect fit for your problems. Use whatever makes you happy :)

You are of course free to dispute what is in the tidyverse, but I pretty strongly believe that it is part of the tidyverse

I think that is good advice but it’s not a great fit for R packages due to the requirements that CRAN has for package submission. I’ve wrapped up my recommended practices in usethis::use_mit_license().

dplyr does not do deep copies. See discussion in https://adv-r.hadley.nz/names-values.html#df-modify

You should take a look at tourrr which implements a bunch of "grand tour" algorithms in R. These take your on a smooth tour of random projections of your data, visualised in various ways (including into 3d if you have some red-blue 3d glasses!)

It should make things a bit faster, and a bit easier to collaborate with people using other languages.

I love exploratory - it's an a really interesting place between GUI and code autocomplete on steroids,