Sigo escuchando acerca de algunos ‘defectos arquitectónicos’ en el software R para la computación estadística, sin embargo, nadie explica claramente cuáles son los defectos. ¿Podría cualquier alma de corazón R arrojar algo de luz?

No hace falta decir que cada lenguaje de programación tiene puntos débiles, simplemente porque fueron diseñados con ciertas fortalezas en mente (y no hay almuerzo gratis). En mi experiencia, la mayoría de las quejas sobre R provienen de personas que realmente no reconocen o aprecian algunas de las ventajas de R; Con una mentalidad cínica, es fácil decir que “el lenguaje tiene fallas” sin una razón legítima.

He programado en R desde hace varios años, y he encontrado que es un lenguaje increíblemente útil y versátil. Un área en la que se puede describir como “débil” es con respecto a la gestión de la memoria. Vea mi respuesta a: ¿Cuál es la diferencia entre data.frame y data.table en R (lenguaje de programación)?

Es una lástima que base-R cree múltiples copias de un data.frame cuando un usuario cambia ingenuamente los nombres de las columnas. Sin embargo, R no fue diseñado para ser increíblemente eficiente en memoria. El lenguaje no es para informáticos, es para estadísticos y, por lo tanto, está destinado a abstraerse de detalles como punteros y direcciones de memoria.

Además, el equipo R-core está muy preocupado por la compatibilidad con versiones anteriores, ya que reconocen que muchos de sus usuarios confían en su código para continuar trabajando incluso mientras actualizan R. Es mi entendimiento que los cambios a la base R que son sustantivos deben ser aprobado por el equipo central, y no están tan ansiosos por romper innumerables secuencias de comandos para pequeñas mejoras de rendimiento. Estarían más centrados en la robustez y corrección estadística y matemática. Esto no es realmente una desventaja por decir, sino una explicación de por qué no vemos que ciertos tipos de cambios se implementen muy rápidamente.

Como señala Andreas Santucci, R es relativamente débil en la gestión de la memoria. Este pequeño tutorial te da algunas ideas sobre cómo lidiar con eso.

Uso de memoria · R. avanzado

En la práctica, dependiendo de su conjunto de problemas y su conjunto de datos y sus algoritmos, esto puede ser irrelevante, importante o un obstáculo para el espectáculo. Algunos algoritmos consumen cantidades muy grandes de memoria en conjuntos de datos muy grandes. También hay operaciones en R que hacen que los objetos se copien en lugar de modificarse en su lugar, por lo que los cambios sutiles en su implementación tienen un impacto sustancial en el uso real de la memoria.

También hay aspectos de R que son inesperados para los programadores que están acostumbrados a otros lenguajes de programación. No es que R esté “equivocado” o “roto”, solo que es diferente y, como tal, es posible escribir código que parece que funcionará y no funcionará. Algunas anécdotas:

Defectos de diseño en R # 1 – Secuencias inversas
Defectos de diseño en R # 2 – Dimensiones caídas

Espero que esto ayude.

John D Cook alude a algunos de ellos aquí.
El lenguaje R, para programadores.

Las fallas de R son particularmente pronunciadas si proviene de la familia de lenguajes de programación ALGOL. De lo contrario, en realidad es un lenguaje correcto.

El único problema importante con R no es tanto un defecto arquitectónico sino un subproducto de una cultura democrática, descentralizada y permisiva (en el sentido de que no hay un dictador excepto quizás el equipo central de R). He estado escribiendo código R y Python por un tiempo, y uno de los principales obstáculos que enfrento a menudo en R es que hay muchas maneras diferentes de hacer las cosas y es difícil determinar cuál es el mejor para una tarea determinada. (por ejemplo, existe la familia de aplicación, biblioteca frente a requerir, adjuntar o no adjuntar, sin mencionar las muchas inconsistencias molestas, etc.). Esto también contribuye a que la sintaxis R sea difícil de recordar. Siempre tengo que tener a mano un montón de fragmentos de código R porque nunca recuerdo cómo hacer las cosas.

Python es mucho más obstinado y tiende a adherirse al principio de que “debe haber una, y preferiblemente solo una, forma obvia de hacerlo”. Por supuesto, hay excepciones, pero el principio general se mantiene en la cultura Python.

Afortunadamente, he convergido en un conjunto de herramientas obstinadas dentro de R (dplyr, ggplot2, tidyr, magrittr%>% pipe). Esto ha mejorado mi productividad enormemente. En lugar de memorizar diversas sintaxis para manipular marcos de datos, simplemente los canalizo a través de dplyr / tidyr para obtener resultados predecibles.