I first ran into this package more than 5 years ago, and tried it for a bit. Unfortunately, I think, it's a bit too intrusive and makes your code so much harder to read for people who are not familiar with the package.
The author is an interesting guy. He has lots of ideas about R, but seems to have spread himself a bit too thin and so he doesn't really finish them. This package is one example, but he also was in the middle of writing two nice books about R [1] [2], and they are still in limbo.
I agree with it being a bit intrusive. I certainly wouldn't write a package in lambda.r or use it in code that I share with coworkers. I think the target audience are people familiar with R who want to explore and play with pure FP concepts, without leaving their comfort zone.
My first thought was "I hope I never encounter code that uses this." It's interesting as a proof of concept, but it makes your R code difficult to understand to 99.9% of R programmers. In my opinion, that is a pretty high cost for what I would consider mostly syntactic sugar.
That said, a lot of the use-case of R is one-off scripts, run locally on a machine by an analyst, as part of preparing a written report for non-technical stakeholders. So the code readability isn't as important.
This is both a strength and weakness of R in general. The R community has many different ways to accomplish the same goals. Production systems decline to use R in large part because of the code maintenance burden across a team, versus Python's "one right way" approach.
I found that the "one right way" python's mantra fall apart when it comes to pandas and numpy. Those libraries must be seen as DSL on top of the language IMHO.
Every time I think code readability isn't important, I am inevitably proven wrong. Either I need to go back months later and need to figure out what I did, or I end up sharing with others. Even those one-off, "never going to touch this again" scripts.
This happens sometimes. 2 reasons I know of: If the powers that be think you’re submission is good they show it again and it can gather upvotes. Or others post it after independent discovery. This counts as an upvote and might update the submission time.
For a more conservative FP-inspired R library there's `lenses` (disclaimer: I am a coauthor), which is available on CRAN, accessible to users familiar with R indexing syntax, tidyverse-compatible, and has gentle introductory documentation: https://github.com/cfhammill/lenses
12 comments
[ 143 ms ] story [ 648 ms ] threadThe author is an interesting guy. He has lots of ideas about R, but seems to have spread himself a bit too thin and so he doesn't really finish them. This package is one example, but he also was in the middle of writing two nice books about R [1] [2], and they are still in limbo.
[1]: https://cartesianfaith.com/2017/04/14/modeling-data-with-fun...
[2]: https://cartesianfaith.com/2018/11/12/preview-my-new-book-in...
My first thought was "I hope I never encounter code that uses this." It's interesting as a proof of concept, but it makes your R code difficult to understand to 99.9% of R programmers. In my opinion, that is a pretty high cost for what I would consider mostly syntactic sugar.
That said, a lot of the use-case of R is one-off scripts, run locally on a machine by an analyst, as part of preparing a written report for non-technical stakeholders. So the code readability isn't as important.
This is both a strength and weakness of R in general. The R community has many different ways to accomplish the same goals. Production systems decline to use R in large part because of the code maintenance burden across a team, versus Python's "one right way" approach.
Does it come down more to an agreement among the team about how code should be written?
https://news.ycombinator.com/item?id=25316608