Les résultats de l'enquête Stack Overflow sont une excellente source d'informations sur ce qui se passe dans le monde du développement. Je faisais défiler les résultats de 2020 à la recherche d'idées sur les langues à ajouter à la documentation de notre conteneur et j'ai remarqué quelque chose d'intéressant sur les types de langues. Il me semble que cela n'est pas souvent vu dans diverses discussions sur les préférences des développeurs.



Les sondages ont la catégorie "Les langages de programmation les plus terribles" (des Langages de programmation les plus redoutés) et "Les langages les plus préférés" . Les deux classements sont basés sur la même question:

, ? ( , , ).

Le "langage effrayant" est celui avec lequel vous travaillez activement cette année, mais vous ne voulez pas continuer à l'utiliser. Une langue préférée est celle que vous utilisez beaucoup et que vous souhaitez continuer à utiliser. Les résultats sont intéressants car ils reflètent les opinions des personnes qui utilisent activement chaque langue. Les opinions telles que «J'ai entendu dire que X est cool» ne sont pas prises en compte lorsque les gens apprécient les choses qu'ils n'utilisent PAS parce qu'ils ont entendu dire qu'il s'agissait d'une nouvelle tendance. L'inverse est également vrai: les personnes qui expriment une aversion pour une langue particulière l'utilisent en fait largement. Ils ont peur de la langue, non pas parce qu'ils ont entendu parler de sa complexité, mais parce qu'ils doivent travailler avec et éprouver une vraie douleur.



Top 15 des langages de programmation effrayants:

VBA, Objective-C, Perl, Assembly, C, PHP, Ruby, C ++, Java, R, Haskell, Scala, HTML, Shell et SQL.



Top 15 des langages de programmation préférés:

Rust, TypeScript, Python, Kotlin, Go, Julia, Dart, C #, Swift, JavaScript, SQL, Shell, HTML, Scala et Haskell.



Il y a un modèle dans la liste. As-tu remarqué?

Le pire code est celui qui a été écrit avant moi

L'ancien code est le pire. Si la base de code est en développement actif depuis plus de trois ans, alors elle est déjà incohérente. La première couche simple est recouverte de cas spéciaux et d'optimisations de performances, ainsi que de diverses branches contrôlées par des paramètres de configuration. Le code réel évolue pour s'adapter à son créneau, tout en devenant de plus en plus difficile à comprendre. La raison est simple, et j'ai entendu pour la première fois cette phrase de Joel Spolsky.

, [] , , : , .



— «, »

Appelons cela la loi de Joel. Beaucoup découle de cette prémisse. Pourquoi la plupart des développeurs pensent-ils que leur ancien code est un gâchis et veulent le jeter et recommencer? Parce qu'écrire quelque chose de nouveau est plus facile pour le cerveau que le travail acharné de comprendre la base de code existante, du moins au début. Pourquoi les tentatives de réécriture du code sont-elles souvent vouées à l'échec? Parce que de nombreux artefacts indésirables sont de petites améliorations vitales qui s'accumulent avec le temps. Sans un plan de refactoring spécifique, vous reviendrez là où vous avez commencé.





Scott Adams a compris



Il est facile de comprendre le code que vous écrivez. Vous le faites et vous l'améliorez en cours de route. Mais il est difficile de comprendre le code simplement en le lisant après coup. Si vous revenez à votre ancien code, vous constaterez peut-être qu'il est incohérent. Peut-être avez-vous grandi en tant que développeur et écririez-vous mieux aujourd'hui. Mais il y a de fortes chances que le code soit intrinsèquement complexe et que vous interprétez votre douleur à comprendre cette complexité comme un problème de qualité du code. C'est peut-être pour cela que le volume de PR non révisés augmente constamment? L'examen des demandes d'extraction est un travail en lecture seule, et il est difficile de le faire correctement lorsque vous n'avez pas de modèle de code fonctionnel dans votre tête.

C'est pourquoi vous en avez peur.

Si le vrai vieux code est injustement considéré comme un gâchis, alors peut-être que les langages de programmation sont évalués injustement? Si vous écrivez un nouveau code Go mais que vous devez maintenir une vaste base de code C ++ vieille de 20 ans, pouvez-vous les classer équitablement? Je pense que c'est ce que l'enquête mesure réellement: des langages effrayants sont susceptibles d'être utilisés dans les projets de friches industrielles existants. Les langues préférées sont plus souvent utilisées dans les nouveaux projets pour créer des pâturages verts. Regardons ça. ^une

Comparaison des langues vertes et brunes

L'indice TIOBE mesure «le nombre d'ingénieurs qualifiés, de cours et d'emplois dans le monde» pour les langages de programmation. Il y a probablement des problèmes avec la méthodologie, mais elle est suffisamment précise pour nos besoins. Nous utilisons l'indice TIOBE de juillet 2016 , le plus ancien disponible sur Wayback Machine, comme proxy pour identifier les langues qui ont accumulé beaucoup de code. Si le langage était populaire en 2016, il y a de fortes chances que les gens soutiennent le code qui y est écrit.



Top 20 des langages de programmation sur la liste TIOBE en juillet 2016: Java, C, C ++, Python, C #, PHP, JavaScript, VB.NET, Perl, assembleur, Ruby, Pascal, Swift, Objective-C, MATLAB, R, SQL, COBOL et Groovy. Nous pouvons l'utiliser comme notre liste de langages qui sont plus susceptibles d'être utilisés dans les projets de support de code. Appelons-les langues brunes. Les langues qui ne figuraient pas dans le top 20 en 2016 sont plus susceptibles d'être utilisées dans de nouveaux projets. Ce sont des langues vertes.





Sur les 22 langues de la liste combinée effrayante / préférée, 63% sont brunes

Langue brune: la langue que vous êtes le plus susceptible d'utiliser dans le cadre du support logiciel.



Langage Java, C, C ++, C #, Python, PHP, JavaScript, Swift, Perl, Ruby, Assembly, R, Objective-C, SQL



Green: le langage que vous êtes le plus susceptible d'utiliser dans un nouveau projet.



Go, Rust, TypeScript, Kotlin, Julia, Dart, Scala et Haskell

TIOBE et StackOverflow ont des idées différentes sur ce qu'est un langage de programmation. Pour surmonter cela, nous devons normaliser les deux listes en supprimant HTML / CSS, les scripts shell et VBA. ²



Bien sûr, une simple division en verts et bruns manque beaucoup de nuances, y compris dans la taille des champs. Je pense qu'il devrait y avoir plus de pâturages verts à Swift qu'Objective-C, mais la technique actuelle semble couvrir tout ce dont nous avons besoin. Il y a beaucoup plus de langues brunes sur cette liste que de langues vertes, mais c'est tout à fait normal, car relativement peu de nouvelles langues apparaissent chaque année.



Maintenant, nous pouvons répondre à la question: les gens ont-ils vraiment peur des langues, ou ont-ils simplement peur du vieux code? Ou pour le dire autrement: si Java et Ruby étaient apparus aujourd'hui, sans une pile d'anciennes applications Rails et d'anciennes applications Java d'entreprise à prendre en charge, seraient-ils encore redoutés? Ou seraient-ils plus susceptibles d'apparaître sur votre liste de favoris?

Langues brunes effrayantes

Langues effrayantes 83% brunes Les



principales langues effrayantes sont presque entièrement brunes: 83% brunes. C'est plus que les 68% de langues brunes sur la liste complète.

Langues vertes préférées

Mes



langues préférées sont 54% vertes, 54% de mes langues préférées sont vertes. Dans le même temps, dans la liste complète, seulement 36% des langues sont vertes. Et chaque langue verte est quelque part dans la liste des favoris.

Un autre défaut humain est que tout le monde veut construire et personne ne veut faire de maintenance.



- Kurt Vonnegut

Cela ne suffit pas pour dire avec certitude que la nécessité d'utiliser la langue dans un projet de soutien est redoutable. Mais il est très probable que ce soit au moins une des raisons. Beaucoup de langages "préférés" sont trop nouveaux ou trop impopulaires pour amasser de nombreux gros projets sales.



En d'autres termes, Rust, Kotlin et d'autres langues vertes sont toujours sur la scène de leur lune de miel. L'amour pour eux peut s'expliquer par le fait que les programmeurs n'ont pas besoin de gérer des bases de code vieilles de 20 ans.

Éliminer les préjugés

Certains langages de programmation plus récents ou historiquement moins populaires peuvent être meilleurs que les langages plus anciens ou plus courants, mais notre capacité à les juger semble plutôt biaisée. En particulier, si la langue est nouvelle ou n'a pas été utilisée auparavant, alors elle a une certaine image angélique. Et plus un langage est utilisé longtemps, plus il devient diabolique aux yeux des développeurs. Je suppose que la raison est que personne n'aime maintenir le code de quelqu'un d'autre. Et aussi à cause de la loi de Joel: c'est très difficile à lire dans le monde réel. Créer quelque chose de nouveau est amusant et de nouvelles langues sont utilisées plus souvent.

Le cycle de battage médiatique des langages de programmation

Au départ, j'ai commencé à fouiller dans ces classements pour mettre en évidence une liste de langues couramment utilisées et en même temps préférées - pour des exemples supplémentaires dans notre documentation et des exemples d'assemblage . Au lieu de cela, l'idée du cycle de vie du langage de programmation est venue: les langages de programmation préférés sont souvent utilisés, cela conduit à la maintenance du code, ce qui fait que les gens ne les aiment pas, ce qui conduit à leur tour les gens à rechercher des pâturages plus verts - et essayer une nouvelle langue ... Les cadres probablement populaires suivent le même cycle de vie.





Le cycle de battage médiatique des langages de programmation



Je n'ai pas les données sous la main, mais je me souviens très bien que Ruby était la langue la plus populaire en 2007. Bien qu'aujourd'hui il ait plus de concurrents, Ruby est meilleur aujourd'hui qu'il ne l'était alors. Cependant, maintenant ils ont peur de lui. Je pense que les gens ont maintenant entre les mains des applications Rails vieilles de 14 ans qui doivent être maintenues. Cela diminue considérablement l'attractivité de Ruby par rapport à l'époque où il n'y avait que de nouveaux projets. Alors attention, Rust, Kotlin, Julia et Go: à la fin, vous perdrez vous aussi vos ailes d'ange. ³

---

<sup>1. . , .



, .



TIOBE, , … Wayback Machine. []



2. HTML/CSS - , TIOBE . - , VBA , . []



3. : Python, C#, Swift, JavaScript SQL . - . , Scala Haskell — ,  — . - ??? []</sup>