Carnet de lecture, juin 2020

Jouir, en quête de l'orgasme féminin

// Jouir, de Sarah Barmak : un essai prêté par JoPrincesse, qui fait halluciner sur le degré de méconnaissance médicale du sexe féminin par rapport au reste du corps (ou au pénis), et donne envie de se pencher sur le tantrisme et tout ce qui a trait au sexe sans se résumer à la pénétration. // Beaucoup aimé que l’auteur ne soit pas dupe de ce qu’elle rapporte (le récit de la séance tantrique en plein festival de Burning Man est assez génial : « J’ai l’impression d’être dans une église baptiste en train d’écouter Jésus Clit me faire un argumentaire marketing. » Jésus Clit!), sans jamais que ce scepticisme barre la voie de l’exploration. Sous-entendu : ok, y’a plein de hippies barrés, mais peut-être qu’il y a quelque chose à en tirer, quelque chose à prendre (qu’on ne trouvera pas via la science ou le porno). // J’ai atteint (en dehors du domaine sexuel) un stade où se joue quelque chose de cet ordre : tout en refusant de tomber dans l’irrationnel, je lorgne tout de même vers des pratiques / croyances / thématiques qui s’en approchent, quelque chose qui n’aille pas contre (in-, irr-) mais appartienne à un autre régime (a-). Probablement une aspiration spirituelle dévoyée qui guette tout agnostique.

// Les Ritals, de Cavanna : je connaissais l’incipit, donné comme extrait-exemple de pacte autobiographique au collège et au lycée. En prépa, ça avait arraché au prof un non, quand même… (m’enfin, aurait ajouté Gaston). L’ayant lu, ça me fait marrer de l’avoir introduit en contrebande dans une dissertation. Bien trop populaire pour un salon littéraire. On veut bien s’encanailler auprès de Céline parce que c’est sulfureux, mais un franc-parler similaire qui ne crache pas de manière systémique sur l’univers et qui, surtout, se mâtine de patois italien, tou n’imagines pas mettere ça dans oune dissertation. // Ça fait rire, et parfois bien jaune : sous la bonhomie, y’a le malheur et tout ce qu’on balance sur les autres pour l’oublier. Comment vous dire qu’on est loin de MeToo et du politiquement correct, avec des jeux d’enfant qu’on qualifierait aujourd’hui d’agressions sexuelles, et un argot bien xénophobe comme il faut. // Ça m’a gavée ou écoeurée par moments, faut bien avouer (si vous le lisez, sautez le chapitre sur la syphilis), surtout que ça ne va nulle part : c’est une tranche-parpaing de vie. Mais y’a un ton, c’est indéniable, et le gloubigoulba franco-italien est plutôt fun quand on joue sur Duolingo en même temps.

Avec un paquet de vieux mètres, papa en fait un neuf. […]
« Papa, pourquoi ils se suivent pas, les numéros ? » […]
« Ma, qué nouméros ?
– Les numéros sur le mètre. Là, il y a 60, et juste après il y a 25, et juste après 145…
– Ma, qu’est-ce qué t’as bisoin les nouméros ? Tou régard combien qu’il y a les branches, et basta, va bene. Quatre branches, ça veut dire quatre-vingts. Ecco. Pour les pétites centièmtres toutes pétites qui sont en plus, tou comptes avec le doigt, à peu près, quoi, voyons, faut pas perdre le temps à des conneries, qué le plâtre, lui, tou sais, le plâtre, il attend pas, lui. »
Je pense que papa, ce jour-là, a flairé que son piston (il n’a jamais bien discerné, à l’oreille, la différence entre piston et fiston) avait déjà un pied chez les bureaucrates.

// Bref, une lecture de métro (mais si, vous savez, le bouquin qui peut se lire par mini-tronçons, en parallèle d’un autre), que j’ai pas mal laissée trainer avec l’arrêt des transports. // Récupéré dans la bibliothèque de mon arrière-grand-mère.

Marcher jusqu'au soir

// D’habitude, dans l’auto-fiction, ce sont les morceaux de fiction qui créent une petite déception lorsqu’ils se détachent de l’expérience vécue – comme dans La Vocation, à la fin de laquelle Sophie Fontanelle rectifie le nombre de soeurs et précise que, non, la rencontre avec un grand nom de la couture n’a pas eu lieu : c’est le destin qu’on égratigne. // Dans Marcher jusqu’au soir, j’ai fait l’expérience inverse : le regret s’est pointé lorsque j’ai pris conscience que la nuit passée au musée par la narratrice n’était pas une expérience de pensée, mais bien une expérience vécue, organisée même, commanditée, ne reculons devant rien. Le livre que j’avais dans les mains était un livre de commande (j’aurais dû m’en douter, avec le pictogramme Ma nuit au musée sur la couverture) : c’est avec la fiction, cette fois-ci que s’envolait la nécessité. Cela m’a contrariée, même une fois dépassée la mention du papier (et non du roman) que Lydie Salvayre s’était engagée à rédiger. Elle s’est sort bien pourtant ; c’est adroit, on sent le métier, l’intelligence qui retombe sur ses pattes. Malgré tout, ce n’est pas le récit personnel de l’expérience que j’ai pu apprécier ; c’est paradoxalement la partie la plus obligatoire, celle sur l’oeuvre – de Giacometti plus que de Picasso (qui surgit en habile contrepoint à la fin).

// Giacometti et moi, c’est comme la nuit de Lydie Salvayre au musée : une non-rencontre. La première fois que j’ai vu ses sculptures, et la seule je crois, Palpatine s’était arrêté devant dans un musée à Berlin ou à Vienne : son ex adorait Giacometti, mais ni lui ni moi ne comprenions vraiment. On avait contourné les oeuvres sans nous attarder, un peu perplexes. // J’avais oublié jusqu’à son nom, jusqu’à lire les mémoires de Simone de Beauvoir, Simone à la dent dure, aux yeux de qui peu de personnes trouvent grâce : Giacometti était de ce peu-là. Mon cerveau l’a ressorti des affaires classées pour le mettre au purgatoire des on verra un jour, peut-être qu’on verra. // Je n’ai pas revu ses sculptures depuis. Il est probable qu’elles ne me feront toujours aucun effet. Marcher jusqu’au soir sera alors à ranger aux côtés des romans de Sophie Chaveau, qui m’ont fait croire que je pouvais m’enthousiasmer pour un art auquel, la lecture finie, je demeure insensible. L’émotion par procuration.

Parcours de lecture

Ce qui a racheté l’errance du récit pour moi, ce sont les réflexions sur l’échec : elles m’ont sonnée, ont résonné sévère. Mindblown, comme on hashtaguerait sur Twitter. Soudain l’échec n’est plus vu comme fin (une impasse), mais comme condition du recommencement : on recommence parce qu’il est impossible d’aboutir, et que, ce faisant, le sujet n’est jamais clos, mais au contraire toujours à explorer. Ca me sidère un peu, mais wow, j’aimeras trouver ça :

s’acharner passionnément et sans perdre courage pour une fin qu’il savait par avance perdue

Sans perdre courage. Tout en sachant.

Je vous laisse sur ces extraits :

Je le soupçonnais même de saborder délibérément certaines de ses pièces, de faire délibérément des gestes malhabiles, dans le but d’exercer son art d’échouer.
Je pense qu’il voulait se prouver de la sorte que ce que l’on taxait d’impossible restait toujours à tenter, toujours toujours toujours, qu’il état au fond le seul pari qui vaille, ce à quoi je souscrivais à cent pour cent.
Qu’il était le seul pari qui vaille, tout en sachant qu’au final il serait, nous serions rendus au sol, avec un devoir à chercher, et la réalité rugueuse à étreindre.

[…] figurer un visage constituait pour lui un projet devant lequel il ne pouvai qu’échouer, un projet impossible au regard de la perfection rêvée, un projet impossible autant que désirable et qui le requérait impérativement.

Il fallait qu’il continue d’échouer, avec courage, avec patience, avec un inflexible entêtement, jusqu’à atteindre , un jour peut-être ou peut-être jamais au bord du grand secret.

Pour lui l’échec se méritait, il se gagnait de haute lutte, et ce n’était pas de la petite bière. Il fallait déployer une énergie considérable pour en supporter l’épreuve. Réussir, en comparaison, était au fond bien plus aisé. Aussi aisé que conclure. La bêtise consiste à vouloir conclure, avait écrit Flaubert. L’échec délivrait de cette obsession idiote de conclure, cette passion contemporaine. L’échec conférait cette liberté.

Il fallait aller de l’aller obstinément et sans répit, puisqu’aller de l’avant c’était se vérifier vivant.

Coding software : splendeurs et misère du code

[Deuxième partie d’un compte-rendu de lecture sur l’essai Geek Sublime: Writing Fiction, Coding Software, de Vikram Chandra. La première concernait la sociologie du geek. La troisième, à venir, porte sur la critique littéraire indienne avec laquelle l’aspect informatique est mis en regard.]

Geek, man and machine

Le but premier et ultime d’un programme informatique est qu’il fonctionne, c’est-à-dire qu’il compile (pas d’erreur qui empêche de le transformer en langage binaire exécutable par l’ordinateur) ET qu’il fait ce qu’on veut qu’il fasse (un ordinateur est bête : il fait toujours ce qu’on lui dit de faire, pas nécessairement ce qu’on veut qu’il fasse). Pourtant, rappelle Knuth (le dieu que révère Vikram Chandra), programmer, ce n’est pas seulement indiquer à un ordinateur ce que l’on veut qu’il fasse ; c’est aussi expliquer à un être humain ce qu’on vaut que l’ordinateur fasse. Cet être humain peut aussi bien être un collègue que vous-même quelques mois après l’écriture du code ; rien de tel, en effet, que de reprendre un ancien bout de code pour vérifier que je est un autre. Pour que votre moi du futur remercie votre moi du passé, il faut, nous dit Knuth, bien choisir le nom des variables (ok), expliquer ce qu’elles représentent (sous forme de commentaires), et introduire les concepts dans l’ordre qui sied à la compréhension humaine (yolo, Boileau). Comme s’il y avait un mode de compréhension humaine. Chacun a donc son idée sur la question, et ses propres critères pour en juger. On retrouve cependant avec récurrence l’idée qu’un code ne devrait pas se répéter.

D’une manière générale, le geek voit la répétition d’un mauvais œil : c’est le boulot de la machine, pas le sien – « any repetition of effort seemed like an insult. » (p. 15) Le geek pourra donc passer cinq heures à coder l’automatisation d’une tâche qui lui aurait pris 30 minutes – et ce, même s’il est probable voire certain qu’il n’aura pas à la reproduire 9 autres fois. Le geek, comme l’homme dont il hérite, est un animal raisonnable : ce n’est pas parce qu’il peut être raisonné qu’il est d’emblée rationnel.

 

xkcd

 

xkcd

 

Le plaisir de coder

Le code peut-il être esthétique ? « The beauty of code » est l’un des leitmotiv de l’essai de Vikram Chandra, et le titre de son chapitre central. Pour autant, vous pouvez ranger Kant, l’émotion esthétique due au vertige des interprétations infinies n’est pas à l’ordre du jour. Vu qu’un programme a pour finalité d’être exécuté par une machine, mieux vaut qu’il n’ait qu’un sens bien défini ; contrairement aux interprétations, les boucles gagnent à ne pas être infinies. Exit la polysémie.

Exit le plaisir esthétique. Bonjour le plaisir sportif. Oui, vous avez bien lu. Pour Yukihiro Matz Matsumoto, le beau code a vocation à rendre le développeur « heureux et productif » (p. 122), et à en croire Vikram Chandra, cela passerait très concrètement par les endorphines : face à problème ardu, « the world fell away, my body vanished, time receded. And three or five hours later, when the pieces of the problem came together just so and clicked into a solution, I surfed a swelling wave of endorphins. » (p. 19) Et si le développeur était accro au code comme d’autres aux sport ?

En 6 ans de Palpatine, je peux vous dire qu’un geek, un vrai geek, ne lâche jamais le morceau. Lorsqu’un problème lui résiste, il y pense tout le temps, fusse en arrière-plan : en marchant (très péripatétique), sous la douche (un grand classique), au concert (la musique aère l’esprit et permet à la pensée de mieux circuler), mais aussi en société, ce qui peut parfois occasionner un freeze en pleine conversation : les pièces click into a solution, réelle ou supposée. (Je le soupçonne de continuer à ruminer au lit, mais il y a des choses que je préfère ne pas savoir avec certitude).

 

xkcd

 

De quoi la métaphore du code comme art est-elle la revendication ?

Palpatine rappelle régulièrement à qui veut l’entendre qu’en France, le code est régi par le code de la propriété intellectuelle, exactement comme un roman (eh non, un programme ne se brevète pas). La métaphore du code comme art a de quoi surprendre, parce que l’on oublie généralement que l’artiste est d’abord un artisan. Le développeur n’est pas un mécanicien qui sert des boulons binaires, c’est un artisan, qui adapte, polit, peaufine… et revendique donc un savoir-faire. Car non, coder, ce n’est pas (uniquement) appliquer des principes mécaniques qui s’enchaîneraient comme le développement d’une équation ; c’est structurer une réalité foisonnante, la mettre en forme, la concevoir. On ignore généralement que le bon développeur est créatif – on l’imagine rusé, oui, mais pas créatif.

Si les développeurs se comparent à des peintres, des musiciens ou des essayistes, c’est pour faire valoir cet aspect méconnu de leur travail. Et revendiquer le statut qui devrait aller avec. Id est la considération, le salaire et… le sex appeal ? Vikram Chandra cite l’interprétation toute personnelle de Ceglowski sur le recours aux comparaisons artistiques : « Great paintings… get you laid in a way that great computer programs never do […] especially if you have the slighteste hint of being a tortured, brooding soul about you… » (p. 8-9). En bref : le geek ne veut pas être un nerd (le retour en grâce du terme geek, employé à tout va, ne doit pas nous faire oublier qu’à la base, c’est un synonyme de nerd, le mec antisocial un peu zarb avec qui on n’a pas du tout envie de traîner)(Palpatine, en tant que ‘vrai geek’, s’offusque régulièrement de ce que n’importe quel bidouilleur soit aujourd’hui honoré d’un qualificatif qu’il a eu à souffrir comme insulte avec ses camarades pendant sa jeunesse ; être geek, ça se mérite !).

 

Architecture

L’art est utile comme métaphore pour exprimer les rapports de proportions et d’harmonie. On pourra dire, par exemple, qu’un beau programme est comme une symphonie : chaque morceau en est une phrase musicale, qui peut être jouée seule, mais trouve sa raison d’être au sein de l’oeuvre, nuancée, enrichie par les phrases musicales qui la précèdent, la suivent, et l’entourent de leurs résonances. « Each small part is coherent, singular in its purpose, and although all these small sections fit together like the pieces of a complex mosaic, they come apart easily when one element needs to be changed or replaced. » (p. 123) Cette modularité, je me la représente sous la forme des sas de station spatiale, par lesquelles les astronautes des films passent toujours pour entrer et sortir sans danger. En cas d’urgence (et dans les films comportant des astronomes, il y a toujours une urgence), ces sas permettent de se défaire d’une partie endommagée sans détruire l’ensemble de la station. C’est-à-dire, pour le développeur, de modifier facilement une fonctionnalité pour le client qui a encore changé d’avis et veut son nouveau choix là tout de suite ; mieux vaut, donc, ne pas avoir à aller fouiller dans tous les recoins du programme pour modifier une fonctionnalité réduite.

 

Big Ball of Mud

L’effet boule de neige boue

L’architecte, qui veille au bon agencement de toutes les parties, joue ainsi un rôle primordial. Et ce n’est pas de la tarte : même un projet très simple se révèle toujours plein d’exceptions et de cas spéciaux qu’il faut gérer (si possible, sans faire rejaillir la complexité de ces exceptions sur les manipulations ordinaires). On a vite fait, les deadlines aidant, de se laisser embringuer : « you know that functionality should be somewhere else but you don’t have the time to bother, the users ask for a new feature and you patch it in, and of course you mean to come back later and clean everything up, but then, before you know it, you are trapped inside an unwholsome, uncontrollable atrocity, a Big Bull of Mud » (p. 126), « and yes, it is a technical term of art » (p. 127). Devenue incontrôlable, une Big Ball of Mud peut atteindre un nombre de ligne et une complexité tels que le programme échappe purement et simplement à la capacité de conception humaine. Plus personne ne comprend comment il fonctionne de bout en bout. « No temple, no cathedral has ever contained as many moving parts. » (p. 124)

 

xkcd

 

xkcd

[Go to indique au programme d’aller à telle ou telle ligne… qui a de fortes chances de bouger lors du développement. C’est le truc crade par excellence, à ne pas faire. Une pratique qui vaut -42, vous dira Plapatine.]

 

Dinosaures sous respiration artificielle

Comment traquer des bugs et ajouter des fonctionnalités à un programme que l’on ne comprend pas, quand la moindre modification effectuée dans un coin peut avoir des répercussions inattendues à l’autre bout du système ? Généralement, nous dit Vikram Chandra, on est pris de l’envie de tout réécrire de manière propre. Sauf qu’on n’en a jamais le temps ni le budget. Alors on rajoute une rustine, un peu de boue à la Big Ball of Mud.

Il existe ainsi des programmes qui tournent depuis des décennies et qui ne peuvent pas être correctement maintenus ni mis à jour parce que plus personne ne comprend comment ils fonctionnent dans leur ensemble. C’est par exemple le cas du logiciel comptable du Pentagone, apparemment célèbre pour ses erreurs dans les fiches de paye des soldats (p. 128)… Le secteur bancaire est également un beau tas de boue : 90 % des transactions financières dans le monde se font via des logiciels en COBOL, « the computing equivalents of Mesopotamian cuneiform dialects ». Hé oui, le site web tout beau tout neuf tout responsive de votre banque cache un système vieilli jusqu’à la moelle (p. 129)…

 

La programmation orientée objet

Au milieu des années 1980, on a imaginé de rassembler à un même endroit du code les différentes types de données et ce qu’on peut faire avec (i.e. les fonctions qui s’y rapportent). En encapsulant ces informations thématiques dans des objets, on espérait en mettre un peu moins partout. Et cela a fonctionné. Un peu. La programmation orientée objet a résolu certains problèmes, parfois même avec une certaine élégance, souligne Vikram Chandra ; elle a permis de mettre de l’ordre dans la « spaghetti code jungle » (la jungle est de Foote et Yoder, dans Big Ball of Mud, mais le « code spaghetti » est aussi un terme technique consacré, désignant les kilomètres de lignes de code enchevêtrées, issus de la programmation procédurale.). Pour autant, la programmation orientée objet n’est pas une solution miracle et les Big Balls of Mud continuent de proliférer (un peu comme le bordel dans mon studio en dépit des placards)…

« If you’ve ever writen code, the fact that so much software works so much of the time can seem profoundly miraculous. » (p. 124) Le bug est la normalité, pas le fonctionnement. Comme dirait Palpatine, ça « tombe en marche ».

 

Les travaux et les jours

Les bons outils font les bons… jongleurs ?

Un précepte geek enjoint de ne pas réinventer la roue et de se hisser sur les épaules d’un géant, en utilisant ce qui a déjà été fait. Il existe ainsi tout un tas de briques pré-construites qui permettent de réutiliser le travail déjà fait, des librairies dans lesquelles aller piocher un savoir patiemment accumulé ; et tout un tas d’outils pour gérer le code et éviter sa prolifération anarchique. Git, par exemple, permet de gérer le versionnement, pour que plusieurs personnes puissent travailler sur le même programme sans risquer d’effacer le travail des autres, et que l’on puisse à tout instant revenir à une version antérieur. Un outil puissant et précieux, donc, mais complexe à utiliser, qui constitue une compétence en soi (au point de figurer sur les annonces d’emploi au même titre que les langages à maîtriser).

 

L'infobulle en rajoute une couche sur l'original… allez voir ;)

Les outils, remarque Vikram Chandra, deviennent un savoir à part entière – problème du moyen qui devient une fin. « Each tool and pre-constructed library solves a problem that you must otherwise solve yourself, but each solution is a separate body of knowledge you must maintain. » (p. 139-140) D’où pour certains développeurs l’impression de ne plus être à l’aise dans quoi que ce soit. L’assurance d’avoir toujours quelque chose de nouveau à apprendre est l’un des attraits du métier, mais cela peut aussi se transformer en course épuisante contre la montre et l’obsolescence. Se former aux nouveaux langages pour les projets de demain tout en bossant à fond sur les projets en cours…

 

Le nouveau langage à la mode

« Our industry [remarks Steve Yegge] is fashion-driven to a degree that would embarrass haute couture designers from New York to Paris… » Aussi surprenant que cela peut paraître de l’extérieur, la mode dicte les langages que les gens étudient à l’école, qu’il utilisent ensuite dans projets professionnels, ceux à propos desquels des bouquins sont publiés, etc. Palpatine pestait récemment contre les choix de langage faits par ses associés : parce qu’un geek, par principe, peste toujours contre les langages qui ne sont pas ses préférés, mais aussi parce que le choix du langage n’en a pas été un. Il n’a pas fait l’objet d’un choix rationnel après mise en balance avec d’autres langages et étude de leurs avantages et inconvénients pour ce projet particulier ; ses associés l’ont choisi parce que c’est ce qui se fait et ce qu’ils savent faire. (Je soupçonne tout de même Palpatine d’un léger snobisme geek, à kiffer des langages paraît-il d’une grande élégance, mais à peu près jamais utilisés dans l’industrie.)(Un mignon snob, évidemment.

 

Et demain ?

À l’heure où l’on taquine l’idée d’enseigner le code à l’école, Vikram Chandra remarque que la promesse de démocratisation du code, déjà ancienne, n’a jamais vraiment été tenue. La forme de programmation la plus courante dans les entreprises, au final, est celle des feuilles Excel. « The biggest problem is that anyone can create Excel spreadsheets – badly. » (Kwak, The Importance of Excel). Même quand on maîtrise Excel, surtout quand on le maîtrise et qu’on y fait des calculs complexes, ce type de programmation peut s’avérer dangereux, car il est très difficile à auditer et débuguer – pas fait pour. J’ai d’autant moins de mal à le coire qu’il y avait un pro des tableaux Excel dans l’équipe où j’étais en apprentissage ; vous n’avez pas idée du nombre d’entrées et de formules qu’il y avait là-dedans, d’une complexité telle que… lui seul pouvait s’y retrouver. Vikram Chandra cite même le cas d’une erreur financière monstrueuse (à plusieurs millions) due à une feuille de calcul où une cellule calculait la somme au lieu de la moyenne… (p. 142)

Ouais, je sais, c’est moyen glamour d’envisager le futur sous la forme d’un tableau Excel. Du coup, Vikram Chandra se lâche pas mal en imaginant tout un tas de trucs, dont une rencontre du troisième type entre programmation informatique et génétique. Si vous voulez lire là-dessus, je vous conseille plutôt l’article d’Eliness où elle explique son métier de bio-informaticienne.