Live data from Hacker News

Generalizing Support for Functional OOP in R

blog.r-project.org

11–20 of 53 posts

Re: Generalizing Support for Functional OOP in R

#11
post #4

Earlier quoted context omitted.

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…

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.

> 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.

Re: Generalizing Support for Functional OOP in R

#12

To be honest, OOP never really seemed like a good fit for R. Functional programming is a much more natural fit, given that both it and R come from a mathematical point of view. R is a great language for the mathematical/statistical stuff it was invented to do, but I don't think it will ever be a general-purpose language, and it probably would become worse at its core purpose if it tried to. More work on being easily…

Yet you’re using OOP every time you call plot, predict, summary and so on: possibly without realising.

Re: Generalizing Support for Functional OOP in R

#13
post #9

I trust the authors immensely but i don't see what yet another class system in R solves. That's on me, but I'd like to understand more of what motivates this effort.

From the article: “S7 is a new OOP system being developed as a collaboration between representatives from R-Core, Bioconductor, tidyverse/Posit, ROpenSci, and the wider R community, with the goal of unifying S3 and S4 and promoting interoperability.”

It then goes on to describe what that means in depth.

Re: Generalizing Support for Functional OOP in R

#14

To be honest, OOP never really seemed like a good fit for R. Functional programming is a much more natural fit, given that both it and R come from a mathematical point of view. R is a great language for the mathematical/statistical stuff it was invented to do, but I don't think it will ever be a general-purpose language, and it probably would become worse at its core purpose if it tried to. More work on being easily…

Functional programming is not orthogonal to object oriented programming, they are paradigms that can be used together and the popular object system developed in Java is not close to the only way to do OOP.

R, like Common Lisp, uses an OOP system based on generic functions (well, one of many OOP systems in R, but that's a different topic), where the function handles dispatching to match the object.

Effectively instead of:

    object.method()
you have:

   method(object)
So it works perfectly with the functional paradigm while still being capable of everything an object system is.

The most obvious example of this in R is the `plot` function. You as the programmer don't have to know exactly how to plot an instance of a class, you just pass it into `plot` and it will be handled correctly. If you create a new class you just have to extend the definition of plot in a standard way and it will also be handled for you.

It's a shame that the many flavors of OOP remain relatively unknown to most programmers, and in many of the cases where they're tried (JavaScript's prototype system for example) people have essentially replaced them with more familiar systems.

Re: Generalizing Support for Functional OOP in R

#15
post #4

Earlier quoted context omitted.

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…

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.

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.

Re: Generalizing Support for Functional OOP in R

#16
post #4

To be honest, OOP never really seemed like a good fit for R. Functional programming is a much more natural fit, given that both it and R come from a mathematical point of view. R is a great language for the mathematical/statistical stuff it was invented to do, but I don't think it will ever be a general-purpose language, and it probably would become worse at its core purpose if it tried to. More work on being easily…

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…

> I suspect lazy evaluation is a part of this.

I had no idea R was lazy. Makes me wanna learn it now.

Re: Generalizing Support for Functional OOP in R

#17
post #7
post #6

Earlier quoted context omitted.

OOP as used in R is very much a function of API design and not a function of routine R usage for data analysis. To many users of R they are not even aware that they are using OOP at all, especially for the S3 style of objects. When you have an object, like `model summary()` ends up being very natural, and when you fit in the tidyverse operators many very complex workflows end up being very easy to digest. But when yo…

Some detail about that phrase https://www.catalyst.org/2021/03/22/racism-misogyny-asian-am...

I can honestly say that I had never heard that phrase used before now, but I do know I felt icky when I read it in the comment before I even clicked on your link. Definitely glad to see it is being called out, terms like this absolutely need to be removed from modern discourse.

Re: Generalizing Support for Functional OOP in R

#18
post #13
post #9

I trust the authors immensely but i don't see what yet another class system in R solves. That's on me, but I'd like to understand more of what motivates this effort.

From the article: “S7 is a new OOP system being developed as a collaboration between representatives from R-Core, Bioconductor, tidyverse/Posit, ROpenSci, and the wider R community, with the goal of unifying S3 and S4 and promoting interoperability.” It then goes on to describe what that means in depth.

I can read, thak you, and no it doesn't.

It describes 3 new generics in base R that help their new S7 system.

It all seems motivated by better interop with python which is 'neat' but really doesn't seem like a critical necessity of the language. I guess it's more of a tactical thing where they're trying to make it easier for python users to eventually try R. Or for R users that work alongside python users to not abandon R.

Re: Generalizing Support for Functional OOP in R

#19
post #18
post #13

Earlier quoted context omitted.

From the article: “S7 is a new OOP system being developed as a collaboration between representatives from R-Core, Bioconductor, tidyverse/Posit, ROpenSci, and the wider R community, with the goal of unifying S3 and S4 and promoting interoperability.” It then goes on to describe what that means in depth.

I can read, thak you, and no it doesn't. It describes 3 new generics in base R that help their new S7 system. It all seems motivated by better interop with python which is 'neat' but really doesn't seem like a critical necessity of the language. I guess it's more of a tactical thing where they're trying to make it easier for python users to eventually try R. Or for R users that work alongside python users to not aban…

The Python interop is in the blog post because it makes for convenient and compact examples, not because it motivated any of the features.

If you're interested in what motivated S7, you may enjoy this talk Hadley gave: https://www.youtube.com/watch?v=P3FxCvSueag (R7 was the working name for the package at the time)

Post reply on HN