larlet-fr-david-cache/cache/9c0244d3a0cd8e36c041b0f548c0e022/index.md

title: Les outils sont-ils la solution à nos problèmes ?
url: http://blog.mageekbox.net/?post/2018/01/08/Les-outils-sont-ils-la-solution-a-nos-problemes
hash_url: 9c0244d3a0cd8e36c041b0f548c0e022

<p><a href="https://medium.com/@ptitfred/haskell-and-fp-a83b5b22f67f">Frédéric Menou</a> a écrit un très bon article à propos de la <a href="https://fr.wikipedia.org/wiki/Programmation_fonctionnelle">programmation fonctionnel</a> et <a href="https://fr.wikipedia.org/wiki/Haskell">d’Haskell</a>, dans lequel il décrit notamment les raisons qui l’ont amené à apprendre ce paradigme et ce langage.</p>

<p>Je n’ai pas d’avis sur son choix d’Haskell pour son activité, car je ne connais pas ce langage et encore moins son métier.</p>

<p>Par contre, je connais relativement bien la problématique qui l’a mené vers cette solution, car j’ai rencontré exactement la même.</p>

<p>En effet, si je résume (certainement très grossièrement) sa démarche, Frédéric s’est tourné vers Haskell essentiellement parce qu’il cherche à écrire le moins de bogues possible lorsqu’il code, et il pense que le formalisme offert par le langage lui permet d’y parvenir, tout en améliorant la communication avec l’ensemble des parties prenantes dans un développement informatique.</p>

<p>Or, cela fait au moins maintenant presque 12 ans que je cherche à atteindre le même objectif.</p>

<p>De plus, j’ai commencé à développer de la même façon que Frédéric, en me consacrant sur les algorithmes et l’aspect technique, en renforçant ma maîtrise de PHP et des outils afférents grâce à une veille technologique quotidienne.</p>

<p>Notre parcours concernant les éditeurs de code a également été très similaire.</p>

<p>Pourtant, malgré une problématique similaire, nous sommes parvenus à des solutions très différentes.</p>

<p>Frédéric a remis en cause ses outils et en a sélectionné d’autres qui lui semblent plus adaptés pour atteindre son objectif.</p>

<p>De mon côté, au lieu de remettre en cause mes outils, j’ai choisi de me remettre en cause et de mieux comprendre les principes fondamentaux du paradigme que j’utilise, ce qui m’a amené à faire évoluer très fortement mes méthodes de développement.</p>

<p>À mon avis, celui qui peut dire lequel de nous deux a la meilleure stratégie pour atteindre son objectif n’est pas encore né, et je n’en ai donc pas la prétention, mais son billet m’a tout de même inspiré une réflexion que j’aimerai maintenant vous faire partager.</p>

<p>L’être humain a une tendance naturelle à incriminer ses outils lorsqu’il ne parvient pas à réaliser correctement quelque chose.</p>

<p>C’est un fait, et c’est bien normal, puisqu’il est bien plus simple et agréable pour nous de remettre en cause l’outillage que de se remettre en cause.</p>

<p>Donc, lorsqu’il est en situation d’échec, l’Homme adopte principalement deux stratégies.</p>

<p>La première consiste à changer d’outils, la seconde à les modifier dans l’espoir qu’une fois « améliorés », ils permettront de réussir.</p>

<p>Et parfois (et j’insiste sur ce « parfois »), je pense que cela a des effets très pervers, et je vais donner trois exemples, certes très caricaturaux, mais qui sont également à mes yeux très représentatifs.</p>

<p>Autrefois, dans des temps fort fort lointains, le développeur devait gérer lui-même la mémoire utilisée pour son programme, ce qui parfois, provoquait des erreurs de segmentations.</p>

<p>Une couche de complexité a donc été ajoutée aux langages informatiques afin de décharger les développeurs de cette tâche et ainsi éviter ces erreurs, et aujourd’hui, ils n'ont plus à se soucier de la mémoire vive, ou de quoi que ce soit d’autre relatifs au matériel sur lequel sera exécuté le code, d’ailleurs.</p>

<p>Mais qui, aujourd’hui, connait encore le fonctionnement de la mémoire vive d’un ordinateur ?</p>

<p>Pour ce que je peux en constater, il n’y a plus que les vieux barbus et les spécialistes de l’embarqué qui possèdent encore cette connaissance, alors qu’il s’agit de l’une des bases de la technologie sur laquelle repose le métier de développeur.</p>

<p>De plus, si autrefois, il pouvait y avoir des erreurs de segmentations, en contrepartie, la mémoire était généralement gérée aux petits oignons, car il s’agissait en plus d’une ressource comptée qu’il ne fallait pas gaspiller.</p>

<p>Mais aujourd’hui, il suffit qu’un onglet inactif dans un navigateur ne consomme pas plus de 80 Mo pour que nous soyons heureux…</p>

<p>Le quotidien du développeur a donc été « amélioré » grâce à une évolution de ses outils, mais en contrepartie, il a perdu de la connaissance et les programmes ont perdu en efficacité.</p>

<p>Quant à la stratégie du changement total d’outil pour palier à une défaillance, l’une des plus belles illustrations est justement la démarche décrite par Frédéric dans son billet (ce qui ne veut pas dire que je pense qu’il a fait une erreur, encore une fois, son billet n’a été qu’une source d’inspiration pour écrire celui-ci).</p>

<p>Nombre de développeurs passent en effet de la programmation orientée objet vers la programmation fonctionnelle, car ils pensent qu’elle est plus apte à répondre à leurs besoins, sans se poser de question par rapport à leur pratique et à leur compréhension de la programmation orientée objet.</p>

<p>Or, pour la plupart, ils pratiquent cette dernière sous une forme « diminuée » qui ne leur permet pas d’en tirer la quintessence.</p>

<p>Et le monde du logiciel n’est pas le seul à être concerné, celui du matériel l’est tout autant.</p>

<p>Les bases de l’architecture x86 ont été posées par Intel à la fin des années 1970, mais pour autant, elle est toujours massivement utilisée aujourd’hui.</p>

<p>Pourtant, je connais assez peu de personnes compétentes dans le domaine qui pense que cette architecture est la panacée.</p>

<p>Mais il faut dire qu’Intel a tout fait pour contrebalancer cela par une évolution à marche forcée des performances, en ajoutant de la complexité couche après couche afin de respecter la <a href="https://fr.wikipedia.org/wiki/Loi_de_Moore">loi de Moore</a>.</p>

<p>Et aujourd’hui, nous faisons face à <a href="https://meltdownattack.com">Meltdown et Spectre</a>, et l’avenir ne semble <a href="https://www.blackhat.com/docs/us-17/thursday/us-17-Domas-Breaking-The-x86-ISA.pdf">pas radieux</a>.</p>

<p>Et comme tous les fondeurs sont pris dans la course à la performance sous la pression du marché, les concurrents d’Intel ont fait de même en utilisant les mêmes concepts, ce qui fait qu’aujourd’hui, la <a href="https://twitter.com/ochsff/status/949840209553887232">quasi-totalité des CPU</a> actuellement en <a href="https://twitter.com/Blips_and_Chitz/status/949979576087797760">activité</a> est plus ou moins vulnérable à ces attaques d’un nouveau genre (même si elles ne semblent pas <a href="https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/">si nouvelles que cela</a>).</p>

<p>D’ailleurs, j’aime beaucoup ce commentaire de <a href="https://lkml.org/lkml/2018/1/3/797">Linus Torvald</a> à ce sujet :</p>

<blockquote>

<p>I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.</p>
</blockquote>

<p>Plutôt que de repartir à la table à dessin et se creuser la tête, Intel a en effet préféré spéculer le plus longtemps possible sur l’architecture x86 en la faisant évoluer aux forceps pour pallier ses défaillances grâce à une augmentation vertigineuse des performances, sans jamais en remettre en cause la philosophie et les fondamentaux.</p>

<p>Pour conclure, il peut être sain de changer d’outils ou de les rendre plus complexes afin de se simplifier la vie, mais il ne faut surtout pas oublier qu’il y a toujours un prix à payer, et par conséquent, il ne faut surtout pas penser qu’un tel changement vous permettra systématiquement d’atteindre votre objectif plus vite ou plus efficacement.</p>

<p>Le chemin que vous aurez à parcourir pourra en être simplifié, mais il pourra également vous emmener vers un précipice, une voie de garage, ou bien encore vous faire faire bien des détours tortueux et dangereux.</p>

<p>Pour preuve, malgré la simplicité apparente de son exemple pour illustrer le typage algébrique, malgré les fonctionnalités d’Haskell qui sont censées lui permettre d’esquiver les bugs, Frédéric a <a href="https://twitter.com/clementd/status/950270642418601984">introduit un bug</a> dans le code présent dans son billet…</p>

<p>Alors parfois, faire preuve d’humilité, d’honnêteté, en remettant en question ses pratiques afin de repartir sur des bases plus saines peut valoir le coût, plutôt que de déléguer à des outils la charge de nous rendre meilleurs, ce qui leur est impossible par nature.</p>

<p>La solution est rarement dans les outils, mais l’Homme est toujours à l’origine des problèmes.</p>