Julia a-t-elle un espoir de rester dans la communauté statistique?

J'ai récemment lu un article de R-Bloggers, qui est lié à ce billet de John Myles White sur un nouveau langage appelé Julia . Julia profite d'un compilateur juste à temps qui lui donne des temps d'exécution rapides et le met dans le même ordre de grandeur que C / C ++ (le même ordre , pas aussi rapide). En outre, il utilise les mécanismes de boucle orthodoxes que connaissent ceux d'entre nous qui ont commencé à programmer sur des langages traditionnels, au lieu des instructions apply de R et des opérations vectorielles.

R ne s'en va pas du tout, même avec des timings aussi impressionnants de Julia. Il bénéficie d'un support étendu dans l'industrie et de nombreux packages fantastiques pour faire à peu près n'importe quoi.

Mes intérêts sont de nature bayésienne, où la vectorisation est souvent impossible. Certes, les tâches en série doivent être effectuées à l'aide de boucles et impliquent des calculs lourds à chaque itération. R peut être très lent lors de ces tâches de bouclage série, et C / ++ n’est pas une promenade dans le parc à écrire. Julia semble être une excellente alternative à l’écriture en C / ++, mais elle en est à ses balbutiements et elle manque de beaucoup de fonctionnalités que j’aime de R. Il n’a de sens que d’apprendre Julia en tant qu’atelier de statistiques informatiques s’il reçoit suffisamment de soutien. de la communauté des statistiques et les gens commencent à écrire des paquets utiles pour cela.

Mes questions suivent:

1. Quelles caractéristiques doit avoir Julia pour avoir l’attrait qui a fait de R le langage de facto des statistiques?

2. Quels sont les avantages et les inconvénients d’apprendre à Julia à effectuer des tâches lourdes en calcul, par rapport à l’apprentissage d’un langage de bas niveau comme C / ++?

Je pense que la clé sera de savoir si les bibliothèques commencent ou non à être développées pour Julia. C’est bien beau de voir des exemples de jouets (même s’il s’agit de jouets compliqués) montrant que Julia souffle R hors de l’eau lors de la tâche où R est mauvais.

Mais les boucles mal faites et les algorithmes codés à la main ne sont pas la raison pour laquelle beaucoup de ceux que je connais et qui utilisent R utilisent R. Ils l’utilisent parce que, pour presque toute tâche statistique sous le soleil, quelqu'un a écrit le code R pour cela. R est à la fois un langage de programmation et un logiciel de statistiques - à l’heure actuelle, Julia n’est que le premier.

Je pense qu’il est possible d’y arriver, mais il existe beaucoup plus de langages bien établis (Python) qui ont encore du mal à rester des outils statistiques utilisables.

Je suis d'accord avec beaucoup d'autres commentaires. "Espérer"? Sûr. Je pense que Julia a beaucoup appris de ce que R et Python / NumPy / Pandas et d’autres systèmes ont fait bien ou mal au fil des ans. Si j'étais plus intelligent que moi et si je voulais écrire un nouveau langage de programmation qui serait le substrat d'un environnement de développement statistique à l'avenir, cela ressemblerait beaucoup à Julia.

Cela dit, il faudra 5 ans avant que cette question puisse être résolue avec le recul. À l'heure actuelle, Julia ne présente pas les aspects critiques suivants d'un système de programmation statistique capable de concurrencer R pour les utilisateurs quotidiens:

(liste mise à jour au fil du temps ...)

• types de facteurs optionnellement ordonnés
• la plupart des tests statistiques et des modèles statistiques
• Programmation alphabète / support d'analyse reproductible
• Tracé de classe R ou même Matlab

Pour rivaliser avec R, Julia et les progiciels de statistiques complémentaires devront être suffisamment propres et complets pour que les non-programmeurs intelligents, disent les étudiants de deuxième cycle en sciences sociales, puissent raisonnablement l’utiliser. Il y a énormément de travail à faire pour y arriver. Peut-être que ça va arriver, peut-être que ça va pétiller, peut-être quelque chose d'autre (R 3.0?) Va le remplacer.

Mise à jour:

Julia prend désormais en charge les DataFrames avec les données / NA manquantes, les modules / espaces de noms, les formulatypes et l' model.matrixinfrastructure, le traçage (sorta), le support de base de données (mais pas encore pour les DataFrames) et la transmission d'arguments par mots-clés. Il existe également un IDE (Julia Studio), un support Windows, des tests statistiques et un support date / heure.

Pour moi, une chose très importante pour un langage d’analyse de données est d’avoir une fonctionnalité d’algèbre de requête / relationnelle avec des valeurs par défaut raisonnables et une conception orientée de manière interactive. Idéalement, elle devrait être intégrée au langage. OMI, aucun langage FOSS que j'ai utilisé ne le fait efficacement, pas même R.

data.frame est très difficile à utiliser de manière interactive - par exemple, il imprime toute la structure de données lors de son invocation, la syntaxe $ est difficile à travailler par programme, l'interrogation nécessite une auto-référence redondante (c'est-à-dire DF[DF$x < 10]), les jointures et les agrégations sont maladroites. Data.table résout la plupart de ces ennuis, mais comme il ne fait pas partie de la mise en œuvre principale, la plupart du code R n'utilise pas ses installations.

Les pandas en python souffrent des mêmes défauts.

Ces reproches peuvent sembler naïfs, mais ces défauts s’accumulent et sont finalement importants dans l’ensemble, puisqu’ils coûtent beaucoup de temps.

Je crois que si Julia veut réussir en tant qu’environnement d’analyse de données, il faut s’efforcer d’implémenter des opérateurs de type SQL (sans la syntaxe SQL) sur un type de données de table convivial.

Je peux signer ce que Dirk et EpiGrad ont dit; Pourtant, il y a encore une chose qui fait de R une langue unique dans son créneau: le système de types orienté données.

R's a été spécialement conçu pour gérer les données. C'est pourquoi il est centré sur les vecteurs et contient des éléments tels que data.frames, factor, NA et attributs.
Les types de Julia sont quant à eux orientés sur les performances numériques. Nous avons donc des scalaires, des modes de stockage bien définis, des unions et des structures.

Cela peut sembler anodin, mais tout le monde qui a déjà essayé de faire des statistiques avec MATLAB sait que ça fait vraiment mal.

Donc, au moins pour moi, Julia ne peut rien offrir que je ne puisse pas réparer avec un morceau de C de quelques lignes et qui tue beaucoup d'expressivité vraiment utile.

Je peux voir Julia remplacer Matlab, ce qui serait un énorme service pour l'humanité.

Pour remplacer R, vous devez prendre en compte tout ce que Neil G, Harlan et d’autres ont mentionné, ainsi qu’un facteur important dont je ne pense pas qu’il a été tenu compte: l’installation facile de l’application et de ses bibliothèques.

À l'heure actuelle, vous pouvez télécharger un binaire de R pour Mac, Windows ou Linux. Il fonctionne avec une large sélection de méthodes statistiques. Si vous souhaitez télécharger un package, il suffit d’une simple commande ou d’un clic de souris. Ça fonctionne.

Je suis allé télécharger Julia et ce n'est pas simple. Même si vous téléchargez le binaire, vous devez avoir installé gfortran pour obtenir les bonnes bibliothèques. J'ai téléchargé la source et essayé makeet cela a échoué sans message vraiment utile. J'ai un diplôme de premier cycle et un diplôme de deuxième cycle en informatique, afin que je puisse faire le tour et le faire fonctionner si j'étais si enclin. (Je ne suis pas.) Est-ce que Joe Statistician va faire ça?

R possède non seulement un vaste choix de packages, mais également un système assez sophistiqué qui crée automatiquement les fichiers binaires de l'application et de presque tous les packages. Si, pour une raison quelconque, vous avez besoin de compiler un paquet à partir du source, ce n’est pas vraiment plus difficile (tant que vous avez un compilateur approprié, etc., installé sur votre système). Vous ne pouvez pas ignorer cette infrastructure, tout faire via github et vous attendre à une large adoption.

EDIT: Je voulais m'amuser avec Julia - ça a l'air excitant. Deux problèmes:

1) Lorsque j'ai essayé d'installer des paquets supplémentaires (oubliez comment ils s'appellent dans Julia), cela a échoué avec des erreurs obscures. De toute évidence, mon Mac ne dispose pas d'un outil similaire à celui auquel il s'attendait. Non seulement cela échoue, mais il reste des choses que je dois supprimer manuellement ou d'autres installations échoueront.

2) Ils forcent un certain espacement dans une ligne de code. Je n'ai pas les détails sous les yeux, mais c'est dû aux macros et au fait qu'il n'y ait pas d'espace entre la macro et la parenthèse ouvrant ses arguments. Ce type de restriction m'ennuie énormément, car j'ai développé la mise en forme de mon code au fil des ans et des langues et que je mets en fait un espace entre le nom d'une fonction / macro et la parenthèse d'ouverture. Je comprends certaines restrictions de formatage du code, mais des espaces dans une ligne?

La langue de Julia est assez nouvelle; son heure de pointe peut être mesurée en semaines (même si son temps de développement peut bien sûr être mesuré en années). Maintenant, ces semaines en lumière étaient des semaines très excitantes - voir, par exemple, la récente discussion à Stanford où "ça venait juste de commencer" --- se concrétiser.

Je continuerais donc à utiliser R et à prendre en compte les alternatives en développement. L'année dernière, beaucoup de gens ont été gaga contre Clojure; Cette année, Julia est la nouvelle saveur dominante. Nous verrons si ça colle.

Bruce Tate ici, auteur de Sept langues en sept semaines. Voici quelques réflexions. Je travaille sur Julia pour le livre de suivi. Ce qui suit n’est que mon opinion après quelques semaines de jeu.

Deux forces fondamentales sont en jeu. Premièrement, toutes les langues ont une durée de vie. R sera remplacé un jour. Nous ne savons pas quand. Les nouvelles langues ont beaucoup de mal à évoluer. Lorsqu'un nouveau langage évolue, il résout généralement un problème de douleur accablant.

Ces deux choses sont liées. Pour moi, nous commençons à voir un thème prendre forme autour de langues telles que le langage R. Ce n'est pas assez rapide, et c'est plus difficile qu'il ne le faut. Ceux qui peuvent vivre dans une certaine enveloppe de performance et rester dans des bibliothèques établies vont bien. Ceux qui ne peuvent pas avoir besoin de plus, et ils commencent à en chercher plus.

Le fait est que les architectures informatiques sont en train de changer et que, pour en tirer parti, le langage et ses constructions doivent être construits d'une certaine manière. Le point de vue de Julia sur la concurrence est intéressant. Il optimise ce qui convient pour un tel langage: une distribution transparente et une circulation efficace des données entre les processus. Lorsque j'utilise Julia pour des tâches typiques, des cartes, des transformations, etc., j'appelle simplement des fonctions. Je n'ai pas à m'inquiéter de la plomberie.

Pour moi, le fait que Julia soit plus rapide sur un processeur soit intéressant, mais ne blâme pas trop R. Ce qui est intéressant pour moi, c’est que, comme les processeurs dépendent de plus en plus des performances multicœurs, les problèmes d’informatique technique sont à peu près idéalement placés. tirer le meilleur parti possible, dans le bon langage.

L'autre fonctionnalité qui aidera à y arriver est bien les macros. Le rythme de la langue est juste intense en ce moment. Les macros vous permettent de créer des blocs de construction plus gros et plus propres. Regarder les bibliothèques est intéressant mais ne donne pas une image complète. Vous devez regarder la croissance des bibliothèques. La trajectoire de Julia est à peu près parfaite ici.

Clojure est intéressant pour certains parce qu’aucun langage technique ne fait ce que R peut faire, alors certains se tournent vers un langage généraliste pour combler ce vide. Je suis en fait un grand fan. Mais Clojure est une distorsion cérébrale assez grave. Clojure sera là pour les programmeurs qui ont besoin de faire de l'informatique technique. Ce ne sera pas pour les ingénieurs et les scientifiques. Il y a trop à apprendre.

Donc pour moi, Julia ou quelque chose comme ça va absolument remplacer R un jour. C'est une question de temps.

Chaque fois que je vois une nouvelle langue, je me demande pourquoi une langue existante ne peut pas être améliorée.

Les grands avantages de Python sont

• un riche ensemble de modules (pas seulement des statistiques, mais des bibliothèques de traçage, sortie en pdf, etc.)
• les constructions de langage dont vous aurez finalement besoin à long terme (constructions orientées objet dont vous avez besoin dans un grand projet; décorateurs, fermetures, etc. qui simplifient le développement)
• de nombreux tutoriels et une grande communauté de support
• accès à mapreduce, si vous avez beaucoup de données à traiter et que cela ne vous gêne pas de payer quelques sous pour l’exécuter sur un cluster.

Pour dépasser R, Julia, etc., Python pourrait utiliser

• développement de la compilation juste-à-temps pour Python restreint pour vous donner plus de vitesse sur une seule machine (mais mapreduce est toujours préférable si vous pouvez supporter la latence)
• une bibliothèque de statistiques plus riche

Julia n'acceptera pas R très bientôt. Découvrez Microsoft R ouvert.

https://mran.revolutionanalytics.com/open/

Ceci est une version améliorée de R qui utilise automatiquement tous les cœurs de votre ordinateur. C'est le même R, le même langage, les mêmes packages. Lorsque vous l'installerez, RStudio l'utilisera également dans la console. La vitesse de MRO est encore plus rapide que Julia. Je fais beaucoup d'informatique intensive et j'utilise Julia depuis plus d'un an. Je suis passé récemment à R parce que R a un meilleur support et RStudio est un éditeur génial. Julia en est encore à ses débuts et ne rattrape peut-être pas Python ou R très bientôt.

Ce qui suit ne mérite probablement pas d'être une réponse, mais il est trop important d'être enterré comme un commentaire sur la réponse de quelqu'un d'autre ...

Je n'ai pas beaucoup entendu parler de la consommation de mémoire, juste de la vitesse. Toute la sémantique de R étant une valeur de passage peut être douloureuse, et ceci a été une critique du langage (qui est une question distincte du nombre de paquets intéressants qui existent déjà). Une bonne gestion de la mémoire est importante, de même que des moyens de gérer les traitements hors cœur (par exemple, les tableaux ou les tables mappés en mémoire de numpy , ou le format xdf de Revolution Analytics). Bien que le compilateur JIT de PyPy permette de réaliser des benchmarks Python frappants, la consommation de mémoire peut être assez élevée. Alors, est-ce que quelqu'un a déjà utilisé Julia et l'utilisation de la mémoire? On dirait qu'il y a des fuites de mémoire sur la version "alpha" de Windows qui seront sans aucun doute corrigées, et j'attends toujours l'accès à une machine Linux pour jouer moi-même avec le langage.

Je pense qu'il est peu probable que Julia remplace un jour R, pour nombre des raisons mentionnées précédemment. Julia est un remplacement Matlab, pas un remplacement R; ils ont des objectifs différents. Même après que Julia ait une bibliothèque de statistiques complète, personne n’y enseignerait jamais un cours d’introduction à la statistique.

Cependant, un domaine dans lequel cela pourrait être incroyable est un langage de programmation optimisé pour la vitesse qui est moins pénible que le C / C ++. S'il était lié de manière transparente à R (dans le style de Rcpp), il serait alors extrêmement utile pour l'écriture de segments de code critiques pour la vitesse. Malheureusement, aucun lien de ce type n'existe actuellement:

https://stackoverflow.com/questions/9965747/linking-r-and-julia

Je suis un novice Julia, et je suis compétent. Les raisons pour lesquelles je trouve Julia intéressante à ce jour sont la performance et la compatibilité.

Outils GPU. J'aimerais utiliser CUSPARSE pour une application statistique. Les résultats du CRAN indiquent qu'il n'y a pas grand chose à faire. Julia a des liaisons disponibles qui semblent bien fonctionner jusqu'à présent.

using CUSPARSE
N = 1000
M = 1000
hA = sprand(N, M, .01)
hA = hA' * hA
dA = CudaSparseMatrixCSR(hA)
dC = CUSPARSE.csric02(dA, 'O') #incomplete Cholesky decomp
hC = CUSPARSE.to_host(dC)

Outils HPC. On peut utiliser un cluster de manière interactive avec plusieurs nœuds de calcul.

nnodes = 2
ncores = 12    #ask for all cores on the nodes we control
procs = addprocs(SlurmManager(nnodes*ncores), partition="tesla", nodes=nnodes)
for worker in procs
    println(remotecall_fetch(readall, worker, `hostname`))
end

Compatibilité Python. Il y a un accès à l'écosystème python. Par exemple, il était facile de savoir comment lire les données d'imagerie cérébrale:

import PyCall
@pyimport nibabel

fp = "foo_BOLD.nii.gz"
res = nibabel.load(fp)
data = res[:get_data]();

Compatibilité C Ce qui suit génère un entier aléatoire à l’aide de la bibliothèque standard C.

ccall( (:rand, "libc"), Int32, ())

La vitesse. Je pensais que je verrais comment le paquet Distributions.jl fonctionnait contre le logiciel Rnorm - qui, je suppose, est optimisé.

julia> F = Normal(3,1)
Distributions.Normal(μ=3.0, σ=1.0)

julia> @elapsed rand(F, 1000000)
0.03422067

En R:

> system.time(rnorm(1000000, mean=3, sd=1))
   user  system elapsed 
  0.262   0.003   0.266 

Julia 1.0 vient de sortir un IDE très utilisable (Juno). Le parti est arrivé un peu tard, Python ayant déjà dominé le Machine Learning, alors que R continuait de dominer tous les autres types d'analyses statistiques. Cela étant dit, Julia se fait déjà une place de choix dans le domaine des algorithmes de finance et de trading, car un temps de développement rapide ET une exécution sont indispensables. À mon avis, à moins qu'un autre langage ne soit nettement meilleur, l'élévation de Julia deviendra probablement la suivante:

(1) Il commence à manger le déjeuner de MATLAB. Les utilisateurs de MATLAB aiment la syntaxe MATLAB mais détestent à peu près tout le reste. La lenteur, les licences coûteuses, les moyens très limités de traiter des structures de données complexes qui ne sont pas des matrices. Je me souviens d'une citation où il est dit que "Si Julia remplace MATLAB, ce sera un énorme service pour l'humanité". Les utilisateurs de MATLAB peuvent très bien maîtriser Julia et seront impressionnés par la facilité avec laquelle il est possible d’écrire un code qualité qui fait bien plus que ce que MATLAB peut faire (structures rapides que vous pouvez insérer dans des tableaux et les parcourir rapidement?). De plus, les chercheurs peuvent créer de sérieuses boîtes à outils en Julia (une petite équipe de doctorants a écrit un ensemble d'équations différentielles de classe mondiale) qui aurait été impossible avec MATLAB.

(2) Il commence à reprendre la recherche en méthodes numériques et en simulation. Le MIT met tout son poids derrière Julia et la communauté des chercheurs écoute le MIT. Les simulations numériques et les nouvelles méthodes numériques sont des problèmes mal définis qui n’ont pas de bibliothèques. C'est ici que brille Julia en tant que langue. S'il n'y a pas de bibliothèques disponibles, il est beaucoup plus facile d'écrire du code de qualité rapide dans Julia que dans n'importe quel autre langage. Ce sera un langage numérique / de simulation écrit par des mathématiciens pour des mathématiciens (son similaire à R encore?)

(3) Une autre percée dans l'apprentissage automatique se produit qui donne l'avantage à Julia. C'est un peu un joker qui pourrait ne pas arriver. TensorFlow est génial, mais il est extrêmement difficile à pirater. Python a déjà commencé à montrer des fissures et TensorFlow a commencé à adopter Swift (avec une mention honorable pour Julia). Si une autre percée en matière d’apprentissage automatique se produit, il sera beaucoup plus facile à implémenter et à pirater dans un paquet Julia comme Flux.jl.

(4) Julia commence à rattraper lentement R, ce qui prendra un certain temps. Faire des statistiques dans MATLAB est pénible, mais Juila est déjà bien en avance sur MATLAB avec Distributions.jl. Le fait est que les flux de travail R peuvent être facilement traduits en Julia. Le seul avantage réel de R est le fait qu’il existe de nombreux packages écrits par des statisticiens pour des statisticiens. Ce processus est cependant également facile à faire en Julia. La différence est que Julia est rapide et que vous n’aurez pas à utiliser une autre langue pour les performances (les packages R les plus "sérieux" sont écrits dans des langages comme C). Le problème avec R est que les packages écrits en R sont trop lents pour gérer de grands ensembles de données. La seule alternative est de traduire les paquets dans une autre langue, ce qui rend le développement de R plus lent que celui de Julia.

Je suis intéressé par la promesse d'une meilleure vitesse et d'une parallélisation facile en utilisant différentes architectures. Pour cette raison, je surveillerai certainement le développement de Julia, mais il est peu probable que je l'utilise tant qu'il ne pourra pas gérer les modèles mixtes linéaires généralisés. à partir d'algorithmes d'apprentissage machine.

Aucun statisticien ne peut se permettre d’avoir une attitude fondamentaliste face au choix des outils. Nous utiliserons tout ce qui nous permettra de faire le travail le plus efficacement possible. Je pense que je vais rester avec R pendant encore quelques années, mais ce serait bien d’être agréablement surpris.

Le luxe de NA en R ne va pas sans pénalités de performance. Si Julia soutient les NA avec une pénalité de performance moins importante, cela devient intéressant pour un segment de la communauté des statistiques, mais les NA imposent également un travail supplémentaire considérable lors de l'utilisation de code compilé avec R.

Beaucoup de paquets dans R reposent sur des routines écrites dans des langages hérités (C, Fortran ou C ++). Dans certains cas, les routines compilées ont été développées en dehors de R, puis utilisées comme base pour les packages de bibliothèque R. Dans d'autres, les routines ont d'abord été implémentées dans R, puis les segments critiques ont été traduits dans un langage compilé lorsque les performances ont été insuffisantes. Julia sera intéressante si elle peut être utilisée pour mettre en œuvre des routines équivalentes. Il est possible de concevoir une prise en charge de bas niveau pour les NA de manière à simplifier le traitement de NA par rapport à ce que nous avons maintenant avec R avec du code compilé.

Le nombre massif de bibliothèques R représente les efforts de nombreux utilisateurs. Cela était possible parce que R offrait des fonctionnalités qui n'étaient autrement pas disponibles / abordables. Pour que Julia soit largement utilisée, elle a besoin d’un groupe d’utilisateurs qui trouvent qu’elle fait ce dont elle a tellement besoin mieux que les solutions de rechange qui en valent la peine et qui nécessitent des efforts pour fournir des choses très élémentaires (par exemple, des graphiques, des classes de dates, des NA, etc.). ) disponible dans les langues existantes.

Je serai direct, je n'ai aucune expérience de R, mais je travaille avec beaucoup de personnes qui pensent que c'est un excellent outil d'analyse statistique. Mon expérience est dans l'entreposage de données, et en raison du modèle de programmation facile à utiliser de Julia mais plus standard, je pense qu'il pourrait être un substitut très intéressant à la partie transformée des outils ETL traditionnels qui fonctionnent généralement très mal, la plupart n'ont aucun moyen de le faire. créer facilement une transformation normalisée ou réutiliser les résultats d'une transformation déjà effectuée sur un ensemble de données précédent. La prise en charge des n-uplets bien définis et typés se démarque. Si je veux construire un cube OLAP devant fondamentalement construire des n-uplets plus détaillés (tables de faits) à partir de n-uplets déjà calculés, les outils ETL actuels ne disposent pas de "blocs de construction" pour en parler. peut aider, cette industrie a travaillé sur cette question de différentes manières dans le passé, mais il y a des compromis à faire. Les langages de programmation traditionnels peuvent aider en fournissant des transformations définies de manière centralisée, et Julia pourrait potentiellement simplifier les agrégations et les distributions non standard communes aux systèmes d'entrepôts de données plus complexes.

Vous pouvez également utiliser Julia et R ensemble. Il y a une interface Julia-to-R . Grâce à ces packages, vous pouvez jouer avec Julia tout en appelant R chaque fois qu’une bibliothèque est nécessaire.

Julia a sans aucun doute toutes les chances de devenir une statistique dont le rêve est devenu réalité. Prenez SAS par exemple. Son pouvoir réside dans les nombreuses procs écrites en C - ce que Julia peut faire est de vous donner les procs avec le code source, avec des matrices une distribution de type de données intégrée avec SAS / iml. Je ne doute pas que les statisticiens se rendront à Julia une fois qu'ils auront compris ce que ce chiot peut faire.

Oh oui, Julia dépassera R assez rapidement. Et les raisons principales seront les "macros", 95% du langage est implémenté dans Julia et sa syntaxe parcimonieuse sans bruit. Si vous n'avez pas d'expérience avec les langages de type lisp, vous ne le comprendrez peut-être pas encore, mais vous verrez assez rapidement comment l'interface de formule R deviendra un mécanisme obsolète et laid, et sera remplacée par des micro-langages spécialisés de modélisation similaires à CL. macro de boucle. L'accès aux références de bas niveau d'un objet est également un avantage considérable. Je pense que R n’a toujours pas compris que le fait de cacher les éléments internes de l’utilisateur complique les choses au lieu de les simplifier.

Comme je le vois maintenant (après des années d'utilisation intensive de R derrière et juste de lire le manuel de Julia), les principaux inconvénients de Julia en ce qui concerne R ne sont pas un support pour l'héritage structurel (cela était intentionnel). Le système de types de Julia est moins ambitieux que S4; il prend également en charge l'envoi multiple et l'héritage multiple, mais avec un catch - il n'y a qu'un seul niveau de classes concrètes. Par contre, je vois rarement des hiérarchies de classes dans R plus profondes que 3 niveaux.

Le temps nous le dira, mais ce sera plus tôt que ne le pensent la plupart des utilisateurs de R :)

Les premiers cas d'utilisation de Julia sont des problèmes numériques. Fondamentalement, vous pouvez décomposer ces domaines de la science analytique et informatique en science des données (pilotée par les données) et en science de la simulation (pilotée par modèle). Julia traite en premier des cas d'utilisation de la science de la simulation. Ils traitent également des cas de science des données, mais plus lentement. R ne sera jamais très utile pour la science de la simulation, mais Julia sera très utile pour les deux dans quelques années.

Il doit pouvoir appliquer n'importe quelle fonction aux grands ensembles de données qui ne peuvent pas être conservés en mémoire de manière transparente pour l'utilisateur.
Cela inclut au moins l’exécution de modèles à effets mixtes, de modèles de survie ou de MCMC sur des jeux de données compatibles avec le disque mais pas sur la mémoire. Et si possible sur des jeux de données distribués sur plusieurs ordinateurs.