Python n’est pas un langage adapté à la data science

• Pour les tâches de données hors deep learning comme l’analyse, la visualisation ou le résumé, Python offre des fonctionnalités suffisantes, mais l’expérience d’usage devient facilement complexe et inefficace
• Dans de nombreux cas observés en laboratoire, il a été constaté à plusieurs reprises que Python demande plus de code et plus de temps que R, même pour de simples transformations de graphiques ou calculs statistiques
• Même avec pandas, matplotlib ou NumPy, la syntaxe, l’indexation, les parenthèses et la structure en chaînage de méthodes font souvent perdre de vue la logique au profit des détails d’implémentation (logistics)
• À l’inverse, le tidyverse de R permet d’exprimer le flux de traitement des données presque au niveau du langage naturel, ce qui facilite la transcription directe de la logique de travail en code
• En tant que langage de data science, Python présente des limites structurelles dans la séparation entre logique et logistics, un problème qui découle de la conception du langage et de son écosystème

---

Comparaison de l’expérience d’usage réelle entre Python et R

• Les membres du laboratoire sont libres de choisir leur langage, mais beaucoup utilisent Python, et un même schéma revient régulièrement : ils peinent à traiter rapidement de simples demandes d’analyse complémentaire
  • Des changements de visualisation comme boxplot → violin plot, histogramme → courbe de densité, ou courbe linéaire → heatmap ne se font pas facilement sur-le-champ
  • Dans R, ce sont des tâches qui se règlent en quelques lignes ; dans Python, elles donnent l’impression de devoir « retourner à son bureau pour tout recoder »
• Même lors de cours coanimés avec des spécialistes Python, l’écart avec R en longueur et en complexité du code nécessaire devient évident
  • La réaction « Pourquoi faut-il que ce soit aussi complexe ? » revient dans de nombreuses situations, ce qui semble relever non d’un manque de compétence individuelle, mais de différences structurelles dans l’architecture du langage et des bibliothèques
  • À logique identique, Python exige souvent indexation, séparation des données, réassemblage et combinaison de plusieurs méthodes, ce qui allonge fortement la structure
  • Le tidyverse de R permet au contraire une expression directe avec des chaînes naturelles comme filter → group_by → summarize

Pourquoi Python est largement utilisé, et quelles en sont les limites

• Le statut de Python en data science repose moins sur une adéquation intrinsèque que sur sa diffusion historique, sa polyvalence et la taille de son écosystème
  • Dans le deep learning, Python est clairement au centre grâce à PyTorch et à l’écosystème IA
  • Mais pour le nettoyage, l’exploration, la visualisation et la modélisation statistique des données, les frictions restent nombreuses
• Sa popularité relève presque d’un accident historique, et la lourdeur de sa structure de langage par rapport à R réapparaît de façon répétée à travers divers exemples

Les conditions d’un bon langage pour la data science

• Pour les tâches centrées sur l’exploration, le résumé, l’ajustement de modèles et la visualisation, un environnement interactif, un faible coût de configuration et une itération rapide sont les critères les plus importants
  • Un langage interprété de script est plus adapté qu’un langage compilé
  • La priorité n’est pas la performance, mais la simplicité du code, la réduction du risque d’erreur et la minimisation de la charge cognitive
  • Si nécessaire, il suffit de réécrire non pas l’ensemble, mais seulement certaines opérations en langage haute performance, comme Rust
• En pratique, les langages réellement envisageables sont R et Python
  • Matlab, Mathematica, etc. sont commerciaux ou disposent d’un écosystème limité
  • Julia est souvent cité, mais l’auteur préfère suspendre son jugement faute d’expérience suffisante

Le problème « logique vs logistics »

• Un langage d’analyse de données doit séparer ce qu’il faut calculer (la logique) de la manière de le calculer (les logistics)
  • S’il faut se préoccuper des types de données, des index, des boucles ou de l’assemblage manuel, c’est qu’on est déjà prisonnier des logistics
• Dans l’exemple Palmer Penguins, le tidyverse de R exprime le calcul des moyennes et écarts-types avec un flux proche du langage naturel
  • Il n’est pas nécessaire de déconstruire puis de réassembler le flux de données
• pandas fournit des fonctions similaires, mais les désignations sous forme de chaînes, les parenthèses, le chaînage de méthodes, reset_index et d’autres opérations annexes nuisent à la lisibilité et à la simplicité
• Si l’on implémente le même travail en Python pur
  • construction des boucles → création des clés de groupe → découpage → calcul de la moyenne → calcul de la variance → calcul de l’écart-type → réassemblage → tri
  • tout doit être géré à la main, ce qui constitue un cas typique où le code de logistics écrase la logique elle-même

Conclusion et annonce de la suite

• En analyse de données, Python révèle de façon répétée un problème structurel qui pousse à se concentrer davantage sur les détails d’implémentation que sur la logique
  • Cela semble être le résultat combiné des caractéristiques propres du langage, des limites de conception de ses bibliothèques et des pratiques de tout l’écosystème
• Un article suivant abordera les causes techniques concrètes qui rendent l’analyse de données plus difficile avec Python qu’avec R

Angles de discussion et de comparaison supplémentaires (y compris les retours de lecteurs)

• Certains estiment que le tidyverse peut être plus verbeux que le R de base, mais reste puissant du point de vue de l’expressivité, de la cohérence et de l’abstraction du traitement des données
• À l’inverse, d’autres soulignent que R est très peu pratique sur les aspects de développement logiciel comme la modularisation, les tests ou l’implémentation d’une CLI
• Python offre une excellente expérience développeur pour le logging, les environnements virtuels, le packaging ou la structure en classes, mais
  • matplotlib est souvent jugé peu intuitif dans sa conception,
  • pandas a la réputation d’une syntaxe incohérente,
  • scikit-learn fait régulièrement l’objet de critiques sur certains choix de conception
• Certains avis vont jusqu’à considérer Python comme un « langage permettant de produire rapidement en masse du code instable et de faible qualité », et avancent que, pour un développement durable, les langages à typage statique sont préférables

[kaydash]

Si la complexité et le volume des données augmentent au point de nécessiter un traitement fractionné par étapes, ainsi qu’un traitement via des données non structurées, des modèles structurés et même des LLM, alors vu la diversité des use cases, n’est-ce pas justement le langage le plus adapté ?

[GN⁺]

Avis Hacker News

• L’auteur a donné plusieurs exemples de transformation, comme remplacer un boxplot par un violin plot, ou un line plot par une heatmap
  mais cette discussion concerne en réalité davantage matplotlib que Python
  si l’on veut le design de ggplot en Python, il suffit d’utiliser plotnine
  si le code R paraît plus concis, c’est grâce à l’évaluation non standard (non-standard evaluation) de R
  Python n’autorise pas ce type d’extension au niveau du langage
  voir aussi Computing on the language

  • Au fond, c’est surtout une discussion sur les différences entre Python et R
    l’évaluation non standard est pratique dans un environnement interactif, mais devient plutôt un désavantage quand on écrit du code d’analyse complexe
    on finit parfois par devoir contourner même des tâches simples
  • En R, voir un pipe placé en fin de ligne est peu agréable
    je trouve préférable d’avoir l’opérateur pipe en préfixe, comme en Elixir
    Python peut imiter une syntaxe proche avec des astuces comme getattr, mais au final c’est davantage un problème de conception d’API de bibliothèque que de langage
  • « Et si on devait faire du travail logistique en R sans bibliothèque ? » Rien que l’idée est horrible
    R n’est facile que lorsqu’il y a des bibliothèques et des recettes prêtes à l’emploi ; sinon c’est vraiment difficile, et la plupart du temps on ne le fait tout simplement pas
  • Pour ce genre d’usage, seaborn est plus adapté
    il abstrait les aspects pénibles de matplotlib tout en offrant beaucoup de possibilités
    Tutoriel Seaborn
  • Au final, le point central ne semble pas être Python, mais plutôt ce que R peut faire et que Python ne peut pas faire

• Je me demande pourquoi, dans les langages de programmation, les tables ne sont pas des objets de première classe
  dans la plupart des langages, il faut apprendre une API séparée comme pandas ou polars pour manipuler des tables
  en R, data.frame s’en rapproche, mais en pratique on utilise plus souvent le tibble de dplyr
  il n’existe toujours pas de langage d’expression standardisé pour manipuler les données tabulaires
  Polars et dplyr partagent une philosophie similaire, mais au final SQL semble être la seule base commune
  Python n’est pas parfait sur ce point, mais R ne l’est pas davantage à mon avis

  • J’ai l’impression qu’il manque beaucoup de structures au niveau du langage
    des structures comme les tables, matrices, graphes et machines à états ne sont pas prises en charge au niveau du langage, ce qui limite leur usage
    les outils fournis par défaut définissent en grande partie la « voie élégante » d’un langage
    autrefois, même les key-value stores relevaient de bibliothèques externes, alors qu’aujourd’hui c’est presque standard
  • Des langages comme Q, Rye ou Lil traitent les tables comme un véritable type de donnée de première classe
    je pense qu’un jour les langages grand public absorberont eux aussi cette forme de programmation orientée table
    Langage Q, comparatif avec Rye, outil expérimental Lil
  • tibble et data.table héritent de data.frame, donc les fonctions de base de R continuent de fonctionner telles quelles
    les conversions entre les trois objets sont aussi très simples
  • Quand une table passe de 1 million à 1 milliard, puis à 1 trillion de lignes, la nature du problème change complètement
    concevoir une API standard capable de gérer élégamment de tels écarts d’échelle n’est pas simple
  • Le data.table de R est excellent
    mais dplyr a gagné sur la documentation et l’onboarding, ce qui lui a assuré l’adoption dans l’industrie

• Le fond de l’article est correct, mais c’est dommage que l’auteur ait révélé trop vite ses arguments
  R est fort pour le traitement de dataframes, mais faible pour la gestion de fichiers et la maintenance
  quand on fait beaucoup de ce genre de tâches, Python est meilleur ; et si la performance compte aussi, on se tourne plus volontiers vers Julia
  le choix du langage dépend donc des priorités
  je vois souvent des étudiants essayer de résoudre avec pandas des problèmes non tabulaires, comme les graphes ; dans ce cas, il faut sans doute repenser le choix de l’outil

  • L’exemple de code Python est mal choisi
    avec numpy, le calcul de la moyenne et de la variance est déjà intégré
    Python et R ont une difficulté d’apprentissage comparable, mais Python a pour avantage son intégration avec d’autres applications
  • La deuxième partie de l’article est disponible ici
  • J’utilise moi aussi Python et R à parts égales
    Python est efficace pour traiter de gros fichiers, tandis que R l’est davantage pour analyser des données agrégées
    chaque langage doit être utilisé comme l’outil adapté au bon contexte

• En tant que programmeur Python, j’ai aussi utilisé R, et Python est un langage qui « fait à peu près tout assez bien, sans être parfait »
  si l’on passe ses journées à faire de l’analyse de données, il vaut mieux apprendre R
  R est un langage conçu selon la manière de penser des statisticiens
  cela paraît déroutant au début, mais ce changement de perspective peut au contraire être utile
  malgré cela, je travaille la plupart du temps en Python

• Faire de la data science avec pandas est possible, mais j’ai trouvé cela lourd et complexe
  polars améliore un peu les choses, mais duckdb a complètement changé la donne
  on peut exécuter directement des requêtes SQL dans un notebook et analyser des fichiers parquet
  mélanger des cellules SQL et des cellules Python rend le code plus propre
  en voyant la comparaison finale entre Python et R dans l’article, je me suis dit : « Est-ce que ce ne serait pas bien mieux écrit en SQL ? »

  • Moi, je préfère une approche centrée sur le dataframe, en restant dans le langage
  • J’utilise souvent polars, mais il faudrait que j’essaie duckdb un jour

• Le dernier exemple Python est inutilement verbeux
  avec defaultdict et statistics.stddev, on peut écrire quelque chose de bien plus concis

  • C’est intéressant d’avoir ajouté manuellement la correction de Bessel
    beaucoup l’implémentent sans se demander si elle est pertinente
    en réalité, il faudrait appeler cela sample_std_dev pour être exact
  • On peut aussi utiliser itertools.groupby
    le code n’est pas forcément plus court, mais il exprime plus clairement l’intention
  • Le code d’origine est plus lisible
    vouloir raccourcir à tout prix au détriment de la lisibilité n’est pas une bonne idée

• J’ai réimplémenté le même exemple avec TidierData.jl de Julia, et le résultat est presque identique à la version R
  la syntaxe par macros comme @chain, @group_by et @summarize ressemble beaucoup au tidyverse de R

• Je ne comprends pas très bien la frustration de l’auteur
  le fait que Python ne soit pas optimisé pour la data science est une évidence
  Python n’est pas un DSL, et même MATLAB, pourtant conçu pour le calcul scientifique, n’est pas un langage populaire
  un bon langage ressemble moins à une météo parfaite qu’à une ville agréable à vivre
  Python, c’est un peu « une ville prospère d’Europe du Nord au mauvais climat »
  le sujet de l’article est un peu racoleur, donc je ne trouve pas que cela mène à une discussion très productive

• J’aimerais que Julia soit davantage utilisé
  j’ai autrefois réimplémenté en Julia un algorithme destiné à un article de psychométrie, et il s’exécutait trois fois plus vite qu’en MATLAB
  Lien vers l’article

  • Je me demande dans quelle mesure ces 40 minutes de temps d’exécution gagnées ont réellement compté dans le calendrier global de rédaction de l’article

• Le dernier exemple ressemble moins à du code Python réaliste qu’à une caricature anti-Python
  implémenter soi-même l’écart-type, c’est du niveau d’un devoir de licence
  en pratique, R comme Python exécutent tous deux ce genre de boucles en interne

  • Je comprends que l’article se concentre sur un contexte de recherche
    mais dans un environnement industriel réel, Python facilite bien davantage la collaboration avec les équipes d’ingénierie
    j’ai déjà déployé du code R en production, et c’était très instable
    R est excellent pour l’analyse exploratoire (EDA), mais inadapté au développement logiciel à grande échelle