Python no es un lenguaje adecuado para la ciencia de datos

• En tareas de datos no relacionadas con deep learning, como análisis, visualización y resumen de datos, Python tiene capacidades suficientes, pero la experiencia de uso tiende a volverse compleja e ineficiente
• En distintos casos dentro del laboratorio, se observó repetidamente que, incluso para transformaciones gráficas simples y cálculos estadísticos, Python suele requerir más código y más tiempo que R
• Incluso usando pandas, matplotlib y NumPy, la estructura de sintaxis, indexación, paréntesis y encadenamiento de métodos hace que con frecuencia uno termine atrapado en los detalles de implementación (logística) más que en la lógica
• En cambio, tidyverse de R permite expresar el flujo de procesamiento de datos casi al nivel del lenguaje natural, lo que hace más fácil trasladar la lógica del trabajo directamente al código
• Como lenguaje para ciencia de datos, Python tiene limitaciones estructurales para separar la lógica de la logística, y esto se debe al diseño del lenguaje y de su ecosistema

---

Comparación de la experiencia real de uso entre Python y R

• En el laboratorio, los integrantes pueden elegir libremente el lenguaje, pero hay muchos usuarios de Python, y aparece de forma consistente un patrón en el que no logran resolver con rapidez solicitudes simples de análisis adicional
  • Incluso cambios de visualización como boxplot → violin plot, histograma → gráfico de densidad, o gráfico de líneas → mapa de calor no resultan fáciles de hacer al instante
  • Lo que en R se resuelve en unas pocas líneas, en Python suele sentirse como algo que obliga a “volver al escritorio y ponerse a recodificar”
• Incluso al dar clases en conjunto con expertos en Python, queda en evidencia una gran diferencia frente a R en la longitud y complejidad del código necesario
  • La reacción de “¿por qué tiene que ser tan complicado?” aparece repetidamente en distintas situaciones, y eso parece deberse no a la habilidad individual, sino a una diferencia estructural en la arquitectura del lenguaje y las librerías
  • Aun con la misma lógica, en Python hacen falta indexación, separación y reensamblado de datos, y combinación de varios métodos, lo que vuelve la estructura más verbosa
  • En R tidyverse es posible una expresión directa con cadenas naturales como filter → group_by → summarize

Por qué Python se usa tanto y cuáles son sus límites

• La posición de Python en ciencia de datos se basa más en su expansión histórica, su propósito general y el tamaño de su ecosistema que en una adecuación intrínseca
  • En el campo del deep learning, Python sí es claramente central gracias a PyTorch y al ecosistema de IA
  • Sin embargo, en limpieza, exploración, visualización y modelado estadístico de datos sigue habiendo muchas incomodidades
• Se lo describe como una “popularidad cercana a un accidente histórico”, y la pesadez de su estructura de lenguaje frente a R aparece una y otra vez en varios ejemplos

Condiciones de un buen lenguaje para ciencia de datos

• Para trabajos centrados en exploración, resumen, ajuste de modelos y visualización de datos, lo más importante es un entorno interactivo, bajo costo de configuración y ciclos rápidos de iteración
  • Un lenguaje interpretado de tipo script resulta más adecuado que uno compilado
  • Más que el rendimiento, importan la simplicidad del código, la reducción del riesgo de errores y la minimización de la carga mental
  • Si hace falta, basta con reescribir no todo, sino solo algunas operaciones en un lenguaje de alto rendimiento como Rust
• En la práctica, los lenguajes que realmente vale la pena considerar son R y Python
  • Matlab, Mathematica y otros son comerciales o tienen ecosistemas limitados
  • Julia suele mencionarse, pero el autor no la ha usado lo suficiente como para evaluarla

El problema de “lógica vs logística”

• Un lenguaje de análisis de datos debe separar qué se quiere calcular (lógica) de cómo se calcula (logística)
  • Si uno tiene que preocuparse por tipos de datos, índices, bucles o ensamblado manual, entonces ya quedó atrapado en la logística
• En el ejemplo de Palmer Penguins, el tidyverse de R expresa el cálculo de medias y desviaciones estándar con un flujo cercano al lenguaje natural
  • No hace falta desmontar el flujo de datos para luego volver a armarlo
• pandas ofrece funciones parecidas, pero la cantidad de trabajo accesorio, como especificación en cadenas, paréntesis, encadenamiento de métodos y reset_index, reduce la legibilidad y la simplicidad
• Si se implementa la misma tarea solo con Python puro
  • Hay que hacer manualmente: construir bucles → generar claves de agrupación → dividir → calcular medias → calcular varianzas → calcular desviaciones estándar → reensamblar → ordenar
  • Todo debe procesarse a mano, y eso se vuelve un caso típico donde el código logístico termina aplastando la lógica

Conclusión y adelanto de lo que sigue

• En análisis de datos, Python vuelve a mostrar de manera repetida un problema estructural que hace que uno se concentre más en los detalles de implementación que en la lógica
  • Esto parece ser el resultado combinado de las características del propio lenguaje, las limitaciones de diseño de sus librerías y las costumbres de todo su ecosistema
• En un texto posterior se abordarán las causas técnicas concretas por las que Python hace más difícil el análisis de datos que R

Discusión adicional y puntos de comparación (incluyendo comentarios de lectores)

• También existe la opinión de que tidyverse puede ser más verboso que R base, pero sigue siendo fuerte en expresividad, consistencia y abstracción para el procesamiento de datos
• Por otro lado, se plantea como objeción que R tiene grandes incomodidades del lado del desarrollo de software, como modularización, pruebas e implementación de CLI
• Python ofrece una excelente experiencia para desarrolladores en logging, entornos virtuales, empaquetado y estructura de clases, pero
  • matplotlib tiene un diseño poco intuitivo,
  • pandas una sintaxis inconsistente,
  • y scikit-learn suele ser mencionado por problemas de diseño
• Algunas opiniones consideran a Python como un lenguaje que produce rápidamente código inestable y de baja calidad, y mencionan que para el desarrollo sostenible convienen más los lenguajes con tipado estático

[kaydash]

A medida que aumenta la complejidad y el volumen de los datos, si se vuelve necesario el procesamiento dividido por etapas, además del manejo mediante datos no estructurados, modelos estructurados e incluso el procesamiento a través de LLM, como hay muchos casos de uso, ¿no sería entonces el lenguaje más adecuado?

[GN⁺]

Opinión de Hacker News

• Se dieron varios ejemplos de transformaciones, como cambiar un boxplot por un violin plot o un line plot por un heatmap.
  En realidad, esta discusión trata más de matplotlib que de Python.
  Si quieres el diseño de ggplot en Python, puedes usar plotnine.
  La razón por la que el código en R se ve más conciso es por la evaluación no estándar (non-standard evaluation) de R.
  Python no permite este tipo de extensiones a nivel de lenguaje.
  Consulta Computing on the language para más contexto.

  • Al final, esto es una discusión sobre las diferencias entre Python y R.
    La evaluación no estándar es cómoda en entornos interactivos, pero al escribir código de análisis complejo termina siendo más bien una desventaja.
    Incluso tareas simples a veces requieren rodeos.
  • Es difícil de ver eso de poner el pipe al final de la línea en código R.
    Me parece mejor poner el operador pipe al inicio, como en Elixir.
    Python también puede imitar una sintaxis parecida con trucos como getattr, pero al final esto es más un tema de diseño del API de bibliotecas que del lenguaje.
  • “¿Y si hicieras trabajo logístico en R sin bibliotecas?” Solo imaginarlo da miedo.
    R es fácil solo cuando hay bibliotecas y recetas disponibles; si no las hay, se vuelve realmente difícil, y la mayoría simplemente no lo hace.
  • Para este tipo de objetivo, seaborn encaja bien.
    Abstrae la incomodidad de matplotlib y aun así ofrece funciones ricas.
    Tutorial de Seaborn
  • Al final, el punto clave parece ser no Python, sino hablar de lo que R puede hacer y Python no.

• Me pregunto por qué las tablas no son objetos de primera clase en los lenguajes de programación.
  En la mayoría de los lenguajes hay que aprender APIs aparte, como pandas o polars, para manejar tablas.
  En R, data.frame está cerca de ser un objeto de primera clase, pero en la práctica se usa más el tibble de dplyr.
  Todavía no se ha estandarizado un lenguaje de expresión para trabajar con datos tabulares.
  Polars y dplyr comparten una filosofía parecida, pero al final SQL parece ser la única base común.
  Python no es perfecto, pero creo que con R pasa lo mismo.

  • Siento que faltan muchas estructuras a nivel de lenguaje.
    Estructuras como tablas, matrices, grafos y máquinas de estado no tienen soporte a nivel de lenguaje, y eso limita su uso.
    Las herramientas incluidas por defecto terminan definiendo el “camino bonito” de ese lenguaje.
    Antes, incluso los key-value store eran bibliotecas externas, pero ahora son casi estándar.
  • Lenguajes como Q, Rye y Lil tratan las tablas como un tipo de dato realmente de primera clase.
    Espero que algún día los lenguajes dominantes también absorban esta forma de programación basada en tablas.
    Lenguaje Q, artículo comparando Rye, herramienta experimental Lil
  • tibble y data.table heredan de data.frame, así que las funciones base de R siguen funcionando tal cual.
    La conversión entre los tres objetos también es muy simple.
  • A medida que una tabla crece a 1 millón, 1 mil millones o 1 billón de filas, la naturaleza del problema cambia por completo.
    No es fácil diseñar un API estándar que pueda manejar con elegancia diferencias de escala así.
  • El data.table de R es excelente.
    Aun así, dplyr ganó en documentación y onboarding, y por eso logró adopción en la industria.

• La idea general del texto está bien, pero da pena que el autor revele demasiado rápido la base de su argumento.
  R es fuerte en el manejo de data frames, pero flojo en gestión de archivos y mantenibilidad.
  Si haces mucho de ese trabajo, Python es mejor, y si además importa la velocidad, uno empieza a inclinarse por Julia.
  La elección cambia según las prioridades de cada quien.
  Veo seguido a estudiantes intentando resolver con pandas problemas no tabulares, como gráficos; en esos casos habría que replantearse la herramienta.

  • El ejemplo de código en Python es inadecuado.
    Con numpy, el cálculo de media y varianza ya viene incorporado.
    Python y R tienen una dificultad de aprendizaje parecida, pero la fortaleza de Python está en su capacidad de integración con otras aplicaciones.
  • La segunda parte del texto puede verse aquí.
  • Yo también uso Python y R mitad y mitad.
    Para procesar archivos grandes, Python; para analizar datos resumidos, R resulta más eficiente.
    Cada lenguaje debe usarse como la herramienta adecuada para el caso adecuado.

• Como programador de Python, también he usado R, y Python es un “lenguaje que hace casi todo bastante bien, pero no perfectamente”.
  Si vas a pasar todo el día haciendo análisis de datos, sí conviene aprender R.
  R es un lenguaje diseñado según la forma de pensar de los estadísticos.
  Al principio se siente extraño, pero ese cambio de mentalidad incluso ayuda.
  Aun así, yo trabajo casi siempre en Python.

• Se puede hacer ciencia de datos con pandas, pero me pareció tosco y complejo.
  Con polars mejoró un poco, pero con duckdb cambió por completo.
  Ejecuto consultas SQL directamente en el notebook y analizo archivos parquet.
  Mezclar celdas de SQL con celdas de Python deja el código más limpio.
  Al ver la comparación final entre Python y R en el artículo, pensé: “¿esto no quedaría mucho mejor escrito en SQL?”

  • Yo prefiero trabajar centrado en data frames, resolviendo todo dentro del lenguaje, más que con SQL.
  • Uso polars con frecuencia; también debería probar duckdb.

• El último ejemplo en Python es innecesariamente verboso.
  Con defaultdict y statistics.stddev quedaría mucho más conciso.

  • Es interesante que haya metido manualmente la corrección de Bessel.
    Muchas veces se implementa sin siquiera pensar si esa corrección tiene sentido.
    En realidad sería más preciso llamarlo sample_std_dev.
  • También se podría usar itertools.groupby.
    El código no sería más corto, pero expresaría la intención con claridad.
  • El código original es más fácil de leer.
    No conviene sacrificar legibilidad solo por escribir menos.

• Probé implementar el mismo ejemplo con TidierData.jl de Julia, y sale casi igual que la versión de R.
  La sintaxis de macros como @chain, @group_by y @summarize se parece al tidyverse de R.

• No termino de entender la queja del autor.
  Que Python no está optimizado para ciencia de datos es algo totalmente esperable.
  Python no es un DSL, y hasta MATLAB, aunque fue diseñado para cálculo científico, no es precisamente un lenguaje popular.
  Un buen lenguaje se parece más a una ciudad buena para vivir que a un clima perfecto.
  Python es como “una ciudad nórdica próspera con mal clima”.
  Me parece que el tema del artículo es algo hecho para generar clics, así que no lleva a una discusión muy productiva.

• Ojalá Julia se usara más.
  Hace tiempo reimplementé en Julia un algoritmo para un artículo de psicometría, y corría tres veces más rápido que en MATLAB.
  Enlace al artículo relacionado

  • Me pregunto qué tan importante fue ese ahorro de 40 minutos dentro del calendario total de redacción del paper.

• El último ejemplo parece más una sátira anti-Python que código Python realista.
  Implementar la desviación estándar a mano es cosa de tarea universitaria.
  En la práctica, tanto R como Python ejecutan este tipo de bucles por dentro.

  • Entiendo que el texto se centre en un contexto de laboratorio de investigación.
    Pero en un entorno industrial real, Python es mucho más fácil para colaborar con equipos de ingeniería.
    He desplegado código R a producción y fue muy inestable.
    R es excelente para análisis exploratorio (EDA), pero no sirve para desarrollo de software a gran escala.