La plupart des scientifiques [...] ne savent même pas qu'il existe
Ce genre de trucs, c'est quand même assez récurrent, et à mon avis c'est quand même en grande partie attribuable à des défauts des langages de programmation. On vit dans un monde où il y a des dizaines de langages populaires, et des centaines si on ajoute des trucs comme Julia. Tous les ans, des dizaines de nouveaux langages apparaissent. Dès qu'on fait un peu de programmation, il faut être polyglotte, et si la programmation n'est pas le cœur de métier, alors on peut s'attendre à ce que la règle générale soit de ne pas maitriser les spécificités du langage.
Or, ces langages ont l'air d'être conçus par et pour des gens qui vont en connaitre tous les détails, tout ce qui est mal documenté, tout ce qui n'est pas intuitif, et que c'est de la faute du programmeur s'il ne connait pas ces "finesses". Je trouve que c'est une excuse qui fait injustement reporter la faute sur les utilisateurs et pas sur les concepteurs des langages. Un moment donné, est-ce qu'il n'est pas naturel de s'attendre à ce que la meilleure manière de faire une boucle FOR, c'est de faire une boucle FOR?
La fragmentation, c'est aussi un problème dans ce genre de cas. On a parlé de Julia, par exemple, qui arrive dans un contexte où il y a déja de nombreux langages "scientifiques" et de nombreuses possibilités ; dans une équipe de recherche de 10 personnes, on trouve parfois 10 langages différents : C, C++, Fortran, Ada, OCalm, R, Python, Perl, MatLab, plus les pseudo-langage des logiciels spécialisés (SAS, Mathematica... ), les langages de script, etc. Encore une fois, tout ça vient en plus de la formation scientifique, les gens utilisent ces outils pour arriver à leurs fins, mais la programmation n'est pas leur métier. Et là, paf, «Pourquoi tu ne fais pas du Julia?», «Pourquoi ne pas regarder du côté de Ruby?», «L'avenir, c'est le Go.», etc. Alors oui, tout cela part d'une bonne intention, mais il faut bien comprendre qu'on ne remplace pas un langage par un autre, tout ça se juxtapose. Quand on incite à utiliser Julia pour les nouveaux projets, on peut éventuellement gagner un peu en productivité, mais quid de la maintenance du code une fois que le post-doc ou le doctorant sera parti? Quid du temps de formation, et du manque de support local? Évidemment, ça n'est pas une raison pour ne jamais évoluer, et c'est vrai que des trucs comme Ada, Fortran, ou même C tendent à disparaitre peu à peu, mais ça n'est pas une raison pour refaire pour la 1000e fois le coup du "apprenez ce truc nouveau, ça vous fera gagner du temps". Au final, plus personne ne maitrise réellement chaque langage, ça diminue la qualité du code, et ça n'apporte pas grand chose.
[^] # Re: essayer Julia ?
Posté par arnaudus . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 10.
Ce genre de trucs, c'est quand même assez récurrent, et à mon avis c'est quand même en grande partie attribuable à des défauts des langages de programmation. On vit dans un monde où il y a des dizaines de langages populaires, et des centaines si on ajoute des trucs comme Julia. Tous les ans, des dizaines de nouveaux langages apparaissent. Dès qu'on fait un peu de programmation, il faut être polyglotte, et si la programmation n'est pas le cœur de métier, alors on peut s'attendre à ce que la règle générale soit de ne pas maitriser les spécificités du langage.
Or, ces langages ont l'air d'être conçus par et pour des gens qui vont en connaitre tous les détails, tout ce qui est mal documenté, tout ce qui n'est pas intuitif, et que c'est de la faute du programmeur s'il ne connait pas ces "finesses". Je trouve que c'est une excuse qui fait injustement reporter la faute sur les utilisateurs et pas sur les concepteurs des langages. Un moment donné, est-ce qu'il n'est pas naturel de s'attendre à ce que la meilleure manière de faire une boucle FOR, c'est de faire une boucle FOR?
La fragmentation, c'est aussi un problème dans ce genre de cas. On a parlé de Julia, par exemple, qui arrive dans un contexte où il y a déja de nombreux langages "scientifiques" et de nombreuses possibilités ; dans une équipe de recherche de 10 personnes, on trouve parfois 10 langages différents : C, C++, Fortran, Ada, OCalm, R, Python, Perl, MatLab, plus les pseudo-langage des logiciels spécialisés (SAS, Mathematica... ), les langages de script, etc. Encore une fois, tout ça vient en plus de la formation scientifique, les gens utilisent ces outils pour arriver à leurs fins, mais la programmation n'est pas leur métier. Et là, paf, «Pourquoi tu ne fais pas du Julia?», «Pourquoi ne pas regarder du côté de Ruby?», «L'avenir, c'est le Go.», etc. Alors oui, tout cela part d'une bonne intention, mais il faut bien comprendre qu'on ne remplace pas un langage par un autre, tout ça se juxtapose. Quand on incite à utiliser Julia pour les nouveaux projets, on peut éventuellement gagner un peu en productivité, mais quid de la maintenance du code une fois que le post-doc ou le doctorant sera parti? Quid du temps de formation, et du manque de support local? Évidemment, ça n'est pas une raison pour ne jamais évoluer, et c'est vrai que des trucs comme Ada, Fortran, ou même C tendent à disparaitre peu à peu, mais ça n'est pas une raison pour refaire pour la 1000e fois le coup du "apprenez ce truc nouveau, ça vous fera gagner du temps". Au final, plus personne ne maitrise réellement chaque langage, ça diminue la qualité du code, et ça n'apporte pas grand chose.