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

Jens Oehlschlägel Jens.Oehlschlaegel at truecluster.com
Tue Sep 26 22:52:17 CEST 2017

On 26.09.2017 15:37, Hadley Wickham wrote:
> I decided to make [.tibble type-stable (i.e. always return a data
> frame) because this behaviour causes substantial problems in real data
> analysis code. I did it understanding that it would cause some package
> developers frustration, but I think it's better for a handful of
> package maintainers to be frustrated than hundreds of users creating
> dangerous code.g
> Hadley

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 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. 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?

Kind regards

Jens Oehlschlägel

More information about the R-package-devel mailing list