Journal Etude comparée de la popularité des langages de programmation sur linuxfr

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
24
16
mar.
2018

Récemment, StackOverflow a publié les résultats d'une large enquête auprès de ses contributeurs, et notamment une mesure de l'attrait pour les différents langages de programmation. Je me suis dit qu'il serait intéressant de disposer d'un indicateur similaire pour la communauté linuxfr, et d'observer si celle-ci présentait des particularités ou des divergences avec la communauté des développeurs plus généralement représentée sur StackOverflow.

Or, grâce à la récente déferlante de journaux sur TapTempo, nous disposons effectivement d'une telle mesure, d'une précision scientifique irréfutable, à savoir la note de chacun de ces journaux, qu'il suffit donc de relever, avant de trier les langages en fonction.

Voici donc en exclusivité, le classement 2018 des langages préférés des linuxfriens.

NB : quand il y avait plusieurs implémentations dans le même langage, j'ai pris la moyenne des notes des journaux.

1.  Brainfuck    [ 47 ]
2.  Awk          [ 44 ]
3.  GOTO++       [ 32 ]
    VBA
4.  Scratch      [ 31 ]
5.  CPC BASIC    [ 25 ]
    Ada
6.  Linotte      [ 23 ]
7.  Perl6        [ 22 ]
8.  Haskell      [ 21 ]
    APL
9.  Golang       [ 20 ]
10. PWA          [ 18 ]
11. Tcl          [ 17 ]
12. Kotlin       [ 16 ]
    Elixir
    C
    Emacs Lisp
13. OCaml        [ 15 ]
    Bash
14. Wren         [ 14 ]
    Reason
    Forth
15. Perl         [ 13 ]
    Rust
16. Clojure      [ 12 ]
17. Python 2.7   [ 11 ]
18. Javascript   [ 10 ]
19. PHP          [  9 ]
20. Python 3     [  8 ]
    Java

Visiblement, sur les langages communs à cette liste et au panel des sondés de StackOverflow, les goûts des habitués de dlfp sont très différents. Il n'y a guère que PHP qui met tout le monde d'accord contre lui.

  • # PHP…

    Posté par  (site web personnel) . Évalué à 10.

    J'ai vraiment du mal à justifier le bashing continuel envers PHP.

    Le langage à certes des défauts mais depuis quelques années, avec des frameworks comme Laravel, les PSR, Composer, la documentation… franchement je commence à douter du sérieux de ces points de vue.

    On peut aussi parler de l'environnement autour de JS? Du clivage de la communauté Python avec l'arrivée de Python 3.

    Ah et aussi, c'est vendredi.

    • [^] # Re: PHP…

      Posté par  . Évalué à 4.

      Non mais tu comprends c'est pas hype PHP !
      En dehors des considérations de framework, le langage en lui même a connu de grandes évolutions depuis la version 5 et la version 7 apporte de belles améliorations en terme de performances et du typage strict.

    • [^] # Re: PHP…

      Posté par  (site web personnel) . Évalué à 10.

      PHP, c'est tabou, on en viendra tous à bout !

    • [^] # Re: PHP…

      Posté par  (Mastodon) . Évalué à 10.

      J'ai vraiment du mal à justifier le bashing continuel envers PHP.

      Je pense que ça vient de l'antislash pour séparer les namespaces…

    • [^] # Re: PHP…

      Posté par  . Évalué à 10.

      On peut aussi parler de l'environnement autour de JS?

      L’environnement autour de JS me paraît complètement sain et réfléchi, je ne vois pas le problème

    • [^] # Re: PHP…

      Posté par  (site web personnel) . Évalué à 9.

      Je ne suis pas d'accord. Javascript est tout aussi pourris que PHP.

      Python n'a jamais prétendu pouvoir être utilisé pour faire des (gros) logiciels.

      "La première sécurité est la liberté"

    • [^] # Re: PHP…

      Posté par  . Évalué à 8.

      Perso je n'ai aucune envie de faire du PHP, mais quand je dois installer un truc "web" je suis bien content qu'il soit fait avec ce langage.

      Cette année j'ai essayé de lancer un forum, et abandonné l'idée d'utiliser la solution à la mode, Discourse, devant la complexité et surtout les ressources demandées. J'ai pris Flarum à la place (ok ce n'est pas aussi développé) qui est fait en PHP… Un Apache, une bdd et ça roule.

      • [^] # Re: PHP…

        Posté par  . Évalué à 3.

        J’suis pas trop d’accord. Avec Python (et uwgsi) c’est quand même assez simple de mettre en place une webapp django/flask. En tout cas c’est pas plus compliqué que d’installer une webapp avec PHP-FPM.

        Pour Ruby/Rails, je sais pas, j’y ai jamais touché.

        • [^] # Re: PHP…

          Posté par  (site web personnel) . Évalué à 3.

          Avec Python, tu passes ton temps à faire du pip install puis du pip install -U puis … Bref, les développeurs ont pris la même mouvance que JS de casser les API de leur module à chaque version !

          • [^] # Re: PHP…

            Posté par  . Évalué à 2. Dernière modification le 17 mars 2018 à 12:00.

            Casser les API des versions majeurs c’est pas tellement spécifique à JS, si ?

            C’est plutôt un problème de gestion des dépendances, du style mettre "version minimum" au lieu de "version majeur maximum" dans les setup.py.

            • [^] # Re: PHP…

              Posté par  . Évalué à 4.

              Casser les API des versions majeurs c’est pas tellement spécifique à JS, si ?

              Ben je sais pas mais il arrive un moment ou faut arrêter de tout casser pour tout refaire : bien souvent ça sert à rien, et on en vient à douter de la réelle compétence des développeurs qui s'amusent à faire ça. Certes faut pas non plus rester immobile, mais faut savoir trouver un juste millieu (parfois tu as a peine le temps de développer un truc pour une version n d'un framework que la version n+2 qui casse tout est sortie, et tu passe presque plus de temps à rendre ton projet compatible avec les n versions de bibliothèques qui sortent par an que de développer les fonctionnalités de ton projet. Et le plus grave, c'est que certains trouvent ça normal.

              • [^] # Re: PHP…

                Posté par  . Évalué à 1.

                Bon alors dit comme ça c’est sûr, je ne trouve pas ça normal non plus de tout péter sans arrêt.

                Je suis curieux de savoir à quels frameworks tu penses (pas JS, naturellement :p) notemment avec Python car jusque là je n’ai pas eu de gros problèmes.

                • [^] # Re: PHP…

                  Posté par  . Évalué à 1. Dernière modification le 17 mars 2018 à 16:16.

                  Je ne sais pas si ça s'est stabilisé mais à une époque Rails a eu ce genre de problème. Pour apprendre le framework, j'ai passé beaucoup de temps à adapter les exemples que je trouvais à la dernière version du framework, parce qu'il y avait toujours un truc qui n'allait pas à cause des modifications introduites dans le framework.

                  J'ai connu ça avec certaines bibliothèque NodeJS également.

                  • [^] # Re: PHP…

                    Posté par  . Évalué à 1. Dernière modification le 17 mars 2018 à 16:27.

                    Du coup NodeJS ça paraît plutôt… "naturel" </troll>

                    Rails pour le coup je ne connais pas du tout. Ruby m’a toujours paru assez bancale…

                    • [^] # Re: PHP…

                      Posté par  . Évalué à 2.

                      Euh … Ruby en lui même est très bien, je le trouve beaucoup plus cohérent que python. Le seul reproche qu'on pourrait lui faire serait d'être un peu plus lent.
                      Rails est assez intéressant, et j'avais trouvé dommage qu'il ait été gaché par un tel manque de stabilité.

          • [^] # Re: PHP…

            Posté par  . Évalué à 2.

            Pas différent de faire un curl -s getcomposer | bash puis d’installer les requirements.

    • [^] # Re: PHP…

      Posté par  (site web personnel) . Évalué à 10.

      PHP est en terme de langage une sombre merde comme le prouve ce post légendaire. Pour avoir passé quelques jour sur la grammaire de l'implémentation de référence, je confirme celle-ci est aussi immonde que la conception du langage. Par exemple, on a un parseur dans le lexer (!). Fallait quand même y penser… C'est aussi le code C le plus crade que j'ai pu voir de ma vie. Et la grammaire Yacc la plus… j'ai pas de mot, crade n'est pas assez fort.

      Nonobstant, dans mon taf, j'ai eu à implémenter les parseurs de PHP et de JS.
      A ma grande surprise, la grammaire de PHP, implémenté avec PDT, est assez clean. Je les félicites au passage, c'est un exploit d'avoir nettoyé ça..
      La grammaire de JS est un modèle du genre de n'importe quoi, j'y ai vu des horreurs, avec des instructions à place d'expressions ou inversement, ou les deux. Je me suis bien amusé sur le parseur…

      Conclusion PHP et JS sont deux langages très crades, mais à l'inverse l'un de l'autre :
      - PHP est en fait un langage avec une grammaire relativement classique, un peu incohérente (l'exemple de la "fonction" empty qui n'est pas une fonction mais est dans la grammaire…), mais pas trop. On peut faire n'importe quoi, mais pas trop quand même, et de moins en moins. C'est sa sémantique, par contre qui est du grand n'importe quoi, je renvoi encore une fois aux détails
      - JS est lui sémantiquement beaucoup plus "propre" : on voit que le type qui l'a conçu a une vrai culture en terme de langages. Il y a beaucoup moins d'incohérences sémantiques que PHP. Par contre, mais ça se voit que quand on le parse, l'arbre syntaxique est parfois très surprenant. La liberté et la "puissance" d'expressivité de ce langage est telle qu'on peut faire plein de trucs vraiment crades et imbitables.

      Pour avoir écrit un analyseur de sémantique pour ces deux langages, ce qui est marrant, c'est qu'analyser du PHP est faisable, mais le faire en JS est quasiment impossible. Je m'étais amusé à hacker Flow de Facebook, pour lui faire cracher un AST typé. Après avoir réussi à le coder, je lui ai donné à manger le source de Angular 2 : j'ai arrêté l'exécution après 30h de calcul.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: PHP…

      Posté par  (site web personnel) . Évalué à 5.

      Il n'y a plus vraiment de clivage en Python. Globalement, maintenant, c'est du 3 partout et c'est tout.

      • [^] # Re: PHP…

        Posté par  . Évalué à 6.

        Euh … on doit pas avoir la même notion de ce que signifie "partout" alors.

        • [^] # Re: PHP…

          Posté par  . Évalué à 2.

          Il voulait peut-être dire "Il n'y a plus vraiment de clivage en Python. Globalement, maintenant, c'est du Go partout et c'est tout." :D

        • [^] # Re: PHP…

          Posté par  . Évalué à 2.

          Le fait est qu’il y a encore du code qui n’est pas compatible Python 3, mais l’interpréteur est disponible partout. Ceux qui ne migre pas le font rarement par idéologie.

        • [^] # Re: PHP…

          Posté par  (site web personnel) . Évalué à 2.

          bah bien sûr qu'il y a du vieux code qui traîne, c'est une évidence… mais maintenant, toutes les grandes bibliothèques sont en Python 3 (il suffit de regarder https://python3wos.appspot.com pour avoir une idée : sur les 200 plus téléchargées, 190 sont en Python 3 et sur les 10 restantes, 8 sont des outils internes de Mozilla, 1 est maintenant en Py3 et la dernière a été intégré à Py3), Python 3 est disponible par défaut sur les distribs comme Ubuntu contrairement à Python 2, etc.
          Sauf cas de force majeure, il n'y a plus aucune raison de faire du Python 2 pour un nouveau projet.

  • # erreur de recruteur...

    Posté par  . Évalué à -2.

    C
    

    Désolé, mais je ne crois pas avoir vu d'implémentations de tap tempo en C. En C++, oui, mais ce langage est absent de la liste.

    Pour rappel: C, C++, C#, ObjC ne sont pas les mêmes langages.

    • [^] # Re: erreur de recruteur...

      Posté par  . Évalué à 5.

      • [^] # Re: erreur de recruteur...

        Posté par  (Mastodon) . Évalué à 2.

        j'ai rêvé ou j'ai aussi vu passer une autre implémentation en C, mais en module kernel ?

        impossible de la retrouver.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: erreur de recruteur...

      Posté par  (site web personnel) . Évalué à 6.

      Voir la première réponse pour le port en C. Quant au C++, c'est le langage de l'implémentation originale de TapTempo et le journal correspondant a pu donc être plussoyé non pas à cause de l'attrait pour le langage, mais pour l'idée du logiciel en lui-même. Je l'ai donc exclu par souci de rigueur scientifique.

      • [^] # Re: erreur de recruteur...

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Je l'ai donc exclu par souci de rigueur scientifique.

        Dès le départ ce n'est pas scientifique du tout de prendre la moyenne, puisqu'elle est très sensible aux valeurs extrêmes… Imagine deux journaux pour le même langage X, l'un a une note de 50 et l'autre une note de 2, sa moyenne est donc 26. Le langage Y, quant à lui, a trois journaux ayant les notes 25, 26 et 27, soit une moyenne de 26 aussi. Est-il pertinent de les classer à égalité ? Déjà, le simple fait que Y ait plus de journaux signifie peut-être déjà qu'il est plus populaire. Le classement serait plus réaliste en prenant la somme des notes pour chaque langage (dans cet exemple, X et Y ne sont pas du tout à égalité selon le critère de la note totale).

        Un autre problème : le classement change avec le temps tant que les journaux sont suffisamment récents pour recevoir des notes. Pour être complètement juste il faudrait faire l'analyse une fois que les journaux ne peuvent plus être notés.

        Je sais que ce journal n'est pas 100% sérieux, mais je trouve que même pour plaisanter il faut un peu de sérieux. ;-)

        • [^] # Re: erreur de recruteur...

          Posté par  . Évalué à 9.

          Faudrait un sondage.

        • [^] # Re: erreur de recruteur...

          Posté par  (site web personnel) . Évalué à 4.

          Je suis particulièrement déçu que cette étude ne tienne pas compte du jour de la semaine qui est bien connu pour influencer la réception des journaux : https://linuxfr.org/users/krunch/journaux/dlfp-journalyser-2-0-pas-de-veille-techologique-le-weekend

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: erreur de recruteur...

          Posté par  . Évalué à 7.

          Y'a peut-être aussi une certaine fatigue des lecteurs même les plus curieux de voir 42 journaux sur l'implémentation de TapTempo, qui auraient plussé les premiers journaux et moinssé les derniers.

          Personnellement je n'ai fait ni l'un ni l'autre, mais je regrette que d'autres contenus partent quasiment dans le néant de l'oubli un peu vite parce que pas-de-bol: c'était la vague TapTempo, ton journal est arrivé en 3ème page en 2jours chez tous ceux qui les trient par la date.

          • [^] # Re: erreur de recruteur...

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            je regrette que d'autres contenus partent quasiment dans le néant de l'oubli un peu vite parce que pas-de-bol: c'était la vague TapTempo, ton journal est arrivé en 3ème page en 2jours chez tous ceux qui les trient par la date.

            Alors en regardant bien les notes des derniers journaux et même en les triant par date, ceux qui sont passés au milieu des TapTampo n'ont pas franchement démérité et ont même plutôt été bien voire mieux notés que ces derniers.
            Finalement, la "vague" TapTempo n'a pas vraiment gâché la vie des autres journaux.

          • [^] # Re: erreur de recruteur...

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Petites stats TapTempo/autres journaux:
            - le 26/02 : 1/2
            - le 27/02 : 3/4
            - le 28/02 : 1/3
            - le 01/03 : 2/3
            - le 02/03 : 2/2
            - le 03/03 : 3/6
            - le 04/03 : 1/3
            - le 05/03 : 1/2
            - le 06/03 : 2/5
            - le 07/03 : 0/3
            - le 08/03 : 2/3
            - le 09/03 : 5/9
            - le 10/03 : 5/6
            - le 11/03 : 3/3
            - le 12/03 : 2/2
            - le 13/03 : 3/10
            - le 14/03 : 1/4
            - le 16/03 : 3/8

            Je vous laisse faire le graphique, il est trop tard pour moi :D

          • [^] # Re: erreur de recruteur...

            Posté par  (site web personnel) . Évalué à -5.

            TapTempo? Ah c'est le truc qui SPAM LinuxFR en ce moment avec une méthodologie digne d'une publicité TV Mercurochrome. Désolé j'ai même pas regardé ce que c'était à part un machin qui voulait être écrit dans tous les langages.

            • [^] # Re: erreur de recruteur...

              Posté par  . Évalué à 10.

              Pour faire simple et concis, taptempo est une espèce d'exercice de style niveau programmation. Je conçois que certains n'aiment pas, mais pour ma part je trouve ça intéressant. Maintenant, je pense qu'il manquerait peut-être sur linuxfr la possibilité de filtrer les journaux, et de ne pas voir apparaitre certains tags : ceux qui n'aiment pas ce genrte de journaux affichent tout sauf les journaux sur ce sujet.

              • [^] # Re: erreur de recruteur...

                Posté par  . Évalué à 1.

                Ou pour faire encore plus simple:

                La prochaine fois, le premier auteur de journal pourrait juste écrire un journal succin appelant les codeurs à publier le portage dans leur langage favori dans les commentaires.

                Comme ça il n'y a qu'un seul journal sur TapTempo, et si, désolé, mais "dans mon langage favori, ça donne ça:", ça ressemble bien plus à une réponse au journal qu'à un contenu digne d'un journal dédié.

                • [^] # Re: erreur de recruteur...

                  Posté par  (site web personnel, Mastodon) . Évalué à 10.

                  La prochaine fois, le premier auteur de journal pourrait juste écrire un journal succin appelant les codeurs à publier le portage dans leur langage favori dans les commentaires.

                  Alors étant le premier à publier un journal/fork sur le sujet, je plaide coupable mais franchement, le temps que j'ai passé à rédiger le journal et à peaufiner le portage pour qu'il soit didactique, jamais je ne l'aurais passé pour un commentaire.
                  Ré-écrire un programme existant dans un autre langage, c'est de l'évangélisation pour sa chapelle et donc, pour une pure question d'ego, on le fait dans un journal.
                  Car, au final, les gens qui publient ici recherchent la reconnaissance de leurs pairs.
                  Après, je préfère des journaux comme ça partageant du savoir que des journaux "Vis ma vie", je trouve ça plus dans l'esprit du libre.

                • [^] # Re: erreur de recruteur...

                  Posté par  . Évalué à 8.

                  Le plus simple, c’est de laissez les grincheux grincher et de réagir si à un moment il y a vraiment un problème.

                • [^] # Re: erreur de recruteur...

                  Posté par  . Évalué à 7.

                  Il ne faut pas oublier que le sujet taptempo n'est absolument pas hors sujet sur linuxfr. Les notes attribuées à ces journaux montrent qu'il y a quend même un certain intéret sur le sujet. Certains ont qualifié les journaux de "pollution" : si pour eux taptempoi est une pollution, je les invite à ouvrir leur propre linuxfr like ou ils auraient toute lattitude à censurer ce qu'ils conidèreraient comme pollution, et de laisser ceux que le sujet intéresse libre de diffuser leur portage s'ils le veulent.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.