Code, gloire et beauté

Code

Lorsqu'on écrit un logiciel libre, c'est généralement dans l'espoir de pouvoir faire avancer l'humanité en partageant le code source avec tous ceux qui pourraient arriver à en faire quelque chose.

Du moins, c'est comme ça en théorie.

La pratique, c'est qu'avec la quantité monstrueuse d'informations disponibles sur le grand 'ternet, la plupart des projets gardent une portée très restreinte, et rares sont ceux qui, par hasard ou par mode, sont effectivement réutilisés par des développeurs qui n'avaient rien à voir avec le projet d'origine.

C'est ainsi que depuis une décennie je touille ma merde toute seule dans mon coin, comme avant, sauf que c'est de la merde open-source et publiquement accessible, même si presque personne n'utilise cette possibilité.

Et plus particulièrement, c'est ainsi que l'indifférence générale j'ai développé libupskirt, une bibliothèque en C qui lit des textes en markdown et permet ensuite d'en faire quelque chose, au choix de l'utilisateur ; généralement le convertir en HTML dans le cadre d'un site web.

Bon, ça fait depuis un bout de temps que c'est le code le plus populaire que j'aie jamais écrit : il a dû être réutilisé au moins une ou deux fois, par exemple dans CBlog.

Du moins, c'était comme ça la semaine dernière.

Gloire

Car la semaine dernière, ce n'est pas sans une grande surprise que j'ai été contactée par un ingénieur de github, qui disait en substance que discount ne correspondait pas tout à fait à leurs besoins, ce qui a conduit au développement de redcarpet, qui est en substance ma libupskirt et un adaptateur pour l'utiliser depuis le langage de programmation Ruby. Pour situer, discount est le « concurrent » le plus proche de libupskirt, et son principal défaut à mes yeux (qui a conduit au développement de libupskirt) est son manque de flexibilité dans la sortie : il fait du HTML (ou du XHTML) et rien d'autre.

C'est ainsi que j'ai pu découvrir les deux effets de gloire : ce qu'il y a de meilleur, et ce qu'il y a de pire.

D'un côté, il y a cette impression grisante de reconnaissance. Impression d'autant plus agréable que depuis quelques mois je souffre de mon inutilité dans le cadre de mon travail, et c'est bon de voir que ma production privée peut servir à quelque chose alors que j'étais très loin d'en espérer autant.

Et de l'autre côté, il y a la déception de voir à quel point mon œuvre peut se faire pervertir dans les mains d'un autre. Je vais plus développer ce point parce que c'est plus facile à verbaliser, mais ça a pesé à peu près aussi lourd que le point positif dans mon moi profond.

D'abord il y a le fait que cet abruti de Google s'obstine à envoyer les gens vers une ancienne repository qui n'a plus cours aujourd'hui ; du coup cet ingénieur a eu l'impression de ressusciter un projet abandonné, alors qu'en réalité il va très bien, merci, et il a même atteint un stade de maturité tout à fait honorable (et accessoirement, il prétend aussi l'avoir amélioré de façon à ce qu'il passe les tests officiels, alors que c'était déjà le cas). Mais bon, je suis aussi un peu responsable, j'aurais dû indiquer plus clairement l'obsolescence de cet ancien espace, voire le détruire complètement et rediriger sur le nouveau.

Cependant ce qui m'a le plus choquée dans ses modifications, c'est l'ajout de flags qui sont transmis au code de traitement : d'une part c'est complètement à rebours de l'architecture même de mon code, qui est basée sur une séparation entre le parser et le renderer, alors que ces flags mélangent les deux ; et d'autre part c'est philosophiquement à l'opposé du minimalisme et de la flexibilité qui ont guidé le développement de libupskirt, au point de le clamer comme argument de vente :

This callback mechanism make libupskirt so flexible that it does not need any flag or external information besides input text and renderer to operate.

En français, ça donnerait à peu près : « Ce mécanisme de callbacks rend libupskirt tellement flexible qu'elle n'a pas besoin de flag ou d'information externe en dehors du texte d'entrée et du renderer pour fonctionner. »

Bon avec tout ça, on pourrait croire que je déteste ce pauvre ingénieur, mais je crois que je comprends son point de vue et ses préoccupation, et comment ils l'ont poussé dans cette direction. C'est juste une direction que je détesterai prendre moi-même. Et d'ailleurs, à lui tout seul il a déjà découvert un problème dans libupskirt que je n'ai pas vu, et avec le plus grand public de github et donc plus de gens qui regarderont le code, la qualité de libupskirt ne peut que s'en trouver meilleure.

C'est juste qu'il a pris ma libupskirt et qu'il en a fait quelque qui techniquement y ressemble vaguement, mais qui moralement n'a plus rien à voir ; et ça fait quand même un pincement au cœur. J'imagine qu'un écrivain doit ressentir le même genre de choses lorsqu'il regarde une adaptation au cinéma ou à la télévision d'un de ses romans.

Beauté

Non, ne vous en faites pas, je sais que ma beauté physique n'est plus à sauver, je parle de beauté du code.

Cette histoire de libupskirt arrive à un point intéressant de ma vie, où je suis en train d'hésiter entre deux langages de programmation : le C et l'Ada.

Le C est un langage universel et simple, qui est à la base de tous les systèmes Unix. Sa simplicité le rend plus facile à maîtriser en profondeur, ainsi j'ai par exemple lu plusieurs fois le Standard officiel, je connais un bon nombre de cas particuliers et de pièges, etc. Cependant on lui reproche souvent de ne pas assez protéger le programmeurs contre lui même, ou plutôt contre ses fautes d'inattention et son manque de rigueur.

Ce sont ces deux derniers points qui m'ont poussée vers Ada, qui à l'inverse déploie le maximum de techniques possibles pour mettre en évidence le plus d'erreurs possibles et le plus tôt possible, pour imposer un maximum de rigueur aux programmeurs, et plus généralement pour rendre le code aussi lisible et aussi facile à maintenir que possible. C'est pourquoi ce langage est assez peu populaire : toutes ces contraintes sont considérées comme des fardeaux (ce qui est le cas à court terme), sans prendre en compte tous les bénéfices à long terme. Heureusement que dans les environnements où la qualité des programmes est critique (par exemple les commandes électroniques des avions ou des missiles) il reste encore une place pour ce genre de langages.

Jusqu'à il y a quelques jours, j'hésitais entre ces deux langages uniquement avec ces arguments techniques. La différence massive de popularité entre ces deux langages n'a aucune influence tant que je suis condamnée à touiller mon code de merde toute seule dans mon coin.

La reprise de mon code par GitHub, ou par qui que ce soit de connu ou non, n'aurait jamais pu avoir lieu si j'avais programmé en Ada plutôt qu'en C.

Qu'est-ce que ça change ? J'ai encore du mal à le déterminer. En plus de tous les arguments techniques, s'ajoute qu'une histoire similaire peut se reproduire si je continue à programmer en C, alors que j'oblitère définitivement cette possibilité si je me cantonne à l'Ada. Mais comme cet évènement a une facette positive aussi importante à mes yeux que la facette négative, je ne sais pas trop c'est un bon point que l'Ada m'en protège ou un mauvais point qu'il faille y renoncer pour l'Ada.

On dirait que je n'ai pas fini d'hésiter…

Commentaires

1. Le lundi 28 mars 2011 à 20:21, par K :

Diantre j'ai lu entièrement cet article.
J'aurais aimé donner mon avis sur le C, l'ADA... mais je ne connais que le C, je n'ai absolument aucune idée de ce à quoi l'ADA ressemble.
D'après ce que tu dis, tu sembles t'ennuyer au boulot ! Moi naïvement, je croyais que lorsqu'on travaillait pour la plus belle entreprise du monde avec un logo tout beau et tout coloré, il était impossible de s'ennuyer. J'espère que cela changera car il est tellement agréable d'avoir un boulot passionnant.

2. Le mardi 29 mars 2011 à 1:47, par _FrnchFrgg_ :

As-tu indiqué à l'ingénieur de GitHub qu'il y avait une version plus récente de libupskirt (au passage c'est surprenant comme nom, ça me fait penser à libpr0n le nom interne de la bibliothèque de décodage d'images de Mozilla) ? Qu'a-t-il répondu ? Est-il possible que son coup de "flags" soit facilement implémentable comme une surcouche à coups de callbacks, qui soit donc indépendante et orthogonale à libupskirt pour éviter que son travail soit un fork effectif de ton travail ? Parce que le problème avec ce genre de "revival" d'un code mort c'est que dans les faits ça fait un fork, d'autant plus que c'était pas un cadavre mais juste une vieille mue et que libupskirt a continué à évoluer de son côté... si ça reste "chacun dans son coin" l'un ne profitera pas à l'autre.

3. Le mardi 29 mars 2011 à 10:51, par Natacha :

K, l'Ada ressemble en gros à du Pascal :-) Et accessoirement, ça s'écrit Ada, comme le prénom de Lady Lovelace, et non ADA comme si c'était un acronyme. Pour ce qui est de à quoi ressemble programmer en Ada, si tu vois la différence entre programmer « normalement » en C, et programmer en C avec absolument toutes les erreurs et tous les warnings activés, même les plus pénibles, en transformant tous les warnings en erreur fatale ; ben si tu multiplie cette différence par dix, tu arrives sur de l'Ada.

Sinon concernant mon boulot, je ne m'ennuie pas, et ce que je fais m'intéresse beaucoup. Le problème c'est que je ne suis pas encore au point sur tous les prérequis, ce qui me ralentit au point que les tâches qui me sont affectées traînent trop aux yeux de mes coéquipiers, qui du coup me reprennent les tâches en question. Résultat, je n'ai encore rien réussi à faire d'utile, et j'ai été plus un frein qu'un bénéfice pour mon équipe. Et ça, ça fait mal à l'ego, et le mien n'est pas vraiment le plus robuste qui soit.

_FrnchFrgg_, oui, j'ai répondu à l'émail de l'ingénieur GitHub, avec diverses informations, dont le fait qu'il n'est pas parti sur la dernière version. Je n'ai pas eu de réponse, ce qui pourrait me faire douter que l'émail ait été effectivement lu ; mais il a appliqué un des patchs n'existant que sur la nouvelle repository [https://github.com/tanoku/redcarpet/commit/725443f5cdc3ce3bc330cc5a3cbb18c5a07ddddf], et il a fait un changement que j'ai suggéré dans ce même émail [https://github.com/tanoku/redcarpet/commit/28ee5228d9a4b8969822a6c11800fd346a9c856b].

J'ai critiqué un de ses commit, et ça a été suivi d'effet, mais si je commence à critiquer tous ses commits, ça va rapidement mal se passer. Le coup des flags est ce qui m'a le plus choquée, mais j'aurais à redire sur tout le reste. Par exemple j'ai une approche très restrictive des caractères actifs : si quelque chose peut être séparé par des espaces ou des tabulations, je teste pour les espaces et les tabulations, pas sur tous les caractères pour lesqueles isspace() renvoit 1 ; ou mes autoliens sont les mots qui commencent par l'exregex http:|https:|ftp:|mailto: tandis que pour lui c'est [a-zA-Z.+-]{2,}:

Bref il semble y avoir une faille trop grande dans nos approches pour les faire cohabiter. À partir de là, deux solutions : soit il importe le code upstream brut et se débrouille pour mettre ce qu'il faut autour pour l'adapter à ses besoins (je ne doute pas que ce serait le cas si j'avais un minimum de popularité préalable, ce n'est pas très difficile, il suffit de rentrer dans l'état d'esprit de la lib' avant de coder) ; soit il fork. Et quelle solution sera retenue est complètement hors de de mon contrôle.

Ce qui est en mon pouvoir, c'est d'essayer de tirer le maximum de son travail. C'est pourquoi je surveille le flux RSS des commits, je vais backporter le maximum, et tant pis pour le reste. C'est à lui de voir dans quelle mesure il veut bénéficier de mes développements futurs ; mais j'imagine qu'il ne doit pas avoir beaucoup d'incitation à le faire, car lesdits développements futurs vont probablement être peu nombreux vu que je considère le projet comme terminé (il ne me reste dans la pile que quelques raffinements de code, qui n'auraient même pas de sens si j'opte pour l'Ada).

Et pour le nom, j'étais incapable d'en trouver un toute seule, alors je m'en suis remise à #freebsd-fr, et je crois que le chemin mental a été markdown → (mark, down) → (?, up) → upskirt. J'ouvre la compétition pour un nom pour la version Ada de cette lib', si tu as une meilleure idée… ;-)

4. Le mardi 29 mars 2011 à 13:42, par W :

libupdress ?

5. Le mardi 29 mars 2011 à 21:23, par florimond :

J'ai eu la sensation bizarre que tu racontais ça comme ... un viol ?

6. Le samedi 2 avril 2011 à 21:01, par Roman Age :

Je comprends ton sentiment, mais pourquoi choisir l'open source alors, si toi-meme tu ne comptes pas de facon réaliste bénéficier du travail des autres sur ce projet? Plutot que de penser utiliser une facon détournée (un langage obscure) dans le but d'éviter que d'autres ne dénaturent ton code, pourquoi ne pas remettre en cause la vraie raison de ce conflit (le fait que le code soit open source, avec toutes les conséquences que cela implique)?

7. Le dimanche 3 avril 2011 à 13:14, par Natacha :

W, tiens pas mal ça. Ou même libdressup, complètement correct politiquement ;-)

Florimond, je ne suis pas très au point sur la façon dont est raconté un viol, parce que je supporte très très mal ce genre de descriptions. En tout cas ce que j'ai ressenti n'avait rien à voir.

Romange Age, d'abord j'ai choisi l'open source sans m'imaginer que ce genre de chose m'attendais : je pensais vraiment qu'un ou deux utilisateurs de ma bibliothèque serait le summum de ce que je pouvais espérer.

Ma motivation pour l'open source n'a jamais été bénéficier du travail des autres, mais de pouvoir éventuellement faire bénéficier quelqu'un de mon travail. C'est pour ça d'ailleurs que je fais de l'open source BSD plutôt que GPL : je n'ai pas besoin qu'on me « rende » le travail fait à partir du mien.

En fait, si je voulais vraiment « éviter que d'autres ne dénaturent mon code », il me faudrait une licence genre CC-BY-ND pour le code, qui alors ne serait plus open source. Je me demande si ce genre de licences est répandu, il faudrait chercher.

Mais en fait la « dénaturation » en elle-même ne me dérange pas plus que ça, je crois que ce qui me dérange le plus est l'impression de gâchis à la fois dans le renoncement aux concepts clef qui ont fait de libupskirt ce quelle est, et dans l'impossibilité de bénéficier facilement du travail fait dessus alors qu'avec la même quantité de travail, orienté différemment, ce serait possible.

Enfin vu les commentaires, j'ai l'impression que j'ai surexprimé aussi bien le côté négatif que le côté positif de cette histoire, ça ne me touche franchement pas plus que ça.

Pour ce qui est d'Ada (c'est vraiment si obscur que ça ?), en fait c'est l'inverse : je n'envisage pas l'Ada pour me débarrasser des réutilisateurs, mais avant je n'envisageais pas l'Ada justement pour les réutilisateurs potentiels. L'Ada me séduit par son design, très proche de ma façon de penser (genre Steelman requirements et tout ça), et coder dans le désert, sans espoir de servir à quelqu'un d'autre moi, était un des principaux points qui m'ont fait rester au C (l'autre étant la misère au niveau des compilateurs). Cet évènement a juste sérieusement diminué le poids de cet argument contre l'Ada.

8. Le jeudi 7 avril 2011 à 11:28, par Fred :

Tu n'as plus qu'à publier la version Ada avec une interface C en supplément :D

9. Le samedi 14 janvier 2012 à 3:00, par bohwaz :

Je trouve la polémique sur le nom assez marrante, surtout quand on sait qu'il existe la libcaca et la libpipi, qui ont même des logos qui vont bien : [http://caca.zoy.org/]

Poster un commentaire

Nom ou pseudonyme :

Adresse e-mail (facultatif, ne sera pas publié) :

Site web (facultatif) :

Format de mise en forme : format historique Markdown restreint

Enregistrer ces informations dans un cookie

Commentaire (sera publié dans cette page, voir les conseils de mise en forme ci-dessous) :

Message personnel (ne sera pas publié) :

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.