¿Por qué no se puede usar R para escribir código de grado de producción? ¿Por qué Python no se usa también para la creación de prototipos?

Quiero agregar algo sobre el papel de R en la creación de prototipos. Una razón principal por la que R es una herramienta importante para la ciencia de datos es la gran cantidad de herramientas analíticas que se han implementado en R y en ninguna otra parte. Cualquiera que dude de esto simplemente no tiene mucho conocimiento sobre la cantidad de herramientas analíticas existentes.

Los detalles de su dominio son importantes aquí, pero por regla general, ninguna otra plataforma se acerca al número de algoritmos disponibles. Igualmente importante, estas bibliotecas tienden a jugar bien juntas. Debido a que R core se basa en estructuras de datos como data.frame y las series de tiempo, los escritores de bibliotecas han podido construir sobre estructuras de datos relevantes para su dominio, en lugar de implementarlas desde cero. Esto hace que sea más fácil implementar una biblioteca analítica para R y también promueve la compatibilidad entre bibliotecas.

Cuando realiza un prototipo en R, puede probar rápidamente una gran cantidad de herramientas analíticas. Al final de la etapa de prototipo, ha identificado la pequeña cantidad de algoritmos que realmente quiere poner en producción. Lo más probable es que no los produzca con R (aunque podría), sino que los volverá a implementar desde cero en la plataforma que elija.

Creo que una de las cosas que distingue el flujo de trabajo de la ciencia de datos de otro flujo de trabajo de ingeniería es la gran complejidad de las opciones. En ingeniería, tiene poco sentido tener una plataforma completa solo para ‘probar’ diferentes algoritmos. Pero en análisis, hay mucha más complejidad algorítmica en juego. No puedes simplemente adivinar qué algoritmos necesitas porque tienes experiencia: tienes que experimentar. Una plataforma completa para la experimentación rápida es exactamente lo que necesita para respaldar el trabajo analítico, que, por cierto, siempre ha sido la razón por la que R existe en primer lugar.

Discutiría la premisa de la pregunta. R puede ser y se usa en la producción. La pregunta realmente debería centrarse en qué tipo de entorno de producción y tarea. Construir un servidor web para un sitio web de alto tráfico en R puro sería un error; construyendo una simulación fluidodinámica en R, también. Pero puede implementar un servidor web de análisis de producción en su organización para cientos de usuarios en Shiny, probablemente más rápido que con cualquier marco web existente; y la cantidad de aplicaciones corporativas dirigidas a menos de 1000 usuarios es sorprendentemente alta, así como la cantidad de conjuntos de datos de menos de 50 GB (que R puede manejar perfectamente). R también se puede utilizar para tareas de análisis de datos por lotes a gran escala (especialmente en Linux). Otra ventaja de R es la administración de paquetes bastante indolora. Por otro lado, para tareas analíticas en tiempo real a gran escala, no usaría ni R ni Python, sino Clojure (siéntase libre de reemplazar eso con Scala, F # o el idioma que elija).

Creo que la respuesta a continuación (por A. Sharma) supone demasiado sobre la naturaleza del entorno de producción; y repite algunos conceptos erróneos sobre R. Trataré de abordar algunos de estos puntos por punto, porque son muy comunes.

1. [Python] Relativamente muy rápido

   Señalaría que los puntos de referencia de Julia no tienen sentido fuera de contexto, ya que implementan el mismo algoritmo en todo el lenguaje para mostrar la versatilidad de Julia. Pero el código de código nativo de R puede realizar estas tareas mucho, mucho más rápido si se usa, digamos, la memorización en lugar de la recursividad. Y además de eso, la forma correcta de ver R no es diferente a Python: un lenguaje muy flexible capaz de orquestar tareas, que generalmente se ejecutan utilizando funciones rápidas y optimizadas escritas en Fortran, C y C ++, por lo que el diferencial de rendimiento generalmente es insignificante.

2. Código bellamente escrito

   Es más fácil escribir código feo en R. No me importaría tener un poco más de azúcar sintáctica aquí y allá, y menos conversiones / promociones, que están dirigidas al uso interactivo. Pero el código R puede ser increíblemente elegante y ofrece capacidades superiores para programar en el idioma. Verifique el código de cualquiera de los grandes confirmadores de paquetes R, como H.Wickham, M.Dowle o R.Francois.

3. Mejor implementación de los conceptos de OOP

   Sin duda aquí, pero estoy en paz con eso; y recomendaría que mis amigos pythonistas dejen de escribir clases (
   )

4. Bibliotecas para proporcionar casi cualquier cosa que se pueda hacer en R

   Esto es evidentemente falso. Ejercicio: tome cualquiera de las páginas de vistas de tareas de CRAN ( http://cran.r-project.org/web/vi …) e intente asignar las bibliotecas a Python. Ni siquiera está cerca, ni por asomo. Y, en muchos de estos paquetes hay mucho conocimiento específico de dominio. Están escritos por los mejores expertos en sus campos.

5. Escalable (compatible con Hadoop / Pig)

   Como se mencionó anteriormente, la “escalabilidad” está en el ojo del espectador; y las percepciones del lenguaje cambian muy rápido. Recuerdo que hace solo 10 años la gente se burlaba de que Python fuera utilizado en cualquier función de producción, Django fue ignorado en público, etc. (todavía hay tales detractores, por cierto). Para Hadoop, consulte http://cran.r-project.org/web/vi … así como los productos Revolution Analytics.

6. Mejor funcionalidad para interactuar con otros sistemas.

   Creo que Python es de primera clase aquí, sin excepción, pero no se perderá nada en R. Interactúa con todas las bases de datos conocidas y ha soportado una integración caballeresca con una serie de grandes proveedores (Oracle, Teradata, Netezza, Tibco, Tableau ..)

7. Creación rápida de prototipos (puede usarlo como lenguaje de programación con Numpy / Pandas / … o usar el concepto de OOP para crear un contenedor alrededor de su aplicación para interactuar con otros sistemas)

   Esto es raro. En todo caso, la creación de prototipos de R es * demasiado * rápida, porque el lenguaje es expresivo. ¡Terminas tomando atajos y siendo demasiado inteligente!

Y para responder a la segunda parte de la respuesta: Python se usa para la producción y creación de prototipos, todo el tiempo . Entonces, también discutiré esa premisa. Y, agregaría, Python sigue siendo un lenguaje hermoso, con muchas herramientas de desarrollo, una comunidad muy grande y amigable, mucho soporte corporativo y un conjunto completo de bibliotecas en muchos dominios de aplicación. ¿Necesito decir mas?

Unas pocas cosas:

1) OOP puede ser útil, no siempre es un desperdicio, y un buen sistema de objetos sería útil. A ese respecto, la confusión sintáctica de R entre funciones y métodos no es tan buena (sin mencionar la definición de clases a través de llamadas a funciones y la dualidad S3 / S4), aunque uno puede acostumbrarse. El uso de las clases y los beans Java de Python son ejemplos de prácticas de programación terribles, pero la OOP en sí misma puede ser muy poderosa: observe los buenos híbridos OOP-FP como Scala u OCaml. Lo OOP también es discutible: Python no tiene la encapsulación adecuada, pero Java sí. Java no tiene métodos amigos, pero C ++ sí. Paul Graham tuvo un buen artículo sobre cómo no es fácil ponerse de acuerdo sobre lo que realmente es la OOP: para mí es encapsulación, herencia y polimorfismo, pero ¿se incluiría la herencia múltiple (Python) o se prohibiría (Java), si contamos con base en la herencia o polimorfismo de origen genérico? Sobre todo, ¿le importa a la mayoría de los científicos de datos y estadísticos, o solo a las personas que también son ingenieros de software profesionales y que se preocupan más por esas cosas?

2) Si R es principalmente funcional en lugar de orientado a objetos, ¿por qué no admite la optimización recursiva de la cola? Si me equivoco acerca de esta falta de apoyo, avíseme. ¿Les importaría a los usuarios que no son expertos en CS escribir sus bucles o simplemente vectorizarlos?

3) En un mundo multinúcleo, tener un tiempo de ejecución de un solo subproceso y escalar mediante multiprocesamiento es similar a escribir aplicaciones web usando CGI en 2014. La sobrecarga de cambio de contexto del sistema operativo es muy grande (por ejemplo, cuando se usa doMC et al. para procesamiento multinúcleo): una vez más, si su código se interpreta 100 veces más lento que C ++ o Java / Scala JITted, tal vez eso sea una pequeña penalización en el gran esquema de las cosas. Sin embargo, puede no ser un problema para pequeños conjuntos de datos, en esos casos, la creación rápida de prototipos de R es mucho más importante que el rendimiento.

4) R aún puede ser rápido “cuando se escribe en C ++”, que es la cantidad de bibliotecas R escritas de todos modos. Con las bibliotecas 3k +, es posible que nunca tenga que escribir C ++, pero se beneficie de la velocidad razonable de las bibliotecas existentes. El compilador de bytecode también ayuda bastante.

5) El recolector de basura de R apesta en comparación con cualquier plataforma moderna, pero especialmente en relación con la JVM. También lo hace la administración de memoria de R en general, con pasar por copia en lugar de por referencia. R no luce el recolector de basura de Haskell que puede limpiar un gigabyte de basura por segundo para hacer todo por copia. En lenguajes como Scala, puede hacer cosas por referencia, pero puede construir estructuras de datos inmutables si lo desea; depende del caso de uso. Una vez más, si estas cosas son importantes o no depende del tamaño de los datos, de la frecuencia de creación y destrucción de objetos (por ejemplo, es un sistema en tiempo real alimentado por Storm / Spark Streaming / Samza o simplemente un proceso por lotes ejecutado una vez en Un rato).

6) ¿Usarías R en producción ya que es GPL? Dado el vacío legal de GPL para aplicaciones SaaS, tal vez, pero R también tiene componentes AGPL en estos días, por lo que aún sería un problema. Para el envío de sortware, GPL es un no-no. Puede obtener R comercial de Revolution Analytics, pero eso puede ser costoso.

7) El conjunto adecuado de bibliotecas depende de lo que hagas. Si es PNL, el NLTK de Python podría ser suficiente, lo mismo con scikit-learn para aprendizaje automático. Python, Java, Scala, etc. son totalmente inadecuados cuando se trata de estadísticas: ahí es donde realmente brilla R. ¿Tal vez si lo que haces es visión artificial, entonces deberías usar C ++ o Python wrapper para OpenCV? Si está trabajando en dinámica de fluidos computacional, ingeniería mecánica, etc., ¿MATLAB u Octave serían mejores opciones? Si hace investigación de operaciones todo el día, ¿podría usar Python con un solucionador profesional como Gurobi? Todo depende de cuáles sean tus objetivos.

8) La calidad de producción depende de los casos de uso. Mis aplicaciones de ciencia de datos manejan terabytes de datos, así que uso Scala y Java. Sin embargo, para un pequeño conjunto de datos, es evidente que haría un análisis en R: no tiene sentido ser un experto en ingeniería de software o CS cuando la productividad del desarrollo del modelo está en juego. Pero para grandes datos, es difícil vencer a la plataforma JVM: sin embargo, pagará el precio cuando se trata de la velocidad a la que desarrolla los modelos, ya que es posible que necesite desarrollar los algoritmos desde cero y solo luego aplicarlos.

No seamos fanáticos de ninguna plataforma, herramienta o lenguaje: cada uno tiene sus fortalezas y debilidades. 🙂

No debería ser ‘ no puedo ‘ sino ‘ no ‘.

Sí, R no está estáticamente escrito. ¿Pero es JavaScript, que es bastante popular en el desarrollo web, estadísticamente tipificado?

Sí, R no es rápido. Pero no todas las aplicaciones deben ser rápidas.

Sí, la OOP de R (S3, S4) no es OOP en sentido estricto. Pero, ¿cómo desarrollaron los programadores una aplicación antes de OOP?

Sí, R aún no es escalable. Pero no todos los datos tienen que ser distribuidos.

Sin embargo, es innegable que lo anterior hace que R sea más difícil de adoptar.

Otras razones pueden ser

– la mayoría de los programadores convencionales (.NET, JVM) no conocen bien R
– la mayoría de los estadísticos (o entusiastas de R) no saben cómo desarrollar una aplicación
– es probable que su licencia abra su código fuente completo

Realmente no puedo hablar con la parte R, así como no lo uso a menudo. Esto se debe a que, en mi opinión, Python se puede usar para la creación de prototipos y en realidad es muy adecuado para ello. Las bibliotecas disponibles como matplotlib, pandas, statsmodels y scikitlearn más las bibliotecas integradas de Python le brindan un buen lugar para comenzar para la mayoría de los problemas sin tener que reinventar la rueda.

Luego, cuando haya realizado su experimentación y tenga una prueba de concepto, todo ese código ya está en un lenguaje de programación legible, robusto y ampliamente conocido que usted (o un ingeniero de software profesional) puede optimizar, convertir en un módulo, escriba piezas personalizadas adicionales para, y combine con otros módulos de Python para hacer algo realmente útil. ¿Desea crear una API web que ejecute algunos análisis largos y que devuelva datos y trazados más adelante? Conecte su prototipo de Python a Flask / Django y una cola de trabajos como Celery o RQ. ¿Necesita paralelizarlo en algún servidor monstruo con 16 núcleos? Mire en JobLib o multiprocesamiento. Etcétera etcétera…

En última instancia, Python tiene una gran comunidad tanto en Data Science como fuera de ella, y como resultado, el código ya se ha escrito para resolver muchos problemas asociados con la construcción de sistemas de producción de todo tipo, muchas veces, se necesita más que estadísticas y trazados básicos. para hacer algo realmente útil. Dicho esto, si te sientes cómodo con R, probablemente sea por lo que deberías hacer prototipos por ahora: el objetivo de los prototipos es saltar y escribir algo rápido para ver si vale la pena el esfuerzo de desarrollar algo robusto. Si genera un análisis realmente valioso en R, probablemente haya una manera de replicar ese análisis en Python y si no lo hay, tiene suerte; Es un lenguaje de programación adecuado donde usted (u otra persona) puede implementar los métodos necesarios.

Creo que la razón principal es que Python es un lenguaje de programación real, mientras que R es un script estadístico. Y para mantener un sistema de producción (es decir, grande) necesita un lenguaje de programación real. Hoy en día, muchos proyectos de software fallan debido a la abrumadora complejidad del código grande. Se han inventado muchos principios de diseño de programación para que la mente humana “limitada” pueda enfrentar este desafío. Python hace un excelente trabajo apoyando la programación avanzada, mientras que R apenas lo intenta.

Para resumir:
* el código de producción puede volverse grande y complejo
* programar software grande es muy, muy difícil
-> solo Python intentó admitir conceptos de programación avanzados para que se puedan mantener grandes sistemas de producción

Python carece de algunos paquetes estadísticos ya que el interés en Python por las estadísticas / aprendizaje automático comenzó considerablemente más tarde, pero se está poniendo al día ya que se ha formado una gran comunidad para escribir paquetes de aprendizaje automático y visualización.

Ahora puede decidir cuál de las siguientes dos sucederá más rápido para ponerse al día con la otra opción:
* Los desarrolladores de Python usan un lenguaje excelente y fácil de mantener para escribir paquetes adicionales si es necesario
* alguien reescribe R desde cero para que sea adecuado para escribir proyectos de software

Considerables jugadores impulsan a Python como el futuro de la ciencia de datos:
Continuum Analytics recibe $ 3 millones en fondos DARPA XDATA
Microsoft Corporation patrocina IPython

He escrito un artículo sobre eso:

¿Puedo usar R en producción? – Hacker Noon