[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