Journal "beauté du code"

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
19
29
sept.
2014

Vous parlez beaucoup de la beauté du code, d’une esthétique du code. Comment expliquer à quelqu’un qui n’a jamais codé, à quoi peut ressembler un beau code ?

"Il faut de la simplicité – un beau code est aussi simple que possible – mais aussi de l’expressivité. Car en un sens, on n’écrit pas le code pour sa machine, mais pour les autres programmeurs, qui liront votre code après vous. Certains codes ont une vie très longue : quelqu’un essaiera peut-être de comprendre dans vingt ans ce que vous avez essayé de faire.

Et donc, quand vous écrivez du code, vous essayez de le rendre le plus clair possible. Il doit être clair d’une ligne sur l’autre, mais aussi de façon globale : son architecture doit être limpide. Chaque concept doit avoir une fonction définie et les relations entre les différentes couches du programme doivent être évidentes. Alors le code devient très beau.

Et si quand un problème survient, on peut isoler une des parties du code sans devoir toucher à tout le reste, c’est le plus beau. Si, quand vous touchez quelque chose, tout le reste du code se met à vibrer de partout, alors vous savez que c’est vraiment laid."

http://rue89.nouvelobs.com/2014/09/27/geek-sublime-code-cest-emotionnel-254952

  • # le goût et les couleurs

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

    Si, quand vous touchez quelque chose, tout le reste du code se met à vibrer de partout, alors vous savez que c’est vraiment laid

    Cette phrase a fait resurgir en moi des souvenirs de thèse que j'aurais aimé oublier :-)

    Je trouve que s/beau/maintenable/ serait plus exact, on peut trouver certaines constructions élégantes alors qu'elles ne sont pas pour autant maintenables…

    • [^] # Re: le goût et les couleurs

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

      Si c'est pas maintenable, alors c'est laid, je ne vois pas comment cela pourrait être autrement. Ce que tu appelles élégant, ça doit plutôt s'appeler la feinte du corbeau à 5 becs, c'est malin, c'est rusé, c'est ce que tu veux mais c'est pas beau.

      Beau devrait certainement être un mélange de maintenable, donc facile à lire, le moins verbeux possible et le plus rapide possible.

      • [^] # Re: le goût et les couleurs

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

        Un peu d'ouverture d'esprit, je te prie.

        Une pâquerette, certains trouvent ça beau, d'autres trouvent ça moche. Rien à voir avec des critères objectifs. Allez je vais te citer un extrait de http://rue89.nouvelobs.com/2014/09/27/geek-sublime-code-cest-emotionnel-254952

        N’est-ce pas un peu abusif de la part des codeurs de se revendiquer artistes – juste une façon pour eux de gagner un prestige qu’ils ne méritent pas vraiment ?

        Je suis d’accord avec vous ! C’est une méprise sur la nature de l’art et du travail d’artiste. Les programmeurs ont tendance à croire énormément en la rationalité : « Quoi qu’il arrive dans le monde, je peux le comprendre. » Du coup, face à la question « comment être un artiste ? », ils se disent : « Bon, si je réfléchis là-dessus un petit moment, je vais pouvoir moi aussi être un artiste. » [Rires.]

        • [^] # Re: le goût et les couleurs

          Posté par  . Évalué à 3.

          gagner un prestige qu’ils ne méritent pas vraiment ?

          Hors du fait qu'un développeur est ou non un artiste, qu'est-ce qui fait que quelqu'un mérite ou pas de se revendiquer artiste ?

          Pour ce qui est des codeurs :
          Quel est l'apport de se considérer comme un artiste ? Est-ce qu'ils sont reconnus socialement comme des artistes ?
          La technique est-elle toujours décorrélé de l'artistique ? Les gens qui font des effets spéciaux, les développeurs de jeux vidéos, ceux qui créent des jeux, les prestidigitateurs, les gens qui faisaient des automates ne sont-ils pas des artistes ?

          La beauté du code permet de donner un objectif de qualité qui est tellement compliqué qu'on arrive pas à le définir, n'est-ce pas là le propre de la beauté artistique (on peut facilement dire pourquoi quelque chose est beau ou ne l'est pas, mais décrire de manière factuel comment obtenir quelque chose de beau est une autre paire de manche) ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: le goût et les couleurs

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

            Les gens qui font des effets spéciaux, les développeurs de jeux vidéos, ceux qui créent des jeux, les prestidigitateurs, les gens qui faisaient des automates ne sont-ils pas des artistes ?

            Je dirais plutôt que ce sont des artisans : ils maîtrisent une, ou plusieurs, techniques, pour créer des objets qui correspondent à certains canons de la beauté.

            Les artistes ne produisent pas du beau, mais du sens.

            « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

            • [^] # Re: le goût et les couleurs

              Posté par  . Évalué à 9.

              Précisément, la frontière artisan/artiste est assez floue.

            • [^] # Re: le goût et les couleurs

              Posté par  . Évalué à 2.

              Les artistes ne produisent pas du beau, mais du sens.

              Mais encore ?

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: le goût et les couleurs

                Posté par  . Évalué à 10.

                Par là : →

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: le goût et les couleurs

              Posté par  . Évalué à 0.

              Les artistes ne produisent pas du beau, mais du sens.

              Je dirais plutôt qu'ils produisent (sont censés produire) de l’émotion.

            • [^] # Re: le goût et les couleurs

              Posté par  . Évalué à 3. Dernière modification le 29 septembre 2014 à 18:01.

              Les artistes ne produisent pas du beau, mais du sens.

              Le philosophe et le mathématicien seraient donc des artistes ?

            • [^] # Re: le goût et les couleurs

              Posté par  (site web personnel) . Évalué à 2. Dernière modification le 29 septembre 2014 à 18:49.

              Les artistes ne produisent pas du beau, mais du sens.

              Faux: les artistes disent produire du sens. Mais souvent ça n'a aucun sens, et c'est juste de la branlette.
              Il y a aussi beaucoup de personnes qui se disent artistes mais ne sont pas plus artistes qu'un gamain de 2 ans.

              Bref, de quel droit dis-tu qu'une personne est artiste ou pas, suivant quels critères, des vrais, hein, pas un "du sens" parce que bon, un codeur produit aussi du sens?

              ils maîtrisent une, ou plusieurs, techniques, pour créer des objets qui correspondent à certains canons de la beauté.

              Tiens, cette définition marche avec 99% des gens qui se disent artistes…

              Est-ce qu'ils sont reconnus socialement comme des artistes ?

              Socialement, on a de tout et n'importe quoi (un truc hyper moche va être considéré comme une "oeuvre", jsute parce que la personne a trouvé un mécène qui va bien), des gens sont morts puis on a trouvé qu'ils sont artistes, ça n'est pas vraiment un critère. Les codeurs sont les artistes qui seront reconnus comme tels dans 100 ans, comme d'autres personnes sont des "références de l'art" des dizaines d'années après leur mort (et avant, c'était juste des nuls dont on se foutait).

              • [^] # Re: le goût et les couleurs

                Posté par  . Évalué à 10.

                Faux: les artistes disent produire du sens. Mais souvent ça n'a aucun sens, et c'est juste de la branlette.
                Il y a aussi beaucoup de personnes qui se disent artistes mais ne sont pas plus artistes qu'un gamain de 2 ans.

                Conclusion : Zenitram est un artiste (et le post auquel je réponds le prouve).

          • [^] # Re: le goût et les couleurs

            Posté par  . Évalué à 2.

            on peut facilement dire pourquoi quelque chose est beau ou ne l'est pas

            Oulala, ce n'est pas si evident que celà.
            Le "beau" est-il universel? Je pense (avec certains philosophes) que le beau n'est pas universel, et qu'il s'agit plutôt d'un concept essentiellement culturel et sociologique. (en gros, tu prends un type que t'aurai trouvé d'une tribue recement decouverte, tu le met devant mona lisa ou la tour effel, il va pas trouver celà plus "beau" que le resto macdo d'a coté)

            Oui… je sais, ca n'a rien avoir avec le sujet, c'est juste pour dire :)

    • [^] # Re: le goût et les couleurs

      Posté par  . Évalué à 3.

      Cette phrase a fait resurgir en moi des souvenirs de thèse que j'aurais aimé oublier :-)

      Tu parles de ça ?

  • # Ceci n'est pas un troll.

    Posté par  . Évalué à 4.

    Lors d'une formation SCRUM on m'a expliqué qu'il était important de faire du code bien crade pour que ça nous fasse plaisir de tout démolir lorsqu'il faut rajouter une fonctionnalité (le mec était spécialiste .NET).

    Le beau code, c'est très surfait.

    • [^] # Re: Ceci n'est pas un troll.

      Posté par  . Évalué à 4.

      Merci à ceux qui appliquent ces principes, ça fait une semaine que je dois retracer ce que fait un fichier de 3000 lignes. Ça me fera très plaisir de le supprimer et faire la même chose en 2 ou 3 modules bien segmentés.

      • [^] # Re: Ceci n'est pas un troll.

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

        ça fait une semaine que je dois retracer ce que fait un fichier de 3000 lignes.

        hum, 3000 lignes c'est rien du tout hein :-)
        Je connais des softs dont 1 méthode dépasse déjà plusieurs centaines de lignes et où les tailles de fichiers sont à 5 chiffres…

        • [^] # Re: Ceci n'est pas un troll.

          Posté par  . Évalué à 1.

          Je connais des softs dont 1 méthode dépasse déjà plusieurs centaines de lignes et où les tailles de fichiers sont à 5 chiffres…

          Si c'est du Java, ça ne compte pas. Quel est réellement la taille du code effectif. :)

        • [^] # Re: Ceci n'est pas un troll.

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

          Vim ? Un demi-mega octet pour le fichier eval.c . J'arrive plus à retrouver des mega-fonctions mais il y en a pléthore !

  • # Plutôt beauté du design

    Posté par  . Évalué à 10.

    C'est un peu exagéré de parler de beauté du code comme un objectif.

    En effet, parfois on tombe sur des morceaux de code magnifiques: une astuce qui utilise le language en dehors de l'usage courant, un problème résolu de manière ultra succinte avec un language fonctionnel, un one-liner en shell. Les coding contest montrent aussi des résultats assez hallucinants parfois, sans parler des démo ASM en quelques K…

    Toutefois, dans un milieu pro, c'est rarement les lignes de codes en elles même qui font notre fierté. C'est plutôt la structure de l'application, les structures de données utilisées, la complexité résultant de leur usage et parfois l'anticipation de futurs changements.

    Quoi de plus jouissif quand le client demande un changement assez complexe et que l'on s'aperçoit qu'il ne nécessitera que très peu d'adaptations parce que notre développement à toujours favorisé une certaine généricité plutôt que l'accumulation de hacks crados qui auraient pu rendre le code très spécifique. Une bonne structure et le code qui va avec se réusinent bien en général.

    • [^] # Re: Plutôt beauté du design

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

      Une bonne structure et le code qui va avec se réusinent bien en général.

      Je pense que cela rentre précisément dans ce qu'il appelle le beau code.

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

    • [^] # Re: Plutôt beauté du design

      Posté par  . Évalué à 3.

      En effet, parfois on tombe sur des morceaux de code magnifiques: une astuce

      AMHA du code beau n'est pas astucieux. Une astuce c'est un truc qui peut casser dès qu'on met à jour le compilateur et/ou le runtime ou dès qu'on change d'environnement. Un code beau tente d'être concis mais sans être succin. On peut souligner la beauté du geste des participants à IOCCC, mais pas la beauté de leur code.

      Personnellement pour moi un code beau c'est celui qui va avoir une séparation nette entre la technique et le métier. Du coté métier on manipule des concepts métier (j'augmente tous les employés) dans la technique on implémente les concepts métiers (un employé c'est …, une augmentation c'est…).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Plutôt beauté du design

        Posté par  . Évalué à 1.

        (Les avatars rendent la mise en page foireuse,
        cet espèce d'ipse lorem ipsum tagadum
        règle le problème)

        C'est astucieux et beau :

        float Q_rsqrt( float number ){
            long i;
            float x2, y;
            const float threehalfs = 1.5F;
        
            x2 = number * 0.5F;
            y  = number;
            i  = * ( long * ) &y; // evil floating point bit level hacking
            i  = 0x5f3759df - ( i >> 1 ); // what the fuck?
            y  = * ( float * ) &i;
            y  = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
            // y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed
        
            #ifndef Q3_VM
            #ifdef __linux__
              assert( !isnan(y) ); // bk010122 - FPE?
            #endif
            #endif
            return y;
        }

        source: Id Tech 3

        • [^] # Re: Plutôt beauté du design

          Posté par  . Évalué à 4.

          Dommage que ce soit du code incorrect (warning: dereferencing type-punned pointer will break strict-aliasing rules) et que ce soit moins performant qu'un calcul explicite avec sqrt.

          C'est une curiosité intéressante mais je veux éviter d'avoir ce genre de chose dans mon code.

          • [^] # Re: Plutôt beauté du design

            Posté par  (site web personnel) . Évalué à 1. Dernière modification le 29 septembre 2014 à 17:19.

            Il ne s'agit pas du calcul d'une racine carrée, mais du calcul rapide de l'inverse d'une racine carrée:
            https://fr.wikipedia.org/wiki/Racine_carr%C3%A9e_inverse_rapide

            • [^] # Re: Plutôt beauté du design

              Posté par  . Évalué à 4.

              D'après https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723 lorsque l'on écrit 1/sqrt(x) et que l'on compile avec -ffast-math c'est plus rapide (et précis) que cette astuce.

              Il optimise aussi sqrt(x) en x*1/sqtr(x) qui est plus rapide !

              • [^] # Re: Plutôt beauté du design

                Posté par  . Évalué à 4.

                Enfin ce code est issu de "id Tech 3" qui d'après Wikipedia date de fin 1999.
                Depuis les compilateurs/processeurs se sont peut-être suffisamment améliorés pour rendre obsolète ce genre d'astuce.

                Pour moi ce code est peut-être au choix:
                - une solution élégante à un problème rencontré par les développeurs à l'époque : mise en oeuvre d'une approximation mathématique, plus rapide et dispo sur toutes les plateformes tout en s'assurant que ses défauts n'étaient pas gênants pour le domaine concerné.
                - ou l'exemple typique de chose à ne pas faire (si c'était juste pour le fun).

                • [^] # Re: Plutôt beauté du design

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

                  De mémoire, c'est surtout les multiplieurs en un seul cycle qui rende cette astuce inutile.

                  sqrt(x) est une instruction lente quand elle existe, genre en n cycles, n étant le nombre de bit du nombre. 1/sqrt(x) est au contraire rapide, souvent un seul cycle, et est donc souvent présente dans les jeux d'instruction.

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

                  • [^] # Re: Plutôt beauté du design

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

                    Oui, c'est typiquement une approximation de 1/sqrt sur 11 bits qui est fournie par les processeurs modernes via les instructions sse / vmx / neon etc (peut etre même en faisant des calculs similaires niveau hardware à ceux de quake ! qui sait). Si l'utilisateur veut une sqrt de precision superieure il doit faire une ou deux iterations de newton pour raffiner le resultat.

        • [^] # Re: Plutôt beauté du design

          Posté par  . Évalué à 8.

          C'est efficace, mais est-ce que c'est beau ? (est-ce qu'un code avec comme commentaire "what the fuck ?" est beau)

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Plutôt beauté du design

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

            Comme on l'a dit plus haut, le code est destiné à être lu par un compilateur mais surtout par des programmeurs: pour apprécier les qualités ou les défauts du dit code, il faut donc tenir compte de son public de lecture.

            Si le public est formé de développeurs généralistes, tout le monde est d'accord pour dire que le snippet en question est tout pourri. On peut cependant imaginer qu'un labo de numériciens a une culture et un folklore complètement différent, qui modifie complètement les besoins qu'ils peuvent avoir en termes de commentaires ou de références à des articles publiés — ou autres documents du même genre.

            Pour en revenir au bout de code en question, des recherches archéolgiques te donnent raison: personne ne semble vraiment capable d'expliquer en détails comment marche la fonction!

            • [^] # Re: Plutôt beauté du design

              Posté par  . Évalué à 4.

              Pour en revenir au bout de code en question, des recherches archéolgiques te donnent raison: personne ne semble vraiment capable d'expliquer en détails comment marche la fonction!

              C'est très loin d'être mon impression en lisant le lien :

              How the code works

              The magic of the code, even if you can't follow it, stands out as the i = 0x5f3759df - (i>>1); line. Simplified, Newton-Raphson is an approximation that starts off with a guess and refines it with iteration. Taking advantage of the nature of 32-bit x86 processors, i, an integer, is initially set to the value of the floating point number you want to take the inverse square of, using an integer cast. i is then set to 0x5f3759df, minus itself shifted one bit to the right. The right shift drops the least significant bit of i, essentially halving it.

              Using the integer cast of the seeded value, i is reused and the initial guess for Newton is calculated using the magic seed value minus a free divide by 2 courtesy of the CPU.

              But why that constant to start the guessing game? Chris Lomont wrote a paper analysing it while at Purdue in 2003. He'd seen the code on the gamedev.net forums and that's probably also where DemoCoder saw it before commenting in the first NV40 Doom3 thread on B3D. Chris's analysis for his paper explains it for those interested in the base math behind the implementation. Suffice to say the constant used to start the Newton iteration is a very clever one. The paper's summary wonders who wrote it and whether they got there by guessing or derivation.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Plutôt beauté du design

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

                C'est très loin d'être mon impression en lisant le lien […]

                Et bien merci pour cette correction, j'étais complètement passé à côté de cet article de Chris Lomont!

        • [^] # Re: Plutôt beauté du design

          Posté par  . Évalué à 4. Dernière modification le 29 septembre 2014 à 16:13.

          Je ne sais pas ce que l'auteur de la dépêche avait en tête en parlant de beau code.
          Mais moi, cela me fait plutôt penser à une architecture fonctionnelle, bien pensée et bien écrite pour ton logiciel.

          Là tu présentes une astuce mathématique pour améliorer (ou pas, cette astuce est ancienne, elle a peut-être déjà été prise en compte dans les architecture/runtime récent) la performance de la fonction racine carrée.

          C'est une belle astuce mathématique, mais cela n'a pas de sens pour moi, d'essayer de qualifier ce code de beau ou non.
          À part peut-être pour le style comme le choix des noms de variables, l'indentation, …

          • [^] # Re: Plutôt beauté du design

            Posté par  . Évalué à 1.

            Je ne sais pas ce que l'auteur de la dépêche avait en tête en parlant de beau code.

            À mon avis, c'était à peu près le contraire de celui qui est présenté en exemple.

            Là tu présentes une astuce mathématique

            Certainement pas "mathématique". C'est une sorte d'heuristique algorithmique, un peu du même genre que "sin(60°) ~ e/π". Plus bricolé que ça, c'est pas possible.

            • [^] # Re: Plutôt beauté du design

              Posté par  . Évalué à 3.

              Certainement pas "mathématique". C'est une sorte d'heuristique algorithmique, un peu du même genre que "sin(60°) ~ e/π"

              j'appelle ça mathématique moi.
              C'est peut-être le fait que ce soit une approximation ou qu'elle se sert de la représentation binaire des nombres qui te donne l'impression que ça ne l'est pas ?

              • [^] # Re: Plutôt beauté du design

                Posté par  . Évalué à -1.

                À mes yeux, dès qu'on passe dans le domaine de l'approximation, on sort des mathématiques, c'est à dire de la représentation symbolique, pour passer dans l'imperfection du monde réel.

                Il peut exister des astuces mathématiques, par exemple l'accélération d'un algorithme par la recherche de solutions entières avant de passer à une résolution numérique. On pourrait même discuter de l'aspect mathématique de certaines approximations numériques (séries de Taylor, etc), qui consistent à prendre un résultat mathématique (une série infinie) et à le tronquer pour l'implémenter dans un algorithme. Mais là, l'exemple dont on parle, c'est l'exploitation d'une coïncidence numérique fortuite pour accélérer un calcul. C'est certainement ingénieux et utile, on peut même trouver ça génial, mais "beau"? Je sais bien que tous les goûts sont dans la nature, mais je pense qu'on est quand même à l'extrême limite de ce qu'un être humain peut trouver beau être atteint d'une pathologie quelconque :-)

                Pour moi, ce code est aussi beau qu'un cardan de suspension. Il est probablement fonctionnel, mais il n'est pas fait pour être regardé, encore moins admiré.

                • [^] # Re: Plutôt beauté du design

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

                  On pourrait même discuter de l'aspect mathématique de certaines approximations numériques (séries de Taylor, etc), qui consistent à prendre un résultat mathématique (une série infinie) et à le tronquer pour l'implémenter dans un algorithme.

                  Y'a quand meme une iteration de newton-raphson dans l'algo en question, ça me semble être un parfait exemple de ce que tu cites

                  • [^] # Re: Plutôt beauté du design

                    Posté par  . Évalué à 1.

                    Je ne pense pas que la discussion porte sur cette ligne de code :-) Évidemment, si on trouve un diamant dans une crotte de chien, on peut voir le diamant, ou la crotte de chien :-)

                  • [^] # Re: Plutôt beauté du design

                    Posté par  . Évalué à 3.

                    Je me permets de me re-répondre, pour me contredire : ce code est une abomination mathématique, parce qu'il préfère une valeur de départ moins bonne (d'après Wikipédia, 0x5f37642f donne une meilleure valeur de départ que 0x5f3759df), pour la simple raison qu'un seul tour de Newton donne une meilleure approximation finale (!). On n'est donc dans le bricolage crado le plus total—bricolage génial, mais c'est crade du début à la fin).

                • [^] # Re: Plutôt beauté du design

                  Posté par  . Évalué à 2. Dernière modification le 30 septembre 2014 à 10:30.

                  À mes yeux, dès qu'on passe dans le domaine de l'approximation, on sort des mathématiques

                  en mathématiques, on approche les fonctions trigonométriques par des polynômes (on approche tout par des polynome d'ailleurs)

                  On pourrait même discuter de l'aspect mathématique de certaines approximations numériques (séries de Taylor, etc), qui consistent à prendre un résultat mathématique (une série infinie) et à le tronquer pour l'implémenter dans un algorithme.

                  C'est donc bien une approche mathématique, c'est son implémentation numérique qui en réduit la précision, et quand on veut faire une approximation pour une valeur numérique en particulier, il faut bien, de toute façon, stopper le calcul à un moment donné.

                  Mais là, l'exemple dont on parle, c'est l'exploitation d'une coïncidence numérique fortuite pour accélérer un calcul.

                  Pourquoi une coïncidence ? les constantes n'ont pas été choisies au hasard

                  C'est certainement ingénieux et utile, on peut même trouver ça génial, mais "beau"?

                  Je n'ai jamais prétendu que ce code était beau, je le trouve même très moche, d'un point de vu des noms de variables et des commentaires par exemple. Je ne laisserai jamais passer ça sous cette forme dans ma boite ! Mais j'accepterai sans problèmes l'astuce mathématique si elle à un sens à l'endroit ou elle est utilisée. C'est juste un problème de forme pour moi.

                  Il est probablement fonctionnel, mais il n'est pas fait pour être regardé, encore moins admiré.

                  Il n'est surtout pas fait pour être commité !
                  - des noms de variables à une lettre qui n'ont aucun sens.
                  - une constante dans une variable (threehalf), les autres directement dans le code ???
                  - des commentaires (en très petite quantité) qui n'ont strictement aucune utilité pour comprendre le code…

                  Le type qui me propose ça dans ma boite, je lui interdit le droit de commit à lui et sa famille sur 42 générations…

                  • [^] # Re: Plutôt beauté du design

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

                    Le type qui me propose ça dans ma boite, je lui interdit le droit de commit à lui et sa famille sur 42 générations…

                    Tu sais que tu parles de John Carmack, un des meilleurs codeurs de tous les temps ? https://fr.wikipedia.org/wiki/John_Carmack

                    Les génies sont incompris…

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

                    • [^] # Re: Plutôt beauté du design

                      Posté par  . Évalué à 10. Dernière modification le 30 septembre 2014 à 11:40.

                      Je viens de vérifier, et effectivement, il n'a pas les autorisations pour commiter ! Ouf !

                    • [^] # Re: Plutôt beauté du design

                      Posté par  . Évalué à 5.

                      Tu sais que tu parles de John Carmack, un des meilleurs codeurs de tous les temps ?

                      Tout le monde aimerait que ce soit vrai mais c'est une légende urbaine. John Carmack n'a pas écrit cette fonction.

                      • [^] # Re: Plutôt beauté du design

                        Posté par  . Évalué à 2. Dernière modification le 01 octobre 2014 à 11:45.

                        Et les fonctions :

                        int Sys_MonkeyShouldBeSpanked( void )

                        C'est qui, qui les a écrit ?

                  • [^] # Re: Plutôt beauté du design

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

                    en mathématiques, on approche les fonctions trigonométriques par des polynômes (on approche tout par des polynome d'ailleurs)

                    C'est assez loin d'être vrai, même pour les fonctions réelles sur un intervalle compact. Tout dépend de ce qu'on veut démontrer.

                • [^] # Re: Plutôt beauté du design

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

                  À mes yeux, dès qu'on passe dans le domaine de l'approximation, on sort des mathématiques, c'est à dire de la représentation symbolique, pour passer dans l'imperfection du monde réel.

                  Faire des approximations c'est l'activité principale de tous les mathéamticiens qui font de l'analyse ou de la géométrie (même algébrique). À part ça, tout va bien!

                  On a le droit de ne pas aimer le calcul numérique, mais pas de le dire comme ça!

                  • [^] # Re: Plutôt beauté du design

                    Posté par  . Évalué à 4.

                    On a le droit de ne pas aimer le calcul numérique, mais pas de le dire comme ça!

                    Beuh, je n'ai jamais dit que je n'aimais pas le calcul numérique, c'est même le contraire, et j'en fais tous les jours. C'est juste que ce n'est pas des mathématiques. Le travail mathématique, c'est de défnir par exemple les équations récursives, de montrer qu'elles convergent, que le résultat est unique et défini, que les fonctions sont dérivables, etc. Mais l'implémentation de ces méthodes et leur utilisation, c'est de l'algorithmique ou de l'informatique, mais je ne comprends pas où est le travail mathématique là-dedans!

                    Après, les mathématiciens peuvent évidemment utiliser eux-mêmes des méthodes numériques dans leur boulot, mais ça ne donne pas magiquement une dimension mathématique à un algorithme…

                    • [^] # Re: Plutôt beauté du design

                      Posté par  . Évalué à 4.

                      Qu'elle est ta définition de "mathématiques" ?

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: Plutôt beauté du design

                        Posté par  . Évalué à 2.

                        Plus ou moins celle de Wikipédia, je pense : "Les mathématiques sont un ensemble de connaissances abstraites résultant de raisonnements logiques appliqués à divers objets tels que les nombres, les figures, les structures et les transformations." […] "Les mathématiques se distinguent des autres sciences par un rapport particulier au réel car l'observation et l'expérience ne s'y portent pas sur des objets physiques".

                        Je veux bien concevoir que tout problème numérique déterministe peut être formalisé sous forme de question à l'apparence mathématique : "à combien de décimales doit-on tronquer le cube d'un nombre en virgule flottante codé en binaire sur une architecture 64 bits pour s'assurer d'une erreur relative inférieure à 10-10 a nécessairement une réponse, trouver cette réponse nécessite d'utiliser des outils mathématiques, mais ça revient à dire que le calcul du brut imposable sur une fiche de paye relève des mathématiques, ou que n'importe quel bout de code est mathématique par nature.

                        Pour être un peu plus clair, je considère que

                        const double pi = 333./106.;

                        est une astuce numérique, alors que

                        const double pi = 6*asin(0.5);

                        est une astuce mathématique. Je n'essaye même pas de faire un classement entre les deux, c'est juste que quand on parle de beau code, les astuces mathématiques me semblent plus élégantes que les astuces numériques (même si elles sont moins optimales, par exemple).

                    • [^] # Re: Plutôt beauté du design

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

                      Le travail mathématique, […]

                      Étant mathématicien je sais assez bien ce qu'est le travail mathématique et je ne vois toujours pas ce qui te permet de tracer une ligne claire entre mathématiques et calcul numérique.

                      Après, les mathématiciens peuvent évidemment utiliser eux-mêmes des méthodes numériques dans leur boulot, mais ça ne donne pas magiquement une dimension mathématique à un algorithme…

                      Les méthodes numériques sont pourtant sujettes à des raisonnements mathématiques! Et il y a même des mathématiciens qui s'y intéressent beaucoup.

            • [^] # Re: Plutôt beauté du design

              Posté par  . Évalué à 0.

              C'est l'inverse de la racine carré.
              Et je trouve ça plus beau (et moins soporifique) qu'un code qui fait ce qu'il doit faire sans aucune originalité.

              • [^] # Re: Plutôt beauté du design

                Posté par  . Évalué à 7.

                Et je trouve ça plus beau (et moins soporifique) qu'un code qui fait ce qu'il doit faire sans aucune originalité.

                Tu lis le code sans comprendre ce qu'il fait (sans avoir un bon gros bagage mathématique et/ou sans avoir lu la page wikipedia), tu as un problème sur ce code y toucher est très dangereux. C'est du code fragile d'un expert que seul un expert peut retoucher.

                C'est une astuce sympa mais je ne trouve pas ça beau. Pour moi le beau doit se lire, tu sais ce qu'il fait et pourquoi.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Plutôt beauté du design

                  Posté par  . Évalué à 0.

                  C'est pour ça qu'on a fait 5 ans d'étude, parfois plus; pour avoir ce bagage.
                  Et avec un peu de TDD ce bout de code n'est pas si dangereux que ça.

                  • [^] # Re: Plutôt beauté du design

                    Posté par  . Évalué à 3.

                    le truc, c'est qu'après les 5 ans d'étude, le niveau n'est pas très homogène… et il y en a qui ne comprendront jamais ce code, peut importe le nombre d'année d'études.

                    Mais dans l'absolu tu as raison, et c'est le sens de ma remarque sur beauté pour quoi, maintenable par qui.

                    • [^] # Commentaire supprimé

                      Posté par  . Évalué à 1.

                      Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Plutôt beauté du design

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

                  Moi j'attends d'avoir enfin un langage qui permet d'exprimer la fonction sous forme d'une approximation utilisant un tour de newton rafson, sans montrer un paquet de constant, ou un paquet ignoble de template ou de macro.

                  Le vrai problème est là : avoir un langage suffisamment expressif pour le codeur qui arrive ensuite, et pour générer exactement ce que l'on veut.

                  C'est souvent fait avec des templates C++, qui devient un langage dans le langage, ou avec des générateurs de code.

                  Souvent, on veut simplement de la "propagation de constante balèze" avec gestion des conteneurs (liste, tableau, string). Par exemple, compiler une expression régulière décrite sous forme de string à la compilation, décrire une forme de code plus rapide (fftw), générer des structures de donnés d'après un modèle (EMF d'Eclipse gère la structure de modèle objet, et la sérialisation XML depuis une DTD ou un modèle UML)…

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

                  • [^] # Re: Plutôt beauté du design

                    Posté par  . Évalué à 3.

                    J'ai vu un RK4 en simulink avec uniquement des blocs de base, pas d'appel à une fonction et je me suis dit que c'était le "langage" idéal pour faire ça. C'était magnifique. Ou pas…

                    (bon ils avaient une raison. Je ne dis pas que c'était une bonne raison, mais au moins c'était une justification. Le tout passait dans un générateur de code pour finalement être compilé vers de l'embarqué, et les "règles" de "codage" autorisent uniquement certains blocs)

                    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                    • [^] # Re: Plutôt beauté du design

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

                      C'est un peu l'idée documenté exactement ce que l'on veut faire, au lieu de mettre le résultat de pré-calcul en dure. Cela permet aussi de relire les pré-calcul.

                      Cela me fait mal de lire que l'exemple que tu donnes, est dans le truc directement concurrent avec ma boite (qui édite SCADE suite), c'est le karma :)

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

                  • [^] # Re: Plutôt beauté du design

                    Posté par  . Évalué à 3.

                    Souvent, on veut simplement de la "propagation de constante balèze" avec gestion des conteneurs (liste, tableau, string). Par exemple, compiler une expression régulière décrite sous forme de string à la compilation, décrire une forme de code plus rapide (fftw), générer des structures de donnés d'après un modèle (EMF d'Eclipse gère la structure de modèle objet, et la sérialisation XML depuis une DTD ou un modèle UML)…

                    C'est vrai que créer programmatiquement des données statiques (au sens où c'est de la donnée et non du calcul dans le binaire) est souvent manquant. Il n'y a guère que les macro (de C/C++, je ne connais pas bien celles de lisp) et les templates C++ qui le permettent (dans les langages classiques). Je ne sais pas si hotspot n'est pas capable d'arriver à ce genre de résultats après un certain temps (mais j'ai jamais vérifié).

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Plutôt beauté du design

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

                      ocaml avec ocamlp4 mais la syntaxe était incompréhensible. On dirait que le nom était bien choisi en rapport avec les reformé du même nom.

                      Ils ont créé un nouveau truc, les points d'extension qui ressemble à des annotations java, histoire de créer des filtres code vers code, comme lisp, mais les exemples sont incomplets. C'est comme si il montrait les appels de fonctions, sans montrer les définitions de fonctions.

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

                    • [^] # Re: Plutôt beauté du design

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

                      les templates C++

                      ou celles de D.

                    • [^] # Re: Plutôt beauté du design

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

                      et les constexpr ? mmh ?

                      • [^] # Re: Plutôt beauté du design

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

                        pas mal.

                        Mais ça c'est vraiment très con :

                        "It can call only other constexpr functions"

                        Cela veut dire pas de lib standard, pas de lecture de fichier, pas d'io, etc…

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

                        • [^] # Re: Plutôt beauté du design

                          Posté par  . Évalué à 2.

                          "It can call only other constexpr functions"

                          ça parait logique.

                          Cela veut dire pas de lib standard, pas de lecture de fichier, pas d'io, etc…

                          la lib standard peu évoluer en proposant des constexpr !
                          Pour la lecture de fichiers, je ne vois pas le souci, un fichier c'est dynamique, si ce que tu veux c'est sont contenu statique au moment de la compilation, il y à la directive #include pour cela.
                          Pour les io, je ne sais pas, mais ça me parait louche, c'est typiquement un truc dynamique, dans quel cas on voudrait avoir un résultat statique d'une lecture d'un io ?

                          • [^] # Re: Plutôt beauté du design

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

                            il y à la directive #include pour cela.

                            oulala… Tu inclus un fichier binaire (jpg) dans un programme avec #include ? Tu réussi à parser un fichier xmi uml ou DTD pour créer des class à la volé avec #include ?

                            dans quel cas on voudrait avoir un résultat statique d'une lecture d'un io ?

                            Quand sa forme se rapproche plus du métier ou du besoin que le code source. C'est la raison d'être des DSL : s'éloigner du code pour s'approcher du problème à résoudre ; cela facilite la relecture, les vérifications, les règles génériques, l'automatisation, etc…

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

                            • [^] # Re: Plutôt beauté du design

                              Posté par  . Évalué à 2.

                              oulala… Tu inclus un fichier binaire (jpg) dans un programme avec #include ? Tu réussi à parser un fichier xmi uml ou DTD pour créer des class à la volé avec #include ?

                              si ce sont des datas binaires, il existe des tas de d'outils qui te permettent de les ajouter dans ton programme et de les retrouver avec.
                              Si tu veux créer des classes à la volée à la compilation, ce dont tu as besoin c'est un outil de génération de code, pourquoi voudrais-tu une fonctionnalité du langague qui permettre de lire ce fichier à la compilation ? Je pense que c'est un faux problème, ou alors, il me manque des informations.

                              Quand sa forme se rapproche plus du métier ou du besoin que le code source. C'est la raison d'être des DSL : s'éloigner du code pour s'approcher du problème à résoudre ; cela facilite la relecture, les vérifications, les règles génériques, l'automatisation, etc…

                              ça ne m'avance pas, quel est ton problème à résoudre ? Une solution sert à résoudre un problème, quand on cherche une solution pour résoudre sa solution, c'est qu'il y a quelque chose qui dans la solution de base, en général, c'est qu'elle n'est pas bonne.

                              • [^] # Re: Plutôt beauté du design

                                Posté par  (site web personnel) . Évalué à 2. Dernière modification le 01 octobre 2014 à 16:07.

                                Si tu veux créer des classes à la volée à la compilation, ce dont tu as besoin c'est un outil de génération de code,

                                Et donc tu utilises 2 outils et 2 langages pour faire quelques choses de très proche, avec tous les problèmes imaginables à l'interface.

                                ça ne m'avance pas, quel est ton problème à résoudre ?

                                J'ai déjà donné des exemples : inclure un binaire sans outils externe, pas de générateur de code externe, mais un générateur en library.

                                Et puis, c'est même pire que ça. Je parle de lire un fichier pour générer des API, et tu me parles "générateur de code", tu imagines la différence de difficulté entre une bonne propagation de constante et un compilateur ?

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

                                • [^] # Re: Plutôt beauté du design

                                  Posté par  . Évalué à 2.

                                  Et donc tu utilises 2 outils et 2 langages pour faire quelques choses de très proche, avec tous les problèmes imaginables à l'interface.

                                  oui.
                                  C'est pas comme si on ne faisait pas déjà ça depuis toujours. flex, bison, moc en sont des exemple parmi d'autres !

                                  J'ai déjà donné des exemples : inclure un binaire sans outils externe, pas de générateur de code externe, mais un générateur en library.

                                  Mais ça, ça n'est pas un problème que tu as, mais une solution que tu proposes.

                                  Et puis, c'est même pire que ça. Je parle de lire un fichier pour générer des API, et tu me parles "générateur de code"

                                  C'est quoi la différence ? une API c'est du code. il existe déjà des tas d'outils qui transforment des graphes uml en code (api seulement)

                                  tu imagines la différence de difficulté entre une bonne propagation de constante et un compilateur ?

                                  Je pense oui, mais ça ne me dit toujours pas pourquoi tu as besoin de ces choses de façon constante dans ton language !
                                  c++ fait des algos, et il le fait très bien, il sait déjà gérer une certaine forme de propagation de constantes, il en gère un peu plus maintenant, si tu veux un meta langage qui fasse autre chose, utilise un autre langage et voila !

                  • [^] # Re: Plutôt beauté du design

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

                    En fait ce que tu veux c'est une forme de propagation de constantes interprocédurales, non ?
                    <pub>Pythran le fait dans certains cas</pub>

                    Par exemple :

                    def fib(n):
                          return n if n < 2 else (fib(n - 1) + fib(n - 2))
                    
                    def foo(): print map(fib, [1,2,3])

                    est transformé (à la compilation) en

                      def fib(n):
                          return (n if (n < 2) else (fib((n - 1)) + fib((n - 2))))
                      def foo():
                          print [1, 1, 2]
                    • [^] # Re: Plutôt beauté du design

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

                      Oui, c'est de la propagation de constante. Sauf qu'en général, dés qu'un conteneur rentre dans la boucle, cela stop (string, list, etc…). Impossible de compiler une regexp par exemple.

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

                      • [^] # Re: Plutôt beauté du design

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

                        J'ai peu de bagage en langages fonctionnels, mais vu les bonnes propriétés de ces derniers, y a pas de compilo qui fait de la propagation de constantes avancées pour ces langages ?

                        • [^] # Re: Plutôt beauté du design

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

                          Haskell fait de la deforestation, qui évite la création d'arbre inutile dans un traitement (genre empilement de map).

                          ocaml fait le minimum. Il fait quelques optimisation haut niveau comme le tail recursif, mais c'est tout : presque pas de propagation de constante, pas d'inlining, pas de spécialisation de fonction, pas de déroulage de boucle.

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

                          • [^] # Re: Plutôt beauté du design

                            Posté par  . Évalué à 4.

                            Ça me surprend, j'ai toujours eu de très bons échos sur les performances d'OCaml.

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                            • [^] # Re: Plutôt beauté du design

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

                              Oui, cela va vite, mais sans se fouler.

                              Le système de typage permet d'éviter tout un tas de programmation défensive. Globalement le modèle haut niveau est très bon, et donc ils n'ont pas jugé utile d'aller plus loin.

                              Mais cela veut surtout dire que doubler les performances de certain code doit être possible.

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

                              • [^] # Re: Plutôt beauté du design

                                Posté par  . Évalué à 4.

                                Je comprends bien, mais le langage n'est plus nouveau, il n'y a vraiment personne qui veut s'y coller ?

                                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                • [^] # Re: Plutôt beauté du design

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

                                  C'est un langage de recherche. Pendant un moment, il y avait 5 ou 6 personnes sur le nouveau système de typage (GADT), mais une demi pour gérer la correction de bugs. Ocaml pro va peut être changer cela.

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

                          • [^] # Re: Plutôt beauté du design

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

                            C'est un peu approximatif! OCaml fait de l'inlining inter-module — des fois il faut motiver le compilateur en ajustant son “agressivité” — et cela me suprprend un peu de voir qu'il ne fait pas du unfolding de boucles — mais peut-être qu'il faut motiver un peu le compilateur en stimulant son agressivité.

                            Si je me souviens bien, le compilateur optimise la taille du programme plutôt que la “vitesse” et je mets des guillemets sur “vitesse” parceque l'inlining et l'unfolding ne sont que spéculativement des optimisation en vitesse, qui sont parfois contredites par l'expérience. L'optimisation en taille est en revanche faite face à un critère complètement objectif.

                            • [^] # Re: Plutôt beauté du design

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

                              je mets des guillemets sur “vitesse” parceque l'inlining et l'unfolding ne sont que spéculativement des optimisation en vitesse,

                              C'est souvent un argument mis en avant contre l'inlining, qui s'avère faux chaque fois que j'en fais l'essaie. Et contrairement, a ce que crois les personnes qui pensent cela, faire de l'inlining réduit le code la plus part du temps, car la propagation de constante/l'élimination de code mort, jouent ensuite leur rôle.

                              L'optimisation en taille est en revanche faite face à un critère complètement objectif.

                              Oui, mais dont on se fout un peu sur nos machines de bureau tant que le binaire n'a pas fait x10 ou x100.

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

                              • [^] # Re: Plutôt beauté du design

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

                                C'est souvent un argument mis en avant contre l'inlining, qui s'avère faux chaque fois que j'en fais l'essaie.

                                D'autres personnes ont des expériences différentes, apparemment.

                                Oui, mais dont on se fout un peu sur nos machines de bureau tant que le binaire n'a pas fait x10 ou x100.

                                Pas forcément, il vaut mieux avoir un boucle for non déroulée qui tient dans le cache L1 qu'une boucle déroulée qui n'y tient pas.

                                C'est une chose qu'on contrôle très mal à l'échelle d'un programme, parceque passer d'un modèle à l'autre (folded/unfolded) change de façon imprévisible la façon dont le code est saucissonné en morceaux de pages de cache.

                                Le comportement normal du compilateur est l'optimisation pour la taille, mais on peut le configurer pour qu'il fasse autre chose.

                                • [^] # Re: Plutôt beauté du design

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

                                  Pas forcément, il vaut mieux avoir un boucle for non déroulée qui tient dans le cache L1 qu'une boucle déroulée qui n'y tient pas.

                                  Je veux dire sur du vrai code de la vrai vie. Tu te rend compte de la taille de code qui rentre dans un cache L1 ? On parle de boucle interne, pour remplir les 16/32/64 Ko de cache L1, il faut sans doute, l'équivalent d'un millier de lignes de code.

                                  C'est une chose qu'on contrôle très mal à l'échelle d'un programme, parceque passer d'un modèle à l'autre (folded/unfolded) change de façon imprévisible la façon dont le code est saucissonné en morceaux de pages de cache.

                                  Oui et sur un code moyen, cela ne change rien. Par contre localement, la différence de performance est énorme. En -O3, gcc a tendance a dérouler les petites boucles 16 fois. J'estime que dérouler 4x fois ne peut jamais faire perdre de performance.

                                  Le comportement normal du compilateur est l'optimisation pour la taille, mais on peut le configurer pour qu'il fasse autre chose.

                                  Tu parles de Ocaml, car tous les compilateurs C optimisent pour la vitesse. Le "-Os" de gcc évitent seulement les optimisations connues pour faire enfler le code.

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

                                  • [^] # Re: Plutôt beauté du design

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

                                    Je veux dire sur du vrai code de la vrai vie. Tu te rend compte de la taille de code qui rentre dans un cache L1 ? On parle de boucle interne, pour remplir les 16/32/64 Ko de cache L1, il faut sans doute, l'équivalent d'un millier de lignes de code.

                                    Le point clef est l'alignement plutôt que la taille. Changer le code en déroulant change l'alignement de façon non maîtrisée, on peut donc se retrouver dans des situations où le code non déroulé est mieux aligné que le code déroulé ce qui le rend plus rapide.

                                    Oui et sur un code moyen, cela ne change rien.

                                    Cela change l'alignement.

                                    Tu parles de Ocaml,

                                    Oui, on parle de OCaml dans ce fil, non?

                                    • [^] # Re: Plutôt beauté du design

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

                                      L'année dernière le blog d'ocamlpro parlait d'un projet pour inliner de façon plus agressive, mais ça n'a plus l'air actif. Ceci dit, dernièrement, il y a eu des améliorations du côté de la propagation des constantes et quelques autres optimisations, à en croire le changelog de la 4.02.

                                    • [^] # Re: Plutôt beauté du design

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

                                      J'ai encore l'impression de parler avec un universitaire qui fait des compilos mais qui n'a absolument aucunes idées précises de comment fonctionne un cpu, ni comment les compilo comme gcc optimisent à bas niveau.

                                      C'est le genre de personne qui s'étonne quand on leur dit qu'un code plus verbeux peut être bien plus rapide qu'un code plus court (moins de dépendance read after write).

                                      Le compilo gère évidement l'alignement qui ne sera jamais cassé. De plus, les prefetchers font en sorte qu'il n'y a jamais de ruptures sur les enchainements de lignes de cache. Ils sont très efficace concernant le code, bien plus que pour les données.

                                      Le point clef est l'alignement plutôt que la taille. Changer le code en déroulant change l'alignement de façon non maîtrisée, on peut donc se retrouver dans des situations où le code non déroulé est mieux aligné que le code déroulé ce qui le rend plus rapide.

                                      Si jamais tu tombes sur le compilo suffisamment crétin pour ne pas faire d'alignement, il faut aussi que la perte de performance d'alignement ne soit pas compensé par la réduction du nombre de teste de boucle, et par la recombinaison des instructions.

                                      Cela change l'alignement.

                                      Non. C'est géré.

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

                                      • [^] # Re: Plutôt beauté du design

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

                                        C'est le genre de personne qui s'étonne quand on leur dit qu'un code plus verbeux peut être bien plus rapide qu'un code plus court (moins de dépendance read after write).

                                        C'est le genre de personne qui a écrit exactement ça dans le post auquel tu réponds, non?

                                        Non. C'est géré.

                                        Ok, au temps pour moi.

                                        • [^] # Re: Plutôt beauté du design

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

                                          C'est le genre de personne qui a écrit exactement ça dans le post auquel tu réponds, non?

                                          Je pensais même à du code local.

                                          "a+b+c+d" sera un code plus court que "(a+b)+(c+d)" qui utilise plus de variable intermédiaires, mais le deuxième code sera 30% plus rapide, dans le meilleur des cas.

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

                                • [^] # Re: Plutôt beauté du design

                                  Posté par  . Évalué à 3.

                                  Le compilateur d'Intel en -O2 déroule 2 à 8 fois automatiquement la plupart des boucles qu'il rencontre (sauf si le nombre d'instructions dépasse les limites, cas d'exception). Je n'ai pas vérifié pour le compilateur GNU, mais avec -O3 il y a des chances qu'il fasse pareil.

                                  • [^] # Re: Plutôt beauté du design

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

                                    De mémoire, j'aurais dis 16. J'imagine que c'est plus une histoire de taille du cœur de la boucle.

                                    L'idéal est d'utiliser tous les registres (on déroule plus), pour ensuite mélanger les instructions qui sont indépendantes ce qui permet de bien utiliser le pipeline, mais il ne faut jamais devoir utiliser la mémoire (on déroule moins) qui deviendrait un goulet d'étranglement.

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

        • [^] # Re: Plutôt beauté du design

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

          Tout est relatif :

          • dans le monde du jeu vidéo (et surtout à l'époque) ce code est merveilleux

          • dans le monde super sexy et à la pointe de la techno du XXeme siècle qu'est l'informatique de gestion ce code peut passer pour un délire de débutant, un trip sous LSD ou autre.
            En cas de bug on regarde même pas, on vire on réécrit.

          La raison, c'est la finalité du code, c'est super optimisé pour du calcul graphique en 3D et donc super bien voire même génial.

          C'est difficile à maintenir et à lire mais bon pour un jeu OSF

          Pour du code qui doit tourner, voire même évoluer pendant plusieurs années il vaut mieux éviter.

          • [^] # Re: Plutôt beauté du design

            Posté par  . Évalué à 3.

            Il est pourri ton faux dilemme, tu dis toi même que pour écrire n'importe quoi qui peut durer un peu c'est pas parfait (il n'y a pas que l'informatique de gestion, il y a aussi les moteurs de base de données, les noyaux de systèmes d'exploitation, les shell, les éditeurs de texte, les navigateurs, les serveurs,…).

            Son code était bon parce qu'il répondait à un besoin de performance à une époque donnée, c'était intéressant dans les jeux vidéo, dans les codes de calculs numériques, en simulation, etc. Mais il semble qu'aujourd'hui ce soit déprécié par l'amélioration des compilateurs.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Plutôt beauté du design

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

              C'est pas un dilemme, je voulais juste préciser que le beau code est relatif en fonction de sa finalité.
              Pour faire plus simple :

              Dans le jeu vidéo : si c'est rapide et que ça tourne tant pis si c'est illisible
              Dans d'autres secteurs : la lisibilité et donc la maintenabilité du code est une priorité, et tant pis si cela se traine

              Et par conséquent, du beau code dépend du contexte dans lequel il est employé

              Exemple dans les années 80, j'avais du écrire des choses du style (en basic de l'époque):

              B = 100*(A>5)*(A5) and (A<10) THEN B=100

              Est ce beau ? oui et non
              Par contre comme je devais jongler avec 80 Ko de mémoire RAM cela me faisait gagner quelques octets
              qui pouvais servir ailleurs

      • [^] # Re: Plutôt beauté du design

        Posté par  . Évalué à 2.

        ça peut être du code astucieux sans effets de bord hors de la fonction/méthode.

        • [^] # Re: Plutôt beauté du design

          Posté par  . Évalué à 3. Dernière modification le 30 septembre 2014 à 10:50.

          Oui cette fonction est de qualité (AMHA), car c'est une fonction pure qui s'utilise facilement (elle n'expose pas sa logique interne).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Plutôt beauté du design

        Posté par  . Évalué à 3.

        Une astuce c'est un truc qui peut casser dès qu'on met à jour le compilateur et/ou le runtime ou dès qu'on change d'environnement.

        Non. Par exemple si je veux savoir si un nombre est une puissance de 2, je peux écrire

        _Bool
        is_power_of_2_naive(unsigned long n)
        {
            unsigned long remainder = 0;
            while (!remainder) {
                remainder  = n % 2;
                n         /= 2;
            }
            return remainder == 1 && n == 0;
        }

        Ça marche, c'est assez direct, et au pire j'aurai log_2 n itérations (puisque je divise par 2 à chaque itération).

        On peut quand même simplifier :

        _Bool
        is_power_of_2_naive(unsigned long n)
        {
            if (n == 0) return false;
            while (n%2 == 0) 
                n /= 2;
            return n == 1;
        }

        On peut même rendre l'écriture plus compacte :

        _Bool
        is_power_of_2_naive(unsigned long n)
        {
            if (n == 0)  return false;
            for (; n%2 == 0; n /= 2) 
                ;
            return n == 1;
        }

        Mais bon jusque là, « l'astuce » c'est juste connaître le langage, et savoir exprimer la même chose de différentes façon. Il s'agit donc purement de style.

        Mais je peux être réellement astucieux, et répondre en temps constant :

        _Bool
        is_power_of_2(unsigned long n)
        {
            return (n > 0) && ((n & (n-1)) == 0);
        }

        Un entier non-signé ne changera jamais ses propriétés, donc j'ai la garantie que ce code fonctionnera toujours en C/C++ (et en fait n'importe quel langage qui permet les opérations bit-à-bit sur des entiers).

        • [^] # Re: Plutôt beauté du design

          Posté par  . Évalué à 3.

          _Bool
          is_power_of_2_naive(unsigned long n)
          {
              if (n == 0)  return false;
              for (; n%2 == 0; n /= 2) 
                  ;
              return n == 1;
          }

          en quoi c'est plus compact que :

          _Bool
          is_power_of_2_naive(unsigned long n)
          {
              if (n == 0)  return false;
              while (n%2 == 0) n /= 2;
              return n == 1;
          }

          Ce qui a le bon goût de ne pas tordre une construction du langage par lubie.

          Ta dernière solution n'est pas astucieuse elle utilise l'une des propriétés mathématiques. Ce n'est pas la première solution à la quelle pense un développeur, mais ça n'a rien de bien compliqué.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Plutôt beauté du design

            Posté par  . Évalué à 2.

            Utiliser une connaissance en maths, physique, …, bref une connaissance du domaine auquel s'applique la fonction qu'on écrit pour optimiser/simplifier le code, oui, c'est astucieux. Perso, je n'aurais jamais pensé au coup du n & (n-1). Il faut accepter le fait que l'informatique est l'enfant des maths et de l'électronique, et donc que tout « truc et astuce » tombera souvent dans un domaine ou l'autre. Et de temps en temps, utiliser les propriétés du langage utilisé sera une utilisation astucieuse du langage, et donc sera une « astuce de programmation ».

            En résumé : si à chaque fois que quelqu'un utilise une astuce pour simplifier/optimiser du code, on contre en disant « mais c'est pas de l'info, c'est des maths », alors on peut dire la même chose de 90% des « astuces » utilisées dans les autres domaines (mécanique, électronique, etc.), car après tout, toute modèle passant par une science « dure » est exprimé en termes mathématiques…

          • [^] # Re: Plutôt beauté du design

            Posté par  . Évalué à 2. Dernière modification le 01 octobre 2014 à 18:43.

            Tu « triches » dans le sens où tu mets le corps du while sur la même ligne. :) J'aurais pu faire pareil avec mon corps vide dans le for.

            Ensuite, utiliser n /= 2 dans la post-condition n'est absolument pas un détournement, car il s'agit bien d'une façon d'itérer sur la boucle. Par exemple, écrire un truc comme ceci (en supposant une liste chaînée) :

            link_t*
            find(list_t* list, const void* data)
            {
                link_t* cur = NULL;
                for (cur = list->head; cur != NULL && list->cmp(cur->data,data) != 0; cur = cur->next)
                    ;
                return cur;
            }

            est parfaitement idiomatique, et clair. Tu pourrais bien sûr écrire quelque chose du genre :

            link_t*
            find(list_t* list, const void* data)
            {
                for (link_t *cur = list->head; cur != NULL; cur = cur->next)
                    if (list->cmp(cur->data,data) == 0) 
                        return cur;
            
                return NULL;
            }

            Et ce serait (peut-être) plus clair pour un nouveau venu dans le monde du C, mais à mon avis ni plus ni moins pour quelqu'un qui connaît « raisonnablement bien » le langage (c'est-à-dire qui a plus de 6 mois d'expérience avec).

            • [^] # Re: Plutôt beauté du design

              Posté par  . Évalué à 3.

              Tu « triches » dans le sens où tu mets le corps du while sur la même ligne. :) J'aurais pu faire pareil avec mon corps vide dans le for.

              Je le fais quand la ligne en question reste courte, que ça ne nuit pas à la lisibilité.

              Ensuite, utiliser n /= 2 dans la post-condition n'est absolument pas un détournement, car il s'agit bien d'une façon d'itérer sur la boucle.

              Laisser vide 2 des 4 instructions faisant partie de la boucle for c'est dommage (et pour moi c'est signe que ce n'est pas la construction qu'il te faux).

              Et ce serait (peut-être) plus clair pour un nouveau venu dans le monde du C […]

              Je préfère aussi la première (mis à part que la ligne est trop longue à mon goût) et n'importe qui ayant touché du C, C++, Java, C#,… pendant plus d'une semaine devrait le comprendre.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Plutôt beauté du design

                Posté par  . Évalué à 2.

                Laisser vide 2 des 4 instructions faisant partie de la boucle for

                Des 4? Tu considères donc le corps d'une boucle comme partie intégrante de la boucle?
                Pas moi, mais c'est une question d'opinion j'imagine.

                Mais du coup, dans mon opinion, il n'y à donc qu'un champ sur 3 qui n'est pas utilisé, et il s'agit de l'initialisation de la boucle. Ce champ est régulièrement laissé vide, pour un tas de raisons.

                • [^] # Re: Plutôt beauté du design

                  Posté par  . Évalué à 3.

                  Pas moi, mais c'est une question d'opinion j'imagine.

                  Pas vraiment quand on voit comment c'est défini (p 147) :
                  http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

                  D'ailleurs c'est pareil quand tu vois la définition de la syntaxe.

                  Mais OSEF, ça fait 2 instructions vides.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Plutôt beauté du design

          Posté par  . Évalué à -1.

          is_power_of_2(1) renvoie true ;)

          • [^] # Re: Plutôt beauté du design

            Posté par  . Évalué à 10.

            En même temps 20 = 1

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Plutôt beauté du design

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

      Beau‚ ce n'est pas forcément utile ou agréable ou dans le cas qui nous occupe ici maintenable.

      A mon avis ce qui caractérise le beau c'est justement lorsqu'il y a quelque chose qui dépasse les qualités fonctionnelles du produit. Si tu prends par exemple le code de apache 1.3, il etait loin d'être maintenable et souffrait de problèmes de design important. A vrai dire c'était une série de hacks avec des ifdef spaghetti dans tous les sens. Mais finalement cela en faisait un morceau tellement essentiel du l'histoire de l'informatique qu'il avait une beauté certaine.

      En le lisant, tu pouvais découvrir l'évolution des systèmes, leur parenté‚ leurs manques. Les tentatives diverses pour avoir des ipc efficaces‚ des codages de caractères insoupsonnés‚ des hacks pour résoudre toutes sorte de problème qui ont émaillés l'histoire du web.

      Bref tu te retrouves devant des morceaux de codes qui te font voyager dans le temps‚ devant l'intention de programmeurs désarmés face a des problèmes nouveaux et qui finalement imaginent des solutions pas si éloignées des outils actuels …

      Un tel code est une horreur a maintenir et a de grosses limites en efficacité. Pourtant il reste d'une beauté émouvante et a mon avis difficilement contestable.

  • # Le beau code c'est bien, ...

    Posté par  . Évalué à 2.

    mais le bro code c'est ma référence (oui je sais ça date un peu maintenant mais je suis vieux ;-( ) …

  • # Asimov...

    Posté par  . Évalué à 3.

    … faisait dire à l'un de ses personnages:

    Une équation ne peut être mathématiquement juste si elle n'est pas poétiquement équilibrée.

    Je pense personnellement que ça s'applique très bien au code (= équation mathématique, non?)

    Je ne suis pas un grand codeur, mais quand j'examine mes créations "de loin", j'ai l'impression qu'un code bien écrit (dans le sens fonctionnel), "ça" se voit (indentation, etc.). Lorsque j'ai un code qui n'est pas "beau", très souvent, il y a un problème fonctionnel dedans.

    Remarques totalement subjectives et absolument non "industrialisables".

    :-)

    Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.

    • [^] # Re: Asimov...

      Posté par  . Évalué à 2.

      Mouais, je suis pas un grand codeur non plus, mais je me méfie comme de la peste de cette impression, personnellement. Je pense que tu peux très bien produire un code très élégant dans lequel peut se planquer un magnifique bug et faire planter superbement un programme.

      Dans le monde de l'industrie ou de la science, y a un tas de truc très élégants et qui semblaient très réussis et qui ce sont vautrés lamentablement. Les plus célèbres sont le Titanic, la constante cosmologique d’Einstein ou les motocyclettes Ducati.

      Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

      • [^] # Re: Asimov...

        Posté par  . Évalué à 2.

        Dans le monde de l'industrie ou de la science, y a un tas de truc très élégants et qui semblaient très réussis et qui ce sont vautrés lamentablement. Les plus célèbres sont (…) la constante cosmologique d’Einstein (…)

        Peux-tu détailler STP ?

        Sinon il n'y a pas que l'industrie et la science qui sont concernés, mais tous les domaines. En politique on a eu par exemple dans la catégorie "truc très élégants et qui semblaient très réussis et qui ce sont vautrés lamentablement", il y a aussi Ségolène Royal aux présidentielles …

        • [^] # Re: Asimov...

          Posté par  . Évalué à 1.

          Détailler, c'est bien grand mot, mais dans le cadre de l'élaboration de sa théorie de relativité générale, Einstein aurait ajouté cette constante pour rendre l'univers stable (ce qui peut être interprété (avec précaution) comme une volonté de sa part de rendre sa théorie plus jolie). Néanmoins, on s'est aperçu ensuite que l'univers était en expansion et il est revenu dessus en la qualifiant de boulette. Bon en même temps des boulettes comme ça, je veux bien en faire tout les jours perso.

          Bon il s’avère que récemment certains pensent que c'était pas forcément une boulette, mais là, moi, j'ai déjà décroché depuis un moment.

          Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

          • [^] # Re: Asimov...

            Posté par  . Évalué à 2.

            Bon il s’avère que récemment certains pensent que c'était pas forcément une boulette, mais là, moi, j'ai déjà décroché depuis un moment.

            C'est pour ça que je t'ai demandé de détailler, car j'ai cru comprendre également récemment en regardant une émission sur ce sujet que ce n'était peut-être pas une boulette.

        • [^] # Re: Asimov...

          Posté par  . Évalué à 2.

          "truc très élégants […]", il y a aussi Ségolène Royal

          Élégant? Euhhhh si on veux… les goûts et les couleurs après tout…

          • [^] # Re: Asimov...

            Posté par  . Évalué à 2.

            Compare avec ses adversaires de l'époque.

      • [^] # Re: Asimov...

        Posté par  . Évalué à 3.

        le Titanic

        Son unique défaut c'est de manquer de canots de sauvetage, je ne connais pas de bateau de voyage capable de résister à un éperonnage avec un iceberg.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Asimov...

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

          L'acier était aussi trop fragile, ce qui a augmenté la taille de la déchirure. Le bateau aurait du couler plus lentement ou pas du tout.

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

        • [^] # Re: Asimov...

          Posté par  . Évalué à 4. Dernière modification le 30 septembre 2014 à 10:15.

          Alors, de ce que j'en sais,ce n'était pas son unique défaut. La conception des cloisons étanches qui devait assurer la flottabilité du navire même dans le cas d'un percement de la coque sous la ligne de flottaison n'avait pas prévu une ouverture longitudinale de cette ampleur, qui a noyé plusieurs compartiments, provoqué l'enfoncement de la partie avant et du fait du manque de hauteur des cloisons, noyé progressivement, à mesure de l'enfoncement du navire, les compartiments vers l'arrière, jusqu’à l'épuisement de la réserve de flottabilité du navire, ce qui a entrainé rapidement le naufrage.

          Bon après, on peut discuter, parce qu'avec des si … Mais si ce problème de conception avait été mieux pris en compte, on peut espérer qu'il eu tenu plus longtemps à flot, surtout que le temps était calme et que ça aurait permis au secours d'arriver sur zone.

          Sinon, personnellement, j'ai vu un porte-container qui s'en était mangé un (un petit, certes) dans l'atlantique nord et dont le bulbe était complètement détruit et qui flottait encore, il avait même réussi à rejoindre par ses propre moyen Halifax.

          Bon sinon, je vois que personne n'a râlé pour les Ducati :).

          Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

  • # Zen Python

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

    Pour ceux qui ne connaîtraient pas encore:

    >>> import this
    The Zen of Python, by Tim Peters
    
    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # relativité étendue

    Posté par  . Évalué à 7.

    De toute façon, à lire tous les trolls sur les codes, langages, hack et consorts, la beauté du code me semble assez relative au niveau de celui qui parle.

    Et faire un code maintenable par d'autres c'est bien dans l'idée, mais quels autres ? Ceux qui ont le même niveau que toi ? des ingés avec 15 ans d'expé dans la techno ? des bts qui sortent de l'école, des prestas ssii balancés sur la techno avec une demie journée de "formation", des stagiaires ?

    Et sur une machine qui iddle à 99% du temps ? sur une machine à 100% proc pratiquement tout le temps ? sur des calculs itératifs des milliards de fois ? sur une boucle exécutée une fois tous les 36 du mois ?

    C'est une question ou il n'y a pas de réponse, il y a autant de réponse que de personnes et de cas.

    Lorsque l'on reprend du code qu'on a fait il y a 10 ans, on a vue le chemin parcouru et on est capable d'améliorer son code (par expérience) et parce que notre manière de coder à changé. Maintenant si on prend le cas inverse, est-ce que 15 ans après je dois toujours faire le code de tel manière que je puisse le maintenir si j'avais 15 ans de moins ?

    C'est plus le pourquoi on avait fait cela que comment on avait cela qui est compliqué. Il suffit de le documenter dans le code. La beauté est un truc tout relatif.

    • [^] # Re: relativité étendue

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

      La beauté est un truc tout relatif.

      Non, il y a des trucs qui restent.

      Si tu arrives à pondre un algo avec 4 cas génériques, dans tout les cas, c'est plus simple à maintenir que faire les 60 cas un par un.

      J'avais le cas aussi de structures de donné strictement nécessaire, ou pas. Si il existe des champs inutiles, comme le savoir en ne lisant que le code localement ?

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

      • [^] # Re: relativité étendue

        Posté par  . Évalué à 1.

        ok… et si tu es le seul à savoir lire les 4 cas génériques et comprendre qu'ils cachent les 60 cas réels, comment sait-tu que cela ne va pas casser dans 5 ans lors d'un refactoring par un mec qui ne réalisera pas que tu adresses 60 cas et non juste 4 ?

        • [^] # Re: relativité étendue

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 29 septembre 2014 à 17:22.

          En général, le typage ne laisse pas passer. Il force aussi au codeur suivant à réfléchir un peu.

          Si on reste sur du code propre et pas du hack de concours, un code réduit est toujours préférable à un truc verbeux, dont on finit forcément par perdre la structure d'ensemble.

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

          • [^] # Re: relativité étendue

            Posté par  . Évalué à 1.

            moi les certitudes ça m'a toujours fait peur… mais je dois pas être assez smart peut être.

            • [^] # Re: relativité étendue

              Posté par  . Évalué à 3.

              Je suis bien certain que tu es certain d'avoir peur des certitudes…

          • [^] # Re: relativité étendue

            Posté par  . Évalué à 2.

            Accessoirement, si le code n'est, par malheur, pas assez parlant lui-même, il reste les commentaires. Les commentaires qui peuvent aussi servir à pointer un endroit ou l'on à du tordre le code pour obéir à des règles métier un peu farfelues, ou parce que le code avec lequel on interagit (et sur lequel on à bien entendu aucun pouvoir) est buggué/complexe/bancal.

            Je pense que tout le monde sera d'accord avec moi pour dire que quand on maintien du 10 ans d'âge, on fait attention quand on refacto, et même si c'est hyper tentant de refacto en masse, il faut savoir se contenir…

            Donc, je suis complètement d'accord avec toi :)

            • [^] # Re: relativité étendue

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

              Les commentaires..

              Je préfère 10x un nom parlant à des commentaires. Je connais 2 sortes de commentaires : ceux qui noient le code et le rende illisible (genre une ligne sur 2 est un commentaire), au lieu de tout sortir des fonctions, ce qui empêche de voir la fonction en entier sur un écran, et ceux qui sont obsolètes.

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

              • [^] # Re: relativité étendue

                Posté par  . Évalué à 4.

                Personnellement j'ai remarqué que la taille des fonctions que j'écris excède rarement 20 lignes. Donc je suis assez large avant d'arriver à une méthode qui ne s'affiche plus sur un écran (même avec un netbook).

                Les commentaires me servent pour décrire certains aspects qui ne sont pas facile à faire ressortir dans un code. Il ne dois pas décrire ce qu'on fait mais pourquoi on le fait.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: relativité étendue

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

                  Il ne dois pas décrire ce qu'on fait mais pourquoi on le fait.

                  100% d'accord

                  Les commentaires me servent pour décrire certains aspects qui ne sont pas facile à faire ressortir dans un code.

                  Si le code est moche, il vaut mieux le changer, il y a de grande chance que malgré le commentaire, il pose problème plus tard.

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

                  • [^] # Re: relativité étendue

                    Posté par  . Évalué à 2.

                    Si le code est moche, il vaut mieux le changer, il y a de grande chance que malgré le commentaire, il pose problème plus tard.

                    Ce n'est pas toujours possible, pour diverses contraintes.
                    Genre: usine à gaz qui pète à la moindre modif (cause principale: variables globales, je vous hais!), manque de temps, fonction qui fait le café, le thé et accessoirement qui effectue une tâche utile, etc.

                    • [^] # Re: relativité étendue

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

                      Je vois. Je déteste ce genre de code. Le genre de pile de patchs locals sans architecture global. Le truc qui casse à chaque modification.

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

                      • [^] # Re: relativité étendue

                        Posté par  . Évalué à 2.

                        C'est ça. Sentiment partagé, rassures-toi, mais dans ce type de code les commentaires sont un mal nécessaire, et on ne peut nettoyer le bordel que petit à petit… et croiser les doigts pour ne rien casser au passage.

                        • [^] # Re: relativité étendue

                          Posté par  . Évalué à 3.

                          J'ai l'impression d'être au boulot après le boulot là…

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: relativité étendue

                Posté par  . Évalué à 2.

                Je préfère 10x un nom parlant à des commentaires.

                Je suis d'accord, mais parfois il n'y à pas le choix.

                Je connais 2 sortes de commentaires

                Tu as oublié:

                • le code zombifié,
                • les notes style TODO,
                • ceux qui disent ce que le dev pense de son propre code,
                • ceux qui résument une ligne longue comme le bras et illisible, genre quand la ligne inclue des appels à std::mem_fun, std::bind1st, ou std::bind2nd (je sais, depuis C++11, on peut simplifier considérablement ça, mais on ne peux pas l'utiliser partout, le C++11…)
                • ceux qui parlent des règles de gestion stupides
                • ceux qui permettent de générer une doc

                Mais c'est clair: je suis aussi du genre à préférer éviter les commentaires que je le peux, par exemple un truc genre "i = 2* 3.14 * r; //3.14 is PI" n'apparaîtra jamais dans mes codes. Je préfère faire une constante et lui filer la valeur 3.14… bon, avec PI, c'est trivial, mais un autre exemple déjà cité ici: i = 0x5f3759df - ( i >> 1 ); montre que ça ne l'est pas toujours… (oui, je trouve ce truc crade, peu m'importe qui l'a écrit à l'origine. Les magic values, c'est déjà pas top, mais quand en plus c'est pas mis dans des constantes… berk)

                • [^] # Re: relativité étendue

                  Posté par  . Évalué à 2.

                  Tu as oublié le plus horrible : le code lui même mis en commentaire suite à des modifications.

                  • [^] # Re: relativité étendue

                    Posté par  . Évalué à 1. Dernière modification le 04 octobre 2014 à 11:37.

                    Pour le coup ça me choque pas, ça permet à quelqu’un qui reprend le code dans 10 ans et qui se dit « j’ai besoin d’un peu plus de précision » de voir du premier coup d’œil comment faire sans avoir à comprendre le reste du code.

                    • [^] # Re: relativité étendue

                      Posté par  . Évalué à 3.

                      Mais dpuis 10 ans, le code en question ne correspond à rien parce qu'il y a plein d'autre code qui a été ajouté entre deux et d'autres modifications ont été faites.

                    • [^] # Re: relativité étendue

                      Posté par  . Évalué à 3.

                      Mouai… il paraît que c'est à ça que servent les VCS, en fait. Avoir le source d'origine, et la liste des patchs qui y ont été appliqués avec en prime, un commentaire de leur auteur.

                      • [^] # Re: relativité étendue

                        Posté par  . Évalué à 1.

                        C’est pas une question d’historique (à priori on a toujours voulu de cette précision, c’est pas un changement), c’est une manière simple, concise et rapide d’expliquer une partie de l’algorithme, une manière élégante de dire « y * ( threehalfs - ( x2 * y * y ) ) c’est juste une manière de s’approcher du résultat, on peut le faire autant de fois qu’on veut pour avoir la précision souhaitée, mais pour ce qui nous intéresse, une seule itération suffit », moi qui ait jamais entendu « Newton-Raphson » avant aujourd’hui (et qui n’a rien compris du reste de l’algorithme), j’ai compris ça du premier coup. C’est donc un commentaire efficace :)

                        • [^] # Re: relativité étendue

                          Posté par  . Évalué à 3.

                          Et mettre ça dans une boucle qui itère precision fois, precision étant un entier défini avant et laisser au compilateur le soin de dérouler la boucle ça ne te paraît pas plus clair ?

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: relativité étendue

                          Posté par  . Évalué à 3.

                          Soit tu réponds à autre chose (je pense que c'est ça ) et dans ce cas je me permets de rappeler ce dont on parle ici:

                          Tu as oublié le plus horrible : le code lui même mis en commentaire suite à des modifications.

                          Soit je n'ai rien compris à ton propos, soit tu dis n'imp.

                          On parle de code qui fut utile un jour, et qui ne l'est plus. En général, ce type de code est le résultat d'un bug ou d'une évolution, et l'on à donc mis en commentaire l'ancien pour y revenir plus vite si la nouvelle version merde.
                          Au bout de 10ans, tu peux te retrouver avec 3 versions de la même fonction, 2 bugguées (mais tu ne sais pas quel était le bug) et 1 est une ancienne version complète…

                          Et quand tu dois attaquer un petit code source de, disons, 5000 lignes, et que tu te retrouves avec 200 lignes de zombies, ben voila, ça aide pas à la compréhension.

                  • [^] # Re: relativité étendue

                    Posté par  . Évalué à 4.

                    Non non, c'est ce que j'appelle du code zombie :) il est mort mais pas totalement…

  • # C'est plus général que ça.

    Posté par  . Évalué à 5.

    Dans tout artisanat (sans le sens noble du terme), on a une notion de beauté.

    L'exemple caricatural à mon avis est celui d'un médecin qui parle d'une « belle plaie ».

  • # L'avis de Joel Spolsky sur la question

    Posté par  . Évalué à 3.

    http://www.joelonsoftware.com/articles/Wrong.html

    En substance : il faut avoir un peu de métier pour appréhender réelement la "propreté" et la "beauté" du code.

    BeOS le faisait il y a 20 ans !

Suivre le flux des commentaires

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