R est-il "si mauvais" qu'il devrait être réécrit à partir de zéro ?

Question

La semaine dernière, j'ai suivi une discussion dans laquelle Ross Ihaka a écrit :

Je m'inquiète depuis un certain temps que R ne va pas fournir la base dont nous allons avoir besoin pour les calculs statistiques statistiques à l'avenir. (Il se peut bien que le futur soit déjà sur nous). Il y a certainement problèmes d'efficacité (vitesse et utilisation de la mémoire), mais il y a des problèmes plus fondamentaux fondamentaux. Certains d'entre eux ont été hérités de S et d'autres sont propres à R. à R.

Il a ensuite continué à expliquer. Cette discussion a commencé par Og de Xi'an et a ensuite été suivi par des commentaires à reddit , statalgo , DecisionStats , columbia.edu , Hacker News , Liste de diffusion r-help et peut-être d'autres endroits.

N'étant pas informaticien, j'essaie de comprendre ce qu'il faut en penser.

• R est-il si défectueux qu'il vaut mieux le réécrire que le réparer ? En cherchant sur stackoverflow, je suis tombé sur Quand réécrire un code de base à partir de zéro ? y Dans quelle situation faut-il réécrire le code à partir de zéro ? (basé sur l'article de Joel Les choses que vous ne devriez jamais faire ), les deux fils de discussion soutiennent qu'un cas très( !) extrême est nécessaire pour justifier une réécriture du code. Mais est-ce le cas avec R ?
  • R peut-il être modifié de manière à résoudre ces problèmes et devenir "le langage statistique du futur" ?
  • Qu'en est-il de l'aspect social de la chose ? R dispose déjà d'une large base d'utilisateurs. Si R devait "mourir", est-il possible d'imaginer que tous les utilisateurs soient prêts à passer à un nouveau langage ?

Je pense que cette question n'est pas subjective, mais comme elle comporte tant d'incertitudes, j'ai décidé de la marquer comme un wiki communautaire.

Answer 1

Je pense que certaines personnes bien informées sont plutôt injustes envers R. Pour commencer, R a commencé comme une version modifiée et libre de S et il s'agit avant tout d'un logiciel de statistiques. Je n'entends personne se plaindre de l'affreux SAS y SPSS et la lenteur avec laquelle ils effectuent certains de leurs calculs. Pour ce à quoi il est le plus souvent utilisé, c'est-à-dire l'analyse statistique, R est sans aucun doute la meilleure chose qui soit.

Deuxièmement, bien que R ne soit pas le langage de programmation le plus optimal, il est assez puissant. si vous savez comment l'utiliser . La vectorisation de R est tout simplement la meilleure fonctionnalité qui soit. En ce qui me concerne, je me sers de for boucle trois fois par an et une application deux fois par semaine. Tout le reste est constitué de calculs vectoriels. Mais dans les benchmarks, cette caractéristique de R est souvent ignorée (par ex. aquí ), ce qui a conduit à l'accusation - à mes yeux erronée - de lenteur de R. Ce n'est pas le plus rapide, mais si vous savez ce que vous faites, vous pouvez toujours faire une belle course.

Troisièmement, R est avant tout un langage de script, qui me permet d'essayer différentes analyses à la volée. Cela est impossible en C++, Fortran, Ruby, Python, Perl ou toute autre "alternative plus rapide". Ce ne sont pas des alternatives, c'est aussi simple que cela. Ils sont supérieurs pour un certain nombre de tâches, mais pas pour une analyse statistique efficace. J'ai besoin de la ligne de commande R pour cela.

Oui, j'apprécierais que les bizarreries de R disparaissent. Oui, il serait merveilleux d'avoir un peu plus de puissance de programmation dans R qui nous permette d'utiliser R encore plus comme un langage de programmation également. Une réécriture complète, compatible avec l'ancien code, avec un gain de vitesse d'un ordre de grandeur, des codes plus propres, etc.

Mais tant que quelqu'un ne voudra pas faire tout cet effort gratuitement, je resterai avec R.

---

Comme certaines personnes l'ont fait remarquer - à juste titre -, Python dispose également d'une ligne de commande. Cependant, cette ligne de commande n'est PAS orientée vers l'analyse statistique, et même avec la fonction SciPy et stat.py installés, IPython /DreamPie/tout autre ligne de commande que vous avez ne se rapproche même pas de R en termes de facilité d'utilisation, d'exhaustivité et de disponibilité des techniques.

R est bien trop souvent confondu avec un autre langage de programmation. Ce n'est pas le cas. Il s'agit d'un progiciel statistique qui permet également la programmation à part entière. Python est un langage de script qui possède également des bibliothèques pour les statistiques. Il y a tout un monde de différence entre ces deux-là.

Answer 2

Certaines des accusations qui ont été portées contre R au fil des ans sont les suivantes :

1. C'est lent.

2. Il ne joue pas bien avec très grand ensembles de données.

Pour beaucoup de gens, le temps d'écriture du code est un facteur beaucoup plus important que le temps d'exécution, donc 1 n'est pas un gros problème. De même, la valeur de très grand a augmenté avec la rapidité des ordinateurs, à tel point qu'il n'est plus un problème pour de nombreux chercheurs.

Ce dont Ross Ihaka parle, c'est d'un langage permettant de traiter des problèmes tels que "analyser ce génome" ou "trouver des tendances dans le graphe social de Facebook", pour lesquels R ne peut pas facilement s'adapter. Un tel langage pourrait être un langage de niche pour le traitement des grandes données, ou pourrait avoir un usage plus répandu ; il est bien trop tôt pour le dire.

Il faut garder à l'esprit que Ross Ihaka aime vraisemblablement créer de nouveaux langages (il l'a déjà fait, à tout le moins), et qu'il est donc naturel qu'il veuille s'y essayer à nouveau. Deuxièmement, il pourrait écrire quelque chose qui jouerait bien avec le code R, de sorte que le travail sur CRAN ne serait pas gaspillé. Enfin, tout nouveau langage ne sera pas utilisé pendant une bonne décennie, et les rumeurs de mort de R sont donc largement exagérées.

EDIT : Pour répondre à la question "est-il préférable de corriger les bogues ou de réécrire à partir de zéro ?", je ne vois pas pourquoi il faut choisir l'un ou l'autre. A court terme, il y a de nombreuses améliorations qui peuvent être et seront apportées à R. A plus long terme, de nouveaux langages seront inévitablement créés, et viendront compléter ou remplacer ceux existants. Une étape intermédiaire qui n'a pas vraiment été discutée pour R est un équivalent de Python 3 : Un remaniement du langage qui abandonne la compatibilité au profit de la suppression de certains défauts.

Answer 3

table.de.données contribue grandement à rendre R efficace, par rapport aux performances de regroupement et de consultation des cadres de données classiques. Les problèmes de syntaxe sont moins problématiques, car vous pouvez simplement les contourner. Toute réécriture de R devrait être sous la forme d'un dérivé de Python 3 non compatible avec les backwords mais très proche, sinon il ne sera tout simplement pas adopté.

Answer 4

Il me semble qu'un petit effort d'optimisation de R pour la vitesse serait bien plus efficace que d'essayer de réécrire à partir de zéro. Les efforts de Radford Neal ainsi que le commercial Révolution R semblent tous deux avoir montré qu'avec une quantité raisonnable de travail, des gains de vitesse assez importants peuvent être obtenus. Rcpp vous permet d'écrire assez facilement des fonctions personnalisées pour qu'elles soient très rapides grâce à des liens avec C++ (et Julia peut servir ce rôle un jour). Et le data.table fournit une structure de données indexée par référence (par opposition à la copie).

Et le gputools paquet et les extensions parallèles alimentent l'observation de @RichieCotton selon laquelle le matériel devient simplement plus rapide en multipliant tout gain matériel par X processeurs/cores.

Je pense donc qu'à moins que vous ne tiriez déjà parti de tous ces outils et optimisations, et que vous ne trouviez toujours pas R satisfaisant, parler d'une réécriture est extrêmement prématuré. La plupart des gens que je connais n'ont même pas de bibliothèques optimisées installées.

Enfin, je pense que le problème de la vitesse est exagéré d'un ordre de grandeur ou deux. Les exemples donnés sont tout simplement trop affreux pour être crus, et sont sujets à des améliorations faciles qui produisent des gains de vitesse massifs .

Answer 5

Il est évident que ce n'est que ma compréhension de la situation, mais je n'ai pas lu les propos de Ross Ihaka comme "R est cassé et doit être jeté", mais comme "certains des travaux de statistiques du futur ne sont pas vraiment adaptés à R, et nous pourrions avoir besoin d'une autre solution", ce à quoi il a probablement raison.

R a commencé en tant qu'outil d'enseignement, puis s'est développé de manière organique, reprenant son lien avec le S et la base d'utilisateurs, l'équipe R-Core et CRAN, et franchement, R est incroyable dans ce qu'il fait (si vous n'avez pas deviné, je amour R), mais elle ne peut pas tout faire, et c'est ce que dit Ross, mais je pense qu'elle va continuer à se développer et à s'étendre à de nouveaux domaines, mais elle ne peut pas tout faire.

Ainsi, à l'avenir, il se peut qu'un nouveau langage (peut-être 'Q' ?) soit mieux adapté à ces types de problèmes (comme les ensembles de données massifs, les problèmes en temps réel, etc.) et qu'il soit lié à R pour faciliter l'apprentissage des personnes susceptibles d'utiliser les deux, mais il ne tuera pas R.

Donc, pour répondre à la question originale ; Non, R n'est pas si cassé qu'il faille le réécrire, mais il y a des tâches pour lesquelles nous avons besoin d'un nouveau langage, Oui, R peut être patché pour corriger les limitations existantes, ou pour s'étendre à de nouveaux domaines, et non, R ne mourra pas, il pourrait juste avoir de nouveaux amis...