• # C'est quoi le sujet?

    Posté par  . Évalué à 5.

    Bonjour,

    J'ai commence a lire 5 minutes, ca parle de complexite des logiciels avec toutes leurs lignes de code mais je n'ai pas compris ou ils veulent en venir.

    Tu parles de meta programmation. Est-ce que c'est lie a la meta programmation comme dans cet article wikipedia: https://fr.wikipedia.org/wiki/M%C3%A9taprogrammation

    • [^] # Re: C'est quoi le sujet?

      Posté par  . Évalué à -1.

      Bonjour,

      ça parle plutôt de généricité de code. On code avec un langage évolué, genre sa langue maternelle, et, oh magie, ça pisse du code.
      On a de bons exemples, qui fonctionnent, avec les compilateurs, les interpréteurs et les SGBDR.
      Ce dernier cas est intéressant. On tape sa commande SQL, et hop, le moteur de la base de données , l'analyse, choisi le meilleur algorithme à son goût le compile et l'exécute.
      C'est là ou le préfixe méta à son sens.

      La page anglaise de wikipedia est plus proche de la notion que je conçois (désolé pour Linux*FR*)
      Ça permet de s'abstraire de l'implémentation de la machine en s'exprimant dans un langage intelligible.

      Ça reste quand même du domaine du rêve, et les codeurs resteront pour un temps certain nécessaires.

      • [^] # Re: C'est quoi le sujet?

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

        On code avec un langage évolué, genre sa langue maternelle, et, oh magie, ça pisse du code.

        J'ai ri.
        Parce que bon, avec tous les quiproquos possibles (testé dans la vie réelle) et les désaccords sur le sens des mots entre 2 personnes (alors pour qu'un "pisseur de code" automatisé arrive à comprendre des millions de gens…), c'est la méthode la plus sûre pour avec un programme peut-être non bugué (à croire que le "pisseur de code" est sans bug, ce qui est faux) qui fera tout sauf ce qu'on pensera qu'il fera.

        Petite pensée pour Data.

        On tape sa commande SQL,

        Donc un langage déjà informatiquement structuré, et non une "langue maternelle" évolutive. Donc HS.

        Ça reste quand même du domaine du rêve,

        Ha ça…

        • [^] # Re: C'est quoi le sujet?

          Posté par  . Évalué à -4.

          J'ai ri.

          Je suis, moi même, un pisseur de code; et je fais des bugs.

          Donc un langage déjà informatiquement structuré, et non une "langue maternelle" évolutive. Donc HS.

          Bon, il est déjà proche du langage courant, yes or not? Donc mauvaise foi.

          Ha ça

          Ben oui, mais ça vient

          • [^] # Re: C'est quoi le sujet?

            Posté par  . Évalué à 10.

            Bon, il est déjà proche du langage courant, yes or not? Donc mauvaise foi.

            Autant que n’importe quel langage de programmation.
            Alors, oui, select from where, c’est effectivement proche du langage naturel. Enfin, ça dépend du langage parce que naturellement, select where from, ca fait du sens aussi. Et je sais pas pour toi, mais moi j’utilise rarement « etoile » dans mon langage courant, ni NULL. De même, dans le langage courant, les parenthèses servent généralement à indiquer un apparté, et n’ont pas une semantique aussi forte qu’en sql.

            Left join, inner join ou insert into select, ou n’importe quel commande sql non triviale, ça devient vite du charabia pour ceux qui ne sont pas rompus aux subtilités sémantiques (et je laisse de côté les histoires de performances).

            Le langage naturel, ça marche parce qu’on a une culture commune et un cerveau qui sait comprendre le contexte pour corriger les ambiguïtés (et même ça, ça marche pas toujours), et qui fait énormément d’assomptions quand le contexte ne suffit pas.
            Quand je te dit « j’ai mangé un avocat », tu te doutes bien que je ne suis pas cannibal, tu en conclus que j’ai mangé un légume.
            Si je te dit « la comptable est partie avec la caisse, la police la cherche depuis 3 jours », tu ne sais pas si la police cherche la comptable ou la caisse. En pratique, ça te fait pas tiquer parce tu part du principe que les deux sont ensemble de toutes façons, mais rien n’indique ça.

            On peut aussi aborder les variations régionales. Si je te demande d’aller acheter du lait chez le dépanneur, tu va me regarder avec une drôle demain tete. Un québécois ira chez l’epicier du coin naturellement. Ce même québécois risque d’être étonné si tu lui demande d’aller chez le reubeu pour la même chose.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: C'est quoi le sujet?

              Posté par  . Évalué à 1.

              Oui mais tout ça relève comme tu le dis d'une culture, c'est-à-dire une somme de connaissances acquises outre la langue, et/ou d'un contexte, lui aussi assimilable.

              Les IA progressent très vite en compréhension du langage naturel, et je ne vois pas pourquoi elles ne pourraient pas intégrer ces notions.

              Combien de temps avant que non seulement elles décortiquent ta liste de requis pour pondre du code, mais allons plus loin: qu'elles comprennent tes intentions pendant que tu les expliques très mal?

              Le sujet "les AI vont tous nous remplacer" semble très populaire ici, mais c'est un peu comme partout: tout le monde croit que ça va arriver, mais que ça va remplacer… les autres, pas moi!

            • [^] # Re: C'est quoi le sujet?

              Posté par  . Évalué à 1.

              Non, bien sûr, le SQL n'est pas un langage naturel, mais bien formel.
              Ce que je voulais dire, c'est que l'interprétation d'un langage procédural en langage machine est plus évidente et moins automatique, que la traduction, dans ce même langage machine, d'une expression SQL.
              La traduction d'une boucle "for" est quand même plus simple à faire, en langage machine, qu'une jointure en SQL.
              Mais je pense, malgré tout, que l'on pourra compiler, un jour, le langage naturel ou un dérivé plus formel (l'anglais l'est déjà).
              Avant que les machines nous remplacent, nous aussi, travaillons à notre perte dans la joie.

  • # UN BIZUTH !

    Posté par  (site web personnel) . Évalué à 8. Dernière modification le 26 novembre 2017 à 18:51.

    Super !!!
    faites chauffer le goudron !
    Sortez les plumes !

    ok -> []

  • # Article pas terrible

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 26 novembre 2017 à 19:45.

    L'article n'est pas terrrible parcequ'il passe à côté de plein de points assez évidents dont il serait pourtant assez facile de parler dans un journal tout public. Il est difficile d'y voir autre chose qu'un coup de pub un peu perso du ”directeur du laboratoire.”

    Voilà tous les points qui viennent en tête de façon (presque) immédiate en lisant l'article:

    1. Dire que la programmation WYSIWYG réduirait les bugs dans les programmes est un peu pipo. Il y a des milliers si ce n'est des millions de personnes qui programment en WYSIWYG tous les jours et qui ne sont pourtant pas à l'abri des bugs, même les plus simples: il s'agit des utilisateurs de tableurs. Les tableurs les plus connus ne disposent pas d'un mode “plan” qui permettrait de lire (coucou le texte!) l'ensemble des définitions d'une feuille de calcul pour vérifier sa cohérence.

    2. L'article ne parle pas du tout d'autres approches pour réduire les bugs, comme le typage statique, les méthodologies montantes pour l'analyse du code (certaines basées sur l'IA), les fuzzers, les mélangeurs de mémoire, etc.

    3. L'article ignore totalement que tous les langages ne suggèrent pas des modes de développement identiques, par exemple en Common Lisp on développe de façon interactive, c'est quasiment du WYSIWYG avec un point focal.

    Visual Studio, c’est plus de 55 millions de lignes de codes, et 98% d’entre elles ne sont pas pertinentes, estime Granger. Le problème est que c’est un assemblage de plein de travaux différents et pour le comprendre, le parcourir, pour un informaticien, il faut être capable de jouer les fonctions qu’on rencontre dans sa tête. C’est comme jouer aux échecs avec un bandeau sur les yeux : l’essentiel de l’énergie est dépensé à avoir une représentation des pièces et de leurs mouvements… tant et si bien qu’il ne reste plus d’énergie mentale pour penser au jeu lui-même.

    1. Le paragraphe que je cite est complètement faux, la première fois que j'ai utilisé un débogueur visuel c'était en 1999 ou 2000… aux dernières nouvelles, ça existe toujours et tous les programmeurs connaissent ce genre d'outils – même s'ils ne sont pas forcément disponible pour tous les langages.

    L'idée de programmer en utilisant un logiciel WYSIWYG est par ailleurs loin d'être nouvelle:

    1. Le programme “concept“ sensé illustrer le propos de Victor Bret, le directeur du laboratoire, semble être une réimplémentation dans un navigateur du logiciel de géométrie interactive CABRI qui existait dès la fin des années 90. Il y a plein de variations sur ce type de programme, il y en avait un clone dans KDE, etc.

    2. Un outil de programmation interactive plus grand public que le CABRI est l'Automator d'Apple. En gros les diverses applications compatibles avec ce système exportent des traitements. Par exemple l'opération “Choisir des fichiers” de l'explorateur de fichiers, l'opération “Filtre Sépia” de l'application de visualisation d'image et l'opération “envoyer un mail” de l'application de messagerie. Le logiciel Automator permet de combiner ensemble ces opérations pour obtenir des chaînes de traitement, et on peut attacher ces traitements à certaines évènements du système, par exemple pour que le traitement se déclenche pour les fichiers déposés dans un dossier qui devient “magique”. Cela existe depuis 2004 et même si les traitements sophistiqués ne sont pas possibles (il n'y a qu'une seule branche de traitement) cela fournit une offre convaincante pour concevoir des traitements par lot simplets.

    3. À la fin des années 90 un copain de fac m'avait parlé d'un logiciel qu'ils utilisaient pour concevoir les circuits électroniques, qui était exactement un environnement de développement WYSIWYG – certes non généraliste. Certains participants de LinuxFR connaissent certainement par cœur ce type de logiciel!

    4. Plus proche de nous, les développeurs utilisant React ont à leur disposition quelques outils qui leur permettent de faire du développement interactif.

    Pour être clair je pense que l'idée de faire du développement interactif avec un outil visuel permettant d'ajuster des blocs entre eux est en soi pertinente, mais si on veut être pris au sérieux en tant que chercheur sue le sujet, il me semble plus judicieux de proposer un environnement qui permettrait de développer une application relativement ambitieuse en guise de prototype plutôt que de refaire un truc qui date des années 90. Cela permettrait de montrer comment on résout de cette façon là des problèmes auxquels sont confrontés les programmeurs. (Bref de s'intéresser un peu au nœud du problème!)

    Du coup on se demande ce que fait réellement dans la vie Victor Bret. Est-ce un agent de la CIA qui a une couverture de chercheur en systèmes automatiques? Est-ce que cela vaut le coup de lire les articles de James Somers dans The Atlantic? (Qui à la différence du blog qui en rapporte le propos ont une prétention journalistique!) Est-ce que ça vaut le coup de traduire ces articles en français?

    • [^] # Re: Article pas terrible

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

      Moi y a un truc qui m'a bien fait marrer c'est qu'il dénonce la complexité des logiciels comme source de bug (et il a parfaitement raison), et pour résoudre ça, il veut une usine à gaz qui va générer automatiquement du code à partir des specs. Comme si ça allait faciliter les choses de rajouter une couche d'abstraction dans un système déjà complexe.

      Au passage, pour illustrer, il donne un exemple trivial d'une gestion d'ascenseur, ou avec un simple Arduino je peux te faire un code certifié 100% sans bug (et promis, la porte ne s'ouvrira que si l'ascenseur est à un étage). Son exemple est rigolo parce que en tant que codeur, il se pourrait très bien que j'ai pas spécialement pensé à ça (admettons), mais si je devais décrire le système avec des boi-boites et des fi-fils, le pb serait le même : il faut y penser ! La difficulté n'est pas de le coder, mais bien d'y penser. Mais une fois qu'on y a pensé, pas besoin d'un clic-o-tron pour gérer un ascenseur, ça n'apporte strictement rien.

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

      • [^] # Re: Article pas terrible

        Posté par  . Évalué à 6.

        si je devais décrire le système avec des boi-boites et des fi-fils, le pb serait le même : il faut y penser ! La difficulté n'est pas de le coder, mais bien d'y penser. Mais une fois qu'on y a pensé, pas besoin d'un clic-o-tron pour gérer un ascenseur, ça n'apporte strictement rien.

        Bah, un clickotron qui représente graphiquement la gestion d'un ascenseur, je faisais déjà ça en 1996 durant mes études : ça s'appelle le grafcet.

    • [^] # Re: Article pas terrible

      Posté par  . Évalué à -2.

      Je n'ai pas dit que j'étais d'accord avec l'auteur de l'article, mais qu'il était argumenté.
      Les commentaires le sont d'ailleurs, pour ou contre. Ça repose.
      Un article comme ça dans un média reconnu (mainstream?) c'est rare.

      J'ai une formation des années 90 (début, je suis vieux) mais les outils ne sont pas si mal. Vous vous en servez encore.
      Les outils graphiques sont ce qu'ils sont, mauvais.

      Par contre, un bon compilateur, interpréteur qui permettrait de traduire notre pensée en code ça serait pas mal, non?

      "Jump out of the system", comme me disait mon prof en programmation fonctionnelle (fin 80), reste une utopie, mais avec le matériel actuel on pourrait y arriver. Sauf si les codeurs, comme moi, sont fainéants.

      • [^] # Re: Article pas terrible

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

        Oui et je parle bien de l'article, pas de ton journal! :) Comme je l'ai écrit il y a beaucoup des points que je mentionne dont il n'était pas difficile de parler dans un média grand public, d'autant plus que l'auteur original serait programmeur. Je ne suis pas d'accord avec l'idée qu'écrire sur un sujet technique dans un media tout public autorise à se contenter d'un texte de mauvaise qualité – qui est à la limite de l'auto-promotion puisque vu son contenu on est en droit de se demander ce qui a effectivement été écrit par le journaliste et ce qui sort d'un dossier qu'on lui aurait mis entre les mains.

      • [^] # Re: Article pas terrible

        Posté par  . Évalué à 4.

        Je n'ai pas dit que j'étais d'accord avec l'auteur de l'article, mais qu'il était argumenté.
        Les commentaires le sont d'ailleurs, pour ou contre. Ça repose.
        Un article comme ça dans un média reconnu (mainstream?) c'est rare.

        Il faut faire attention avec ces journaux. Si on s'y interesse on finis par penser comme eux, par extension, penser comme tout le monde et finalement se plonger avec la force du nombre dans les erreurs et les delires collectifs sans s'en rendre compte.

        Il faut les laisser mourir et plutot chercher l'info volontairement au lieu de se laisser servir. Et on se trompe, on apprend, on est curieux, on decide et c'est bien plus sain.

        • [^] # Re: Article pas terrible

          Posté par  . Évalué à -1.

          c'est marrant, je suis curieux, et ai un esprit critique.
          Après, libre à vous d'entrer dans la paranoïa.
          Je cherche l'information en toute indépendance, et je suis ravi de la partager.
          Même si ce n'est qu'un lien; peut-être, un jour, j'écrirais un vrai journal.
          Pour l'instant j'en suis incapable.

          • [^] # Re: Article pas terrible

            Posté par  . Évalué à 5.

            c'est marrant, je suis curieux, et ai un esprit critique.
            Après, libre à vous d'entrer dans la paranoïa.
            Je cherche l'information en toute indépendance, et je suis ravi de la partager.
            Même si ce n'est qu'un lien; peut-être, un jour, j'écrirais un vrai journal.
            Pour l'instant j'en suis incapable.

            Moi je n'ai pas assez d'esprit critique. Je suis fort influencable. Comme je ne peux rien y faire, j'essaie plutot de percevoir ce qui m'influence et de faire le choix d'accepter ou de m'en detourner.

            Mais ce n'est pas super important. C'est parce que vous aviez l'air de faire des efforts pour trouver des bons articles dans la presse mainstream. Je pense qu'il vaut mieux s'en detourner plutot que de faire ce genre d'effort.

            Un article comme ça dans un média reconnu (mainstream?) c'est rare.

    • [^] # Re: Article pas terrible

      Posté par  . Évalué à 3.

      C’est comme jouer aux échecs avec un bandeau sur les yeux : l’essentiel de l’énergie est dépensé à avoir une représentation des pièces et de leurs mouvements…

      Je suis pas un joueur d’échecs mais j’imagine qu’un bon joueur calcule plusieurs coups à l’avance (pour lui et son adversaire) et a toujours l’échiquier (ou plutôt, plusieurs variantes de l’echiquier) dans sa tête quoi qu’il arrive?
      A ce compte la, il peut jouer les yeux bandes, ça fait pas une énorme différence.

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Article pas terrible

      Posté par  . Évalué à 2.

      Pour être clair je pense que l'idée de faire du développement interactif avec un outil visuel permettant d'ajuster des blocs entre eux est en soi pertinente

      Et ça existe déjà. Ça s'appelle Scratch :D

      • [^] # Re: Article pas terrible

        Posté par  . Évalué à 4. Dernière modification le 27 novembre 2017 à 10:37.

        Et ça existe déjà. Ça s'appelle Scratch :D

        Ca ressemble toujours beaucoup a du code habituel. C'est surtout l'utilisation des couleurs qui est un peu plus approfondie, comme de decider de mettre une couleur pour identifier les methodes d'un module. Mais je doute que ca une direction qui permette d'eviter les bug. Ca ne simplifie pas la complexite d'un gros systeme.

        J'aurais plutot pense a Simulink qui enferme des composant preprogrammes dans des boites. J'ai l'impression que ces boites ne partagent pas d'etat global ou ce genre de truc et finalement ca ressemble a de la ligne de commande bash avec les pipes, mais avec plus de parametres d'entree/sortie et c'est pilote par interface graphique: https://en.wikipedia.org/wiki/Simulink

      • [^] # Re: Article pas terrible

        Posté par  . Évalué à 2.

        Moi je pensais au grafcet.

  • # Du code

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

    Du code
    http://www.commitstrip.com/fr/2016/08/25/a-very-comprehensive-and-precise-spec/

    blog.rom1v.com

  • # Bof mouais pfff

    Posté par  . Évalué à 4.

    Mouais, construire une usine à air compressé en aval de l'usine à gaz pour éviter les bugs…

    Le problème des logiciels à plusieurs millions de lignes de code, ce n'est pas forcément les millions de lignes de code. Si le moindre composant contient un noyau Linux, ça en fait des lignes de code, mais ça n'implique pas forcément une complexité délirante.

    Comme l'article mélange un peu tout (mauvaises pratiques de programmation, mauvais choix industriels, problèmes de formation, …), pas facile de retrouver ses petits. Mais je ne vois rien sur la métaprogrammation.

    Dans l'ensemble, je doute que l'amélioration de la situation vienne des outils (outils de preuve, programmation "visuelle", déboggueurs, nouveaux langages de programmation, etc). J'ai l'impression que les améliorations viendront d'une amélioration des pratiques (ce qui vient parfois avec l'utilisation d'outils, mais pas forcément).

    • [^] # Re: Bof mouais pfff

      Posté par  . Évalué à 5.

      Quoi qu’il arrive, l’écosystème logiciel est complexe. Une amélioration des pratiques ne modifiera cette complexité qu’à la marge. Exemple, si tu veux faire un logiciel qui manipule la loi, ben tu te fades la complexité de la loi, et elle ne dépend pas des pratiques logicielles, elle est intrinsèque.

      On peut cependant observer qu’un outillage puissant est important pour débusquer et/ou se débarrasser des bugs des programmes C - ou l’utilisation de meilleurs langages comme Rust qui permettent d’en éviter certains. Mais il faut construire un Rust.

      La thèse de l’article c’est que la complexité des spec des logiciels qu’on veut écrire dépasse la capacité d’un être humain à l’appréhender. On peut être tenté de résoudre ça de manière « pratique » en limitant la complexité des programmes à quelque chose de gérable, en faisant des programmes « simples », mais c’est reporter la complexité (intrinsèque) à un niveau « supérieur » (l’interaction entre ces briques). Et c’est pas dit qu’on puisse tout le temps ramener par de simple pratique cette « complexité de niveau supérieure » à quelque chose de gérable facilement. Du coup, des outils et des pratiques pour gérer ça sont utiles.

      Cela dit je suis pas certains qu’on puisse séparer outil et pratiques si facilement (non seulement on crée des outils pour s’aider à travailler de la manière qu’on veut, ex. git par Linus, mais aussi les pratiques découlent des outils qu’on utilise (ex. les design pattern ne s’implémentent pas de la même manière dans différents langages).

      • [^] # Re: Bof mouais pfff

        Posté par  . Évalué à 2. Dernière modification le 27 novembre 2017 à 13:42.

        La thèse de l’article c’est que la complexité des spec des logiciels qu’on veut écrire dépasse la capacité d’un être humain à l’appréhender

        Ce n'est pas vraiment ce que j'ai compris. Pour moi, l'auteur parlait des problèmes de la conception des logiciels. Typiquement, ça parle de code spagghetti, de variables qui sont accédées d'un peu partout, du fait qu'on n'arrive pas forcément à comprendre les implications du code qu'on a sous les yeux. Je n'ai peut-être pas vraiment compris, du coup, parce que pour moi, c'est avant tout un problème de conception du logiciel, de gestion de projet, et de compétence (voire de capacités) des programmeurs. C'est vrai que pour écrire du code, il faut parfois être très très concentré, ça peut demander un niveau d'abstraction assez profond, mais finalement pas beaucoup plus que pour écrire un roman avec beaucoup de personnages, ou de concevoir un objet industriel complexe. Et justement, la plupart des langages de programmation et de méthodes de programmation efficaces offrent des outils pour réduire cette complexité, de manière à ne travailler qu'avec des sous-parties indépendantes du logiciel. Ce n'est pas parce qu'un logiciel a 10M lignes qu'à chaque ligne de code on est susceptible de savoir ce qui se fait à l'intérieur de n'importe quel autre module. La programmation fonctionnelle, la programmation objet, ou simplement les bons comportements (encapsulation, pas de magic values, pas de variables globales, passage par valeur, pas de pointeurs nus…) permettent de grandement réduire la taille des sous-problèmes qu'on doit régler quand on code.

        Après, je n'ai jamais participé à des projets gigantesques où la quantité de code était telle qu'il était humainement impossible d'avoir en permanence une représentation mentale de l'organisation complète du logiciel. J'ai toujours trouvé hallucinant la taille de certains logiciels, en me demandant s'il y avait en effet besoin d'autant de code pour effectuer des tâches qui n'apparaissaient pas comme si complexes que ça. Quand on dit qu'il faut 20M lignes pour coder le système de freinage et d'accélération d'une voiture, ça me semble assez dément. Comme ça a été dit plus haut, si tu as besoin de plusieurs centaines de lignes pour piloter un ascenseur, c'est que tu as un sérieux problème de design.

        • [^] # Re: Bof mouais pfff

          Posté par  . Évalué à 3.

          J'ai toujours trouvé hallucinant la taille de certains logiciels, en me demandant s'il y avait en effet besoin d'autant de code pour effectuer des tâches qui n'apparaissaient pas comme si complexes que ça. Quand on dit qu'il faut 20M lignes pour coder le système de freinage et d'accélération d'une voiture, ça me semble assez dément.

          Il doit y avoir des filtres a base de resolution d'equation differentielles. Pour faire plus smooth.

        • [^] # Re: Bof mouais pfff

          Posté par  . Évalué à 2.

          Quand on dit qu'il faut 20M lignes pour coder le système de freinage et d'accélération d'une voiture, ça me semble assez dément

          J’aurai tendance à penser qu’on met des gens avec un minimum de compétences pour faire un truc pareil, perso. Je sais bien qu’on peut penser que la majorité des programmeurs ont un niveau moyen, ça me semble un poil arrogant de penser qu’il n’y a pas de bonne raison pour ça et que le code d’un système critique n’est pas passé par des revues de code qui détectent les problèmes de design évident. C’est si compliqué d’imaginer que tous les problèmes de la vraie vie n’ont pas des solutions simples ?

          Ça explique une certaine foi dans le progrès technologique de ta part remarque …

          • [^] # Re: Bof mouais pfff

            Posté par  . Évalué à 5.

            C’est si compliqué d’imaginer que tous les problèmes de la vraie vie n’ont pas des solutions simples ?

            Bah, on peut se battre à coups de généralités pendant longtemps, ça ne va pas faire avancer le Shmilblick.

            Comme on n'a pas accès au code de ces trucs critiques, on ne peut pas savoir. Le seul truc qui, à ma connaissance, a fuité dans la presse, c'est l'histoire du logiciel de Toyota, pour lequel les experts n'étaient d'accord que sur le fait que le code était tellement imbittable qu'il était impossible de savoir s'il y avait des bugs ou non.

            Le truc, c'est qu'il y a une telle inflation de la taille des logiciels sans pour autant que les fonctionnalités soient faramiseuse qu'il est plutôt sain de se poser des questions. Après, on peut aussi se mettre la tête dans le sable et se dire "boarf, il collent 20M lignes de code dans ma bagnole, mais ils doivent savoir ce qu'ils font". Mais on sait tous que ça n'est pas le cas ; il y a plus de lignes de code dans une bagnole que dans un avion de ligne, et ça, c'est louche, par exemple.

            • [^] # Re: Bof mouais pfff

              Posté par  . Évalué à 2.

              En admettant que tu aies raison, comment lutter contre cette inflation ? Dire « il faut lutter contre l’inflation » ça relève du voeux pieux et ça ne fournit pas de méthode pour améliorer les choses. Perso la réponse « c’est la faute des programmeurs qui codent mal » me semble assez peu convaincant. Ça ne fournit pas d’explication au fait qu’il codent mal.

              Faudrait-il que ça passe par des … outils pour les aider ?

              • [^] # Re: Bof mouais pfff

                Posté par  . Évalué à 4.

                c’est la faute des programmeurs qui codent mal

                Je ne pense pas avoir dit ça. Pour avoir un avis réellement intéressant, il faudrait discuter avec des gens qui sont spécialistes de l'embarqué et des systèmes sécurisés ; le cas de la bagnole ou de l'avion de ligne sont particulièrement techniques (contraintes du temps réel, problèmes de sécurité, etc). Si on en revient à des applications traditionnelles sur un ordinateur, qui ne font rien de critique, alors je pense que l'hyper-inflation du code vient de l'utilisation de tout un tas de couches de frameworks, de générateurs de code, de compilateurs de compilateurs entre plusieurs langages, etc., donc typiquement de l'utilisation d'outils "modernes", censés faciliter la tâche du développeur, mais qui finissent par encapsuler le code dans des couches multiples de trucs lourds et inutiles. Au final, on a un oignon, alors que le code lui-même représente un tout petit truc au centre.

                Un truc par exemple que je trouve hallucinant, c'est la taille des applications Android. Le moindre démineur pèse des dizaines de méga-octets, c'est totalement ridicule. Comment imaginer que ce genre de choses puisse tourner rapidement et efficacement?

                Après, le problème ne vient pas forcément des programmeurs, mais plutôt de la gestion des projets, de la manière de calculer la productivité, d'encourager les pratiques vertueuses ou de décourager les mauvaises pratiques (copier-coller…).

                • [^] # Re: Bof mouais pfff

                  Posté par  . Évalué à 4.

                  J’ai l’impression d’entendre une vieille rengaine .

                  Et puis tu montres des injonctions contradictoires : éviter le copier coller, donc faciliter les techniques de réutilisation du code, et en même temps ne pas utiliser de framework, ce qui a pour but de pas réinventer la roue. Les générateurs de code, franchement, je comprend pas. Utiliser un générateur de code ça minimise le code qu’il y a à écrire, au même titre qu’un compilateur. Autant se concentrer à les fiabiliser et à fiabiliser les générateurs.

                  Du coup on a un gros problème pour mesurer ce qu’on appelle une « ligne de code ». Si on compte les lignes transformées (compillées, générées), les lignes écrites, on trouvera pas le même chiffre. Ptete même moins si on considère les techniques d’élimination du code mort.

                  • [^] # Re: Bof mouais pfff

                    Posté par  . Évalué à 2.

                    Bah oui, tu n'as pas tort, mais du coup, je ne comprends pas pourquoi ces usines à gaz annoncent des millions de lignes de code. C'est sûr que si tu as un truc pour lire un DVD, et que tu as derrière un Linux, un Firefox, et un truc en java, bah avant d'avoir la moindre ligne de code tu te tapes un système bloaté derrière… Mais est-ce vraiment de ça dont on parle? Quand on regarde le nombre de lignes de code derrière un logiciel métier, on ne parle pas du système.

                    Après, toujours pareil : 990 000 lignes de bibliothèques et 10 000 lignes de vrai code, ça n'est pas du tout pareil que 1M lignes de code pour le logiciel. D'un autre côté, des bugs peuvent se cacher dans les bibliothèques, les compilateurs, les surcouches, les frameworks…

                    Dans le fond, c'est plus un sentiment général qu'une méthode de développement. J'ai l'impression que si on voulait des systèmes moins buggés et plus compréhensibles, il faudrait beaucoup moins de code, de la factorisation de code via des bibliothèques, et des applications qui restent simples et qui ne font qu'une chose, mais bien. Or, on se dirige vers exactement le contraire : de plus en plus de surcouches, des méga-projets qui se battent sur la longueur du code, des trucs tellement complexes que personne ne comprend vraiment ce que ça fait, des bugs insolubles, des livraisons de binaires via des containers qui contiennent de multiples duplicats des mêmes bibliothèques jamais mises à jour, avec des versions différentes… On peut coller autant de tests unitaires ou d'assistants de preuve derrière, on ne fait que vérifier avec une machine qu'on n'a pas tout pété, mais on ne maitrise pas mieux pour autant ce qui tourne sur la bécane.

                    • [^] # Re: Bof mouais pfff

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

                      D'un autre côté, des bugs peuvent se cacher dans les bibliothèques, les compilateurs, les surcouches, les frameworks…

                      J'ai l'impression que si on voulait des systèmes moins buggés et plus compréhensibles, il faudrait beaucoup moins de code, de la factorisation de code via des bibliothèques

                      Je sais pas trop où tu veux en venir et je soupçonne ne pas être le seul.

            • [^] # Re: Bof mouais pfff

              Posté par  . Évalué à 1.

              C'est vrai que autant de lignes de codes pour un programme sans interface graphique, qui gère de l'informatique matérielle (capteurs - actionneurs), ça paraît très curieux.
              Peut-être utilisent-ils des environnements de développement dit rapides, qui produisent rapidement du code lourd et lent ?

            • [^] # Re: Bof mouais pfff

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

              Après, on peut aussi se mettre la tête dans le sable et se dire "boarf, il collent 20M lignes de code dans ma bagnole, mais ils doivent savoir ce qu'ils font". Mais on sait tous que ça n'est pas le cas ; il y a plus de lignes de code dans une bagnole que dans un avion de ligne, et ça, c'est louche, par exemple.

              Mouais.
              Pour avoir travaillé sur des projets aéro, les 20 millions de ligne sont largement dépassés rien que par le système multimédia qui peut embarquer un Linux avec pas mal de composant. Chez Airbus, sur certains modèles, les interfaces de commandes des stewart c'est un Linux qui lance Firefox (via X) en plein écran avec un plugin Java derrière.

              Bref, tout dépend si les 20 millions de lignes chez Toyota ne gère que les freins (ce qui est quand même beaucoup c'est vrai) ou toute la voiture. En tout cas un avion complet c'est vraiment beaucoup de code, même sans le multimédia.

              Après l'automobile et l'aéronautique, même s'ils ont beaucoup de points communs en terme de rigueur de développement, ce ne sont pas les mêmes exigences exactement pour certifier le produit à la vente. Peut être que l'automobile a été trop souple dans ce cas là.

Suivre le flux des commentaires

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