S01E26 — 23-08-2024.

Dans les méandres de l’analyse lexicale.

jour 26.

Un endroit dans lequel, je me suis dirigé sans réelles connaissances. J’hésite entre octets et caractères, je ne compte plus le nombre de Tokenizer sans y trouver une quelconque issue. Résultat, une incapacité à analyser un code source, une analyse approximative dans laquelle un jeton sur deux est pris en compte ou d’autres conséquences non-concluante. Tel un homme éclairé, je ne dois plus avoir peur de l’ombre. C’est en passant par les ténèbres que je pourrai entrevoir la lumière. Tel est mon ninjutsu révélé via un genjutsu. Être resté dans l’obscurité de l’analyse lexicale m’a permis de comprendre l’essence pure de la mécanique qui s’en dégage.

Je ne compte plus les jours, coincé dans la spirale du Tokenizer — aujourd’hui, j’entrevois les lueurs qui semblent provenir des rayons de la réussite. Sache que pour parvenir à scanner la source d’un fichier m’a fait perdre, le peu de poil que j’ai au menton. La solution était simple :

1. html5ever — je le remets ici, car c’est une pépite qui mérite vraiment qu’on rentre dans la tête des auteurs.
2. whatwg — la spécification via laquelle html5ever s’est appuyé pour entrevoir l’ombre de la lumière.
3. W3C — une autre spécification tout aussi claire celle du whatwg.

1. html5ever.

J’y reviendrai toujours mais l’oeuvre du premier auteur de cette caisse a fait un travail remarquable. Il a vraiment respecté les spécifications du whatwg à la lettre. Tout en utilisant les concepts du Rust au bon endroit. Il n’y a rien qui dépasse. Bien sûr Mozilla, lui a laissé le temps et l’a embauché pour cela. Keegan, la personne dans l’ombre du projet html5ever était Senior Research Engineer pendant ces deux ans de loyaux service chez Mozilla. Din-gue-rie, tu es embauché pour créer le turfu et non pas en tant qu’exécutant comme la plupart d’entre nous.

Pour la petite histoire, le projet voit le jour un 12 mars 2014 (une date que j’affectionne en plus), avec un prototype qui nous laisse entrevoir les choix judicieux de son approche. Sache que dix ans auparavant, la syntaxe de Rust n’avait pas la même gueule qu’aujourd’hui. J’y vois des types comme ~str, des mots-clés comme priv (pour spécifier la portée d’une propriété dans une struct), cargo n’existait pas, rust-analyzer non plus, #[deriving] était utilisé comme attribut à la place de #[derive], la macro fail!() était la chef — panic!() n’était même pas dans les papiers. Bref, il fallait naviguer avec un tout autre langage, certes encore compréhensibles par les néophytes que nous sommes, mais bel est bien, venu d’un autre temps. Ce qui montre la vision de Keegan, sur le choix du langage et de sa volonté de rester au plus proche de la bibliothèque standard Rust.

le readme de l’époque.

# HTML5 parser for Rust.

Very much a work in progress!  Don't use this.

Avec l’aval d’une entreprise comme Mozilla, il a enchaîné itération sur itération pendant environ six mois avant de livrer une version plus ou moins stable le 26 septembre 2014. Essaye de prendre six mois pour livrer une feature dans une entreprise qui fonctionne en sprint de deux semaines. Tu vas vite prendre la porte, tu ne vas rien comprendre. Si tu aimes les méandres du bas niveau et ses problèmes complexes. Trouve-toi un poste de Research Engineer direct. Là, au moins, tu pourras explorer le champ des possibles cachés derrière chaque problème que tu rencontreras. Et puis entre nous ça t’évitera de prendre la porte, tu travailles dans une entreprise en tant qu’pompier qui doit absolument faire avancer ces tickets dans les deux semaines qui viennent sur pitoyable tableau Kanban dans un Jira.

2. whatwg

C’est fou ce que s’est passionnant de lire une documentation quand chaque détail est mis en lumière pour te permettre de comprendre l’origine du HTML5 et son implémentation. Tout y est. Tu ne peux pas te tromper.

3. W3C.

Pareil que pour la whatwg, je n’aurai jamais pensé qu’un jour dans ma vie, je dirais cela : “la documentation W3C est in-croy-able”. Spécifiée à la pensée près, je nage dans le bonheur dès que je dois m’abreuver d’informations pour finir mon implémentation.

À Comparer avec d’autres documentations comme par exemple, la documentation JSX qui fouette le cachalot fermenté depuis v’là les années. Tu vois tout de suite la volonté derrière l’Open Source :

Partager la connaissance au plus grand nombre.

L’opposé de JSX et sa documentation d’excréments de fils de canidé. Les personnes à l’initiative de ce projet on certes, offert au monde une technologie utilisée par des millions de développeurs dans le monde entier. Mais on fait en sorte que la connaissance reste en leur possession. Tu sens tout de suite qu’il y a Meta/Facebook derrière et qu’ils ne veulent pas que les sans-cervelles comme moi soit capable de reproduire leur technologie. Mais il me semble limpide et clair que monsieur Zuckerberg, n’a pas une seule seconde pensé qu’il y aurait des déviants affamés, dans un quaalude de bouzouk, avides de connaissances pour déchiffrer le secret de l’analyse lexicale pour un langage de programmation ainsi qu’un langage de balisage ressemblant à du JSX. Le tout en partant en partant de Ro-Zé comme Ricky Ro-say. Pas de générateurs de Lexer/Parser à partir d’une grammaire, pas de Parser Combinator, Pas de PhD en poche (malheureusement), pas d’études supérieures en Science Informatique. Seule la curiosité comme fidèle destrier.

Avec un cerveau qui se remplit de connaissances, d’une curiosité comme aisance — je poursuis les intuitions de mes sens. Du HTML, j’en retire que l’essence.

À demain.

@invisageable