Closed mlane3 closed 2 years ago
mlane3
commented
2 years ago I am sorry maybe its an issue in the messaging but I truly feel that some of these changes are out of touch with how people like myself and other use R. I know you probably didn't intend for it to be read that way, but at least from how it is initially presented... this is how it feels.
hadley
commented
2 years ago I can tell from your message that you feel very strongly about this, but it would be more helpful if you could provide specific technical concerns. A few things that I found confusing:
when() and gsub()map_chr(1:5, \(x) x / 2) is rather dangerous.map2(1, 1:10, `+`) still works. But map(1:2, 1:10, `+`) and map2(1:3, 1:10, `+`) will not.hadley
commented
2 years ago happy to discuss this further, but I'm closing the issue for now since it's not actionable for me.
After reading news in #999 and the reactions on the twitter post, I do not feel that the changes to core purpose of purrr aligns with how the packages is used by everyday non-developers. These are the following reasons why.....
Major Concerns:
"prepend(), rdunif(), rbernoulli(), when(), and list_along() have all been deprecated (#925). It's now clear that they don't align with the core purpose of purrr."
Why are rbernoulii and when being depreciated and not moved to separate package? In particular "when()" does not have a replacement prior to 4.2.2 because there are bugs in gsub that were only recently patched in the last few months. Why don't simple make a wrapper to the proper function until the next major release of base R? We have strong concerns about the development of R packages and whether users have a voice or if everything has become developer focused. It does not feel like the depreciation is gradual at all. When myself and my teammates read the new changes, we truly felt that the developer of the packages either doesn't understand or they simple don't care how non-developers use there open source package.
"_dfc() and _dfr() have been superseded in favor of using the appropriate map function along with list_rbind() or list_cbind() (#912)."
When I read this news I truly feel the developer of the packages don't understand how non-developers use there open source package. We have strong objections to this change and concern when combined with other changes it only allow users to purr over a limited number of R data frame types, classes, and most importantly environments.
"lgl(), _int(), _int(), and _dbl() now use the same (strict) coercion methods as vctrs (#904). This means that..."
So you are going to take vctrs, something that is arguably the worst implemented change in all of tidy verse history. And now apply it to all of purr? Your taking something that broke so much code and tutorials 3.6 and 4.0 that your now applying it to purr? When I read this news I truely feel the developer of the packages don't understand how non-developers use there open source package. How is this a gradual depreciation? We have strong objections to this change and concern when combined with other changes it only allow users to purr over a limited number of R data frame types, classes, and most importantly environments.
"map2(), modify2(), and pmap() now use tidyverse recycling rules where vectors of length 1 are recycled to any size but all others must have the same length (#878)."
Is very confusing because it implies that first index, second index are the same length. Why would use use map2 at all then? Why have a second index or second anything if your first is the same? How would anyone know how to use the package? These index changes are an example of why the vctrs and dplyr principles don't make sense. It would make more sense to add a function to make recycling rules explicit. It would make even more sense not to touch the length of indexes at all.