Python dépasse Java en popularité selon l’indice TIOBE de novembre

Posté par  (site web personnel) . Édité par Davy Defaud, ted et Xavier Teyssier. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
27
6
nov.
2020
Python

Selon TechRepublic, qui commente la dernière édition de l’indice TIOBE qui mesure (de façon certes un peu opaque) la popularité des langages de programmation, Python vient de passer devant Java et est devenu deuxième derrière C. Preuve à la fois de la maturité du langage Python dans l’industrie et de la montée en force des usages pour lesquels il excelle (notamment l’apprentissage automatique).

Cela serait sans doute anecdotique si d’autres sources n’avaient pas également classé Python parmi les langages les plus dynamiques ces dernières années, notamment :

Par ailleurs, si vous utilisez Python et que vous souhaitez exprimer votre avis sur son évolution, il vous reste (à la date d’écriture de cette dépêche) deux jours pour participer à l’enquête annuelle de la PSF (Python Software Foundation) et de JetBrains auprès des développeurs Python.

Aller plus loin

  • # Allons

    Posté par  . Évalué à 4.

    La vraie nouveauté de cet indice, c'est que Nim fait une entrée fracassante dans la top 100 !

    Comment ça vous ne connaissez pas ? Par ici m'sieurs-dames !

    https://nim-lang.org/

    Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

    • [^] # Re: Allons

      Posté par  . Évalué à 3.

      Sûr ? Sur la page de l'index TIOBE je ne le vois ni dans les tableaux des places 1 à 50, ni dans le paragraphe qui liste les places 51 à 100.

      • [^] # Re: Allons

        Posté par  . Évalué à 5.

        Heu… je viens de vérifier et en effet, il ne s'y trouve plus.

        J'ai regardé il y a quelques jours (nous étions déjà en novembre). Ça devait encore être le classement du mois d'octobre.

        Bin dis donc, ça aura été une étoile filante dans le classement.

        Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

    • [^] # Re: Allons

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

      Cela a l'air sympa Nim effectivement …

  • # De l'engouement pour Python

    Posté par  . Évalué à 10.

    Je peine à comprendre l'engouement pour Python.
    Je peine tellement à le comprendre que quand je vois la multitude de billets de ce type, je culpabilise d'autant plus de ne pas arriver à aimer ce langage.

    Pour moi, chaque fois que je fais du Python - et dieu sait que je préfère éviter -, je me retrouve à pester contre sa syntaxe, son packaging ou sa documentation.

    Alors si une âme charitable peut m'expliquer ce que les développeurs du monde entier lui trouve, je lui en serais très reconnaissant; parce que moi manifestement j'ai l'impression de passer à côté de la panacée.

    • [^] # Re: De l'engouement pour Python

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

      Salut,

      J'ai découvert python il y a 7/8 ans, je cherchais à l'époque un framework web pour des développements internes, à base de brassage de données dans des DB (import / export, recherche, CRUD…), je suis alors tombé sur Django. À l'époque, j'avais fait du C# essentiellement, un tout petit peu de Java et de PHP. La solution devait être libre (je suis fonctionnaire, donc pas de budget).

      Je n'était pas spécialement fan du PHP de l'époque, je n'y ai pas trop touché, et puis c'était l'époque où les soucis de jeunesse du PHP commençaient sérieusement à se faire sentir (autour de la version 5, de mémoire, "00001" == 1 est vrai, ordre les params de fonctions en dépit du bon sens, pas d'objets qui tienne la route…par exemple).

      Mes critères alors étaient d'avoir un ORM (je sortais d'un truc où le seul endroit où je pouvais coder c'était dans les requêtes SQL, si si, j'ai fait une appli de gestion de stocks comme ça…), la gestion des sessions, des utilisateurs…

      Je sais que depuis PHP a évolué, mais bien connaître une Framework est un vrai avantage en terme de productivité ! De plus la doc de Django était très bonne à l'époque, et c'est toujours le cas !

      Je me suis donc retrouvé à coder du python comme ça, et depuis je n'ai pas arrêté. Je fais toujours du Django et certaines applications que j'ai développé à l'époque tournent toujours ! Ma plus vieille doit avoir 7 ans, il y a toujours des utilisateurs dessus (c'est trucs métier pour quelques utilisateurs, dans un LAN : pas beaucoup de risques de sécurité, donc maintenance minimale). De fil en aiguille, on se retrouve à écrire des scripts "jetables" en python, ils tournent toujours plusieurs années plus tard…

      La migration de python 2.7 vers python 3.5 s'est faite petit à petit, appli par appli, merci Gunicorn et les Virtualenvs. La solution mod_wsgi pou Apache de l'époque était globalement mono-interpréteur (Tu choisissais 2.7 ou 3.5 pour le serveur, et basta)

      Donc en fait, je suis arrivé au python comme ça, et depuis ça ne me lâche plus.
      J'apprécie sa souplesse, à son écosystème, à pypi, même si il faut faire super gaffe à ses dépendances quand on déploie une nouvelle version de son appli. J'ai encore du boulot sur le sujet !

      Donc voilà comment on se met à faire du python et à aimer ça :)

      J'ai découvert par la suite la communauté autour du python, elle est super acceuillante et vraiment très sympa, très ouverte.

      J'ai d'abord choisi un Framework, j'ai appris le langage sur le tas, j'ai amélioré les compétences petit à petit.

      Voilà comment on se met à aimer python.

      Courage !

      • [^] # Re: De l'engouement pour Python

        Posté par  . Évalué à 7.

        Bonjour,

        Quand je te lis j'ai l'impression que tu es venu à aimer Python pour son écosystème. C'est Django qui t'a mis le pied à l'étrier, mais tu aurais pu tout aussi bien faire du Ruby avec RoR.

        C'est une chose qui, je le constate avec les nouveaux développeurs que je côtoie, revient souvent : On découvre un langage par ses outils. Et on ne découvre pas les outils grâce aux langages; je sais pas si je suis clair, si ?

        J'ai fait du Python. J'en referais sûrement un jour et peut-être même que je changerai d'avis et me convertirai complètement. En attendant,je vais continuer à rester sur ma réserve et à m'étonner de la hype toujours grandissante autour de ce langage.

        Merci pour ton retour en tout cas.

        • [^] # Re: De l'engouement pour Python

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

          tu es venu à aimer Python pour son écosystème

          c'est un peu l'intérêt :-)

          après, pip avec venv est le meilleur ami (ou le meilleur ennemi) face à PHP, pour les projets web.

          Heureusement que python s'est engouffré dans le big data, il partait de très loin — en propre, sans ses bibliothèques — avec le GIL qui empêche d'utiliser plus d'un cœeur o_O

          ça se discute (même si on n'est plus 'dredi)

          • [^] # Re: De l'engouement pour Python

            Posté par  . Évalué à 2.

            Pour PHP, tu as composer et les sockets php-fpm - même si je te l'accord c'est moi simple rapide à mettre en place - qui permettent de gérer plusieurs versions de PHP et des paquets différents.

    • [^] # Re: De l'engouement pour Python

      Posté par  . Évalué à 6.

      Pareil je n'aime pas le typage dynamique

    • [^] # Re: De l'engouement pour Python

      Posté par  . Évalué à 10.

      Difficile d'expliquer les goûts des autres.
      Il faut regarder le langage lui même mais aussi les autres langages en comparaison.

      IMHO

      J'aime bien :

      • indentation au lieu d'accolades et de ";"
      • une lib standard riche
      • un écosystème très riche
      • gestion des dépendances (pip et pypi.org)
      • list comprehension
      • tout est un dictionnaire
      • programmation fonctionnelle
      • générateur et coroutines

      J'aime moins:

      • pas de typage
      • pas de compilateur : ça foire à l'exécution
      • performance (ça se mitige avec du pypy, du numpy et du cffi)
      • pas de pattern matching
      • pas de macro (mais du metaprogramming avec ast)
      • packaging, trop d'options imparfaites, j'aime pyinstaller

      Les langages que j'aime au moins autant voire plus:

      • haskell, c'est beau, mais je suis pas encore assez fluent
      • elixir, pour le |> et le pattern matching
      • awk, spécialisé dans le traitement de données tabulaires
      • bash, pour les |
      • Go : simple, performant

      Les langages que j'aime beaucoup moins, à peu près dans l'ordre de ma pratique

      • Java : trop de boilplater, trop d'objets, trop …
      • C : chez moi ça segfault tout le temps, j'en fait que pour de la perf
      • Javascript : WAT ! et nodejs/npm aussi
      • Typescript : trop proche de js du coup
      • C++ : trop compliqué
      • Perl : trop cryptique
      • Php : je déteste pas, pas waouh
      • Go : moche, simpliste
      • Scala : du java en plus compliqué, hum…
      • OCAML : je lui préfère haskell et écosystème réduit

      Les langages que je ne connais pas assez mais pour lesquels j'ai un petit avis:

      • rust : prometteur au vu de ce qui est fait avec, semble compliqué
      • Clojure : mes expériences avec LISP ne m'ont vraiment pas convaincu. Je commence à douter de ceux qui disent qu'il faut avoir l'illumination
      • Gleam : du Erlang/Elixir typé, bien tentant
      • Ruby : maintenant que je connais Elixir, pkoi pas
      • APL ou J : j'ai vu des démo incroyables

      Et tous les autres que je ne connais pas mais aimerai tester : lua, forth, nim, zig, pony, D, Dart, ReasonML ; ou pas : Julia, Racket, Swift, F#.

      Une vie n'y suffira pas ^ ^

      • [^] # Re: De l'engouement pour Python

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

        Pour le pattern matching, il y a des discussions en cours pour l'ajouter à Python.

        Il y a par ailleurs 3 projets de bibliothèques tierces qui peuvent être utilisés dès aujourd'hui: pampy, python-pattern-matching et patmat.

        Cf. https://github.com/sfermigier/awesome-functional-python#libraries (section "Pattern matching").

        Leur intérêt est néanmoins beaucoup plus limité que la proposition de PEP en cours de discussion par les développeurs et d'évaluation par le Steering Commitee.

        "There's no such thing as can't. You always have a choice." - Ken Gor

        • [^] # Re: De l'engouement pour Python

          Posté par  . Évalué à 3.

          Qu'est-ce qui s'est passé ? Ça fait 15 ans que python refuse de faire un switch.

          Par contre python n'a pas changé… Ajouter 2 mots-clefs d'un coup (si je m’appuie sur la PEP636), il y a pas mieux pour casser la compatibilité…

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: De l'engouement pour Python

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

            1) Le pattern matching n'est pas juste un switch.

            2) La syntaxe Python permet (dans certains cas) d'introduire des nouveaux mots-clefs sans casser l'utilisation du mot en question dans des noms de variables existants, car le contexte est différent. Ex: on peut introduire la syntaxe match: sans casser, re.match(...) ou une variable qui s'appelerait match.

            "There's no such thing as can't. You always have a choice." - Ken Gor

            • [^] # Re: De l'engouement pour Python

              Posté par  . Évalué à 3.

              1) Le pattern matching n'est pas juste un switch.

              Je le sais bien, mais à l'époque ça complexifiait le langage. Le pattern matchin est bien plus complexe.

              2) La syntaxe Python permet (dans certains cas) d'introduire des nouveaux mots-clefs sans casser l'utilisation du mot en question dans des noms de variables existants, car le contexte est différent. Ex: on peut introduire la syntaxe match: sans casser, re.match(…) ou une variable qui s'appelerait match.

              C'est l'utilisation des soft keyword ? Je ne connaissais pas et j'ai beaucoup de mal à trouver de la doc dessus, mais je comprends l'idée. Ça me parait bizarre de gérer case et case différemment de tous les autres mots clefs de structure de contrôle, par contre.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: De l'engouement pour Python

              Posté par  (site web personnel) . Évalué à 3. Dernière modification le 08 novembre 2020 à 16:21.

              1) Le pattern matching n'est pas juste un switch.

              Justement, ça apporte quoi de plus ?

              Dans des langages à typage statique, comme Haskell ou OCaml, le pattern matching permet de filter la structure d'une ou plusieurs variables et de vérifier automatiquement qu'on a pris en compte tous les cas.
              Mais avec un langage à typage dynamique, je ne vois pas ce que ça apporte de plus qu'un switch ou qu'une série de if.

              • [^] # Re: De l'engouement pour Python

                Posté par  . Évalué à 3. Dernière modification le 08 novembre 2020 à 16:43.

                C'est pour faire de la déconstruction de ce qui est décris dans le PEP au dessus. Tu peux matcher les valeurs d'une liste ou déconstruire un objet :

                a=["foo", "bar"]
                match a:
                    case ["foo", param]:
                        print(param)
                
                match event.get():
                    case Click(position=(x, y)):
                        handle_click_at(x, y)

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: De l'engouement pour Python

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

                  Et donc, ça apporte quoi de plus par rapport à un switch ou une série de if ?
                  Est-ce-qu'on a des garanties supplémentaires comme avec le pattern matching typé statiquement ?

                  • [^] # Re: De l'engouement pour Python

                    Posté par  . Évalué à 2.

                    Un peu plus haut tu as la doc qui explique très bien dans un anglais assez simple pour que même moi je puisse le lire sans trop me prendre la tête. Je te met le lien vers l'endroit où il en est question PEP 635: Motivation.

                    Je ne suis pas familier avec le parcourt d'AST en python, mais ça peut servir quand tu utilise un tuple comme objet ad-hoc à le déstructurer de manière plus concise et lisible.

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                    • [^] # Re: De l'engouement pour Python

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

                      Un peu plus haut tu as la doc qui explique très bien dans un anglais assez simple pour que même moi je puisse le lire sans trop me prendre la tête.

                      Un peu plus haut, il y avait 3 proposals longues comme un bras chacune, mais merci pour le lien.
                      Et donc la réponse est : rien à part un raccourcis de syntaxe ("We believe that adding pattern matching to Python will enable Python users to write cleaner, more readable code").

      • [^] # Re: De l'engouement pour Python

        Posté par  . Évalué à 5.

        Les langages que j'aime au moins autant voire plus :
        Go : simple, performant

        Les langages que j'aime beaucoup moins, à peu près dans l'ordre de ma pratique
        Go : moche, simpliste

        Du coup tu aimes ou pas le Go ?

        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

      • [^] # Re: De l'engouement pour Python

        Posté par  . Évalué à 5.

        Java : trop de boilplater, trop d'objets, trop …

        Il y a beaucoup plus d'objets en python. Pour le boilerplate depuis la version 6 (sorti il y a 14 ans tout de même) du java ça va en s'améliorant.

        Typescript : trop proche de js du coup

        C'est vraiment aller vite en besogne. Tu compare 2 langages qui ont des typages qui sont très différents pour en disqualifier un. C'est vraiment aller vite en besogne.

        Scala : du java en plus compliqué, hum…

        Pas la même syntaxe, pas le même typage, pas la même sémantique,…

        Comprends bien, chacun aime les langages qu'il veut sur des critères qui lui sont propres objectif ou non. C'est juste que sur ces 3 cas là (au moins il y aurait des choses à dire sur d'autres), tu me semble avoir des préconçus qui n'ont pas de sens.

        Collectionner les langages c'est très tentant, mais approfondir leur compréhension c'est vraiment important. Par exemple affirmer que python n'a pas de typage, c'est faux.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: De l'engouement pour Python

      Posté par  . Évalué à 7.

      Je suis aussi dans ton cas et j'avais essayé d'en analyser les raisons dans un précédent post :

      Les raisons de la popularité de Python ont été évoquées par les autres commentateurs.
      C'est en effet le Basic du 21ème siècle : sa syntaxe est simple et il n'a pas besoin d'être compilé, donc il est de plus en plus utilisé dans l'éducation. Ceux qui apprennent ainsi la programmation à l'école continuent ensuite d'utiliser le même langage. Du fait de cette base éducation - recherche, de nombreuses librairies sont crées. Et Python en vient à être choisi non pas pour le langage lui-même, mais pour la présence de telle ou telle librairie. Il est par exemple très facile, et avec peu de lignes de code, d'interroger en python une base de donnée et d'afficher le résultat en environnement graphique.

      Alors pourquoi je n'aime pas Python ? Pas pour des raisons techniques objectives, mais probablement un ressenti lié à une mauvaise première impression : le premier tuto que j'ai essayé pour apprendre le langage ne marchait pas, et j'ai perdu du temps dessus, tout simplement parce que le tuto était en Python 2 et mon système en Python 3. Et j'ai trouvé extrêmement léger de la part des concepteurs de changer des choses aussi basiques que la fonction Print ou l'opérateur de division. Si on essaye les tutos du livre "The C Programming Language" (écrit en 1978) avec un compilateur C actuel. Et bien ça marche.

      Ensuite, la définition des blocs par indentation est une fausse bonne idée. Un copié-collé d'un exemple dans votre propre programme ne marchera pas si l'exemple indente avec des espaces et que vous indentez avec des tabulations (ou inversement). Python m'a permis de comprendre à quoi servait la fonction "remplacer les tabulations par des espaces" de Geany, dont je ne voyais pas l'utilité.

      Enfin, la popularité croissante de Python fait que de plus en plus de gros programmes sont réalisé dans ce langage non compilé. Et là non plus, ce n'est pas une bonne idée de compter sur la puissance des machines.

      Enfin, une interrogation similaire ressort de l'index TIOBE : pourquoi Java, qui semble universellement décrié, a t'il toujours eu un classement aussi élevé ?

      Personnellement je n'ai jamais codé en java donc je ne peux pas juger en tant que langage, mais les programmes java étant mal intégré sous Gnu-Linux (jamais réussi à faire fonctionner un pavé numérique externe), j'en ai plutôt une perception défavorable.

      • [^] # Re: De l'engouement pour Python

        Posté par  . Évalué à 10.

        Par ce que ça n'est pas un classement des langages les plus aimsé, mais de ceux qui retournent le plus de résultat quand on recherche un tutoriel. Le TIOBE est un indice très mauvais, et c'est fou que tout le monde le prenne encore pour une référence de popularité.

        • [^] # Re: De l'engouement pour Python

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

          Il y en a bien qui considère que le classement de Shangai sert de référence pour les universités…

        • [^] # Re: De l'engouement pour Python

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

          Le TIOBE est un indice très mauvais

          le [acronyme d'une mesure] est un indice très mauvais, s'il n'est pas contextualisé et n'indique pas ce qu'il mesure et jaugé / jugé / évalué selon ce critère ;-)

          TIOBE a une valeur en soi : il est généraliste, il relève la médiocrité ambiante (java, WTF !? hormis effet de mode qui perdure, même si ça s'améliore dernièrement).

          Un indice pertinent c'est popularité / domaine d'application : histoire de ne pas comparer des choux et des carottes ;-)

          Un peu comme les analyses phoronix où il y a du bon et du nawak, séparer le bon grain de l'ivraie n'est pas si facile :/

          Vous connaissez un site qui recense un ensemble d'indicateurs permettant de les comparer ? (selon plusieurs domaines, pas que les langages)

          • [^] # Re: De l'engouement pour Python

            Posté par  . Évalué à 3.

            Le problème c'est justement qu'il se présente comme un indice de "popularité" et que le lien de cause a effet avec le nombre de résultats retourné pour des requêtes très précises dans les moteurs de recherche est tout sauf clair.

          • [^] # Re: De l'engouement pour Python

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

            TIOBE a une valeur en soi : il est généraliste, il relève la médiocrité ambiante (java, WTF !? hormis effet de mode qui perdure, même si ça s'améliore dernièrement).

            Quand un langage est très utilisé depuis 30 ans, c'est plus qu'un effet de mode…

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: De l'engouement pour Python

        Posté par  . Évalué à 6.

        Enfin, une interrogation similaire ressort de l'index TIOBE : pourquoi Java, qui semble universellement décrié, a t'il toujours eu un classement aussi élevé ?

        Tu confond la bulle qui t’entoure avec l'univers ;)

        Java est un langage qui trouve très bien sa place en programmation de service :

        • l'indépendance vis à vis du système d'exploitation (dans le langage, le binaire et le packaging) sont intéressant pour développer depuis un système d'exploitation
        • son temps de démarrage et de chauffe ont moins d'importance que la qualité du code généré par le JIT et du garbage collector
        • un écosystème très complet et très mature avec des standardisations qui apportent de la valeur. Je ne dit pas quelles en apportent toutes, mais quelque chose comme JDBC soit une API pour interroger des bases de données SQL, non limitant, avec une implémentation pour toutes les bases de données, etc c'est vraiment agréable
        • un outillage vraiment très cool, l'IDE peut donner énormément d'information, des outils d'analyse statiques comme sonarqube qui font un super job
        • le langage évolue dans la bonne direction, pour remplacer quelque chose d'en place il faut :
          • que tu apporte une valeur suffisante pour compenser la migration
          • que tu tes chances d'être pérenne pour éviter un blocage dans quelques années
          • que la valeur que tu apporte se maintienne dans le temps, si la solution initiale t'aura rattrapée dans 3 ans faire une migration qui prend 2 ans, ne vaut probablement pas le coût

        Évidement il y a d'autres raisons bien plus dommage comme l'inertie ou le fait qu'on ne reprochera pas à un décideur de partir sur java que sur le dernier langage sorti le week-end dernier.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: De l'engouement pour Python

          Posté par  . Évalué à 4.

          J'ajouterai aussi l'excellente compatibilité entre les versions de la JVM au cours du temps. Jusqu'à Java 8, "rien n'était jamais cassé" au niveau des interfaces. C'est vrai que cela a un peu changé depuis Java 9 mais les dépréciations sont quand même faites très calmement et anticipées sur plusieurs versions.

          Ça reste quand même un énorme effort à mettre au crédit de l'éditeur.

          • [^] # Re: De l'engouement pour Python

            Posté par  . Évalué à 4.

            La rupture en question c'est une partie de la bibliothèque standard qui a était déplacée dans une bibliothèque. Tu ajoute cette bibliothèque dans ton classpath et sans même avoir à rebuild le code.

            Par contre JavaEEJakarta EE a/va bien péter la compatibilité et ça ça va être couteux

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: De l'engouement pour Python

        Posté par  . Évalué à 3.

        Ensuite, la définition des blocs par indentation est une fausse bonne idée. Un copié-collé d'un exemple dans votre propre programme ne marchera pas si l'exemple indente avec des espaces et que vous indentez avec des tabulations (ou inversement). Python m'a permis de comprendre à quoi servait la fonction "remplacer les tabulations par des espaces" de Geany, dont je ne voyais pas l'utilité.

        Au début, je me disais aussi que c'était une fausse bonne idée.

        Et puis j'ai bossé bossé comme ingénieur intégration, à devoir faire des merges entre branches de code sur des milliers de fichiers en C.

        Et là, quand quelqu'un vous modifie un bloc de code tabulé avec des espaces ou inversement, le merge peut vite devenir un enfer.
        Des faux conflits partout. Ou bien du merge automatique qui foire avec de la duplication de bout de codes. J'ai subi ce genre de désagrément avec Cvs, Perforce et Git.

        Et le 'ignore space' pour la résolution de confit peut aussi apporter son lot d'autres effets de bords.

        Et même avec des règles de codage interdisant en interne les tabulations et de la revue de code par un pair avant commit, ce genre de mix tabulation / espaces subsistent.

        Donc finalement, un langage qui par défaut utilise l'indentation pour définir un bloc de code, cela rend la vie plus simple au pauvre intégrateur… :-)

        • [^] # Re: De l'engouement pour Python

          Posté par  . Évalué à 4.

          Je n'ai jamais vu ce genre de problème et s'il arrive tu peux annuler le merge ajouter un commit de auto reindent et faire ton merge. Je fais peux de python, mais sur du yaml, j'ai déjà souffert. Les exemples qui peuvent devenir bien relou, c'est de merger des changements d'indentation. En yaml c'est pire, mais de ce que je m'en suis servi ça m'a déjà un peu embêté.

          Tu peux même le détecter avant si tu préfère, tu peux aussi refuser le commit si tu le détecte ou avoir un linter qui rapport ça ou ajouter un hook git et le problème est probablement plus le non respect des règles parce que python ne va pas non plus apprécier des indentations inconsistantes.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: De l'engouement pour Python

      Posté par  (Mastodon) . Évalué à 7. Dernière modification le 07 novembre 2020 à 09:30.

      Tout dépend de quels autres langages tu as sous la main. Si tu as déjà du Perl (autre que un petit oneliner par-ci par-là), ou du C++ (avec ta petite compilation de librairies fétiches) ou du Rust pour citer un truc récent, je pense que tu peux passer à côté de Python sans pb.

      Moi j'avais pas tout ça : je suis un vieux ("le C c'est la vie") et je fais principalement du logiciel embarqué donc ça me va. Je script en Bash et c'est cool. Bon parfois c'est galère, mais c'est cool le Bash, j'ai même fait un serveur Web qui comptabilise des événements simples.

      Mais il me fallait un langage de plus haut niveau pour facilement faire des applis plus évoluées (avec une GUI, ou une vraie appli Web par exemple). C'est ce bouquin (en plus du lobbying de quelques collègues) qui m'y a foutu.

      Bingo, c'est ce qui me manquait réellement.

      Si par exemple tu taquines sérieusement le C++, le Java, je pense que tu peux très bien vivre sans Python : ces langages t'offrent à peu près les même facilités de langages évolués (pour ne citer qu'eux : manipulation de chaînes de caractères, itérateurs, gestion des exceptions… et surtout des librairies en veux-tu en voilà !)

      parce que moi manifestement j'ai l'impression de passer à côté de la panacée

      La panacée non, je fais bcp de reproches à ce langage (mélange de syntaxe objet et procédural par exemple), mais un outil bien sympa (comme il en existe d'autres) sans aucun doute.

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

      • [^] # Re: De l'engouement pour Python

        Posté par  (site web personnel) . Évalué à 9. Dernière modification le 07 novembre 2020 à 16:40.

        Tout d'abord merci de parler de mon livre :) ( PS : envoie moi un petit mail que je t'envoie une dédicace pour ton exemplaire … )

        Et en plus je suis d'accord avec toi, un langage c'est comme un outil, tu peu scier avec une lime et limer avec une scie … si cela t'amuses

        Et tu as des outils comme le couteau suisse qui dépanne dans beaucoup de cas de figure.

        Python est un peu comme un couteau suisse, l'expression basic du 21e siecle est, à mon avis, bien aproprié.

        Il ne peut pas concurrencer tout les langages dans tous les domaines, c'est évident.

        Mais avec python tu peu découvrir ou même créer de très belles choses dans de nombreux domaines mais avec certainement plus de facilité que dans d'autres langages.

        Personnellement il me sert :

        comme langage de script quand certaines choses sont trop pénible à faire en shell.

        Pour faire de petit site web dont le simple but est de fournir un "petit" service à d'autres.

        Pour prendre des données d'un coté (base de données, logiciel style JIRA … ) et les fournir a mes collèges en Pdf, Excel ou CSV … c'est facile avec python car il a des bibliotheques et paquets qui te simplifie la vie

        Ce qui me plait le plus dans python c'est qu'il s'agit d'un langage simple et concis :

        Pour l'écriture de ce bouquin j'ai écrit 192 scripts pour l'illustrer, et je viens de vérifier un seul fait plus de 400 lignes, une dizaine dépasse les 100 lignes, la grosse majorité font entre 10 et 100 lignes.

        Ce n'est pas le langage ultime (cela n'existe pas encore :) ), je continue de faire des shellsscripts car le shell est parfait pour cela, mais comme tout les langages il a ses limites.

        mais sur de petites taches ou il n'y a pas besoin de sortir la grosse artillerie (quand le volume et la fréquence ne justifie pas un programme compilé) python est très pratique, tu peu faire de jolies choses tres facilement et simplement.

        Et cerise sur le gateau : la lisibilité, quand tu reprends un scripts que tu as fais des années auparavant, tu le relis sans probleme.

        Simple (pas simpliste) facile, concis et lisible … c'est normal qu'un langage avec ces qualités soit apprécié par beaucoup de monde, surtout quand il permet "d'approcher" beaucoup de domaine.

        Mais c'est sur que, quand regarde ce langage, on peut lui trouver beaucoup de défaut mais quand on le compare ont le trouve super bien …

        • [^] # Re: De l'engouement pour Python

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

          salut, je t'ai envoyé un mail mais j'ai pas eu de réponse. L'as-tu reçu ?

          j'ai utilisé l'adresse de contact que tu mets sur ton site.

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

    • [^] # Re: De l'engouement pour Python

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

      manque plus que les job….

      www.solutions-norenda.com

      • [^] # Re: De l'engouement pour Python

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

        +1

        Alors que l'on demandent beaucoup de dev java et/ou PHP

        très peu de python.

        Et quand il y a un job … le salaire n'est pas à la hauteur :(

        • [^] # Re: De l'engouement pour Python

          Posté par  . Évalué à 4.

          Alors que l'on demandent beaucoup de dev java et/ou PHP

          En même temps, il y a énormément d'applications dans ces langages qu'il faut maintenir et faire évoluer. Et une fois que t'as plein de monde qui fait du Java ou du PHP dans la boutique, quand tu as des nouvelles appli à faire… Et bien, tu pars plutôt sur du Java ou du PHP (surtout vu la taille des écosystèmes).

          Les grosses DSI, avec toutes leurs règles et processus, sont assez conservatrices dans l'ajout de technologies différentes (je ne dis même pas "nouvelles !) :-)

    • [^] # Re: De l'engouement pour Python

      Posté par  (site web personnel) . Évalué à 9. Dernière modification le 07 novembre 2020 à 14:38.

      Pourrais-tu citer un langage qui te plaît bien pour qu'on aie des éléments de reflexion ?

      En ce qui me concerne, je suis passé du C++ au Python et j'ai beaucoup beaucoup apprécié la transition.

      Ce qui m'a bien plu:

      • langage très concis, très peu verbeux
      • des structures très matures (listes, dictionnaires, tuple, fonctions, etc) et très faciles à utiliser. C'est vraiment une simplification au quotidien de la vie du développeur
      • pas de compilation, on peut faire des cycles edition / execution / correction très rapidement (même si sur des gros projets, l'absence de compilation / typage devient un souci)
      • pas de pointeurs, pas de segfault, une charge mentale en moins
      • un très léger goût de programmation fonctionnelle, avec des map, lambda, reduce et autres, très très chiant à mettre en oeuvre en C++ (à l'époque, c'était il y a 15 ans).
      • une documentation très fournie
      • une approche assez pragmatique d'un certains nombre de problèmes, à l'opposé d'une vision puriste très défendue à l'époque dont je parle

      Ce qui me reste de tout ça aujourd'hui, c'est vraiment l'efficacité. Quand je pense un programme un peu complexe, j'arrive très vite à le mettre en oeuvre en Python là où je sais que d'autres langages vont me donner plus de fil à retordre.

      L'écosystème de bibliothèque est assez phénoménal et permet de trouver plus ou moins toujours ce dont on a besoin.

      Pourquoi est-ce que Python est aussi populaire aujourd'hui ? Je pense que l'alliance d'une syntaxe relativement simple à appréhender et d'un écosystème extrêmement riche fait qu'il plait beaucoup. Le parallèle que tu fais avec Visual Basic est tout à fait approprié, même si Python va bien plus loin que Visual Basic. On en retrouve à la fois dans la communauté scientifique, dans des interfaces graphiques ou dans de la programmation système.

  • # Le classement incroyable d'un language - ou, ce qu'on lit dans l'indice Tiobe

    Posté par  . Évalué à 6.

    Quel language, numéro 1 dans les années 80, est toujours plus populaire que Haskell, Lua, Kotlin, TypeScript, Nim, Clojure, Elixir ou F#? … Lisp, messieurs dames !

    maturité du langage Python dans l’industrie

    L'indice veut dire que beaucoup de monde cherche sur google comment faire quoi avec Python.

    • [^] # Re: Le classement incroyable d'un language - ou, ce qu'on lit dans l'indice Tiobe

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

      Comme je l'ai écrit dans la dépêche, l'indice TIOBE n'est pas à prendre pour parole d'évangile. C'est un indice parmi d'autres.

      D'autres sources d'informations, de nature diverse, convergent pour donner Python dans le Top 3 voire mieux:

      • IEEE Spectrum (cf. la dépêche)
      • Le nombre de questions/réponses sur StackOverflow
      • Le nombre de projet sur GitHub
      • Les sondages de StackOverflow ou GitHub auprès de leurs communautés
      • Le fait qu'il est à présent le langage enseigné en premier dans pas mal d'universités, et le langage par défaut dans l'enseignement scolaire, pour pas mal de pays
      • Le fait que Python est le langage no 1 (au coude à coude avec JavaScript) des projets informatiques open source de l'Etat français, selon mon décompte et en partant des données de code.etalab.gouv.fr: https://fermigier.com/images/python-etalab.png

      Popularité des langages dans les projets open source de l'Etat

      Chacune a des biais différents, plus ou moins ennuyeux, néanmoins la convergence de ces sources à donner des similaires montre que, contrairement à ce que nous disent encore certains DSI un peu conservateurs, Python est bel est bien entré dans le mainstream.

      "There's no such thing as can't. You always have a choice." - Ken Gor

    • [^] # Re: Le classement incroyable d'un language - ou, ce qu'on lit dans l'indice Tiobe

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

      Du coup, que les gens cherchent comment faire des choses avec, n'est-ce pas un signe de difficulté plutôt que de popularité ?

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Le classement incroyable d'un language - ou, ce qu'on lit dans l'indice Tiobe

        Posté par  . Évalué à 5.

        Difficulté peut être pas, mais tu lève peut être un point. Perso j'utilise python pour des petits scripts et via ipython. Comme ce n'est pas mon langage principale, il m'arrive souvent de me reposer des questions triviales de syntaxe alors que je ne fais que peu de recherche directement sur mon langage principal (c'est plutôt sur son écosystème). Le fait que python est un langage outil utilisé par des non développeurs et en second/troisième langage doit jouer

        Néanmoins tous les indicateurs montrent une progression de python et ça n'est pas déconnant quand en France par exemple on l'apprend maintenant aux lycéens.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Il y a 20 ans ...

    Posté par  . Évalué à 4.

    Quelqu'un qui se reconnaîtra peut être m'a dit:
    "Si ton script bash fait plus de 5 lignes: ré-écrit le en Python"

    Et j'en ai écrit des (millions de ?) lignes de Python depuis:
    * Scripts en programmation système
    * Wrapper en entrée/sortie de programmes Fortan en science.
    * Workflow et ordonnancement de programmes
    * Métaprogrammation (i.e. manipulation de chaine de caractère)
    * Interface vers des programmes plus bas niveau comme le C ou OpenCL.

    Finalement il manque les interfaces graphiques, le web et les bases de données, mais je ne pense pas devoir changer de langage de programmation pour ça.

  • # Le Windows des langages de programmation ?

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

    Pour moi Python, c'est un peu le Windows des langages de programmation : au début ça a l'air cool et après… bah on va faire avec maintenant qu'on le connait…

    C'est vrai qu'il est bien pratique pour scripter ou pour avoir une lib qui fait le job. Par contre, je ne comprends pas les retours positifs sur son écosystème. Perso, quand je ne peux pas utiliser Nix, je me retrouve à gongler entre pip, virtualenv et conda. Je trouve ça moins pratique que ce que proposent rust, julia ou même haskell.

    • [^] # Re: Le Windows des langages de programmation ?

      Posté par  . Évalué à 1.

      Enfin, Windows il est quand même closed-source, Python non ! Quand tu veux comprendre comment cela fonctionne à l'intérieur, c'est pas la même chose.

    • [^] # Re: Le Windows des langages de programmation ?

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

      On est d'accord sur une chose Julia remplacera avantageusement Python et Rust C/C++. Mais ces langages sont tout jeune, ils ont pas encore la maturité. La maturité, c destin ensemble de librairie natives, une communauté conséquente, une utilisation dans les entreprises qui se lancent difficilement dans un langage qui peu faire un flop…
      Et il y a 10-15 ans, il existait C/C++ trop complexe et puissant pour de petits besoins, PHP avait une connotation de code sale, Java très verbeux/complexe gourmand en RAM et avec une étape de compilation, ou Python…

      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

  • # Pour alimenter la discussion ...

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

    Pour alimenter la discussion :

    Que python soit de plus en plus aimé/plébiscité/utilisé : OK

    Cela vient certainement que c'est un excellent choix pour commencer l'informatique et apprendre la programmation, ce qui améne de plus en plus de monde à utiliser ce langage et à le faire connaître.

    je vois mal PHP ou Java à cette place, même si on demande plus de dev PHP et Java que de dev python.

    Par contre pourquoi Ruby n'a t il pas connu la même popularité ?

    Lui aussi est simple, élégant et lisible.

    Et surtout avec Ruby On Rails, on peut faire de très jolies choses.

    bref si quelqu'un a une explication ?

    • [^] # Re: Pour alimenter la discussion ...

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

      Je tique quand tu dis que Ruby est lisible. A chaque fois que je tombe sur du code Ruby, je suis obligé de cligner des yeux pour bien capturer tous les caractères. Prenons l'exemple en page de garde de ruby-lang.org

              # La classe Majordome
              class Majordome
                def initialize(nom)
                  @nom = nom.capitalize
                end
      
                def saluer
                  puts "Bonjour #{@nom} !"
                end
              end
      
              # Créer un nouvel objet
              m = Majordome.new("patron")
      
              # « Bonjour Patron ! »
              m.saluer
      

      Les caractères @ et #{@ m'écorchent un peu les yeux. Je suis astigmate, ce qui doit pas aider. Sur des caractères comme ça collés les uns aux autres, j'ai tendance à voir juste un gribouilli de lignes.

      En comparaison, le code Python est plus aeré et ne fait pas souffrir mon astigmatisme.

      J'aime pas tellement non plus le côté Smalltalk où tout est un objet et tu accèdes en suffixant à ses propriétés. C'est très cohérent, mais je m'y fais pas bien.

      Guido van Rossum (l'auteur de Python) a expliqué il y a longtemps qu'il avait fait délibérement le choix d'utiliser un opérateur type len(toto) plutôt que toto.len pour prendre la longueur d'un objet, afin de rester dans du code qui se lit comme une phrase. Le Ruby se lit plutôt comme du Yoda.

      Globalement, la syntaxe du Ruby est plus éloignée de Java/C/C++ que ne l'est Python. J'imagine que c'est ça qui fait la différence à la longue.

      En tout cas, il y a clairement quelque chose qui ne plaît pas dans Ruby puisqu'il est parti avec un très gros avantage sur Python du temps de la gloire de Ruby on Rails, pour se retrouver derrière.

      • [^] # Re: Pour alimenter la discussion ...

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

        Le Ruby se lit plutôt comme du Yoda.

        cela doit faire partie de la réponse, à mon avis …

        D'ailleurs cela me rappelle la méthode join

        "string".join( [ 'l', 'i', 's', 't', 'e' ] )

        que je savais pas ou caler dans la table des matières … coté Chaines de caractères ou Conteneurs ?

        Ma fille est astigmate aussi, je lui poserais la question sur la lisibilité :)

      • [^] # Re: Pour alimenter la discussion ...

        Posté par  . Évalué à 1.

        J'arrive même pas à comprendre l'exemple.

        Un majordome qui s'appelle "Patron", et qui dit bonjour en donnant son propre nom, ce qui fait qu'on croit qu'il pense que c'est nous le patron ?

        "Monsieur Perrin, votre prénom c'est François, c'est juste ? Et bien lui c'est pareil, c'est Just son prénom !"

        Et j'adore les commentaires, qui ajoutent tellement à la lecture du code :-) ! Je sais, c'est un exemple pour un language, et ça permet de distinguer les blocs, mais j'ai l'impression que plein de gens pensent que les commentaires servent à expliquer ce que fait le code, et non pourquoi il le fait. Peut-être à force de lire des exemples ?

    • [^] # Re: Pour alimenter la discussion ...

      Posté par  . Évalué à 6.

      Par contre pourquoi Ruby n'a t il pas connu la même popularité ?

      Parce que python.

      La progression de python en big data/data science (c'est assez générique je parle de numpy à sparc en passant par panda et les notebooks) et dans l'enseignement lui ont donné un coup de projecteur qui limite beaucoup la place pour ses alternatives.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Pour alimenter la discussion ...

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

      bref si quelqu'un a une explication ?

      À mon avis c'est notamment parce que globalement les 2 langages sont très proches (libres & communautaires, portables/multi-plateformes, interprétés, langages impératifs orientés objet, typage fort et dynamique, gestion automatique de la mémoire, polyvalents, expressifs/concis, assez lents…), mais Python est plus vieux et a donc l'avantage d'une communauté plus grosse à la base (et du coup plus de bibliothèques, de tutoriels…). Et donc au moment de choisir un de ces 2 cousins, on part naturellement vers le plus populaire (et qui du coup reste le plus populaire).

      C'est un motif qu'on retrouve un peu tout le temps ; 2 solutions techniquement très proches dont une prend l'avantage "réseau" à un moment pour une raison ou une autre, et qui finit par éclipser l'autre (ex: FreeBSD qui propose dans l'ensemble quelque chose de proche d'une distribution Linux, mais à l'époque des déboires juridiques des *BSD, Linux est passé devant).

    • [^] # Re: Pour alimenter la discussion ...

      Posté par  . Évalué à 3.

      Il faut comprendre aussi qu'il n'y a pas que des geeks informaticiens qui écrivent du code. Il y a des « ingénieurs » au sens large dans pleins de domaines, et pour cette catégorie il faut un « langage canonique » alors que pour certains informaticiens l'aspect cabalistique de leur science fait partie du folklore … Ensuite il faut se rendre compte que l'aspect cabalistique n'est pas bon pour l'industrie lorsque il faut maintenir les codes.

      Personnellement je trouve que Ruby a une syntaxe dans la ligné de Perl et qu'il faut apprendre certains détails de la syntaxe pour comprendre le code même si tu as déjà été confronté à plusieurs langages dans ta vie.

      De plus Ruby a été longtemps en deçà de Python au niveau performance de l’interprété. La communauté est plus grande et plus diversifiée, ce qui est bénéfique pour le langage.

      La genèse de Go suit aussi cette logique et répond à la problématique : comment livrer rapidement un logiciel performant et fiable avec une équipe de développeurs plus ou moins talentueux et gérer le turn over. La réponse est un langage simple, compilé et adapté aux problématiques actuelles. C'est l'anti-thèse de Ocaml, très beau sur le plan théorique mais en pratique, c'est trop compliqué pour le développeur lambda, pas assez performant, trop peu utilisé etc.

      Autre exemple, j'ai récemment vue le code de l'UI d'un respirateur né pendant le confinement écrit dans un langage super hype de la mort qui tue … Si tu pars tu principe que le code doit être audité et maintenu, la réponse est que c'est un imonde charabia pour tout le monde sauf pour la personne qui l'a codé, peux importe que tu maîtrises 50 frameworks UI.

      Bref Python est un bon remplaçant, pour Pascal, Basic, Visual Basic etc. et même Javascript

      • [^] # Re: Pour alimenter la discussion ...

        Posté par  . Évalué à 3.

        C'est l'anti-thèse de Ocaml, très beau sur le plan théorique mais en pratique, c'est trop compliqué pour le développeur lambda, pas assez performant, trop peu utilisé etc.

        Il n'a jamais fait de phrase à trou dans son enfance en cours de français le développeur lambda ? Parce qu'écrire un programme en OCaml c'est le même principe. Elle est où la difficulté ?

        Exemples:

        • Je mange du pain
        • Je bois de l'eau

        de ces deux phrases, on peut abstraire un motif sous la forme :

        • Je verbe de qqchose

        ce motif, on peut l'appliquer soit au couple manger - pain, soit au couple boire - eau, afin d'obtenir les phrases précédentes.

        Après, certes, on peut commencer à construire des phrases plus complexes, en partant par exemple de ce patron :

        • je regarde qqchose

        ce qui peut donner :

        • je regarde la télé
        • je regarde le chien du voisin

        Dans le deuxième exemple, le complément d'objet est lui-même un composé dont on peut abstraire un motif. Disons, celui-ci :

        • l'animal de qqu'un

        qui peut être instancier sous la forme :

        • le chien du voisin
        • le chat de ma tante
        • le poisson rouge de Nicolas

        et ainsi de suite. Ensuite, en composant les patrons de phrases, on construit des phrases de plus en plus complexes (ce qui ne veut pas dire compliquée ;-).

        Tu t'y prends autrement pour exprimer ta pensée de manière écrite? Le développeur lamabda, aussi, a une autre façon de procéder? Si c'est le cas, j'aimerais bien savoir laquelle.

        En programmation fonctionnelle, abstraire un mot pour former un patron c'est ce qui se nomme la lambda abstraction (le mot clef fun de OCaml), puis appliquer un patron à des cas particuliers cela s'appelle l'application de fonction, et la phase qui remplace le paramètre formelle par le paramètre effectif se nomme la beta reduction (c'est-à-dire l'exécution du code).

        (* j'ai les motifs suivants *)
        1 + 2
        2 + 3
        
        (* j'abstrais le patrons suivants *)
        fun x y -> x + y
        
        (* je l'utilise pour retrouver les exemples du dessus *)
        (fun x y -> x + y) 1 2
        
        (* et là le runtime fait des substitutions successives ou beta reduction *)
        (* on commence par susbstituer le premier paramètre x *)
        (fun y -> 1 + y) 2
        
        (*on fait pareil avec y *)
        1 + 2
        
        (* on calcule *)
        3

        Après le langage va rajouter des catégories grammaticales ou types pour bien vérifier que l'on utilise les patrons avec des mots ou construction conforme au règle de la grammaire, comme tout langage à typage statique. Autrement dit, dans le patron "je verbe de qqchose", il n'est pas correcte de vouloir utiliser le mot "bouchon" à la place du verbe car il n'appartient pas à la bonne catégorie grammaticale.

        Qui y a-t-il de compliquer à comprendre dans tout cela ?

        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

        • [^] # Re: Pour alimenter la discussion ...

          Posté par  (site web personnel) . Évalué à 4. Dernière modification le 09 novembre 2020 à 18:17.

          Ton explication est claire et limpide, et cela semble simple
          mais c'est pas intuitif et demain je ne serais plus capable de refaire l'exemple

          Présente le code a une assemblée de codeur "lambda"

          et Honnêtement :

          (* j'ai les motifs suivants *) => la une grosse partie de l'assistance s'en va

          (* j'abstrais le patrons suivants *) => ici tu en as perdu encore … (et dans certaines entreprises les délégués syndicaux te regardent d'un sale oeil … )

          (* et là le runtime fait des substitutions successives ou beta reduction *) => si quelques uns restaient …

          motifs / abstrais / beta reduction => les termes ne sont pas assez "basique" pour certains et trop théoriques.

          et pourtant c'est des mots simples :)

          sincerement : (enfin si j'ai bien compris)

          def ajoute(x, y):
             return x + y
          
          ajoute(1,2)
          

          Tu sais certains dev mélangent encore Go, Mo, To
          ne savent pas ce qu'est un plan d'execution de requete
          et refuse de taper une ligne de commande même si c'est plus simple

          Et je ne parle pas des Chefs de projets et des (con)sultants

          PS : pour ceux qui ne supportent pas la méchanceté gratuite, je peu aussi vous faire une facture si vous y tenez :)

          • [^] # Re: Pour alimenter la discussion ...

            Posté par  . Évalué à 3.

            sincerement : (enfin si j'ai bien compris)

            def ajoute(x, y):
              return x + y
            
            ajoute(1,2)

            Oui tu as bien compris le code, mais en OCaml c'est du même ordre si on vire toutes mes explications autour :

            let ajouter x y = x + y
            
            ajouter 1 2

            la définition de ajouter c'est juste du sucre syntaxique pour cette définition :

            let ajouter = fun x y -> x + y
            
            (*qui est elle même du sucre syntaxique pour celle-ci *)
            let ajouter = fun x -> fun y -> x + y

            mais cela je peux aussi l'écrire en python :

            ajouter = lambda x, y : x + y

            D'ailleurs j'ai toujours trouver l'utilisation du mot clef lambda quelque peu pédant, un peu comme Haskell qui utilise \ parce que ça ressemble à la graphie du lambda dans l'alphabet grec.

            Ce que je voulais signaler c'est que la programmation fonctionnelle n'a rien d'étrange ou de si compliquée : c'est fondamentalement ce que nous faisons quand on fait des phrases à trous.

            Il y a deux modèles de calcul qui servent de base aux langages de programmations. Celui de Turing avec sa machine et ses instructions pour en modifier l'état qui sert de base aux paradigme impératif. Celui de son directeur de thèse, Alonzo Church, à savoir le lambda-calcul avec son système d'expression et de réécriture d'expression qui sert de base au paradigme fonctionnel.

            Ce que je disais c'est que les phrases à trous sont du lambda-calcul, tout comme le calcul tel qu'on l'enseigne dans les cours de mathématiques élémentaires.

            Pour bien illustrer cet aspect où tout est expression en programmation fonctionnel (c'est vrai de OCaml mais aussi de lisp, ses dériviées, Haskell, elixir…), prenons cet exemple :

            let paire x = x mod 2 = 0

            cette fonction teste la parité de son paramètre, elle compare à 0 le reste de la division euclidienne par 2 (x mod 2).

            Avec la fonction ajouter de ci-dessus, on peut l'appeler ainsi :

            ajouter (if paire 2 then 1 else 2) 2

            ce qui vaut toujours 3. Ici if paire 2 then 1 else 2 est une expression comme un autre, que je peux donner en argument à ajouter car elle à le bon type. De la même façon que l'expression composée le chat de ma tante peut être passer à la phrase à trous "je regarde qqchose" car elle a la bonne catégorie grammaticale.

            motifs / abstrais / beta reduction => les termes ne sont pas assez "basique" pour certains et trop théoriques.

            Mon discours n'était pas destiné à des débutants, je m'interrogeais seulement sur ce qu'il y a de si compliqué à comprendre dans le paradigme fonctionnel alors que l'on fait la même chose à l'entrée du collège en cours de français (j'ai eu l'idée en faisant faire ses devoirs à une de mes nièces qui était en 6ème).

            Ce qui est vrai avec OCaml, ce n'est pas que la langage soit compliqué, mais qu'une grande partie de ses utilisateurs (le milieu académique faisant de la recherche en langage de programmation) fait des choses compliquées avec : pour leur santé mentale, il n'essaieraient même pas de les faire en Python ou Go. ;-)

            Si tu veux voir un programme simple, mais un peu plus évolué que les one liner de ces commentaires, tu peux regarder le journal sur taptempo en OCaml.

            Pour finir, il y a un point qui m'a échappé dans ta réponse :

            (* j'abstrais le patrons suivants *) => ici tu en as perdu encore … (et dans certaines entreprises les délégués syndicaux te regardent d'un sale oeil … )

            Ici tu considères que j'ai en face de moi un public de développeurs ? Ils ont eu peur de quoi ? du mot abstraction ? Si c'est le cas, effectivement les délégués syndicaux ne vont pas m'aimer : là c'est direction les ressources humaines, tu prends tes affaires et pas la peine de revenir demain. :-D
            C'est le métier du programmeur que de créer des abstractions. S'ils ont peur d'un mot qui constitue le cœur de leur activité, que font-ils ici ?

            Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: Pour alimenter la discussion ...

              Posté par  (site web personnel) . Évalué à 2. Dernière modification le 10 novembre 2020 à 15:52.

              pour leur santé mentale, il n'essaieraient même pas de les faire en Python ou Go. ;-)

              :)

              C'est le métier du programmeur que de créer des abstractions. S'ils ont peur d'un mot qui constitue le cœur de leur activité, que font-ils ici ?

              C'est un peu la question que je me pose tout les jours …

              Le télétravail a eu pour effet de considérablement diminuer le volume de questions idiotes par jour, et c'est dommage car j'aurais du en noter quelques unes et faire un livre de blagues :)

              Car il y a aussi l'effet inverse … tout est abstrait et beaucoup oublie le coté "matériel" et réel des choses :

              Exemple : un machine virtuelle Windows de 150 Go stockée sur un vieux disque USB 2.0 … oui cela se traîne et c'est normal …

              "Pourquoi la connexion chez le client est lente … j'ai la fibre chez moi avec 300 Mb/s"

              Trèves de plaisanterie … je ne connais pas Ocaml mais ton explication donne envie de s'y attarder un peu pour en connaître un peu plus

              • [^] # Re: Pour alimenter la discussion ...

                Posté par  . Évalué à 4.

                Le télétravail a eu pour effet de considérablement diminuer le volume de questions idiotes par jour, et c'est dommage car j'aurais du en noter quelques unes et faire un livre de blagues :)

                Un peu comme les perles du bac, ça aurait pu être marrant. :-)

                Trèves de plaisanterie … je ne connais pas Ocaml mais ton explication donne envie de s'y attarder un peu pour en connaître un peu plus

                J'ai jeté un œil du côté de elixir (mentionné dans un autre commentaire par un adepte de python), et ça peut être intéressant à regarder pour appréhender l'approche fonctionnelle de la programmation. Venant de python ce sera peut être moins perturbant : pas de typage statique et une syntaxe plus proche.

                Néanmoins, sur leur syntaxe, ils m'ont bien fait rire sur un point (cf. chapitre sur les modules et fonctions) :

                ajouter = &(&1 + &2)
                
                # ils considérent cela comme du sucre syntaxique pour
                
                ajouter = fn (x, y) -> x + y

                Utiliser la notation de De Bruijn dans un langage généraliste, je dois dire que je n'avais jamais vu cela. :-D

                Leur présentation de la notion de clôture (closure) me semble un peu étrange par rapport à ce qu'elle est réellement, mais à part cela ça peut être amusant de regarder de ce côté.

                Sinon, pour ce qui est de python vs OCaml, il y a le développeur d'un gestionnaire de paquet multi-platforme (Linux, MacOS et Windows) zero install qui a fait la migration du code de python vers OCaml en 2013. Il a détaillé son expériences sur son blog dans une longue série d'articles. Au bilan on se retrouve 6 ans plus tard avec une personne qui pense que le projet est mort parce qu'il y a peu voire pas d'activité sur le dépôt de code, et l'auteur de lui répondre :

                Well, this is the problem with OCaml. When 0install was written in Python, I did frequent bug-fix releases. Now it’s in OCaml, there’s no need to do that. e.g. there were 8 Python releases in 2012 vs 1 OCaml release last year. I prefer it that way, but it’s bad for the project’s metrics.

                source

                :-)

                Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

        • [^] # Re: Pour alimenter la discussion ...

          Posté par  . Évalué à 4.

          Tu montre des expressions d'une ligne. En une ligne quasiment tout langage qui n'est pas volontairement abscons sera simple.

          Mais il est bien plus intuitif de décrire un programme de manière impérative, il est aussi bien plus confortable d'avoir un accès direct aux effets de bords.

          Qui y a-t-il de compliquer à comprendre dans tout cela ?

          Avoir le bon niveau d'abstraction est quelque chose de véritablement complexe. Ça impact la lisibilité, la compréhension et l'évolutivité du code sachant que lisibilité et compréhension sont des notions tout à fait subjective et que ce ne sera pas la même chose d'un développeur à l'autre. Affirmer que l'abstraction c'est simple c'est comme dire que l'escalade c'est facile, il suffit d'attraper des prises et de se hisser dessus. Il y a beaucoup de subtilité derrière cette abstraction et non ça n'est pas simple.

          Autre chose manipuler des listes ne demande pas de notions particulières, là où la programmation fonctionnelle va te demander de comprendre des notions comme la reduction, fold, zip,… C'est élégant, mais c'est des notions plus sophistiquées.

          Enfin l'impératif va simplifier grandement le print debugging et l'élaboration incrémentale. Tu ne peux pas découper un code où tu le veux en fonctionnel ou plus exactement les primitives sont de plus haut niveau donc tu ne peux pas les étudier pas à pas. Bien sûr c'est possible, mais tu va avoir besoin de bien maitriser ce que tu fais pour pouvoir faire quelque chose qui intéresse surtout les débutants.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Pour alimenter la discussion ...

            Posté par  . Évalué à 2.

            Mais il est bien plus intuitif de décrire un programme de manière impérative, il est aussi bien plus confortable d'avoir un accès direct aux effets de bords.

            Parle pour toi, l'impératif rempli d'effets de bords je n'y comprends strictement rien dès que le programme devient trop gros. C'est un paradigme qui m'est totalement incompréhensible.

            Autre chose manipuler des listes ne demande pas de notions particulières, là où la programmation fonctionnelle va te demander de comprendre des notions comme la reduction, fold, zip,… C'est élégant, mais c'est des notions plus sophistiquées.

            Qu'est ce qu'il y a de compliqué là-dedans ? Prenons le reduce (ou fold) : c'est un peu comme une boucle de rétroaction. J'ai un système qui prend deux entrées et renvoie une sortie, je mets ma liste sur une des entrées qui sera consommée un par un, et je branche la sortie sur l'autre entrée : le système s'arrête quand il n'y plus rien à consommer dans liste.

                 -------------------------
                 |   _________________   |
                 |   |               |   |
             --------|               |   |
                             +       |----
             --------|               |
                     |_______________|
            

            C'est le schéma du dessus le reduce : je branche ma liste dans l'entrée du bas et je renvoie la sortie dans l'entrée du haut. Pour que ça marche il faut également donner une valeur initiale à l'entrée du haut, pour le premier tour, avant qu'elle ne soit alimentée par la sortie. Coder ce composant est on ne peut plus simple :

            let reduce f acc l =
              match l with
              | [] -> acc
              | hd :: tl -> reduce f (f hd acc) tl

            Le composant est constitué d'un opérateur à deux entrées (le paramètre f, qui était l'addition dans mon schéma), d'un accumulateur acc qui jouera le rôle de l'entrée avec rétroaction et d'une liste l à envoyer sur la deuxième entrée.

            Comment fonctionne-t-il ? C'est simple : il décompose la liste par un pattern matching. Soit la liste est vide est, dans ce cas, on renvoie ce qui a été accumulé sur la premier entrée. Soit elle ne l'est pas et, dans ce cas, elle est constitué d'une tête (son premier élément) et d'une queue (le reste de la liste). À ce moment, on donne les deux entrées acc et hd à la fonction dans notre boite (le terme f hd acc) puis on renvoie la sortie dans la première entrée et le reste de la liste tl dans la seconde entrée.

            Exemple d'usage : calculer la somme d'une liste d'entiers. Pour cela, il faut mettre l'addition comme fonction dans la boîte et partir de 0, ce qui donne :

            let somme liste = reduce (+) 0 liste
            
            somme [1; 2; 3] (* qui retournera 6 *)

            Ce qui demande du temps, et de l'expérience, c'est de comprendre toute la puissance du reduce et à quel point on peut faire de choses avec un tel composant, pourtant en apparence si simple.

            Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: Pour alimenter la discussion ...

              Posté par  . Évalué à 5.

              Parle pour toi, l'impératif rempli d'effets de bords je n'y comprends strictement rien dès que le programme devient trop gros. C'est un paradigme qui m'est totalement incompréhensible.

              C'est comme ça que fonctionne un ordinateur et les cours de programmation commencent tous par expliquer le fonctionnement d'un ordinateur. La relation entre ce que tu écris dans ton code et ce qui est exécuté par la machine est largement plus simple que ce qu'implique le fonctionnel.

              Les débutants ne commencent pas par faire de grands programmes. Comme dans toutes choses tu commence simple et tu progresse.

              Qu'est ce qu'il y a de compliqué là-dedans ? Prenons le reduce (ou fold) : c'est un peu comme une boucle de rétroaction.

              Je ne sais pas quoi répondre. On est pas dans le même monde.

              Comment fonctionne-t-il ? C'est simple

              Pour faire un type d'opération tu as ressenti le besoin de parler de boucle de rétroaction (concept de mécanique sophistiqué). Son implémentation simple implique de la récursivité. Tu verrais la difficulté pour les prof de collèges pour expliquer la récursivité aux élèves…

              Peut être que l'on ne comprends pas le mot simple de la même façon. Je parle de facilité d'accès et pas de simplicité algorithmique. La programmation fonctionnel permet d'obtenir des

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Pour alimenter la discussion ...

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

                des blocages clavier ? /o\

              • [^] # Re: Pour alimenter la discussion ...

                Posté par  . Évalué à 3. Dernière modification le 11 novembre 2020 à 16:10.

                Je ne sais pas quoi répondre. On est pas dans le même monde.

                Sans doute pas dans le même, effectivement. ;-)

                Il ne faut pas s'arrêter au vocabulaire que j'ai utilisé : ici je m'adresse au lectorat de linuxfr, où je partais d'une réponse à quelqu'un qui mentionnait des « ingénieurs au sens large » et des « programmeurs lambda ». Je m'attends à ce que cette population ne soit pas choquée et comprenne la notion de boucle de rétroaction.

                Ceci étant mon monde n'est pas celui de l'informatique mais de la musique, qui est loin d'être composé de techniciens et d'ingénieurs, et je te garantie qu'ils comprennent ce qu'est une boucle de rétroaction : quand il y a un larsen, ils savent d'où cela vient et comment régler le problème. ;-)

                Tu verrais la difficulté pour les prof de collèges pour expliquer la récursivité aux élèves…

                Je ne sais pas la difficulté que rencontre les profs de collèges sur ce point mais, pour ma part, les premiers algorithmes que j'ai appris étant enfant sont hautement récursifs et totalement fonctionnels dans leurs principes, et il en est de même de tous les écoliers de France depuis des décennies. Je veux parler des algorithmes d'addition et de multiplication avec retenue, ainsi que celui de la division euclidienne (celui où l'on pose la division). Tu as peut être oublié ce que tu faisais étant enfant à l'école primaire.

                Si je veux être pompeux et utiliser un concept sophistiqué, je pourrais employer, par exemple, celui de monade d'état et pourtant c'est au cœur des API REST. Si j'en crois la présentation de wikipédia :

                La communication client–serveur s'effectue sans conservation de l'état de la session de communication sur le serveur entre deux requêtes successives. L'état de la session est conservé par le client et transmis à chaque nouvelle requête. Les requêtes du client contiennent donc toute l'information nécessaire pour que le serveur puisse y répondre. La visibilité des interactions entre les composants s'en retrouve améliorée puisque les requêtes sont complètes. La tolérance aux échecs est également plus grande. De plus, le fait de ne pas avoir à maintenir une connexion permanente entre le client et le serveur permet au serveur de répondre à d'autres requêtes venant d'autres clients sans saturer l'ensemble de ses ports de communication, ce qui améliore l'extensibilité du système.

                source

                Moi quand je lis ça, je me dis : tiens, ils travaillent dans une monade d'état.

                Peut être que l'on ne comprends pas le mot simple de la même façon. Je parle de facilité d'accès et pas de simplicité algorithmique. La programmation fonctionnel permet d'obtenir des

                Je voudrais bien te répondre, mais il semble que ton clavier se soit blo

                Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                • [^] # Re: Pour alimenter la discussion ...

                  Posté par  . Évalué à 6.

                  Je ne sais pas la difficulté que rencontre les profs de collèges sur ce point mais, pour ma part, les premiers algorithmes que j'ai appris étant enfant sont hautement récursifs et totalement fonctionnels dans leurs principes, et il en est de même de tous les écoliers de France depuis des décennies. Je veux parler des algorithmes d'addition et de multiplication avec retenue, ainsi que celui de la division euclidienne (celui où l'on pose la division). Tu as peut être oublié ce que tu faisais étant enfant à l'école primaire.

                  Je ne vais reprendre qu'une partie car il me semble que c'est le nœud de notre désaccord. Appliquer une recette n'a aucun rapport avec en comprendre le fondement (surtout que ton exemple est généralement présenté comme itératif et non fonctionnel). Ce n'est pas parce qu'on a vu un objet tomber qu'on comprends la relativité générale.

                  Réellement tu compare utiliser une méthode dans un cas précis qui t'a était dicté et en comprendre suffisamment sa mécanique pour la réutiliser. Savoir faire cette addition sur les entiers va devoir être réappris pour l'appliquer à une représentation binaire, octale ou hexadécimale des nombres, pourtant l'algo est le même. Ça montre bien qu'il n'y a pas de compréhension de cet algo il est appliquer tel quel. C'est comme mélanger la farine et les œufs sans savoir la chimie qui se cache derrière.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Pour alimenter la discussion ...

                    Posté par  . Évalué à 3. Dernière modification le 12 novembre 2020 à 17:49.

                    Je ne vais reprendre qu'une partie car il me semble que c'est le nœud de notre désaccord.

                    Il y a bien là un point de désaccord, tu sembles, à mes yeux, sous estimer grandement les capacités intellectuelles et de compréhension d'un enfant.

                    Je vais d'abord parler d'un personne que je connais bien : moi-même. J'ai effectué mon école primaire dans les années 80 au sein d'une école privée. Pour l'accès au collège, il y avait un examen d'entrée en 6ème. Parmi les exercices de calculs, il y en avait un qui consistait à effectuer une addition et une multiplication en base 10… puis en base 5. Il fallait ensuite convertir les résultats d'une base à l'autre pour bien vérifier que le résultat était indépendant de la base choisie.

                    Oui : on demandait cela à des élèves en fin de CM2. Je t'accorde que tous n'y arrivaient pas, mais j'étais loin d'être le seul à y arriver, et nous comprenions ce que nous faisions. On ne se contentait pas d'appliquer bêtement une recette sans savoir pourquoi elle fonctionne. Je suppose que le choix des bases était fait à partir du nombre de doigts que l'on possède sur nos mains. Mais dans le fond, pas de grande différence, sur le plan algorithmique, avec une base 2, 8 ou 16.

                    Ensuite, pour les enfants d'aujourd'hui, je n'ai comme exemple proche que mes nièces, n'ayant pas d'enfants. Elles sont en 5ème, CM1 et CP. Les deux grandes comprennent leurs algorithmes, à commencer par la raison d'être de la retenue, quand à la dernière je lui ai déjà appris les petites additions à deux chiffres sans retenue. Et non, elles n'appliquent pas bêtement une recette sans la comprendre.

                    surtout que ton exemple est généralement présenté comme itératif et non fonctionnel

                    Euh, une récursion fonctionnelle c'est itératif. Elle est où ta distinction ? Un procédé récursif ou itératif, c'est bonnet blanc et blanc bonnet. Quand une personne se dit que pour une poule, il faut un œuf, mais que pour un œuf, il faut aussi une poule, puis qu'elle réitère (note bien le choix du verbe), elle fait de la récursion. Le problème ici étant : quelle est la condition d'arrêt ?

                    Mais rassure moi, pour l'algorithme d'Euclide, on ne vous le présentait pas autrement qu'avec ce one liner ?

                    let rec pgcd a b = match (a mod b) with 0 -> b | r -> pgcd b r
                    
                    (* exemple *)
                    pgcd 21 15;;
                    - : int = 3

                    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                    • [^] # Re: Pour alimenter la discussion ...

                      Posté par  . Évalué à 2.

                      Je t'accorde que tous n'y arrivaient pas

                      De ce que je lis 40% des élèves n'y arrivaient pas. Si à coté on regarde ceux qui appliquent sans réfléchir.

                      Euh, une récursion fonctionnelle c'est itératif. Elle est où ta distinction ?

                      Je ne saurais pas dire comme ça, mais je rapproche plus l'addition posée d'un comptage des doigts de sa main gauche avec l'index de sa main droite que d'une récursion. Oui on peut l'exprimer de manière récursive, mais je ne pense pas que ça puisse être considéré de la maitrise de la récursion.

                      Mais rassure moi, pour l'algorithme d'Euclide, on ne vous le présentait pas autrement qu'avec ce one liner ?

                      Hum pas vraiment. Je l'ai appris d'une manière vraiment scolaire ainsi perso :

                      1. tu prends le reste de la division entière le plus grand des 2 nombres par le plus petit
                      2. tu remplace le plus grand nombre par ce reste
                      3. si ce reste n'est pas égale à 0, prendre au point 1
                      4. sinon le résultat c'est le dernier reste différent de 0

                      Oui, on peut dire pleins de choses sur la non élégance de cet algo, mais c'est vraiment un truc comme ça que j'ai appris.

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                      • [^] # Re: Pour alimenter la discussion ...

                        Posté par  . Évalué à 2.

                        Oui, on peut dire pleins de choses sur la non élégance de cet algo, mais c'est vraiment un truc comme ça que j'ai appris.

                        C'est le bon algo, avec néanmoins une comparaison inutile entre les deux nombres. Le principe est celui-ci :

                        1. prendre deux nombres a et b
                        2. calculer le reste r de la division de a par b
                        3. si r est nul, b est le pgcd recherché
                        4. sinon recommencer en 1 avec b et r

                        et c'est ce que fait ma boucle en un one liner. Il n'est pas nécessaire de chercher à savoir lequel des deux nombres est le plus grand. Si b est plus grand que a, le reste est a, et le point 4 remet tout dans le bon ordre au premier tour. Ensuite, le reste, qui servira de diviseur, sera toujours plus petit que le dividende.

                        De ce que je lis 40% des élèves n'y arrivaient pas.

                        J'ai eu beau cherché dans ce document, je ne vois pas d'où tu tires ce nombre. De mémoire, on était bien moins de 60% à y arriver. J'ai raconté cette anecdote pour montrer que le changement de base était accessible à certain élèves de primaires (les plus doués en maths d'entre eux) et qu'il devait donc être une formalité pour des étudiants dans le supérieur (ceux qui font des études d'info). Ceci étant, je me demande la part d'enfants qui appliquent sans comprendre et ceux qui comprennent réellement : la raison leur est enseignée (voir par exemple la chaîne lumni lancée pendant le confinement) mais combien la retienne et la comprenne réellement, je ne le sais.

                        Ceci étant, je maintiens que, comme pour le pgcg, l'alogrithme est hautement récursif et fonctionnel :

                        let ajouter_chiffre c1 c2 =
                          let res = c1 + c2 in
                          if res < 10 then (res, 0) else (res - 10 , 1)
                        
                        let additionner l1 l2 =
                          let rec loop (res, retenue) m n =
                            match m, n with
                            | c1 :: reste1, c2 :: reste2 ->
                               let c, retenue = ajouter_chiffre c1 (c2 + retenue) in
                               loop (c ::res, retenue) reste1 reste2
                            | [], c :: reste | c :: reste, [] ->
                               let c, retenue = ajouter_chiffre c (0 + retenue) in
                               loop (c :: res, retenue) [] reste
                            | [], [] ->
                               List.rev (if retenue = 0 then res else retenue :: res)
                          in loop ([], 0) l1 l2
                        
                        (* 1 + 999 = 1000 *)
                        additionner [1] [9; 9; 9];;
                        - : int list = [0; 0; 0; 1]
                        
                        (* 31 + 35 = 66 *)
                        additionner [1; 3] [5; 3];;
                        - : int list = [6; 6]

                        Ici les nombres sont représentés par une liste de chifres en mode "petit boutiste". Le code lui même reproduit parfaitement les différentes étapes d'apprentissage d'un enfant, et les sources d'erreurs potentielles où il faut prendre garde.

                        L'on apprend d'abord à ajouter des chiffres de petites tailles. Ma nièce en CP est à ce stade là, elle n'a pas encore à gérer le cas de la retenue dans la fonction ajouter_chiffre. Ensuite, lorsque la somme dépasse la dizaine, on leur enseigne que l'on crée un paquet de dix (ou dizaine) et que l'on garde le reste : deuxième branche du if then else de la fonction ajouter_chiffre. C'est là que se situe l'origine et la raison d'être de la retenue.

                        Ensuite, lorsque l'on pose l'addition, on a deux listes de chiffres puis l'on a va en construire une autre (sans modifier les deux en entrées) en appliquant itérativement (c'est-à-dire récursivement) l'addition de chiffre sur nos deux listes jusqu'à épuisement complet.

                        De plus, les différentes branches montre bien deux sources d'erreurs ou de confusion qui arrive au cours de l'apprentissage :

                        • la première étant qu'un enfant peut ne pas savoir quoi faire lorsqu'il a épuisé une liste mais pas l'autre (deuxième branche du code)
                        • la seconde étant qu'au début ils leur arrivent souvent d'oublier de redescendre la retenue s'il en reste une à la fin (le if then else de la dernière branche).

                        Enfin, la méthode est facilement généralisable pour un programmeur (ou un enfant dont le niveau d'abstraction est suffisamment développé). Ici la base est codée en dur dans l'addition de chiffres : il suffit d'en faire un paramètre. ;-)

                        (* le tilde ~ devant le paramètre est là pour avoir
                            un paramètre nommé *)
                        let ajoute_chiffre ~base c1 c2 =
                          let res = c1 + c2 in
                          if res < base then (res, 0) else (res - base , 1)
                        
                        let additionner ~base l1 l2 =
                          let rec loop (res, retenue) m n =
                            match m, n with
                            | c1 :: reste1, c2 :: reste2 ->
                               let c, retenue = ajoute_chiffre ~base c1 (c2 + retenue) in
                               loop (c ::res, retenue) reste1 reste2
                            | [], c :: reste | c :: reste, [] ->
                               let c, retenue = ajoute_chiffre c ~base (0 + retenue) in
                               loop (c :: res, retenue) [] reste
                            | [], [] ->
                               List.rev (if retenue = 0 then res else retenue :: res)
                          in loop ([], 0) l1 l2
                        
                        (* exemples *)
                        (* 31 + 35 = 66 en base 10 *)
                        additionner ~base:10 [1; 3] [5; 3];;
                        - : int list = [6; 6]
                        
                        (* la même en base 16 *)
                        additionner ~base:16 [15; 1] [3; 2];;
                        - : int list = [2; 4]
                        
                        (* puis en base 13 *)
                        additionner ~base:13 [5; 2] [9; 2];;
                        - : int list = [1; 5]

                        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

    • [^] # Re: Pour alimenter la discussion ...

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

      lisible?

      pour avoir créer un nouveau système d'aviation que son précédent était en ruby…. c'est plus que difficile à lire, même les auteurs originaux avait de la difficulté

      www.solutions-norenda.com

  • # J'aime pyhton car

    Posté par  . Évalué à 2.

    Je travaille dans plein de domaines différents. Et partout je peux utiliser le même langage pour le faire. Piloter mon k8s, faire du web avec django, pousser mes données dans kafka, faire du reporting dans plein de format différents, traiter beaucoup de données et faire de l'apprentissage avec. Utiliser une base graph ou une base relationnelle avec la meme interface. Un seul langage, plein d'usage différents.

    Après je suis pas quelqu'un de très intelligent. Et j'ai le sentiment que même moi qui ne suis pas un super dev je peux faire des trucs qui marchent bien qui sont simples et qui marchent longtemps. Alors que en Java il me semble que pour faire des trucs top, kafka par exemple, il faut etre très bon. Un dev moyen en java peut vraiment faire des trucs pas top.

    Je viens de migrer une application java qui a 3go de source et qui met 15min à compliler dans gitlab et k8s et je trouve ca quand même très lourd.

    • [^] # Re: J'aime pyhton car

      Posté par  . Évalué à 1.

      Après je suis pas quelqu'un de très intelligent. Et j'ai le sentiment que même moi qui ne suis pas un super dev je peux faire des trucs qui marchent bien qui sont simples et qui marchent longtemps. Alors que en Java il me semble que pour faire des trucs top, kafka par exemple, il faut etre très bon. Un dev moyen en java peut vraiment faire des trucs pas top.

      Tu piques ma curiosité, je m'intéresse aux systèmes orientés messages, et j'aimerais bien que tu donnes un exemple de problème qui serait rendu plus simple par python.
      Dans ce type de situation, c'est souvent le framework qui fait la différence.

      Je viens de migrer une application java qui a 3go de source et qui met 15min à compliler dans gitlab et k8s et je trouve ca quand même très lourd.

      3 Go !? Est ce que tu penses vraiment que c'est une preuve de la verbosité ou de la complexité de java ?
      Parce que 3 Go ça doit faire plusieurs millions de lignes.

      • [^] # Re: J'aime pyhton car

        Posté par  . Évalué à 1.

        Je ne dis pas que c'est plus simple. Je dis que avec un seul langage je peux aussi faire ca. Et question performance et fonctionnalités c'est parfait vu que c'est la lib en c qui est utilisée.

        Pour Java je dirais que ca illustre le niveau qu'il faut avoir pour rester propre concis et efficace.

    • [^] # Re: J'aime pyhton car

      Posté par  . Évalué à 3. Dernière modification le 09 novembre 2020 à 12:46.

      C’est quoi comme genre d’appli qui a 3Go de sources ?

      • [^] # Re: J'aime pyhton car

        Posté par  . Évalué à 2.

        Le kernel linux réécrit en Java !

      • [^] # Re: J'aime pyhton car

        Posté par  . Évalué à 1.

        un outil intégré pour de la gestion administrative dans un secteur particulier. Paye, compta etc. En gros ça gère la paperasse des entreprises d'un secteur bien particulier. C'est très complet comme application. D’où la taille je pense. Mais quand même.

        • [^] # Re: J'aime pyhton car

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

          en somme un erp…

          pour avoir bossé sur un système avec une approche à la sap avec des centaines de tables et écran…. on était même pas à 1/3 de cette taille…

          www.solutions-norenda.com

          • [^] # Re: J'aime pyhton car

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

            Pour infos :

            SAP R/3 doit atteindre les 9000 tables, à valider par un spécialiste je l'ai lu qq part il y a longtemps

            Sage X3 : que je connais un peu plus environ 1500 tables et plus de 200 000 objets (fenetres, traitements, etats etc … )

            Un environnement complet avec données de tests c'est plus de 30 Go

            Cela couvre pas mal de domaine quand même : Vente Achat Stock Compta Crm Prod Finance etc …

            • [^] # Re: J'aime pyhton car

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

              c'était il y a environ 10 ans… et sap ne dépassait pas dans les 1100…
              avec des jeux de données, tu peux aisément dépasser la taille des sources d'un système

              www.solutions-norenda.com

            • [^] # Re: J'aime pyhton car

              Posté par  . Évalué à 2.

              Il doit exister quelques cas surtout si ça inclut des assets et des scripts de déploiement voir des données. Mais l'argument, j'ai vu une appli comme ça en langage X donc je préfère le langage Y ne me paraît pas très solide.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: J'aime pyhton car

                Posté par  . Évalué à 0.

                ce n'est pas ce que je dis. Si je me suis mal exprimé j'en suis désolé. Mon propos est de dire que il me semble que pour faire du bon java il faut être très bon. Pour faire du bon python il ne me semble pas que ce soit nécessaire. Je ne crois pas qu'il y est un PEP 20 en java ;)

                • [^] # Re: J'aime pyhton car

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

                  c'est quoi faire du bon java, bon python?

                  www.solutions-norenda.com

                  • [^] # Re: J'aime pyhton car

                    Posté par  . Évalué à -2.

                    Je dirais que du bon code dans un langage c'est l'utiliser de la manière dont il a été pensé. Ou pas d'ailleurs.

                    J'ai le sentiment que python a été pensé. En tout les cas c'est ce que je ressens quand je m'en sers. Rien n'est frustrant. Tout vient bien. Bin ok sauf le moteur de regexp que je trouve trop complexe.

                    A contrario je n'ai pas l'impression que Java ait été pensé mais que c'est plus un mille-feuille résultats d'années de baston entre entreprises qui veulent rajouter leur truc à eux par dessus. Et dans ce cas la faire du bon java c'est savoir faire le tri dans tout ce bordel.

                    • [^] # Re: J'aime pyhton car

                      Posté par  . Évalué à 3.

                      A contrario je n'ai pas l'impression que Java ait été pensé mais que c'est plus un mille-feuille résultats d'années de baston entre entreprises qui veulent rajouter leur truc à eux par dessus. Et dans ce cas la faire du bon java c'est savoir faire le tri dans tout ce bordel.

                      Je ne pense pas que ça vienne de ça. Java a 20 ans et essai de garder la compatibilité la plus longue possible. Tu retrouve donc des API qui ont été pensées à divers moments entre le milieu des années 90 et aujourd'hui. Il me semble que python hésite moins à casser la compatibilité (je crois que ça a été surtout le cas sur la branche 2 et au passage à python 3).

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: J'aime pyhton car

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

      Etre bon en java pour faire du kafka?

      Ta déja utilisé java plus que 5min?

      C'est pas trop les lib, framework qui manque pour cet outil.

      Aller je t'aide puisque tu sembles baratiner assez solide…. Spring boot avec kafka

      www.solutions-norenda.com

Suivre le flux des commentaires

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