Julia crew, where you at?
R adds native pipe and lambda syntax
111–120 of 150 posts
Re: R adds native pipe and lambda syntax
#112Julia crew, where you at?
:wave:
But I’m also part of the R crew so :shrug:
Re: R adds native pipe and lambda syntax
#113Question 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…
> Question by someone who is ignorant but interested in functional programming: what is the closest equivalent to these functions in Python?
The equivalent to the function of the first is python’s lambda syntax, there's no simple syntax providing the same function as the pipe.
Re: R adds native pipe and lambda syntax
#114Question 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 us…
> 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).
What it has to do with functional programming is, first, that it's right side operand is a function, and, second, that it's a technique for unrolling the deeply nested function calls common in expression-oriented functional programming without resorting intermediate assignments which are natural in statement-oriented imperative programming but less so for single-user and not independently semantically important values in expression-oriented functional programming.
Re: R adds native pipe and lambda syntax
#115personally 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.
I use Python whenever I can, but R has loads and loads of statistical libraries that Pyrhon doesn’t. It is not even close.
Yeah, basically this. I assume HN has a higher number of people who work in ML jobs in fields like finance etc. If you're working in any sort of social/public health research, then most new methods seem to be implemented as R packages. I'm thinking of things like new methods for propensity score, sequential trial designs etc. Also seems to be the preferred language on the Stats Stack Exchange posts.
Re: R adds native pipe and lambda syntax
#116Earlier 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.
Pandas/python is amazingly prevalent at trading firms. And everyday, we bitch about the performance, we bitch about the stupid API, we bitch about the GIL, the lack of expressiveness. The list goes on and on. But for some braindead reason, we never switch to Julia. It's masochistic.
I do think Julia is a far better language for numerics than python, but compared to DataFrames.jl, pandas can be quite fast. I know, "but it's easier to make it faster in Julia". Last I checked `sort(df, :col)` was significantly slower than `df[sortperm(df[:col])]`. Someone actually has to go through and make these libraries fast.
Second issue, in my field (bioinformatics) the script is still a pretty common unit of code. Without cached compilation being a simple flag, Julia often is slower.
Re: R adds native pipe and lambda syntax
#117Earlier quoted context omitted.
Pandas/python is amazingly prevalent at trading firms. And everyday, we bitch about the performance, we bitch about the stupid API, we bitch about the GIL, the lack of expressiveness. The list goes on and on. But for some braindead reason, we never switch to Julia. It's masochistic.
I do think Julia is a far better language for numerics than python, but compared to DataFrames.jl, pandas can be quite fast. I know, "but it's easier to make it faster in Julia". Last I checked `sort(df, :col)` was significantly slower than `df[sortperm(df[:col])]`. Someone actually has to go through and make these libraries fast. Second issue, in my field (bioinformatics) the script is still a pretty common unit of…
Yeah, that's a good point. DataFrames.jl starts to really shine what the cookie cutter pandas functions arent adequate for what you need to do. DataFrames.jl can certainly be slower in some cases, but you should expect a consistent level of performance no matter what you do. This is a farcry from Pandas, which tanks by large factors when you start calling Python code vs C code.
In regards to Julia's compilation problem, you can use https://github.com/JuliaLang/PackageCompiler.jl to precompile an image, allowing you to avoid paying the JIT performance penalty over and over again.
Re: R adds native pipe and lambda syntax
#118Earlier quoted context omitted.
It is, and it's not the first language to use it as such. But for many programmers it always triggers the 'escape' alarm in the mind, and it will always cause slight discomfort seeing it used in the raw.
IMO it should be like Fennel and just support `lambda` and `λ`. The latter is not even that hard to type, in virtually any free (libre) OS you can just $ echo ' : "Λ" # GREEK CAPITAL LETTER LAMDA : "λ" # GREEK CAPITAL LETTER LAMDA ' >> ~/.XCompose If you’re limited by a nonfree OS you should be able to patch the problem with free duct tape like Karabiner or AutoHotKey. And in vim you can just *l in insert mode (which…
Now imagine doing that same thing for every system you're programming on. And then imagine having to do it for a million different symbols. I'm sure as hell glad you're not in charge of any of this.
Re: R adds native pipe and lambda syntax
#119I wish more languages gave us a "|>" operator. Too many languages settle with dot notation, which confuses encapsulation/method calling with syntactical convenience.
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…
Pandas does have the .pipe() method [0], which allows you to put an arbitrary callable in a method chain, but it is a bit more cumbersome than in R.
[0] https://pandas.pydata.org/pandas-docs/stable/reference/api/p...
Re: R adds native pipe and lambda syntax
#120I think I'm going to appreciate the native pipes, it will likely improve the readability of my data.table chains.
Do you use the Magrittr pipes? Works well with data.table for me.
I've seen them used with data.table, but I don't use them myself. Reason being that I don't want to load a lib just to make my chains look a bit better. I usually have chains short enough that it's okay doing
DT[..][..][..]