Le week-end dernier, j'ai regardé cette vidéo d'Andreas Kling prototypant un compilateur JIT pour son navigateur Ladybird.
C’est une vidéo très intéressante, pour deux raisons.
Premièrement : si vous êtes intéressé par le fonctionnement des machines virtuelles de bytecode et des compilateurs JIT, tout est là, expliqué étape par étape. Une mine d’or, vraiment.
Deuxièmement : la façon dont Andreas construit ce compilateur JIT est infiniment fascinante. Il est clairement visible qu’il a passé des milliers et des milliers d’heures de sa vie à programmer. Cela apparaît facilement (hey, il crée un compilateur JIT en 1h30) et dans les petits – petits trucs, mouvements et raccourcis. C’est ce dernier point qui est si fascinant, car généralement vous ne captez pas ces petites choses en vidéo, vous oubliez que vous les avez faites ou vous ne pensez même pas qu’elles valent la peine d’être mentionnées.
Ici, nous les avons en vidéo et lorsqu'elles sont regroupées comme celle-ci, vous voyez que les petites choses totalisent beaucoup.
J'ai dû sourire dès le début quand Andreas commence avec un seul fichier, ajoute seulement le boilerplate nécessaire pour quitter avec le code 0, l'ajoute au système de construction, compile et exécute – juste pour s'assurer que tout est correctement câblé et qu'il est prêt. aller. J'ai vu des développeurs se lancer directement dans des modules multiples et écrire un tas de code pour ensuite se rendre compte qu'il ne fonctionne pas et qu'ils doivent tout recâbler pour que cela fonctionne. Bonne décision d'Andreas.
Puis il y a ces courts instants au cours desquels il réorganise très rapidement les fenêtres de son IDE et de ses terminaux. Il est très rapide. J'ai dû faire une pause pour comprendre ce qui se passait et comment essayer de le reproduire dans mon environnement de travail.
Il est rapide en général : il tape très vite, il change de fenêtre rapidement, il écrit des petits fichiers JavaScript avec cat et Vim en quelques secondes, il dit "laisse-moi juste vider ce bytecode pour que nous puissions confirmer" et continue d'écrire 50, 60 , 70 lignes de code – J'ai vu des programmeurs ne pas effectuer d'étape de débogage pendant des jours car il faudrait 50 lignes de code pour le faire au lieu de 2 instructions d'impression en console.
Il navigue également dans ses fichiers en effectuant des recherches, ce que je fais également et que j'ai obtenu grâce aux Sept habitudes d'édition de texte efficace de Bram Moolenaar. Et encore une fois, j’ai souri.
Ensuite, il y a Copilot. C'est partout dans la vidéo. Je n’ai pas compté les « Merci Copilot », mais il y en a pas mal. Copilot remplit l'interpréteur de bytecode, Copilot écrit l'assembly, Copilot écrit des méthodes pour le compilateur JIT. Andreas utilise Copilot consciemment, ce qui, si vous ne l’avez pas vu, peut sembler étrange – après tout, il se complète automatiquement. Mais regardez comment il fait une pause ici et attend que Copilot remplisse l'instruction principale du compilateur JIT, ou comment il regarde attentivement et appuie de temps en temps sur la touche de tabulation pour guider Copilot, lui faisant écrire du code machine. Très intéressant à regarder, d’autant plus que les gens prétendent (j’étais de ceux là - mais Andreas m’a fait changer d’avis) que « ces outils » ne vous rendent plus rapide que lorsque vous travaillez sur du code ennuyeux ou passe-partout. Je ne sais pas s’il existe une accélération 10x, mais je dirais qu’il y en a une. J'utiliserai certaines des astuces d'Andreas dans mes prochains projets.
Mon moment préféré dans la vidéo est celui où Andreas vérifie ce que Copilot a généré. Il ne se contente pas de vérifier les faits en examinant le code et en se demandant « hein, est-ce correct ? » Non. Ce qu'il fait : il utilise la commande cat pour écrire les octets de code machine bruts générés par Copilot directement dans un fichier test.asm, puis l'assemble avec nasm, puis utilise ndisasm pour le démonter à nouveau et finit par regarder les instructions d'assemblage qui mappent aux octets bruts. C’est ainsi que vous devez posséder et utiliser vos outils.
L'impression générale que je retiens de la vidéo est la suivante : la programmation pour Andreas se fait sans effort. Bien sûr, il connaît le domaine et a probablement préparé cette vidéo et écrit le compilateur JIT une fois auparavant, mais quand même : il est rapide, il écrit beaucoup de code, il débogue sans problème, il maîtrise ses outils et les utilise comme des outils, pas comme quelque chose avec lequel lutter.
J'ai collaboré et interviewé de nombreux programmeurs et cette facilité n'est pas universelle. Pour certains programmeurs, écrire du code nécessite un réel effort et ils ne le font que s’ils le doivent. Ils n’écriraient pas un programme « poubelle », car pourquoi jeter quelque chose dans lequel vous avez consacré tant d’efforts ?
Comparez cela à Andreas dans cette vidéo. Son objectif est d'écrire un compilateur JIT, mais il commence par écrire un interpréteur de bytecode. Techniquement, il n'est pas obligé de le faire, mais il le fait pour pouvoir vérifier que son compilateur JIT et sa VM fonctionnent. L'écriture de code n'est pas un obstacle. C'est juste quelque chose qu'il fait.
Il est à l’aise, il joue, il s’amuse. Cela peut demander des efforts, mais il n’y a certainement aucune tension.
C'est une vidéo très inspirante et la pensée qu'elle m'a laissée est la suivante : entre tous les conseils habituels pour devenir un développeur senior — les réflexions (valables !) sur la communication, l'architecture, les compromis, etc. — il est très facile de perdre le fil. Être plus rapide et meilleur en programmation, essayer de produire plus avec une meilleure qualité, devrait probablement toujours être l'objectif n°1 et lorsque vous l'avez atteint, cela semble très impressionnant.
Merci de m’avoir lu!