Python en ciencia de datos: por qué ganó y por qué eso no lo vuelve…

Existe una narrativa cómoda sobre el dominio de Python en ciencia de datos: ganó porque es el mejor. La sintaxis legible, la curva de aprendizaje suave, la versatilidad como lenguaje de propósito general y la riqueza de bibliotecas científicas se enumeran como evidencia de superioridad. La conclusión teleológica sigue: Python ganó, por lo tanto debe ser superior, por lo tanto fue elección racional. Esta lectura tiene un problema: confunde resultado con causa. Python ocupa hoy la posición que ocupa por un encadenamiento de decisiones acumulativas durante quince años, varias de ellas con poco contenido sustantivamente técnico. R sigue siendo, para análisis estadístico tradicional, la herramienta más limpia ergonómicamente. Julia es, para cómputo numérico intensivo, varias veces más rápida en benchmarks reproducibles. Que Python supere a ambos en adopción no demuestra que los supere técnicamente; demuestra que la adopción se decide en otros niveles.

El argumento de este texto es que la elección de lenguaje para data science raramente es una decisión técnica pura, y reconocerlo cambia las preguntas que conviene hacerse. La pregunta útil al iniciar un proyecto no es "¿cuál lenguaje es mejor?", sino "¿dónde va a vivir este código en doce meses, qué talento voy a contratar y qué pipelines de producción voy a integrar?". Las respuestas a esas preguntas suelen llevar a Python no por sus virtudes intrínsecas sino por sus externalidades de red.

Lo que se atribuye a Python y suele ser otra cosa

"Python tiene la sintaxis más legible." Es afirmación de gusto, no técnica. La sintaxis de R en su dialecto tidyverse, con el operador %>% de magrittr (o el nativo |> desde 4.1), produce pipelines analíticos que muchos analistas encuentran más naturales que el equivalente Python con pandas en encadenamiento. Julia tiene multiple dispatch que permite construir APIs polimórficas sin la complejidad de OOP tradicional. La preferencia entre las tres es subjetiva y altamente dependiente del contexto previo del usuario.

"Python es más rápido para iterar." Iterar significa cosas distintas en cada lenguaje. R está diseñado para iteración interactiva sobre datos: el REPL, RStudio, knitr y la cultura de la consola hacen que un análisis exploratorio en R sea típicamente más rápido que el equivalente Python en Jupyter. Lo que Python ofrece en velocidad de iteración es continuidad: el mismo lenguaje sirve para el notebook, para el script, para la API y para el deployment. Esa continuidad no es velocidad de iteración, es ahorro de cambio de lenguaje, que es otra dimensión.

"Python tiene las mejores bibliotecas de ML." Más precisamente: Python tiene PyTorch y TensorFlow, las dos bibliotecas que definieron el deep learning moderno. Esa es la afirmación correcta. Pero esa concentración no es propiedad emergente de Python como lenguaje; es resultado de que Google publicó TensorFlow en Python en 2015 y Facebook publicó PyTorch en Python en 2016. La biblioteca eligió el lenguaje, no al revés. Si las dos hubieran salido inicialmente en Julia, la conversación sobre "el mejor lenguaje para ML" sería distinta.

"Python escala mejor a producción." Python interpretado es notoriamente lento para cargas computacionales puras. Lo que escala a producción son las extensiones C/C++/Rust escritas alrededor (NumPy, Pandas, Polars, scikit-learn, las bibliotecas de DL con backend nativo). Python actúa como capa de orquestación de código no-Python. Argumentar la escalabilidad como propiedad de Python es atribuir al envoltorio el mérito del relleno.

Donde Python efectivamente gana, y no es por sintaxis

Hay diferencias reales y consistentes que sí explican el dominio, pero su naturaleza es de ecosistema y mercado, no de calidad técnica intrínseca:

Continuidad entre notebook y producción. El mismo lenguaje sirve para explorar datos, definir el modelo, exportar el modelo a un servicio web (FastAPI, Flask, Django), automatizar pipelines (Airflow, Prefect, Dagster) y desplegar en infraestructura (Docker, Kubernetes). Esta continuidad reduce la fricción organizacional. Un equipo que entrega análisis en R debe traducir el modelo a otro lenguaje para producción, lo que introduce capas de mantenimiento. Python evita esa traducción.

Disponibilidad de talento. El Stack Overflow Developer Survey ha mostrado a Python como uno de los tres lenguajes más populares de manera sostenida desde 2018, con cuotas crecientes en la categoría científica/datos. La cantidad absoluta de developers que pueden contratarse, la disponibilidad de cursos y bootcamps que enseñan Python como primera opción, y la suposición laboral de que cualquier data scientist sabrá Python, generan un piso de talento que ningún otro lenguaje del segmento alcanza. Para una organización contratando, esto es variable de primer orden.

Integración con el resto del stack tecnológico. Python conversa nativamente con cualquier base de datos, cualquier servicio cloud, cualquier sistema de mensajería, cualquier framework web. R lo hace, pero con menos profundidad y con bibliotecas que suelen ser actualizadas con menor velocidad. Julia lo hace, pero con un ecosistema una décima parte del tamaño. Para construir un sistema de datos end-to-end —no solo modelos— Python tiene piezas listas mientras los otros requieren ensamblaje.

Bibliotecas de deep learning. PyTorch y TensorFlow viven en Python, y Hugging Face construyó sobre PyTorch el hub de modelos preentrenados que define el flujo de trabajo moderno en NLP, visión y multimodal. La inercia de este ecosistema es prácticamente irreversible en el horizonte de tres a cinco años: cualquier lenguaje que quisiera competir tendría que reproducir o interoperar con ese hub.

Ninguno de estos cuatro puntos es "Python es mejor sintácticamente que R o Julia". Los cuatro son externalidades del ecosistema acumulado durante quince años. La pregunta que conviene hacerse no es si Python es superior técnicamente —no lo es de modo evidente—, sino si las externalidades favorecen el caso particular del proyecto.

Donde R sigue siendo la herramienta correcta

Hay nichos donde R no es solo defendible sino preferible, y conviene reconocerlos antes de imponer Python por inercia:

• Estadística inferencial clásica. Modelos lineales mixtos, análisis de supervivencia, series temporales con metodología Box-Jenkins, tests bayesianos con paquetes específicos del dominio. La cobertura de R en estadística académica es superior a la de Python por antigüedad y por la cultura de los autores: muchos métodos estadísticos publicados en revistas vienen acompañados de paquete R nativo escrito por el mismo investigador. La traducción a Python suele ser parcial y posterior.
• Análisis interactivo de datos por equipos no programadores. Analistas con formación en estadística pero no en software encuentran R más limpio para exploración. RStudio como IDE produce un flujo que Jupyter, pese a sus virtudes, no replica con la misma fluidez para ese perfil.
• Reportes reproducibles con tipografía cuidada. R Markdown y Quarto producen documentos científicos integrando código, resultados, gráficos y narrativa con un acabado tipográfico que requiere considerablemente más esfuerzo en Python.
• Visualización con sintaxis declarativa. ggplot2 y su gramática de gráficos siguen siendo, para un sector de usuarios, más expresivos que cualquier alternativa Python. plotnine intenta reproducirlo en Python, pero la implementación nativa en R sigue siendo más completa.
• Investigación académica en ciencias sociales y biomédicas. Comunidades enteras (epidemiología, biostatistics, econometría académica) operan principalmente en R por razones de tradición y porque los paquetes de su dominio son R-first. Forzar Python en esos contextos es perder herramientas específicas a cambio de homogeneidad organizacional.

El argumento operativo: si el output principal del trabajo son análisis estadísticos y reportes, no servicios de producción, R puede ser elección defensible o superior. La narrativa "todo el mundo usa Python" es marketing del momentum, no diagnóstico del caso.

Julia: la promesa pendiente

Julia se diseñó alrededor de 2012 con el objetivo explícito de resolver el "problema de los dos lenguajes": el patrón donde se prototipa en Python o R y se reescribe en C++ o Fortran para producción. La propuesta es ofrecer un lenguaje dinámico con compilación JIT que alcanza performance comparable a C en cargas numéricas. Los benchmarks reproducibles publicados desde 2015 muestran que en cómputo intensivo Julia es habitualmente 10x a 100x más rápida que Python interpretado, y comparable a C++ optimizado.

La adopción de Julia, sin embargo, ha sido modesta. La razón no es que la promesa técnica sea falsa: lo es, en buena medida. La razón es que la promesa técnica resuelve un problema que la mayoría de los usuarios de data science no tiene. Cuando el cuello de botella son IO, queries a base de datos, llamadas a APIs y manipulación de DataFrames de tamaño moderado, la diferencia de performance del lenguaje base es marginal frente a la diferencia entre tener PyTorch o no tenerlo, entre poder contratar developers o no poder, entre integrarse con el stack existente o no.

Julia ocupa hoy nichos específicos: investigación numérica avanzada, cómputo científico de alto rendimiento, simulaciones, cierto sector financiero quant. En esos contextos su elección es defendible y a veces superior. Como reemplazo de Python en data science empresarial general, no ha logrado tracción y los datos de adopción sugieren que no la logrará en el horizonte previsible.

La pregunta práctica al iniciar un proyecto

Reformulada según el análisis anterior, la decisión de lenguaje para un proyecto de data science se reduce a un pequeño número de preguntas:

Pregunta diagnóstica	Si la respuesta es...	El lenguaje plausible es...
¿El output va a desplegarse como servicio en producción?	Sí	Python (continuidad notebook?producción)
¿El output principal son reportes estadísticos para audiencia académica o regulatoria?	Sí	R (calidad de paquetes estadísticos y reportes)
¿Hay cómputo numérico intensivo y custom donde la performance del lenguaje base es cuello de botella?	Sí	Julia (o Python con C++ extension)
¿El equipo que va a operar el sistema durante años tiene experiencia previa en uno de los tres?	Sí	Ese, salvo razón fuerte en contra
¿El proyecto requiere integración con deep learning preentrenado (Hugging Face, modelos foundation)?	Sí	Python (el ecosistema vive ahí)
¿La organización contratará talento adicional durante el proyecto?	Sí	Python (mayor pool disponible)
¿El proyecto es académico, exploratorio, sin requisitos de producción?	Sí	El que el equipo prefiera; los tres son defensables

Notar que ninguna de estas preguntas se resuelve por "qué lenguaje es mejor". Se resuelven por contexto: dónde vive el proyecto, qué talento tienes, qué integración requieres. Python suele ganar la mayoría de los casos no porque sea técnicamente superior sino porque el contexto típico de data science empresarial lo favorece. En contextos atípicos —análisis estadístico puro, cómputo numérico intensivo, investigación académica— las preguntas correctas llevan a otros lenguajes.

El costo de ignorar el matiz

La consecuencia práctica de tratar "Python es el mejor" como verdad establecida y no como estado del ecosistema con causas externas, es operativa: equipos que adoptan Python por inercia para casos donde R o Julia serían más eficientes terminan reescribiendo análisis estadísticos elementales que R resuelve en una línea, o luchando contra performance que Julia entrega gratis. Y a la inversa: equipos que se aferran a R cuando el output debe ir a producción terminan inventando sistemas de bridge brittle que pierden información en cada traducción.

La narrativa "el mejor lenguaje" oculta este matiz. Trata como pregunta universal lo que es pregunta contextual. La forma adulta de responderla no es defender un campeón sino describir la decisión por sus dimensiones reales: producción, talento, integración, performance, dominio del problema. Cuando la decisión se examina así, Python suele ganar pero por razones distintas a las que la narrativa popular cita, y a veces no gana, lo que también es información útil.

El análisis se basa en Stack Overflow Developer Survey 2018-2025, TIOBE Index, IEEE Spectrum Top Programming Languages, documentación oficial de PyTorch, TensorFlow, Hugging Face, R Project y Julia Language, benchmarks publicados por Julia Computing y benchmarks reproducibles de la comunidad (Julia Microbenchmarks, R-bloggers comparatives). Publicado por MOX Networks; la firma desarrolla soluciones que combinan los tres lenguajes según el caso del cliente, sin partnership comercial preferente con ninguno.