Damian Conway à OSCON Europe

Article publié dans Linux Magazine 81, mars 2006.

• GLMF

  Tout d'abord j'aimerais parler de ton livre : ce qui t'a amené à l'écrire, et quel genre de besoin il satisfait.

• Damian

  La vraie motivation est que je donnais beaucoup de formations sur différents aspects de Perl, et je n'arrêtais pas de voir les gens faire les mêmes erreurs fondamentales et les mêmes mauvais choix dans le code, non pas dans le sujet de la formation, mais dans le code autour. Par exemple, on développait des classes orientées-objet dans un cours orienté objet, et ils comprenaient bien l'idée de créer des objets avec bless() et tout cela, mais ils faisaient des erreurs assez fondamentales, comme par exemple ne pas déballer les arguments de leurs sous-programmes de @_ dans des variables lexicales.

  Pour moi, cela n'avait rien à voir avec le contenu du cours, c'était juste de mauvaises habitudes qu'il avaient prises. Ou encore ils utilisaient des constructions que je trouvais et que je trouve encore dangereuses. Ils utilisaient beaucoup d'évaluations de chaînes et ce genre de choses. Sans savoir ce qui pouvait mal se passer avec.

  Il m'est graduellement apparu que les gens ont beaucoup d'information à leur disposition en ce qui concerne les techniques de haut niveau de ce qu'on peut faire avec Perl, mais qu'ils ne se souvenaient pas vraiment ce qu'on leur avait appris à l'origine, quand on leur a appris à programmer, sur les bonnes pratiques, sur la bonne manière de faire les choses.

  Aussi ai-je commencé à développer pour moi-même une liste des choses dont je devrais parler aux gens, des choses qu'ils devraient éviter autant que possible. Ça a commencé à se savoir et les gens voulaient connaître mes idées. Donc j'ai fait un cours là-dessus, et beaucoup de gens étaient intéressés pour le suivre. Je suppose que quand O'Reilly a vu ce cours, hé bien ils se sont dit que ça ferait un très bon livre.

  Et ils m'ont offert de l'argent... alors j'ai écrit le livre. ;-)

• GLMF

  Certaines des recommandations décrites dans le livre donnent l'impression de dire « Si vous êtes un expert, essayez d'être plus moyen, et si vous êtes moyen, restez-le. ». Je pense que ce n'est pas le but, mais...

• Damian

  Je pense que le but du livre n'est pas tant de faire appliquer les 256 recommandations qu'il décrit. Les 256 recommandations sont un cadre pour réfléchir à ces problématiques. Chacune de ces recommandations est conçue pour répondre à un problème particulier qui existe en programmation, ou avec la façon dont Perl a été conçu.

  

  Damian Conway à OSCON Europe 2005
  Photo James Duncan Davidson/O'Reilly Media

  Maintenant, j'explique au tout début du livre que si vous n'êtes pas d'accord avec la solution que je propose, alors assurez-vous que vous avez une raison de n'être pas d'accord, et que ce n'est pas juste « nous n'avons jamais fait comme ça ». Si vous avez une raison, et si vous pouvez argumenter avec succès « Non, nous devons le faire de cette autre façon, car c'est plus logique pour nous », alors ça ne me pose aucun problème que ces gens ignorent ces règles et codent avec le style qu'ils se sont choisi.

  Pour répondre directement à ta question, je pense qu'il faut effectivement que les programmeurs vraiment très avancés soient un peu moins avancés quand ils travaillent en équipe. Parce que ça ne sert à rien d'écrire du code qu'une personne sur dix dans votre équipe va comprendre. Il faut coder à un niveau auquel l'équipe en général peut suivre. Il ne faut pas coder au niveau du plus mauvais programmeur de l'équipe, mais il faut coder à un niveau où il y a au moins quelques personnes qui peuvent comprendre votre code, maintenir votre code, déboguer votre code.

  Et tu sais, franchement, quand on écrit des modules comme ça (très très habiles et difficiles) alors on se crée des problèmes pour soi-même, en ce sens qu'on devient le seul à réellement pouvoir s'en occuper. J'ai fait cette expérience moi-même : j'aimerais pouvoir donner beaucoup des modules que j'ai écrits et avoir quelqu'un d'autre pour s'en occuper à partir de maintenant, mais beaucoup d'entre eux ont un code tellement complexe que les gens les regardent et puis disent « Bien, j'aimerais m'occuper de ce code pour toi, mais je ne le comprends pas. »

  Pour moi, le code est clair et je peux comprendre ce qu'il fait, mais ça n'est d'aucune aide dans un environnement de groupe. Dans un environnement de groupe, il faut jouer en équipe, et jouer en équipe, ça ne veut pas dire jouer mieux que le reste de l'équipe, ça veut dire jouer à un niveau où le reste de l'équipe peut jouer avec vous.

• GLMF

  Mais d'un autre côté, avoir quelqu'un de brillant dans une équipe peut aider à construire un sentiment de ... Les gens aiment faire partie d'une équipe où il y a des gourous.

• Damian

  Absolument. Ça donne un grand sentiment de sécurité de savoir qu'il y a quelqu'un au bout du couloir qui va comprendre le problème avec lequel on se débat. Et je ne suggère pas un seul instant qu'on ne devrait pas embaucher les meilleures personnes ou que le reste de l'équipe ne devrait pas aspirer à devenir de meilleurs programmeurs. Je pense que ce que je dis dans le livre c'est « Si vous devez enfreindre ces règles, faites-le sciemment. Sachez que vous les enfreignez, sachez pourquoi les enfreignez et sachez quelles sont les risques et conséquences futurs de les enfreindre. ».

  Mon problème, c'est que je vois beaucoup de gens enfreindre les règles parce qu'il ne savent même pas qu'il devrait y avoir des règles pour ces choses-là, ou qu'il y a des problèmes dans la manière dont ils font les choses. Tu sais, je ne veux pas que tout le monde devienne des automates qui programment tous dans le même style médiocre. Ce que je veux c'est que les gens soient éclairés, qu'ils deviennent conscients de la décision qu'ils prennent, y compris au niveau des décisions qu'ils prennent quand ils choisissent leurs noms de variables, et qu'il prennent ces décisions d'une manière consciente et intentionnelle, plutôt que de suivre n'importe laquelle des habitudes qu'ils ont prise au fil des ans.

• GLMF

  Donc c'est vraiment « Lisez le livre pour découvrir tous les problèmes potentiels, et puis appuyez-vous dessus pour créer votre propre politique. »

• Damian

  Oui, je crois. Je pense que beaucoup des choses que je suggère sont ... Il est très probable que beaucoup de gens vont les prendre telles quelles de toute façon. Parce que ce sont de bonnes solutions à ces problèmes, et que c'est plus facile de prendre la bonne solution de quelqu'un d'autre que de réinventer sa propre bonne solution.

• GLMF

  Qui sera probablement moins bonne.

• Damian

  Oui. Enfin, je n'en sais rien, mais c'est certainement beaucoup plus de travail et vous ne pouvez pas être certain du résultat, dans ce cas. Ce que j'espère que beaucoup de gens feront, c'est qu'ils vont utiliser le livre pour deux choses : un, qu'ils vont utiliser le livre comme un moyen de comprendre les problèmes plus profonds de la programmation Perl et certaines des manières d'éviter ces problèmes ; mais j'espère aussi qu'ils vont l'utiliser comme base pour leur propre style de programmation. Donc peut-être qu'ils vont prendre 180 des 256 règles, dont ils vont dire « Oui, ceci est sans aucun doute ce que nous voulons, parce que c'est déjà ce que nous faisons. » ou quelque chose comme ça. Et qu'ils diront aussi « mais en ce qui concerne celles-ci nous ne trouvons pas que ce soit un argument irrésistible, nous ne pensons pas que le risque justifie la restriction que la règle impose, aussi nous n'allons pas suivre cette recommandation, ou nous allons suivre une variation de cette règle, ou nous allons la remplacer par notre propre règle. ».

  Et si les gens font cela, alors j'ai atteint mon but, parce qu'ils sont conscients et qu'ils font des choix conscients.

• GLMF

  OK. Je vais maintenant passer à la partie Perl 6 de ton engagement dans Perl. J'ai vu que tu fais une présentation sur le sujet cet après-midi. Comment le développement de Perl 6 a été changé par l'arrivée de Pugs ? Je sais que Pugs faisait partie du plan depuis le début... ;-)

  Note : « Pugs faisait partie du plan depuis le début » fait référence à un T-shirt polémique vendu aux enchères à YAPC::Europe 2005 et qui comportait une photo du ministre de l'information de Saddam Hussein pendant la première guerre du Golfe avec le texte « Pugs has always been in the Perl 6 Roadmap. Oh yes. The Python infidels are already surrendering ».

  Pour plus de détails, voir le journal d'Autrijus http://use.perl.org/~autrijus/journal/26602 et aussi http://articles.mongueurs.net/comptes-rendus/yapc-eu-2005.html#h4 (la partie concernant la vente aux enchères).

• Damian

  Hé bien, je ne pense pas qu'il faisait partie du plan depuis le début. Pugs est quelque chose qui est arrivé de nulle part pour nous, juste sorti de l'esprit brillant d'Autrijus. En terme des différences que nous avons vues en ce qui concerne la phase de conception (qui est la phase dans laquelle j'ai été impliqué) il y a quelques effets. D'une, avoir un très large sous-ensemble de Perl 6 effectivement implémenté nous donne une chance de jouer dès maintenant avec notre conception et de voir ce qui marche et ce qui ne marche pas. Ça nous donne aussi une chance de voir ce qui est implémentable et ce qui ne l'est pas. Tu sais, nous avions des idées sur ce qui était faisable, et peut-être qu'ils ne vont pas être capables de le faire, c'est donc un retour très utile en termes de conception. Nous avons passé beaucoup de temps à faire de la conception du point de vue de ce que nous voudrions voir disponible, et une des choses que Pugs nous donne, c'est une manière de tester « Est-ce faisable ou non ? ». Je pense que l'autre chose est que cela retire beaucoup de pression de l'équipe de conception, parce que nous n'étions pas seulement l'équipe de conception, mais l'équipe d'évangélisation, l'équipe de publicité, l'équipe d'explication, l'équipe de tout-ce-que-vous-avez-besoin-de-savoir-sur-Perl-6-nous-devons-vous-l'expliquer.

• GLMF

  Et l'équipe de conception c'est juste trois personnes ?

• Damian

  L'équipe de conception varie entre six et huit personnes selon les moments. Parmi elles, il y en a un plus petit nombre qui sont très actives dans les véritables aspects de conception et le reste sont plus actifs pour nous dire combien nous sommes stupides de faire certaines choses ou combien nous sommes astucieux de faire d'autres choses.

  Mais ce que Pugs a fait, c'est la chose suivante. La critique a toujours été : « C'est du vaporware. Vous avez travaillé dessus pendant six ans maintenant, et nous n'avons encore rien vu en sortir ! ». Je ne pense pas que ce soit bien vrai, mais tu vois, c'est ce que les gens disent. Et des choses du genre : « Perl 6 ne sortira jamais, c'est comme s'il ne devait jamais être effectivement implémenté. ». Ce que Pugs nous a donné, c'est de pouvoir aller à des conférences et quand les gens disent ça de pouvoir leur répondre : « Hé bien, laisse-moi juste démarrer Pugs et te montrer ces fonctionnalités très sophistiquées de Perl 6 tourner en temps réel, sur mon portable, sur mon écran », voilà qui va les faire taire. ;-).

  Tout cela fait tout bonnement disparaître beaucoup des sentiments négatifs que nous avons dû subir pendant si longtemps. Je veux dire, les gens ont été très positifs aussi au sujet de Perl 6, cela les a beaucoup excités, mais il y a toujours ce sentiment sous-jacent de frustration parce que toutes ces choses merveilleuses que nous promettions n'étaient pas disponibles. Tu sais, tout le monde disait « Je le veux maintenant !». Et maintenant nous pouvons dire : « Hé bien, allez jouer avec Pugs. Et si ce n'est pas dans Pugs, ajoutez-le vous-même. ».

• GLMF

  La différence entre Parrot et Pugs, c'est qu'il est assez compliqué de bosser avec Parrot car soit tu hackes la machine virtuelle elle-même, soit il faut apprendre l'assembleur de Parrot. Mais d'un autre côté, est-ce que Pugs n'a pas le même problème, en ce sens qu'il faut apprendre Haskell ? Ou bien est-ce qu'on peut juste s'en tenir à Perl 6 ?

• Damian

  Je pense que ça dépend de ce que tu veux faire. Si le sous-ensemble du langage que Pugs implémente actuellement te satisfait, hé bien tu peux utiliser Pugs joyeusement tout comme si c'était Perl 6 et implémenter des choses et t'en servir. Si tu es mécontent du fait que Pugs contient des bogues, ou qu'il n'implémente pas une des fonctionnalités que tu recherches, alors tu as le choix entre t'investir et apprendre comment utiliser Haskell et étendre Pugs de cette manière ou bien, puisqu'il y a tellement de développeurs Pugs incroyablement actifs, envoyer un mail et dire « Regardez, ceci n'a pas encore été implémenté, mais est-ce qu'il y a quelqu'un qui veut le faire ? ». Et il y a de grandes chances que quelqu'un s'y mette. La communauté autour de Parrot n'est pas aussi grande ni aussi dynamique que celle de Pugs, c'est donc plus difficile de faire ajouter des choses dans Parrot.

  Mais c'est vrai que si tu veux t'impliquer dans l'implémentation, et effectivement faire de ce langage une réalité, cela demande un certain niveau d'implication, et cela nécessite de comprendre le langage d'implémentation qui est utilisé, que ce soit Haskell, ou l'assembleur Parrot, ou (si tu es vraiment sérieux au sujet de Parrot), même jusqu'au C. Donc oui, je ne pense pas que ce soit pour tout le monde, ce n'est pas pour tous ceux qui veulent utiliser Perl 6 aujourd'hui. Mais je pense que c'est pour ceux d'entre nous qui sont des hackers et qui adorent aller au fond des choses, et mettre les mains dans le cambouis, dans le vrai code source. Je pense que ces deux projets fournissent de bonnes opportunités pour ça. C'est sûr que d'apprendre les entrailles de Parrot va vous en apprendre énormément sur la difficulté de créer des machines virtuelles efficaces. Je pense qu'à la même aune, apprendre le fonctionnement interne de Pugs, apprendre Haskell, fera de vous un meilleur programmeur. Haskell contient des idées merveilleuses et des approches merveilleuses de la programmation que vous ne trouverez pas dans beaucoup d'autres langages. Et donc apprendre à faire ça, même si vous ne finissez jamais par faire de véritable développement sur Pugs, cet apprentissage actif d'Haskell fera de vous un meilleur programmeur.

• GLMF

  Nous avons parlé de Perl 6, Perl 6 est le langage des vingt prochaines années. Au moins, les concepteurs de Perl 6 ont une petite idée de ce dont le futur a besoin en termes de langages de programmation. Quel est ton point de vue sur le hardware ? Le matériel est-il pertinent ?

• Damian

  Ironiquement, la pertinence du matériel est dans un état de superposition en ce moment. S'ils arrivent à faire effectivement marcher l'informatique quantique dans le monde réel (ce dont, franchement, je ne suis pas sûr), s'ils y arrivent, alors le matériel va devenir incroyablement pertinent, parce que la façon dont on programme les ordinateurs quantiques est complètement différente. Cela ouvrira donc un domaine entièrement nouveau de l'informatique. Je pense que les ordinateurs non-quantiques vont encore dominer pendant très longtemps, mais essayer de trouver des moyens pour de simples mortels d'exploiter l'informatique quantique sans avoir besoin d'être docteurs en math va rendre cette nouvelle plate-forme matérielle également très pertinente pour les concepteurs logiciels.

• GLMF

  Pour penser aux abstractions correctes ?

• Damian

  Oui, les manières correctes de penser à un problème et de l'exprimer de façon à ce qu'il puisse automatiquement être traduit en quelque chose qu'un ordinateur quantique peut exécuter.

• GLMF

  Donc pour toi, l'informatique quantique ce n'est pas de la science-fiction ?

• Damian

  La théorie est solide. La théorie marche et nous avons des preuves expérimentales qu'on peut faire des calculs quantiques. Je pense que la difficulté de faire tourner un ordinateur quantique, c'est que c'est comme jongler : maintenir les choses dans des états quantiques n'est pas facile, car l'univers tout entier essaye désespérément d'observer votre système et de défaire la cohésion des états quantiques pour les faire s'écrouler en un état observable.

  

  Damian Conway à OSCON Europe 2005
  Photo James Duncan Davidson/O'Reilly Media

  C'est relativement facile de créer un ordinateur quantique qui a disons deux qubits, deux bits quantiques ; c'est beaucoup plus dur d'en créer un qui en a cinq, et c'est extrêmement difficile d'en créer un qui en a sept. Maintenant, si quelqu'un veut un ordinateur avec 24 qubits, c'est combien de fois plus difficile ? Et donc tout ça se ramène à ceci : il faut que quelqu'un fasse une avancée importante et trouve une façon d'isoler les états quantiques et de les préserver qui ne nécessite pas de super-refroidissement, qui ne nécessite pas d'équipement trop complexe. Parce que si jamais j'ai un jour un ordinateur portable quantique, je ne serai pas capable de le super-refroidir.

  Je suppose donc que ça va se trouver être beaucoup plus difficile qu'on ne l'espérait initialement. Et que le développement dans cette branche va être beaucoup plus lent, et que les ordinateurs quantiques vont être, au moins dans l'avenir prévisible, restreints aux très grandes organisations qui peuvent se permettre de disposer de l'usine nécessaire pour les refroidir et les faire fonctionner.

  Maintenant, je suis sûr que si je dis ça, je me trompe certainement. Que quelqu'un va trouver un moyen de le faire. Certaines des approches qui utilisent de la lumière cohérente plutôt que d'autres types de particules montrent quelques promesses. Donc je pense qu'il y a peut-être quelque chose aujourd'hui dont je ne suis pas au courant, ou à laquelle personne n'a encore pensé, et qui pourrait résoudre ce problème.

  C'est ce que je voulais dire en parlant de superpositions : cela va s'écrouler en une technologie tout à fait viable dans un futur proche ou bien cela va s'écrouler en « Hé bien c'était une bonne idée, mais on n'a jamais pu le faire marcher pour autre chose que des applications expérimentales ».

  Je pense que les questions les plus intéressantes se posent du côté de ce qui se passe pour les architectures informatiques plus conventionnelles, parce que l'une des choses que nous observons, et je m'en rends compte moi-même dans le genre de travail que je fais, c'est que le genre de travaux informatiques qui n'étaient pas du tout faisables deviennent maintenant trivialement faciles à faire.

  Ce que je veux dire par là, c'est ... Je suis un grand fan de l'éditeur vi, et une des choses que je voulais faire avec vi, c'était de configurer une macro qui mettrait facilement un gros paquet de marqueurs de commentaires Perl sur une série de lignes. Donc je presse juste une touche et « tac-tac-tac-tac-tac », sur toute la page, toute une série de marques de commentaires pour commenter un bloc. Et je bidouillais les entrailles de vi en essayant de faire marcher ça, quand j'ai réalisé que je devrais juste appeler Perl à la rescousse pour faire ça. Je devrais juste prendre la ligne, la passer à Perl, lui faire analyser la ligne, ajouter la marque de commentaire et recoller le résultat dans l'éditeur.

  Il y a cinq ans, je n'y aurais même pas pensé, car le coût de lancer un interpréteur Perl, lui faire exécuter le programme et ramener l'information, ça voulait dire que je pourrais faire un commentaire toutes les deux secondes. De nos jours, je peux faire 100 commentaires à la seconde, même en rappelant l'interpréteur Perl à chaque fois, parce que j'ai quelques gigahertz de puissance rien que sur mon portable.

  Alors je me dis : qu'est-ce qui se passe si je dispose de dix fois cette puissance ? Ou cent fois cette puissance ? Ça change l'économie de ce qui est faisable ou pas. Donc ajouter à un langage des fonctionnalités qui n'auraient pas été faisables il y a cinq ans, ça a l'air soudainement tout à fait raisonnable, même si nous savons que ce sera très important en termes de calcul, et que ça risque de défaire d'autres types d'optimisations. Si j'ai des dizaines ou des centaines de gigahertz de puissance de calcul, qu'est-ce que j'en ai vraiment à faire ?

• GLMF

  Mais il y a toujours une limite quand on s'attaque à des problèmes vraiment exponentiels. Aucun niveau de puissance ne pourra ...

• Damian

  Oh, naturellement. Je parle pas de ce genre de problèmes, je parle du genre de problèmes que les gens rencontrent vraiment tous les jours.

  Un autre exemple de cela est le module que j'ai écrit qui fait toutes sortes de reformatages de texte (Text::Autoformat). Il n'est pas concerné par le contenu du texte, il se contente de trouver comment le mettre joliment en forme. Pour le moment, c'est configuré de sorte que toutes les cinq minutes environ, je lui envoie le texte, il fait le travail de mise en forme et le renvoie dans l'éditeur.

  Mais je me dis qu'avec deux ou trois fois plus de puissance dans mon processeur, il n'y a aucune de ne pas le faire marcher tout le temps, qu'à chaque fois que je tape un caractère, il refasse toute la mise en forme. Ça change par exemple la façon dont on ferait de la coloration syntaxique. Avec la coloration syntaxique, actuellement, il faut avoir une sorte d'analyseur incrémental qui s'en occupe. Mais si on a assez de puissance, pas besoin de faire ça. À chaque frappe de touche, on peut relancer l'analyseur complet sur le texte complet. Et ça n'a aucune importance.

  Donc je pense que, pour moi, c'est ça l'aspect intéressant du matériel. Je pense que ce sera intéressant c'est : nous arrivons au bout de la loi de Moore pour ce genre de choses, je veux dire il y a encore un peu de place pour grandir, mais je ne pense pas qu'on pourra avoir une centaine de gigahertz sur du silicium. Franchement, je ne pense pas que cela soit faisable du tout. Il va falloir une nouvelle technologie pour ça, peut-être de la nanotechnologie, rod-logic ou quelque chose comme ça. Pour moi, c'est intéressant. La partie la plus intéressante, cependant, c'est la certitude que je ne vais pas avoir à découvrir ça. Parce que je suis pas du tout un spécialiste du matériel, je suis un utilisateur.

  Note : Rod-logic c'est une théorie informatique à base composants électro-mécaniques de taille microscopique, voire moléculaire.

• GLMF

  Du matériel.

• Damian

  Oui.

• GLMF

  Tu parlais des qubits tout à l'heure, je ne suis pas familier de l'informatique quantique... Un ordinateur quantique n'a pas besoin d'un mégaoctet de mémoire quantique, il a juste besoin de quelques qubits, un octet et quelques ?

• Damian

  Pas vraiment. Le nombre d'états dans lequel un système peut être décide de la complexité des calculs qu'on peut faire avec ce système. Dans un ordinateur habituel, pour chaque état particulier qu'on veut enregistrer, il lui faut son propre bit de mémoire pour l'enregistrer. Dans un ordinateur quantique, dans certaines limites, on peut mettre deux bits d'état dans le même morceau de mémoire, dans le même qubit. Il peut être à la fois éteint et allumé en même temps.

  Donc, si je veux la liste de toutes les séquences de 8 bits possibles, tous les caractères latin-1, par exemple, je vais devoir allouer 256 octets pour stocker cette information. Mais si je peux avoir un octet dans lequel chaque bit peut être à la fois allumé et éteint, alors théoriquement, j'ai tout dans un seul octet. La complexité est alors : comment est-ce que je récupère cette information ? Ce que ça nécessite, c'est que je fasse passer le système par une série d'opérations qui vont effectivement « grepper » les états qui ne m'intéressent pas pour ne conserver que les états qui m'intéressent.

  À ce moment-là (quand il ne reste que les états qui m'intéressent), je n'ai plus qu'à le regarder, qu'à observer le système, et provoquer son écroulement dans l'un de ces états. C'est donc une approche complètement différente. Oui, c'est vrai qu'on n'a pas besoin d'autant de qubits de mémoire pour faire certaines opérations qu'on aurait besoin de mémoire ordinaire pour faire les mêmes calculs. D'un autre côté, il faut toujours stocker cette information, tous les différents bits d'informations qu'on va devoir superposer, donc on ne verra surement pas des ordinateurs purement quantiques. On verra des ordinateurs hybrides qui auront un genre d'arrière-boutique, un mécanisme de cache en mémoire ordinaire, et le processeur lui-même sera construit sur cette approche de superposition quantique.

  Mais, l'autre chose est que le genre de problèmes que les ordinateurs quantiques savent résoudre ne sont pas toujours les mêmes problèmes que les ordinateurs normaux savent résoudre. Donc je ne pense pas qu'on voie avant un bon moment un traitement de texte bâti sur un ordinateur quantique. Parce qu'il n'y a pas de gain évident à faire ça. Les ordinateurs courants ont déjà plus de puissance que nécessaire pour faire quoi que ce soit qu'on veuille faire dans ce genre de domaine. Les problèmes pour lesquels les ordinateurs quantiques brillent sont ceux où il y a une croissance exponentielle, comme tu le disais plus tôt.

  Je discutais ce matin avec quelqu'un qui me parlais du jeu de gomoku, le jeu de plateau. Si on ignore les symétries du jeu, il y a quelque chose comme factorielle 361 parties possibles. Donc jouer au gomoku est de quelques ordres de grandeur plus difficile que de bien jouer aux échecs. Car si on commence à essayer de prévoir les coups... Aux échecs quand on prévoie à l'avance, il y a peut-être une douzaine de coups possibles et ton arbre croît d'un ordre de grandeur à chaque nœud. Mais dans une partie de gomoku, il y a littéralement des centaines de coups possibles à chaque tour, donc on croît de deux ordres de grandeur, et ça devient incontrôlable très rapidement.

  Donc je pense qu'on verra apparaître assez tôt, s'il est possible de réussir cette affaire d'informatique quantique, tout comme on a des co-processeurs mathématiques aujourd'hui, on pourrait voir des co-processeurs quantiques pour s'occuper de ce genre de problème compliqué.

• GLMF

  Et nous aurons besoin de langages pour...

• Damian

  Pour faire correspondre ce que les hackers sont capables de comprendre avec ce que l'ordinateur quantique attend, pour réarranger les choses de cette manière.

  Et pendant qu'on parle de matériel, une autre chose qui a l'air intéressante, ce sont les solutions biologiques aux calculs extrêmes comme ceux-là.

• GLMF

  Les brins d'ADN ?

• Damian

  Les brins bactériens, les choses comme ça, ou oui, les brins d'ADN.

  Si on fait représenter à chaque brin d'ADN une certaine partie du problème ou de la solution, et si on arrange la physique du système de façon à ce qu'ils ne se combinent que de manières valides, alors on peut parcourir instantanément un très grand espace de recherche juste en mélangeant les liquides ensemble et seules les solutions valides vont se combiner et précipiter.

  Mais encore une fois, je ne vois pas vraiment comme on va mettre facilement ça sur une puce. Je sais, je ne suis pas génial, alors peut-être qu'il y a des manières simples de faire ça.

  Je crois que ce que nous disons c'est que le hardware devient de moins en moins hard, il devient plus soft, plus malléable et moins spécifique.

  Donc je pense que nous vivons une époque très intéressante. Qu'une seule de ces choses devienne économiquement viable et donc finisse dans des produits réels que des programmeurs réels puissent utiliser, encore une fois je n'en sais rien, mais c'est une époque intéressante pour faire de l'informatique et voir ces changements arriver.