[R-pkg-devel] tibbles are not data frames

Hadley Wickham h.wickham at gmail.com
Tue Sep 26 23:08:49 CEST 2017


> If that is right -- and I tend to believe it is right -- this change had
> better been done in R core and not on package level. I think the root of
> this evil is design inconsistencies of the language together with the lack
> of removing these inconsistencies. The longer we hesitated, the more
> packages such a change could break. The lack of addressing issues in R core
> drives people to try to solve issues on package level. But now we have two
> conflicting standards, i.e. a fork-within-the-language: Am I a member of the
> tidyverse or not? Am I writing a package for the tidyverse or for standard-R
> or for both. With a fork-of-the-language we would at least have a majority
> vote for one of the two and only the fitter would survive. But with a
> fork-within-the-language 'R' gets more and more complex, and working with it
> more and more difficult. There is not only the tidyverse, also the Rcppverse
> and I don't know how many other verses. If there is no extinction of
> inconsistencies in R, not sufficient evolution in R, but lots of evolution
> in Julia, evolution will extinct R together with all its foobarverses in
> favor of Julia (or Python). May be that's a good thing.

I think you are making a slippery slope argument, and I'm not sure I
buy it. I am quite aware of the danger of introducing additional
inconsistencies, and do it very selectively, only when I'm convinced
that the pain is worth it.

> I think tibble should respect drop=TRUE and respect the work of all package
> authors who wrote defensive code and explicitly passed drop= instead of
> relying on the (wrong) default

We'll consider for the next major release:
https://github.com/tidyverse/tibble/issues/311

> . Again: better would be a long-term clean-up
> roadmap of R itself and one simple standard called 'data.frame'. Instead of
> forking or betting on any particular foobarverse: why not have direct
> democratic votes about certain critical features of such a long-term roadmap
> in such a big community?

I'm not sure that democracy works for programming language design.

Hadley

-- 
http://hadley.nz



More information about the R-package-devel mailing list