Cela m'est très familier - les gens viennent dans mon domaine de différents endroits, et chacun a non seulement son propre logiciel préféré, mais le logiciel qu'ils pensent que «tout le monde» utilise - qui n'est invariablement pas vrai.

Pour le moment, par exemple, j'ai des implémentations de divers morceaux de mon travail dans MATLAB, Mathematica, C ++, Python, Maple, R, SAS ...

Avez-vous été dans une situation similaire (en tant qu'étudiant ou superviseur)?

J'ai été dans des groupes qui ont réussi à réunir tout le monde sous la même bannière de langue, et certains groupes qui ne l'a pas fait (intentionnellement ou non).

Et si oui, avez-vous essayé de faire en sorte que tout le monde utilise la même langue?

J'ai définitivement essayé, et parfois échoué. Vous avez mentionné certains des avantages, mais au-delà du simple partage de code, toute personne utilisant des langages différents rend extrêmement difficile d'apprendre des autres, de partager des solutions ou de collaborer de quelque manière que ce soit. Si vous rencontrez un problème et qu'il est écrit dans une autre langue que celle utilisée par les autres personnes, ce problème vous appartient entièrement - même si les gens veulent vous aider, ils ne le pourront peut-être pas.

Des situations se sont-elles produites, dans lesquelles il était bon que tout le monde n'utilise pas le même outil?

Le seul moment est où "l'outil habituel" est en quelque sorte terrible pour ce qui est nécessaire pour quelqu'un travail. Par exemple, il y a quelques années, lorsque l'écosystème statistique de Python était bien pire, il était bon d'avoir des gens qui connaissaient R. Mais en supposant qu'ils peuvent tous réaliser à peu près la même chose, je ne suis jamais allé "Oh merci mon Dieu, nous sommes tous écrire dans différentes langues! "

La seule exception est que j'ai rencontré quelqu'un dont la capacité à analyser du code basé sur des espaces blancs est ... moins que stellaire, ce qui m'a rendu heureux de pouvoir exécuter des choses dans MATLAB ainsi que Python.

Tout d'abord, vous devez comprendre un point très important: la plupart des langages de programmation servent leurs propres objectifs de niche. En corollaire, il n'y a pas un seul langage qui fasse tout le mieux, ou même tout bien. Par conséquent, l'unification dans une seule langue n'est souvent même pas une option sur la table.

Cela dit, il existe des cas où la même tâche peut être accomplie dans une variété de paramètres. Je vais passer en revue quelques exemples de mon expérience (en tant qu'étudiant diplômé en astrophysique computationnelle).

• Pour hardcore , peg-the-CPU, million -core, vos seules options sont Fortran, C ou C ++. De tels codes sont souvent les bêtes de somme centrales du groupe, et cela n'aide probablement pas à être diversifié ici. Si tout le monde code dans la même langue, les routines développées en un seul endroit peuvent être utilisées ailleurs à peu de frais. Choisissez-en un et appliquez des guides de style stricts sur tout code collaboratif.

• Pour le scripting , vous disposez de scripts shell Unix, Python, Perl, Ruby et beaucoup d'autres. Ici, cela dépend de qui est censé utiliser le script. Si vous écrivez quelque chose pour votre propre flux de travail personnel, il n'y a rien de mal à être différent de tout le monde. D'un autre côté, si j'écris un script destiné à être exécuté, compris et modifié par d'autres membres du groupe (comme le script de configuration pour le code de la bête de somme), il vaudrait mieux être dans une langue convenue.

• Pour les nombres légers , y compris la manipulation de matrices, il existe des programmes propriétaires comme Matlab et IDL, ainsi que des langages libres comme Python et Octave. Étant donné que les tâches utilisant ces programmes peuvent être un peu plus complexes que de simples scripts, il est utile d'avoir d'autres personnes pour obtenir de l'aide. J'étais autrefois le seul utilisateur de Matlab dans un groupe IDL, et je pouvais donc donner ou recevoir peu d'aide en ce qui concerne les chiffres.

• Pour la manipulation symbolique , comme avec Mathematica ou Maple, je pense que les mêmes considérations pour les nombres légers s'appliquent.

• Pour visualisation des données , il existe de nombreuses options, notamment Matplotlib, Matlab, IDL, VisIt, Paraview, MayaVi et yt. Tous ces éléments sont utilisés dans mon groupe, où je suis solidement dans le camp de Matplotlib. Ici, nous avons décidé que la visualisation est autant un art qu'une science, et chacun a ses propres outils avec lesquels il est le plus à l'aise. Si une personne fait ses meilleurs complots dans Matlab, et que quelqu'un d'autre est un naturel chez VisIt, pourquoi les forcer à faire un mauvais usage de l'IDL? En fait, avoir un groupe multilingue s'est avéré bénéfique, car toutes les options ne sont pas toujours disponibles et il est utile d'avoir quelqu'un pour obtenir de l'aide rapidement. Par exemple, seuls certains des éléments ci-dessus peuvent fonctionner sur des clusters de visualisation massivement parallèles pour rendre des ensembles de données de téraoctets dans un temps raisonnable.

Personnellement, j'ai défendu Python pour les scripts et les petits - visualisation à l'échelle. Dans le cas du script, j'ai démontré sa force en réécrivant un script de configuration que le groupe utilisait en un script plus polyvalent et plus lisible, et maintenant nous utilisons Python pour ce script partagé. Autrement dit, ce n'était pas une question de "quelle langue est intrinsèquement meilleure?" mais plutôt "avec quelle langue pouvons-nous faire mieux ?" Pour la visualisation, je n'essaie pas de convertir de force qui que ce soit, mais je partage simplement mes scripts et mes connaissances avec quiconque souhaite apprendre ce que je sais faire.

En résumé, les avantages de l'unification dépendent de la tâche. Le code qui peut être partagé ou réutilisé aide à être dans une seule langue; chacun écrivant sa propre version du même code serait un effort inutile. Les codes personnels, en revanche, fonctionnent bien lorsqu'ils sont écrits dans la langue qui convient le mieux à l'utilisateur; forcer tout le monde à utiliser le même code (en particulier en utilisant le mauvais code pour le travail, comme un package de manipulation de symboles pour la visualisation de données) conduit les individus à être moins efficaces.

Les seules restrictions que j'impose aux membres de mon groupe en ce qui concerne le logiciel qu'ils utilisent dans leurs travaux de recherche sont:

• qu'ils n'utilisent pas de logiciel propriétaire pour lequel le groupe n'utilise pas posséder une licence
• que leur travail peut être partagé ou réutilisé par d'autres membres du groupe à l'avenir

Exiger l'utilisation stricte d'un ensemble d'outils est, je pensez, contre-productif, car cela peut forcer les gens à passer beaucoup de temps à apprendre des choses qui ne leur seront pas nécessairement utiles dans leurs recherches ou plus tard dans leur carrière.

S'ils ne font que commencer dans le domaine de la programmation, je leur demanderai de commencer par Python et les autres codes standard que nous utilisons, car cela simplifie la vie de tout le monde dans le long terme.

Un morceau de sagesse que mon superviseur a partagé avec moi il y a quelques mois, quand je lui ai dit à quel point Julia avait l'air cool. (souvent) ne sont pas vraiment en mesure de choisir notre langue pour la tâche. Nous utilisons les meilleurs outils en cours de développement. Avant, c'était C ++, puis Matlab, maintenant il semble être python. Peut-être que lorsque votre doctorat sera terminé, nous utiliserons tous Julia.

En fait, apprendre une langue est facile. Faites-le simplement, pour pouvoir utiliser les meilleures bibliothèques.

L'une des choses que j'aime chez Julia est qu'en raison de son interface en langue étrangère, vous pouvez appeler les bibliothèques écrites dans de nombreuses langues différentes ( Je connais le code de travail pour appeler: C, Fortran, Rust, Python, Java, Matlab, Mathematica et C ++). Ainsi, ayant maintenu l'accès aux "Meilleurs outils"

Cela ne veut pas dire que vous devez convertir tout le monde à Julia. Le premier point est valable. Apprendre une langue est facile. Obtenir les meilleurs outils (ou dans votre cas peut-être des collaborateurs) ne l'est pas.

Oui, j'ai été dans une situation similaire à la fois en tant qu'étudiant et en tant que superviseur.

En tant qu'étudiant, j'étais la seule personne de mon laboratoire à utiliser Python (d'autres utilisaient Matlab ou même des macros Excel ). Oui j'ai essayé de les convaincre de changer, sans grand succès! Mais ce n'était pas un problème majeur car j'ai fait tout le travail de programmation par moi-même pour mes projets. J'ai parfois aidé sur d'autres projets en utilisant tout ce que le chercheur principal du projet utilisait.

En tant que superviseur, c'était un peu plus compliqué, car mon élève avait besoin de beaucoup de micro-gestion et d'aide sur une programmation simple tâches dans une langue que je n'ai jamais utilisée. Il a choisi cette langue parce qu'il voulait prolonger un programme écrit par un autre groupe de recherche. C'était très frustrant pour nous deux, et j'avais du mal à décider quand passer du temps à trouver des choses simples et quand lui dire à RTFM!

À l'avenir, j'avertirais l'élève avant de commencer le projet: nous convenons que soit il gère seul des problèmes de programmation simples, soit il utilise un langage que je connais bien.

Dans mon cas, j'utilise un mélange de R, C ++ et Python alors que le reste de mon laboratoire utilise Matlab. Et ça se passe plutôt bien, même si je dois admettre que nous n'avons pas besoin de partager beaucoup de code. Quelques observations:

• Avoir des implémentations dans deux langues censées fonctionner de la même manière permet de trouver des bogues dans le code.

• Je peux rapidement évaluer de nouveaux outils dans R qui n'ont pas été implémentés dans Matlab. D'autres peuvent faire de même avec du code Matlab qui n'a pas encore d'implémentation dans R. Cela s'est déjà avéré utile, car R est beaucoup plus facile à utiliser dans les algorithmes d'apprentissage automatique, et Matlab a une excellente bibliothèque pour interpolation polynomiale.

• Si vous prévoyez l'interopérabilité tôt, ce n'est pas si difficile. Nous avons opté pour un format de fichier unique pour les données brutes qui est analysable par tous nos outils, et au cas où nous aurions besoin de créer des scripts dans les deux langues pour interagir, nous pouvons le faire aussi (jusqu'à présent, ce n'était pas nécessaire). Cependant, j'admets qu'il est quelque peu nécessaire d'avoir des compétences en programmation polyglotte pour que cela se produise.

Avez-vous été dans une situation similaire (en tant qu'étudiant ou superviseur)?

Oui, fréquemment - dans mon service actuel, les gens utilisent (en fonction de leurs préférences personnelles et sur les exigences externes) Java, C #, C ++, C, JavaScript, Flash et probablement quelques autres.

Cela varie même beaucoup, car les étudiants peuvent vouloir utiliser encore une autre technologie ou un autre langage pour leurs projets comme les thèses de licence ou de master.

Et si oui, avez-vous essayé de faire en sorte que tout le monde utilise la même langue?

Jamais, à moins que l'interopérabilité ne soit explicite exigence. Cela peut avoir à voir avec le fait que je suis dans un domaine CS (c'est-à-dire où la programmation est plus au "cœur" qu'un simple outil), mais il y a ce que l'on pourrait appeler une règle non écrite selon laquelle vous ne prescrivez pas aux autres ce que technologies qu’ils utilisent. Au mieux, cela pourrait être interprété comme une tentative immature de lancer une guerre des flammes sur un sujet «ringard», au pire, comme une violation de l'autonomie personnelle d'autres chercheurs / développeurs par la micro-gestion.

En ce qui concerne les étudiants susmentionnés, nous précisons clairement que nous ne pouvons fournir aucun support technique s'ils choisissent une technologie avec laquelle aucun de nous n'a d'expérience (mais il convient de noter que nous ne fournirons pas trop de soutien, de toute façon, étant donné que les thèses de licence et de master sont censées se concentrer sur les aspects conceptuels et méthodiques à ma place, et que les étudiants sont censés (montrer qu'ils sont capables de) traiter des problèmes de bas niveau tout en programmant eux-mêmes leur prototype de preuve de concept .)

Des situations se sont-elles produites, dans lesquelles il était bon que tout le monde n'utilise pas le même outil?

Pour éviter de rendre ce son trop unilatéral ou négatif, je vais énumérer les avantages et les inconvénients perçus ici:

Inconvénients: str ong>

• Les artefacts de différentes personnes ne fonctionneront pas nécessairement ensemble.
  • Cela a même conduit à des réimplémentations complètes de prototypes, afin qu'un widget par une personne puisse être utilisé dans l'application par une autre personne qui utilisait un framework et / ou une boîte à outils d'interface utilisateur différents.
• La maintenance de la base de code existante n'est pas une donnée. Une fois qu'un collègue part, son code peut ne plus être abordé pour la seule raison que personne ne connaît la technologie utilisée pour ce code particulier.

Avantages:

• Il n'y a aucun moyen de garantir l'utilisation d'une seule langue, de toute façon; il y a trop de facteurs externes pour cela. On peut plus ou moins tenir pour acquis que dès que l'on a réussi à amener l'ensemble du département à un seul langage de programmation, le prochain projet avec des partenaires externes aboutira au consortium en choisissant une langue différente pour une raison ou une autre. Avoir un département diversifié où le savoir-faire sur différentes technologies et langues est présent, en revanche, peut aider à travailler sur un tel projet.
• Comme décrit en détail dans la réponse de Chris White, différents langages de programmation conviennent souvent à différents objectifs, donc en fonction de ce que vous faites, un changement de langage peut être nécessaire.
• Voir le changement permanent et la diversité rend moins susceptible de «rester coincé» avec une technologie. Créer une collection croissante de code réutilisable est certes avantageux, mais si cela aboutit à l’utilisation de technologies obsolètes car «tout a été jusqu’à présent écrit dans le dialecte de 1982 d’un langage propriétaire qui n’est plus mis à jour» et l’attente est qu’un Le commutateur nécessiterait le portage de la base de code entière, cela n'augmente pas exactement la sortie de recherche. Comme les départements de recherche n'ont généralement pas à produire du code infaillible au niveau de la production, mais seulement des prototypes et des démonstrations de concepts, la stabilité absolue devrait être une préoccupation moindre et, par conséquent, des réécritures constantes "rapides et sales" de certains composants sont acceptables.

EDIT: Chaque fois que je relis ma réponse, le développeur en moi-même frémit d'horreur. Ainsi, permettez-moi de clarifier mon point de vue sur les avantages: Oui, maintenir, mettre à jour et étendre une base de code existante sur de longues périodes de temps est excellent. À mon avis, un mélange idéal est que de petits groupes de personnes au sein d'un même département partagent une technologie particulière et aient ainsi la possibilité d'échanger du code (être le seul lié à un système donné peut être désastreux), tout en même temps s'assurer qu'il y a un flux lent et graduel dans lequel les technologies sont progressivement supprimées et remplacées au fil du temps par de nouvelles.

Avez-vous déjà été dans une situation similaire (en tant qu'étudiant ou superviseur)?

Oui, deux fois. Dans mon groupe précédent, tout le monde utilisait MATLAB, mais j'ai dû apprendre Python car le multitraitement de MATLAB était d'un coût prohibitif. Après avoir appris Python, je l'ai préféré et je m'y suis tenu. Dans mon groupe actuel, tout le monde à part moi utilise MATLAB.

Pour mon propre code d'analyse de données personnelles, j'utilise Python, mais pour le code destiné à être partagé à travers le groupe, j'utilise MATLAB.

Si vous avez une formation en programmation, vous penseriez que cela conduirait à moins de code partagé pour l'analyse des données. Le problème est que personne d'autre dans le groupe n'a une formation en programmation, et ils ne connaissent ni ne se soucient des bonnes pratiques de programmation (je n'ai même pas eu de chance de les convaincre d'utiliser des fonctions plutôt que de copier et coller des blocs de code dans leurs dizaines de milliers de scripts de lignes, sans oublier l'ajout de commentaires). Cela signifie qu'il n'y a presque pas de partage de code, même entre les utilisateurs de MATLAB, et tout le monde finit par écrire son propre code d'analyse de données à partir de zéro. Donc, en raison de la culture du laboratoire, personne n'aurait même réalisé que j'utilisais Python si je ne leur avais pas dit.

L'importance de votre choix de langue dépend donc dans une large mesure du culture du laboratoire, ou peut-être plus exactement à quel point ils sont familiers avec la programmation.

Et si c'est le cas, avez-vous essayé de faire en sorte que tout le monde utilise le même langage?

Non. J'ai suggéré que les gens apprennent Python en plus de MATLAB, sans grand succès. Mais les gens qui m'ont demandé ce qu'ils devraient apprendre, j'ai suggéré d'apprendre MATLAB d'abord, simplement parce qu'ils peuvent être sûrs de trouver quelqu'un qui l'a au moins utilisé auparavant. Je suis le seul à avoir une réelle expérience en programmation, et il existe une tonne de code MATLAB hérité, il n'est donc tout simplement pas possible de changer à ce stade. C'est pourquoi je suggère toujours aux gens d'apprendre Python comme deuxième langue.

Y a-t-il eu une situation où il était bon que tout le monde n'utilise pas le même outil?

Oui, deux cas me viennent à l'esprit.

Premièrement, il y a le fait que j'avais besoin d'écrire un nouvel importateur pour notre format de données propriétaire. En raison d'une faille dans le format, cela pouvait provoquer des dépassements dans le fichier, qui étaient toujours lisibles en principe, mais qui bloquaient à la fois le lecteur de fichiers C natif et le lecteur de fichiers basé sur MATLAB. Mon implémentation Python, cependant, était plus flexible et pouvait gérer les données. Quelqu'un d'autre dans mon groupe a fini par obtenir régulièrement ces débordements, alors j'ai écrit un simple script wrapper qui lirait les données puis les convertirait en fichier MATLAB, sauvant ainsi son projet du désastre.

Le second fait que l'outil basé sur MATLAB pour quelque chose que nous voulions faire est beaucoup, beaucoup, beaucoup plus compliqué, difficile à utiliser et capricieux que l'équivalent Python. Cela a probablement sauvé un bon mois de travail et a abouti à quelque chose avec de bien meilleures performances.

En plus de trouver un moyen d'utiliser plusieurs langages de programmation (par exemple via des interfaces de fonctions étrangères / compiler des éléments dans des bibliothèques / créer des scripts qui peuvent être appelés par d'autres langages), je pense que vous pourriez éventuellement vous mettre d'accord sur un langage de programmation.

J'ai récemment participé à un hackathon. Nous étions trois programmeurs et avions une tâche à résoudre. Nous avons "filtré" les langages de programmation comme ceci:

1. Quels langages savons-nous lesquels sont similaires et appropriés pour la tâche (en termes de facilité d'utilisation / bibliothèques / trucs communautaires comme les didacticiels / apprentissage courbe)
2. Dans quelle mesure les membres de l'équipe connaissent-ils «leur» langue? (Il vaut mieux avoir une personne qui est un expert dans une langue que deux qui en connaissent un peu, car de cette façon vous pouvez poser n'importe quelle question à l'expert.)

(Le hackathon était un succès et j'ai appris un nouveau langage de programmation et un framework dans un autre langage de programmation.)

Je suggère d'utiliser différentes langues: cela permet une validation croisée de vos calculs. Un logiciel / matériel / algorithme peut être erroné. La meilleure façon de vérifier l'exactitude est de répéter le calcul dans un environnement complètement différent. Je pense donc que c'est vraiment bien que les membres du laboratoire utilisent des langues différentes.

Même si tous les membres du groupe basculent vers la même langue - le style de codage peut être différent et n'aidera pas pour le code transfert. Cela ne fonctionnera que si vous codez tous dans la même langue et avez également les mêmes vues sur le codage lui-même. Par exemple, je préfère une modularité maximale, alors que quelqu'un d'autre pourrait préférer l'approche la plus rapide à la place.