Hunter S. Thompson, auteur et journaliste, a dactylographié les écrits d'autres personnes - des romans entiers, même - pour apprendre d'eux. Voici un peu pourquoi il l’a fait :
Si vous tapez le travail de quelqu'un, vous en apprenez beaucoup sur lui. Étonnamment, c'est comme la musique. Et en tapant des parties de Faulkner, Hemingway, Fitzgerald - ce sont des écrivains qui ont été très importants dans ma vie et dans la vie des gens autour de moi - alors oui, je voulais apprendre des meilleurs, je suppose."
Pour savoir quoi exactement ? Voici une autre citation :
Il avait l'habitude de taper des pages de "The Great Gatsby", juste pour avoir le sentiment, a-t-il dit, de ce que c'était que d'écrire de cette façon
Juste pour ressentir.
J'ai lu beaucoup de choses par et sur Hunter S. Thompson et je ne me souviens pas où j'ai commencé cette pratique pour la première fois, mais je sais que j'y pense et le fais depuis plus d'une décennie…
Ce dont je me souviens, c'est qu’Hunter a dit qu'il l'avait fait pour avoir une idée du rythme de l'écriture de quelqu'un. Peut-être que je me souviens mal de lui en utilisant le mot rythme, mais d'après les citations ci-dessus, ce ne serait probablement pas quelque chose avec lequel il n'était pas d'accord.
J'ai toujours voulu essayer d’écrire un roman ou un livre. Il y a quelque chose à l'idée de laisser un morceau d'écriture couler à travers vous, une touche à la fois.
Mais une chose que j’ai énormément fait, c’est de taper du code d'autres personnes. Chaque fois que je suit un livre qui contient du code et que c'est un livre dont je veux vraiment apprendre, je tape le code tout en le suivant. Pas de copier-coller. Jamais.
Je l'ai fait de cette façon depuis que j'ai commencé à programmer et à apprendre des livres. Vous ne savez pas exactement pourquoi, peut-être parce que le copier-coller a toujours eu une odeur de je-ne-sais-quoi. Peut-être parce que j’ai l'impression de sauter par-dessus le vrai travail lorsque je ne le tape pas? Allez savoir.
Quand j'ai lu Learn C The Hard Way de Zed Shaw il y a des années et des années lors de mes études (c’était un livre obligatoire, pauvre de moi), j'ai eu la confirmation que je ne suis pas seul à faire ça. Dans l'introduction, Zed établit quelques règles pour suivre :
Tapez tout le code. Ne faites pas de copier-coller !
Tapez le code exactement tel qu'il apparaît, même les commentaires.
Lancez-le et assurez-vous qu'il affiche la même sortie.
Même les commentaires.
Tout cela ressemble à un exercice stupide et mécanique, n'est-ce pas? Un exercice pour l'exercice. Taper des commentaires - à quoi cela peut-il bien servir ?
Je ne suis pas sûr, mais je suis d'accord avec lui. Dans l'introduction du livre Writing An Interpreter In Go, l’auteur ne fixe pas de règles, mais nous donne un coup de pouce :
Ce livre est destiné à être lu du début à la fin et je vous recommande de suivre en lisant, en tapant et en modifiant le code présenté.
Je ne suis pas un enseignant diplômé et je n'ai pas un seul diplôme universitaire, mais je pense que vous absorbez plus si vous vous engagez activement dans quelque chose au lieu de simplement lire ou écouter. Taper un peu de code, du moins pour moi, semble avoir un meilleur effet d'apprentissage que de le lire.
Cela me fait me demander : si Hunter S. Thompson a tapé Fitzgerald & Hemingway pour devenir un meilleur écrivain, quel code faut-il taper pour devenir un meilleur programmeur ?
typing.io, que j'ai utilisé il y a longtemps pour pratiquer ma vitesse de frappe au clavier (je n’ai jamais réussi à être très bon), a une belle sélection : Redis db.c, PHP, des parties de jQuery, Ruby on Rails, un peu de Perl et bien d'autres dans d'autres langages. Pourtant, l'objectif principal ici est de s'améliorer en vitesse de frappe au clavier, pas de s'améliorer en écriture de code.
Qu'y aurait-il sur une liste pensé spécifiquement à cette fin? Des bouts de code à taper, caractère par caractère, « juste pour en avoir le ressenti » quand le code a été écrit à l'origine ?
Gary Bernhardt a dit un jour qu'il aimait la "cadence de frappe". Ou peut-être pas, parce que je ne trouve pas de source, mais je suis presque sûr que cela est apparu dans une variante de la conférence "Apprendre des maîtres" que Geoffrey Grosenbach a donnée à Railsberry en 2012. La seule chose que j'ai pu trouver, cependant, est un enregistrement de cette conférence de 2013, à RubyConf AU. Cela n'a pas la citation à laquelle je fais référence, mais il y a cette merveilleuse section dans laquelle Gary explique comment il préfère une manière plutôt qu'une autre pour supprimer 2 lignes dans Vim car cela lui évite 1 ou 2 frappes.
Peut-être qu'il n'est pas possible de recréer la pensée en la retapant. Je ne suis pas certain. Ce que je sais - à un niveau non scientifique, c'est que certains morceaux de code ont un rythme, et si rien d'autre, pour avoir une idée de ce rythme - pour trouver la cadence du code – est de le faire en le retapant, eh bien, cela ne me semble pas être un effort inutile.
Merci d'avoir lu.