Live data from Hacker News

R adds native pipe and lambda syntax

developer.r-project.org

101–110 of 150 posts

Re: R adds native pipe and lambda syntax

#101

Earlier quoted context omitted.

R’s data.table package is faster at these things out of the box than any single instance of a database server I’ve encountered. This is frustrating because I’m trying to explain some systemic issues we suffer by not using a relational database, but it’s really hard to make my case when data.table is one install.packages away and a version upgrade from Postgres 9 to something a little faster is gatekept by bureaucracy…

You need a columnar database for good performance. Try DuckDB to ease them into it, it's a columnar SQLite.

Thanks, I’m checking it out, it seems pretty interesting to keep an eye on. Lots of properties that would be useful in our shared computing environment like not requiring root or Docker.

Re: R adds native pipe and lambda syntax

#102
post #98
post #96

Earlier quoted context omitted.

As someone who is now bouncing back & forth between Python and R on a weekly basis, I've been surprised (after making fun of R sometimes) how much I miss the piping when I leave R for Python. Pandas seems so inflexible by comparison, so nitpicky for little gain. I've been surprised again and again how much dplyr supports near-effortless fluency and productivity. Never really thought I'd be writing that in a public fo…

I'm not an R user, but you should try Julia for data analysis. It seems as flexibility (maybe more) than R, while also having blazing performance. I do like Pandas concept of row indices, which I know Julia (and I believe, R) lack.

Tbh R's performance is only an issue when you deal with really big datasets. Most of the time R does just fine, and has a lot more libraries that Julia can ever hope to have.

Re: R adds native pipe and lambda syntax

#103
post #81
post #77

Earlier quoted context omitted.

The anonymous function change is probably a (small) mistake. function(x) {x + 1} is already logically equivalent to and from some perspectives an arguable syntax improvement on \(x) x + 1 Giving everyone two ways of doing one thing just means the tutorials will be fragmented and beginners even more confused. Tierney mentioned that tidyverse found function(x) too verbose and uses fomula syntax. Given how tidyverse oft…

Having the option of writing \(x) x+1 instead of function(x) x+1 not only saves a few keystrokes. It will also produce shorter, and clearer, lines of code. What I don’t understand is the reference to “formula syntax”. What is the issue and how does the new syntax solve it?

Function syntax is this stuff [0, 1]. Tidyverse uses it to accomplish some non-model stuff. The one that leaps to my mind is faceting [2]. I'd expect that sort of thing to be handled by macros.

And all the rest of the comment I wouldn't have typed except I'm already replying, since I know this is one of those two-types-of-people-who-don't-change-opinions situations. But...

> not only saves a few keystrokes.

R is secretly a lisp. People can define whatever they want to be whatever they want. Pipes were already implemented in a library (try doing that in Python). Make your own library or bind \ to a keyboard macro or something if your fingers are on the point of crumbling under the stress of those 7 keystrokes.

Defaults using real words to describe things is good. The function to create a function being function() is eminently reasonable. \() is meaningless and about as useful as a one-word variable

> It will also produce shorter, and clearer, lines of code.

Opinons very much divide. Code length is only a proxy for load on a reader's short term memory which is what matters. \ is going to put more burden on someone if they aren't very familiar with R. Most R coders are not full time programmers and not very good at R.

[0] https://www.rdocumentation.org/packages/base/versions/3.6.2/... [1] https://www.rdocumentation.org/packages/stats/versions/3.6.2... [2] http://www.cookbook-r.com/Graphs/Facets_(ggplot2)/

Re: R adds native pipe and lambda syntax

#104
post #56

Earlier quoted context omitted.

I know R because that's what we used at my first company. I would love to switch to Python/Pandas but I'm comfortable with R and it does everything I need it to with one exception over ten years of heavy use. Python is wonderful but the cognitive load for switching in industry and academia without a clear cost benefit isn't worth it to most people I know in my shoes. I encourage new coders to learn Python but discoun…

I made the switch years ago and there is lots that python does better. I really, really wish for a perfect port of dplyr and ggplot2. Those are what I truly miss, everything else I'm pretty happy with.

It will never happen. Python doesn't trust programmers with the power to make packages like dplyr and ggplot

Re: R adds native pipe and lambda syntax

#105
post #103
post #81

Earlier quoted context omitted.

Having the option of writing \(x) x+1 instead of function(x) x+1 not only saves a few keystrokes. It will also produce shorter, and clearer, lines of code. What I don’t understand is the reference to “formula syntax”. What is the issue and how does the new syntax solve it?

Function syntax is this stuff [0, 1]. Tidyverse uses it to accomplish some non-model stuff. The one that leaps to my mind is faceting [2]. I'd expect that sort of thing to be handled by macros. And all the rest of the comment I wouldn't have typed except I'm already replying, since I know this is one of those two-types-of-people-who-don't-change-opinions situations. But... > not only saves a few keystrokes. R is secr…

I know what formulas are, I just don’t see what’s the connection with the proposed change:

     ‘\(x) x + 1’ is parsed as ‘function(x) x + 1’
I also know that R has some vestigial scheme under the hood, but the syntax is not lisp (it was taken from S). In common lisp one could easily use a macro or reader macro but in R a change in the parser is needed so “\” can be used instead of “function”.

Note that the existing “f

    state.range 
and it will be an improvement to be able to condense it a bit to

    state.range 

Re: R adds native pipe and lambda syntax

#107
post #6

I'm sure some of us who are out of the loop might be wondering: what about the magrittr pipe operator (%>%) that we all know and love? Luke Tierney explains the move from %>% to a native pipe |> here [1]. The native pipe aims to be more efficient as well as addresses issues with the magrittr pipe like complex stack traces. Turns out the |> syntax is also used in Julia, Javascript and F#. The lambda syntax (\(x) -> x…

Its only a proposal in JS. For long function chains i like to use intermediate variables as they make the code easier to understand.

Re: R adds native pipe and lambda syntax

#108
post #89

Question by someone who is ignorant but interested in functional programming: what is the closest equivalent to these functions in Python? (Or correct me if I'm asking the wrong question). I used to love using lambdas in Python, along with map/reduce/filter but for whatever reason the Python community has turned against it. Map and filter can now be nicely done with list comprehensions, although I still haven't found…

I'm not sure what specific "functions" you're talking about, but Python generally encourages a procedural style of programming as opposed to functional. The rationale is that functional code can be really difficult to read if you aren't already familiar with the idioms and terminology, whereas it's pretty easy to mentally parse and understand a `for` loop. So in that sense, list comprehensions are about as far as Pyt…

Having read plenty of python numerical code, I'm not sure "easy to parse and understand" is what exactly comes to mind.

Re: R adds native pipe and lambda syntax

#109
post #89

Question by someone who is ignorant but interested in functional programming: what is the closest equivalent to these functions in Python? (Or correct me if I'm asking the wrong question). I used to love using lambdas in Python, along with map/reduce/filter but for whatever reason the Python community has turned against it. Map and filter can now be nicely done with list comprehensions, although I still haven't found…

There is none and after having used Elixir for a year going back to Python for anything non-trivial input/output parsing feels really cumbersome now.

Other comments have mentioned that functional idioms make code harder to read for devs unfamiliar with the concepts but the pipe operator IMHO has no downsides (I am not even sure what it really has to do with funcational programming, other than that it happens to be used in more functional languages).

Re: R adds native pipe and lambda syntax

#110
post #96

Earlier quoted context omitted.

This, along with inferior metaprogramming affordances, is the biggest reason pandas will never be as productive an analyst tool as R's dplyr. In R you can pipe anything into anything. In pandas you're stuck with the methods pandas gives you. This is also why pandas API is so bloated. A lot of pandas special-case functionality, like dropping duplicate rows, can be replicated in R by chaining together more flexible and…

As someone who is now bouncing back & forth between Python and R on a weekly basis, I've been surprised (after making fun of R sometimes) how much I miss the piping when I leave R for Python. Pandas seems so inflexible by comparison, so nitpicky for little gain. I've been surprised again and again how much dplyr supports near-effortless fluency and productivity. Never really thought I'd be writing that in a public fo…

Personally, I think R as a language is absolutely beautiful. The libraries have tons of warts, and many different styles. And there are perhaps too many object orientation systems built on it. But that you could even build multiple object oriented systems points to how powerful the language is.

I think it's functional orientation and the way that for loops are neglected make it seem completely insane to many people. But this is a far smaller fraction of people today than it was in 2000. back then, Java and C++ didn't even have lambdas. Since then, procedural languages have gained a lot the "mind-breaking" functional features of Lisp-derived languages. Python and JavaScript have become far more common. All the things that made the language of R "weird" and unusable to the Java/C++ crowd have been adopted elsewhere.

Post reply on HN