Contexte: Je suis informaticien dans une start-up à Austin et je viens d’un programme d’études supérieures (Physique). J'utilise Python au quotidien pour l'analyse des données, mais j'utilise un peu R. J'utilise aussi C # / .NET et Java (presque tous les jours), j'ai beaucoup utilisé le C ++ à l'université.
Je pense que le principal problème avec l'utilisation de Python pour les nombres (sur R) est la taille de la communauté d'utilisateurs. Depuis que le langage existe depuis toujours, beaucoup de gens ont fait des choses que vous voudrez probablement faire. Cela signifie que, face à un problème difficile, vous pouvez simplement télécharger le package et vous mettre au travail. Et R "fonctionne": vous lui donnez un jeu de données et il sait quelles statistiques résumées sont utiles. Vous lui donnez des résultats et il sait quelles parcelles vous voulez. Tous les complots que vous voudriez faire sont là, même certains assez ésotériques que vous devrez regarder sur Wikipedia. Aussi bien que scipy / numpy / pandas / statsmodels / etc. sont pour Python, ils ne sont pas au niveau de la bibliothèque standard R.
Le principal avantage de Python over R est qu’il s’agit d’un véritable langage de programmation dans la famille C. Il évolue facilement, il est donc concevable que tout ce que vous avez dans votre bac à sable puisse être utilisé en production. Python a orienté objet, par opposition à R où il se sent comme une sorte de réflexion après coup (parce que c'est le cas). Python fait également bien d'autres choses: le threading et le traitement parallèle sont assez faciles, et je ne suis pas sûr que ce soit le cas dans R. Et apprendre Python vous fournit également un puissant outil de script. Il existe également de très bons IDE (gratuits) pour Python, bien meilleurs si vous êtes prêt à payer (moins de 100 $), et je ne suis pas sûr que ce soit le cas pour R - le seul R IDE que je connaisse est R Studio, qui est très bon, mais n’est pas aussi bon que PyDev + Eclipse, d’après mon expérience.
J'ajouterai ceci comme un coup de pied: puisque tu es toujours à l'école, tu devrais penser à des emplois. Vous trouverez plus d'offres d'emploi pour les développeurs Python hautement qualifiés que pour les développeurs R hautement qualifiés. À Austin, les emplois pour les développeurs de Django sont en train de tomber du ciel. Si vous connaissez très bien R, il existe quelques endroits où vous pourrez capitaliser cette compétence (Revolution Analytics, par exemple), mais de nombreux magasins semblent utiliser Python. Même dans le domaine de l'analyse des données / de la science des données, de plus en plus de personnes semblent se tourner vers Python.
Et ne sous-estimez pas le fait que vous puissiez travailler avec / pour des personnes qui ne connaissent que (disons) Java. Ces personnes pourront lire votre code Python assez facilement. Ce ne sera pas nécessairement le cas si vous faites tout votre travail en R. (Cela vient de l'expérience.)
Enfin, cela peut sembler superficiel, mais je pense que la documentation de Python et les conventions de nommage (auxquelles on adhère religieusement, s’avère) est beaucoup plus agréable que le documentaire utilitaire R doc. Je suis sûr que cela fera l'objet d'un débat animé, mais Python met l'accent sur la lisibilité. Cela signifie que les arguments des fonctions Python ont des noms que vous pouvez lire, ce qui signifie quelque chose. Dans R, les noms d'arguments sont souvent tronqués - j'ai trouvé cela moins vrai en Python. Cela peut sembler pédant, mais cela me rend fou d’écrire des choses comme 'xlab' alors que vous pourriez tout aussi facilement nommer un argument 'x_label' (juste un exemple) --- cela a un effet énorme lorsque vous essayez d'apprendre un nouvelle API module / package. Lire R doc, c'est comme lire des pages de manuel Linux --- si c'est ce qui flotte dans votre bateau, vous avez plus de pouvoir.
Tout cela étant dit, je suggérerais ce qui suit (qui est aussi mon flux de travail typique): puisque vous connaissez Python, utilisez-le comme premier outil. Lorsque vous trouvez Python insuffisant, apprenez assez de R pour faire ce que vous voulez, puis:
- Écrivez des scripts en R et exécutez-les à partir de Python à l'aide du module de sous-processus, ou
- Installez le module RPy.
Utilisez Python pour ce que Python est bon et comblez les lacunes avec l’un des éléments ci-dessus. Ceci est mon flux de travail normal --- J'utilise habituellement R pour les graphiques, et Python pour les gros travaux.
Donc, pour résumer: en raison de l'accent mis par Python sur la lisibilité (recherchez google dans "Pythonic"), la disponibilité de bons IDE gratuits, le fait que ce soit dans la famille des langages C, la plus grande possibilité que vous puissiez capitaliser les compétences et le meilleur style de documentation du langage, je suggérerais de choisir Python comme point de référence et de ne faire confiance à R que lorsque cela est nécessaire.
Ok, c’est (de loin) ma réponse la plus populaire à ce jour sur un site stack, et elle n’est même pas n ° 1 :) J'espère que cela a aidé quelques personnes tout au long du chemin.
En tout cas, je suis arrivé à la conclusion suivante après plusieurs années dans le domaine:
C'est probablement la mauvaise question à poser.
Demander "devrais-je apprendre cette technologie particulière" est une mauvaise question. Pourquoi?
- Changements de technologie. Vous devrez toujours apprendre une autre technologie. Si vous allez travailler sur Twitter, ils exécutent Scala. Certains endroits sont des magasins Python. Certains endroits ne s'en soucient pas. Vous ne serez pas embauché parce que vous connaissez ou ne connaissez pas un élément technologique particulier. Si vous ne pouvez pas apprendre une nouvelle technologie, vous pouvez (et devriez) être licencié. C'est comme si, si une nouvelle clé à pipe sortait et que vous étiez un plombier, et vous ne pouvez pas comprendre comment la nouvelle clé à pipe fonctionne, vous êtes probablement un assez mauvais plombier.
- Étant donné le choix entre "Est-ce que j'apprends cette technologie" ou "Est-ce que je passe plus de temps à résoudre de vrais problèmes", vous devriez toujours choisir ce dernier, sans exception.
En tant qu’informaticien, votre travail consiste à résoudre des problèmes . Cette sagesse est à peu près toujours perdue à chaque conférence ou réunion à laquelle vous assistez - chaque discours sur les «données volumineuses» que j'ai jamais vu porte sur la technologie, pas sur la résolution de problèmes. La résolution du problème est généralement reléguée à quelques diapositives à la fin:
[Talk title = "Apprendre en profondeur chez Cool New Startup"] ... [45 minutes de diagrammes et de techno-babel pendant lesquels je zone et vérifie mon téléphone] ... Et, après avoir implémenté notre cluster Hadoop et [Ben zones out encore une fois] nous pouvons exécuter notre routine d’apprentissage en profondeur, [réveillez-vous: c’est pourquoi je suis venu!] dont les détails sont exclusifs. Des questions?
Cela donne une mauvaise impression que le domaine concerne la technologie, et ce n'est tout simplement pas vrai. Si vous êtes vraiment bon en Scala, ou en Python, ou en R, mais que vous êtes vraiment mauvais pour résoudre les problèmes, vous ferez un scientifique moche .
Paco Nathan était à Austin il y a quelques mois lors d'une conférence "Big Data" qui a duré toute la journée. Cela résume assez bien - la science des données ne concerne pas Scala, ni Hadoop, ni Spark, ou tout ce que l’autre technologie du jour apparaît. En fin de compte, je souhaite embaucher des personnes qui pensent, et non des personnes qui savent utiliser Stack Overflow pour apprendre les kits d’outils.
De même, si vous passez un entretien d'embauche et qu'ils ne vous embauchent pas simplement parce que vous ne connaissez pas certains langages de programmation, cette entreprise craint . Ils ne comprennent pas ce que «scientifique des données» signifie, et c'est probablement mieux pour vous si cela ne fonctionne pas.
Enfin, si vos capacités de résolution de problèmes sont marginales (soyez honnête avec vous-même), ou si vous aimez vraiment le côté technologique, ou si vous apprenez la technologie, c'est ce que vous aimez vraiment (encore une fois, soyez honnête), puis apprenez beaucoup de technologie. Vous serez toujours en mesure de trouver des rôles de type "ingénieur de données" qui correspondent à vos compétences. Ce n’est pas une mauvaise chose, les ingénieurs de données graissent les roues et vous permettent de faire votre travail en tant que data scientist. (La différence s'apparente à l'architecte logiciel par rapport à l'équipe de développement.)