7 ms·

OOP has been a critical part of real-life R for a long time, especially in complex implementations of classes of kernels, algorithms, and so on with S4, and mor

OOP has been a critical part of real-life R for a long time, especially in complex implementations of classes of kernels, algorithms, and so on with S4, and more general-purpose with R6. Without these frameworks it would be difficult to implement them. Personally I find it more expressive for general-purpose computation than Python. The "fs" library is much better at working with files and paths than Python "os" and the multiple other modules that can be needed to work with with typical filesystem operations -/ especially if you are working with more than one file at a time. I would even say that each of the R object systems is more expressive and more flexible than the Python one. I suspect lazy evaluation is a part of this.

fire_lake 2y ago
I too much prefer R to Python (it’s far more expressive, for one) however it’s clear now that Python has “won” in this space and R is a tough sell to a wider team.
- bachmeier 2y ago
  > it’s clear now that Python has “won” in this space and R is a tough sell to a wider team R has always been a language for academics, and it continues to be popular in that domain, with no compelling reason to switch. It has seen usage in the private sector, but that has never been the driving force behind R's development or ecosystem, and I doubt it ever will be. For academics, even if a particular function is only available for Python, it's easy enough to call it from R and do everything else in R.
- orhmeh09 2y ago
  Oh, I agree on that, and I know that most of the time I'll be asked why something isn't in Python so I mainly reserve it for when I am sure nobody will ask "why R?" :-) There is a benefit nowadays that I can rely on Python>=3.6 to be available by default anywhere I am deploying whereas R has to be installed in some way, so like Bash it's part of a toolbox I can rely on being available with at least a constrained set of features.
- rossdavidh 2y ago
  My experience is that you can "sell" R when the statistical or modelling technique is not (or not well) implemented in python. Which still includes a lot of potentially useful statistical techniques! R should/could lean into being the tool that python programmers reach for when they need something a little less mainstream, if they made it easier for non-R programmers to do so.
agumonkey 2y ago
> I suspect lazy evaluation is a part of this. I had no idea R was lazy. Makes me wanna learn it now.
- civilized 2y ago
  R is not lazy. It has non-standard evaluation mechanisms (formulas, promises, quosures...) that enable to you to write domain-specific languages that "do what the user meant". If your code (or the code of the libraries you're using) doesn't use any non-standard evaluation tools, evaluation will be eager and work like any other ALGOL language. It is possible to make some objects behave in a lazy way, but this is also true of many other languages.
  - orhmeh09 2y ago
    Thank you for the correction. Is it possible to use NSE in say Python or JavaScript?
    - CornCobs 2y ago
      Yes, though the languages do not support it explicitly you can simulate lazy evaluation by wrapping all your arguments in closures. This way they won't be evaluated until called within the function body.
      - agumonkey 2y ago
        Sidenote, the evaluation model of python can be surprising. List comprehension will create implicit function scopes that can trip you up.
  - aquasync 2y ago
    R's evaluation of arguments is lazy, so while not at the level of Haskell it feels like a lazy language to me. Try eg: f = function(x) { print('hello'); x } f(print('world')) X is not evaluated in f until referenced. Indeed if you remove x from f, world is not printed.
  - 2y ago
mr_toad 2y ago
Maybe too expressive and too flexible? Different R programs can have wildly different dialects, making it difficult for two R programmers to even understand each other. I’ve seen comics depicting the learning curve for R as having local minima beyond which there are further peaks and troughs of knowledge. A beginner might learn enough to get by, but find the code of someone on the other side of one of those peaks to be a foreign language. Having your coders not understand each other is problematic in a production environment.
- orhmeh09 2y ago
  This is fair. For what it's worth, Python is tending toward this and I think is introducing newer syntax at a faster rate with things such as structural pattern matching and typing, which I have had difficulty explaining to people who don't keep up with each new release.
  - stevenae 2y ago
    Switching from R to Python, this resonates. I write base (non-tidy) R, and it's definitely another language from tidy. That said, having written a fair amount of base Python, jumping into torch/tensor flow feels like an even further separation than base R/tidy.
int_19h 2y ago
In modern idiomatic Python, you should really be using `pathlib` and `io`, not `os`.
- orhmeh09 2y ago
  Yeah, you're absolutely right. The `os` methods are closest to the base R file operations and those in `pathlib` are closest to `fs` (which is a third-party library for R that requires installation).
barfbagginus 2y ago
Pathlib gives a decent oop interface to most file operations. The pathlib docs has a handy Rosetta Stone table for replacing `os` and `shutil` invocations which is very handy. It could still be better, and sadly being in the stdlib means it probably won't be improved. For example, we still need shutil.rmtree to recursively nuke a directory. The pathlib way of doing it is laborious and error prone: https://stackoverflow.com/questions/13118029/deleting-folders-in-python-recursively/49782093#49782093 https://stackoverflow.com/questions/13118029/deleting-folder...
- orhmeh09 2y ago
  Pathlib is a great addition and it's nice that it's in the standard library. I like fsspec also, which has some functionality that overlaps with Python's existing libraries but makes it a little cleaner IMO.

fire_lake 2y ago

I too much prefer R to Python (it’s far more expressive, for one) however it’s clear now that Python has “won” in this space and R is a tough sell to a wider team.

bachmeier 2y ago
> it’s clear now that Python has “won” in this space and R is a tough sell to a wider team R has always been a language for academics, and it continues to be popular in that domain, with no compelling reason to switch. It has seen usage in the private sector, but that has never been the driving force behind R's development or ecosystem, and I doubt it ever will be. For academics, even if a particular function is only available for Python, it's easy enough to call it from R and do everything else in R.
orhmeh09 2y ago
Oh, I agree on that, and I know that most of the time I'll be asked why something isn't in Python so I mainly reserve it for when I am sure nobody will ask "why R?" :-) There is a benefit nowadays that I can rely on Python>=3.6 to be available by default anywhere I am deploying whereas R has to be installed in some way, so like Bash it's part of a toolbox I can rely on being available with at least a constrained set of features.
rossdavidh 2y ago
My experience is that you can "sell" R when the statistical or modelling technique is not (or not well) implemented in python. Which still includes a lot of potentially useful statistical techniques! R should/could lean into being the tool that python programmers reach for when they need something a little less mainstream, if they made it easier for non-R programmers to do so.

agumonkey 2y ago

> I suspect lazy evaluation is a part of this. I had no idea R was lazy. Makes me wanna learn it now.

civilized 2y ago
R is not lazy. It has non-standard evaluation mechanisms (formulas, promises, quosures...) that enable to you to write domain-specific languages that "do what the user meant". If your code (or the code of the libraries you're using) doesn't use any non-standard evaluation tools, evaluation will be eager and work like any other ALGOL language. It is possible to make some objects behave in a lazy way, but this is also true of many other languages.
- orhmeh09 2y ago
  Thank you for the correction. Is it possible to use NSE in say Python or JavaScript?
  - CornCobs 2y ago
    Yes, though the languages do not support it explicitly you can simulate lazy evaluation by wrapping all your arguments in closures. This way they won't be evaluated until called within the function body.
    - agumonkey 2y ago
      Sidenote, the evaluation model of python can be surprising. List comprehension will create implicit function scopes that can trip you up.
- aquasync 2y ago
  R's evaluation of arguments is lazy, so while not at the level of Haskell it feels like a lazy language to me. Try eg: f = function(x) { print('hello'); x } f(print('world')) X is not evaluated in f until referenced. Indeed if you remove x from f, world is not printed.
- 2y ago

mr_toad 2y ago

Maybe too expressive and too flexible? Different R programs can have wildly different dialects, making it difficult for two R programmers to even understand each other. I’ve seen comics depicting the learning curve for R as having local minima beyond which there are further peaks and troughs of knowledge. A beginner might learn enough to get by, but find the code of someone on the other side of one of those peaks to be a foreign language. Having your coders not understand each other is problematic in a production environment.

orhmeh09 2y ago
This is fair. For what it's worth, Python is tending toward this and I think is introducing newer syntax at a faster rate with things such as structural pattern matching and typing, which I have had difficulty explaining to people who don't keep up with each new release.
- stevenae 2y ago
  Switching from R to Python, this resonates. I write base (non-tidy) R, and it's definitely another language from tidy. That said, having written a fair amount of base Python, jumping into torch/tensor flow feels like an even further separation than base R/tidy.

int_19h 2y ago

In modern idiomatic Python, you should really be using `pathlib` and `io`, not `os`.

orhmeh09 2y ago
Yeah, you're absolutely right. The `os` methods are closest to the base R file operations and those in `pathlib` are closest to `fs` (which is a third-party library for R that requires installation).

barfbagginus 2y ago

Pathlib gives a decent oop interface to most file operations. The pathlib docs has a handy Rosetta Stone table for replacing `os` and `shutil` invocations which is very handy. It could still be better, and sadly being in the stdlib means it probably won't be improved. For example, we still need shutil.rmtree to recursively nuke a directory. The pathlib way of doing it is laborious and error prone: https://stackoverflow.com/questions/13118029/deleting-folders-in-python-recursively/49782093#49782093 https://stackoverflow.com/questions/13118029/deleting-folder...

orhmeh09 2y ago
Pathlib is a great addition and it's nice that it's in the standard library. I like fsspec also, which has some functionality that overlaps with Python's existing libraries but makes it a little cleaner IMO.