“Speed matters”, quelques réflexions
Durée de lecture estimée : 6 minutes
Je viens de lire le billet de blog Speed matters: Why working quickly is more important than it seems et ai été plutôt convaincu par son propos.
Cette idée était déjà plus ou moins présente dans mon esprit mais ce billet l’a pas mal clarifée. D’après l'auteur, la règle générale semble être : les systèmes consommant des éléments rapidement sont alimentés par plus d’éléments. Les systèmes lents meurent de faim.
Je me suis surpris, en lisant le dit billet, à chercher d’autres situations où la rapidité est clef, et en voilà quelques unes qui me semblent intéressantes :
L’art
Le premier domaine qui m’a sauté à l’esprit est le domaine artistique.
La musique est un bon exemple. La pratique d’un instrument demande de pouvoir rapidement changer de note, de sonorité et de rythme. C’est d’ailleurs l’objectif de l’entrainement.
C’est aussi le cas du solfège, et même de l’apprentissage de la lecture de la langue en général, où lire rapidement les notes et autres indications sur la partition permet de grandement fluidifier l’apprentissage du morceau.
Un autre domaine artistique où la prise de vitesse est le but de l’entrainement est le dessin, l’art graphique. Je ne suis pas dessinateur mais de ce que j’ai pu en comprendre, une bonne séance d’étude est une séance où l’artiste a amélioré sa vitesse d’exécution d’un point particulier.
Par exemple, un débutant aura du mal à tracer des traits comme il les désire. Mais à force d’entrainement, saura tracer rapidement et précisément et pourra se concentrer sur des points plus précis ou difficiles de la technique.
Il me semble maintenant que l’acquisition de vitesse soit le but premier de tout apprentissage. Maitriser un élément signifierait alors être en mesure de l’exécuter rapidement, et l’exécution rapide ouvre les portes des éléments plus complexes, composés des éléments plus simples.
La programmation
Un autre domaine auquel j’ai tout de suite pensé en lisant l’article est la programmation informatique.
L’auteur avance que toute chose rapide aura tendance à attirer et à être beaucoup réutilisée. Je pense que c’est une des raisons principales qui expliquent l’engouement actuel pour les langages dynamiques de programmation comme Python ou Javascript.
La vitesse que proposent ces langages se trouve dans le cycle de développement. Ici, plus de temps de compilation interminables. On peut démarrer le programme immédiatement après avoir fait une modification au code source. Le sentiment de perte d’inertie est fortement réduit, ce qui encourage le développeur à expérimenter plus de choses dans son projet, puisqu’il n’a plus à s’arrêter pour attendre la fin d’une compilation souvent lente.
Cependant, je pense que les langages dynamiques à la mode aujourd’hui ne sont pas au maximum de ce qui est faisable en terme de vitesse. Et que ceux-ci, et même tous les langages de programmation en général, gagneraient à avoir un environnement de développement semblable à ceux des langages Lisp.
En effet, les langages Lisp ont une longue lignée d’environnements de développement interactif qui ont pris aujourd’hui la forme de systèmes comme SLIME pour Common Lisp ou Geiser pour Scheme.
Ces systèmes proposent un feedback instantané. Ici, en plus de proposer un cycle de développement sans temps de compilation, il n’est même plus question de relancer le programme. Les changements sur le code sont effectués en temps réel dans le programme en cours d’exécution. De plus, ces environnement offrent un accès instantané à la documentation.
La prédisposition de Lisp pour ce genre d’environnement est une des raisons principales qui font que j’utilise ces langages aujourd’hui. Pouvoir modifier chaque bout de code en un instant et expérimenter de nouvelles choses en une fraction de seconde est un véritable bonheur. Quand je retourne à des langages moins évolués, j’ai l’impression de me retrouver au moyen-âge, et ma motivation en prend un sacré coup…
Quelques pistes…
De mon point de vue, d’autres choses gagneraient à devenir plus rapides.
Étant quelqu’un d’assez timide, je ressens personnellement les communautés de projets libres réactives comme étant encourageantes et amicales.
Si une communauté est réactive, je serai poussé à tenter plus de choses dans celle-ci, et cela même si mes contributions sont rejetées. Car ici la réponse négative n’est pas le problème, c’est le manque de feedback, qui donne une impression de lourdeur et de dédain à la communauté entière.
D’ailleurs, si tu n’as encore jamais contribué à un projet libre, je te conseille de regarder le projet CHICKEN. La communauté est justement très réactive et n’hésitera pas à te guider ! C’est super motivant !
Un dernier point avant de te laisser : je pense que les systèmes d’exploitation gagneraient à proposer des cycles de développement rapides à l’image de ce qui se fait pour Lisp. L’état actuel des systèmes est assez affolant. Je me demande d’ailleurs comment font les développeurs de tels systèmes pour ne pas tomber dans de profondes dépressions. En effet ces systèmes sont très souvent écrits dans des langages comme le C, où les compilateurs les plus utilisés sont assez lents. Et en plus de ce temps de compilation, le temps nécessaire à relancer le programme est effroyable, il faut redémarrer complètement la machine !
J’ai toujours voulu contribuer à des systèmes d’exploitation, mais j’attendrai avec espoir que des systèmes interactifs voient le jour. Certains projets sont dans de bonnes voies, comme les systèmes à micro-noyau comme Minix ou le projet RUMP chez NetBSD.