Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

R adds native pipe and lambda syntax

developer.r-project.org

Post reply on HN
Print view View original

41–50 of 150 posts

Re: R adds native pipe and lambda syntax

#41

Post by civilized »

hated wrote: post #32
civilized wrote: post #26

Earlier quoted context omitted.

Nah, it's not nicer. dplyr is way better than pandas. But there is no end to the supply of Python fanbois who only know Python and assume that whatever's in Python just has to be better

Pandas is used in some top 10 banks for analytics. Its performance is abysmal at the scale used there. Nobody wants to invest resources in training analysts to write high performance code so here we are. I have never viewed SQL more highly after seeing the mess that analysts make when writing imperative code.

No surprise there - pandas encourages ugly, inefficient code with its bloated, unintuitive API.

Once I was a lead on a new project and asked the intern to write some basic ETL code for data in some spreadsheets. I said she could write it in Python if she wanted, because "Python is good for ETL", right?

This intern was not dumb by any means, but she wrote code that took 5 minutes to do something that can be done in Also, if your bank analysts pick up dplyr, they can use dbplyr to write SQL for them :)

Re: R adds native pipe and lambda syntax

#42

Post by _2d30 »

stewbrew wrote: post #36

Well, afaik it isn't really a pipe but syntactic sugar. A pipe streams data from one output stream to an input stream. This rewrites the code as if the input were passed as an argument.

That's exactly right. This is useful in the context of a large portion of R's most popular data wrangling packages known as the "Tidyverse". These packages used an equivalent pipe function that was non-native and had some perf and understandability issues.

Re: R adds native pipe and lambda syntax

#43

Post by peatmoss »

Huntsecker wrote: post #24

personally Im surprised R is still in active development when the main use case for people to use R (at least when I was using it) was for statistical analysis. Python with its libraries (a lot I believe ported from R) just does is nicer, and faster.

R vs. Python flamewars always strike me as a Budweiser vs. Miller kind of argument. Neither is really a “craft beer” of programming languages. Neither are super remarkable as programming languages. Both made a bunch pragmatic tradeoffs to appeal to large audiences that share similar values—both are “average joe” beers.

Python has comparative advantages over R in production roles. R has comparative advantage in statistical libraries, visualization, and meta programming. Neither are exemplars for production deployment or meta programming (R is an exemplar for stats libraries however).

Re: R adds native pipe and lambda syntax

#44

Post by _2d30 »

wodenokoto wrote: post #14

Kind of odd they didn't decide to go with the magrittr syntax, which is in common use and heavily promoted in dplyr / tidyverse. I wonder if RStudio will change its `ctrl` + `shift` + m shortcut from the magrittr ( %>% ) style pipes to these new pipes ( |> )

You can't do that if you wanted it to be a symbol of its own. The use of wrapping "%" is native functionality so making `%>%` into a symbol would break the consistency of that.

Re: R adds native pipe and lambda syntax

#45

Post by dm319 »

CameronNemo wrote: post #30
civilized wrote: post #26

Earlier quoted context omitted.

Nah, it's not nicer. dplyr is way better than pandas. But there is no end to the supply of Python fanbois who only know Python and assume that whatever's in Python just has to be better

I don't mind pandas so much, although dplyr is quite nice IMO (feels like natural language and declarative/SQL like, whereas pandas ends up with lots of procedural idioms). ggplot is something that I don't think matplotlib is comparable to at all, though. I am so much faster at iterating on a visualization with R/ggplot than Python/matplotlib. Maybe it is my tooling, though. How about others who have used both? What…

No, same here. I tried to recreate some covid rate graphs in python. The ggplot code did facetting and fitted a LOESS to the data. Nothing ground breaking, but it really hit the limits of what seaborn was able to do, and I wasn't able to tinker with it much further. It got to the point where to make it look good I needed to calculate all the curves manually.

Re: R adds native pipe and lambda syntax

#46

Post by peatmoss »

civilized wrote: post #41
hated wrote: post #32

Earlier quoted context omitted.

Pandas is used in some top 10 banks for analytics. Its performance is abysmal at the scale used there. Nobody wants to invest resources in training analysts to write high performance code so here we are. I have never viewed SQL more highly after seeing the mess that analysts make when writing imperative code.

No surprise there - pandas encourages ugly, inefficient code with its bloated, unintuitive API. Once I was a lead on a new project and asked the intern to write some basic ETL code for data in some spreadsheets. I said she could write it in Python if she wanted, because "Python is good for ETL", right? This intern was not dumb by any means, but she wrote code that took 5 minutes to do something that can be done in Al…

R’s meta programming facilities are head and shoulders above Python’s, which I think explains the brilliance of dplyr and dbplyr. But I feel like with R you have to scrape back a bunch of layers to get to the Schemey parts. I’ve always wondered what Hadley and Co would have done with dplyr and dbplyr had they had something like Racket at their disposal.

Re: R adds native pipe and lambda syntax

#47

Post by vharuck »

wodenokoto wrote: post #14

Kind of odd they didn't decide to go with the magrittr syntax, which is in common use and heavily promoted in dplyr / tidyverse. I wonder if RStudio will change its `ctrl` + `shift` + m shortcut from the magrittr ( %>% ) style pipes to these new pipes ( |> )

I'm sure they wanted to not replace magrittr pipes. R is introspective, and some reckless people (like myself) will mess with functions' guts in a few scripts. Replacing the `%>%` function with a syntax symbol will break those scripts. Even with scripts that don't metaphorically shove their hands down the garbage disposal, programmers might've relied on certain behaviors of the magrittr pipe.

The R Core team is very cautious about breaking anything, including universally acknowledged terrible defaults (I never thought `stringsAsFactors = TRUE` would ever go away). They know the majority of R programmers are not experts in programming. These users just want to write a script, debug it, and then use it for years with complete trust in the results.

Re: R adds native pipe and lambda syntax

#48

Post by canjobear »

Huntsecker wrote: post #24

personally Im surprised R is still in active development when the main use case for people to use R (at least when I was using it) was for statistical analysis. Python with its libraries (a lot I believe ported from R) just does is nicer, and faster.

About 8 years ago I agreed with this point, but with the development of tidyverse, R has become far superior to Python for anything involving dataframes.

I teach classes involving data analysis, some in Python and some in R (different topics). The amount of time the Python students spend fighting pandas---looking up errors, trying to parse the docs, trying out new arcane indexing strategies---is obscene. On the other hand, the R students progress rapidly. I'd move everything to R if I could, but Python is still better for NLP pipelines.

Re: R adds native pipe and lambda syntax

#50

Post by em500 »

civilized wrote: post #41
hated wrote: post #32

Earlier quoted context omitted.

Pandas is used in some top 10 banks for analytics. Its performance is abysmal at the scale used there. Nobody wants to invest resources in training analysts to write high performance code so here we are. I have never viewed SQL more highly after seeing the mess that analysts make when writing imperative code.

No surprise there - pandas encourages ugly, inefficient code with its bloated, unintuitive API. Once I was a lead on a new project and asked the intern to write some basic ETL code for data in some spreadsheets. I said she could write it in Python if she wanted, because "Python is good for ETL", right? This intern was not dumb by any means, but she wrote code that took 5 minutes to do something that can be done in Al…

IMO they should just bite the bullet and learn proper SQL. I say this as a data scientist who learned SQL later than C, Matlab, R, Python/Pandas (though earlier than PySpark).
Post reply on HN