más referencias interesantes

[Julenasti]

https://epiverse-trace.github.io/posts/for-vs-apply/

[VeruGHub]

https://ivelasq.rbind.io/blog/understanding-the-r-pipe/

[Julenasti]

INCLUIDO https://emf.creaf.cat/workflows/r_parallel_computing_tech_doc/

Creo que al final de los apuntes se podría añadir una breve explicación de esto junto con un ejemplo porque suele ser una pregunta bastante recurrente

[Julenasti]

https://jennybc.github.io/purrr-tutorial/index.html

[Julenasti]

https://cran.r-project.org/web/packages/dplyr/vignettes/programming.html

el data masking y el tidy selection son dos problemas muy comunes al que uno se enfrenta cuando empieza a escribir funciones en formato tidy. Creo que por lo menos añadir el link estaría bien

[Julenasti]

INCLUIDO quizás en un link podríamos poner más variantes de map que no profundizamos pero que pueden ser útiles, principalmente pensando en imap y modify https://adv-r.hadley.nz/functionals.html#map-variants

[Julenasti]

INCLUIDO esta reflexión también me parece interesante: The more clearly you can express the intent of your code through function names, the more easily others (including future you!) can read and understand the code. https://adv-r.hadley.nz/function-operators.html

[Julenasti]

INCLUIDO creo que podriamos ampliar la parte de programación orientada a objetos (OOP) para que quede un poco más claro la diferencia con FP. Aquí alguna información relativamente sencilla de entender que nos puede ayudar en esto (lo acortaria más que aquí):

Generally in R, functional programming is much more important than object-oriented programming, because you typically solve complex problems by decomposing them into simple functions, not simple objects. The main reason to use OOP is polymorphism (literally: many shapes). Polymorphism means that a developer can consider a function’s interface separately from its implementation, making it possible to use the same function form for different types of input. This is closely related to the idea of encapsulation: the user doesn’t need to worry about details of an object because they are encapsulated behind a standard interface.

To be concrete, polymorphism is what allows summary() to produce different outputs for numeric and factor variables:

diamonds <- ggplot2::[diamonds](https://ggplot2.tidyverse.org/reference/diamonds.html)

[summary](https://rdrr.io/r/base/summary.html)(diamonds$carat)
#>    Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
#>    0.20    0.40    0.70    0.80    1.04    5.01

[summary](https://rdrr.io/r/base/summary.html)(diamonds$cut)
#>      Fair      Good Very Good   Premium     Ideal 
#>      1610      4906     12082     13791     21551

You could imagine summary() containing a series of if-else statements, but that would mean only the original author could add new implementations. An OOP system makes it possible for any developer to extend the interface with implementations for new types of input.

To be more precise, OO systems call the type of an object its class, and an implementation for a specific class is called a method. Roughly speaking, a class defines what an object is and methods describe what that object can do. The class defines the fields, the data possessed by every instance of that class. Classes are organised in a hierarchy so that if a method does not exist for one class, its parent’s method is used, and the child is said to inherit behaviour. For example, in R, an ordered factor inherits from a regular factor, and a generalised linear model inherits from a linear model.

There are two main paradigms of object-oriented programming which differ in how methods and classes are related. In this book, we’ll borrow the terminology of Extending R61 and call these paradigms encapsulated and functional:

In encapsulated OOP, methods belong to objects or classes, and method calls typically look like object.method(arg1, arg2). This is called encapsulated because the object encapsulates both data (with fields) and behaviour (with methods), and is the paradigm found in most popular languages.

In functional OOP, methods belong to generic functions, and method calls look like ordinary function calls: generic(object, arg2, arg3). This is called functional because from the outside it looks like a regular function call, and internally the components are also functions.

John Chambers’ pithy quote: “Everything that exists in R is an object”. However, while everything is an object, not everything is object-oriented.

To tell the difference between a base and OO object, use is.object() or sloop::otype():

Para más información ver https://adv-r.hadley.nz/oo.html y sus trade-offs https://adv-r.hadley.nz/oo-tradeoffs.html