- La programmation de gauche à droite permet au programme de rester valide dès la saisie du code, ce qui maximise la prise en charge par les outils comme l’autocomplétion de l’éditeur
- Les list comprehensions de Python nuisent à l’autocomplétion à cause de variables non déclarées et de l’absence d’inférence de types
- Rust et JavaScript permettent de construire naturellement le programme de gauche à droite, ce qui rend l’usage des variables et l’exploration des méthodes plus intuitifs
- Le style fonctionnel en C et en Python nuit à une expérience de codage efficace à cause de la faible découvrabilité des noms de fonctions ou des structures
- Pour les logiques complexes, un code qui se déploie de gauche à droite est plus facile à lire, avec une meilleure maintenabilité et extensibilité
Programmer de gauche à droite
Le code doit être valide dès le moment où on le saisit
Les limites des list comprehensions en Python
- La syntaxe de list comprehension en Python
words_on_lines = [line.split() for line in text.splitlines()] pose problème, car elle oblige à accéder à une variable non déclarée (line), ce qui empêche l’éditeur de fournir correctement l’autocomplétion ou l’inférence de types
- Pendant la saisie partielle du code
- si l’on tape
words_on_lines = [line.sp, l’éditeur ne connaît pas le type de line et ne peut donc pas suggérer de méthodes
- il devient aussi difficile de détecter des erreurs potentielles comme une faute de frappe dans le nom de variable (
lime, par exemple)
- Pour obtenir des suggestions correctes, il faut écrire du code inachevé, ce qui rend le processus peu intuitif et inconfortable
Construction de gauche à droite en Rust
- Dans l’exemple Rust (
let words_on_lines = text.lines().map(|line| line.split_whitespace());)
- la variable (
line) est considérée comme déclarée au moment même où elle apparaît pour la première fois avec la fonction anonyme, ce qui permet immédiatement l’autocomplétion et les suggestions de méthodes
- en pratique, la méthode
split_whitespace a elle aussi été facile à trouver grâce aux suggestions automatiques
- Cette approche permet au programme de rester toujours partiellement valide, ce qui permet à l’IDE ou à l’éditeur d’aider à coder en temps réel
Progressive Disclosure et utilisabilité des API
- La progressive disclosure est un principe de conception selon lequel l’utilisateur n’est exposé qu’au niveau de complexité dont il a besoin, et il peut aussi s’appliquer à la programmation
- Exemple : une UX de traitement de texte où les options liées à une image n’apparaissent qu’au moment où l’on ajoute une image
- Le langage C offre peu de support dans ce domaine
- comme toutes les fonctions liées à
FILE *file ne se découvrent pas via file., il faut mémoriser les conventions de nommage (fread, fclose, etc.), ce qui rend les fonctionnalités difficiles à découvrir
- à l’inverse, dans un langage idéal, les suggestions de méthodes via
file. permettraient de découvrir progressivement les fonctions associées
Différence de découvrabilité entre fonctions et méthodes
- Comparaison entre les exemples Python
map(len, text.split()) et JavaScript text.split(" ").map(word => word.length)
- en Python, comme les noms de fonctions tels que
len, length ou size ne sont pas prévisibles, il faut souvent essayer plusieurs variantes avant de trouver ce qui fonctionne réellement
- en JavaScript, il suffit de taper
.l après word. pour que l’éditeur propose length et d’autres méthodes, ce qui améliore fortement la découvrabilité
- même des fonctions d’ordre supérieur comme
map rendent immédiatement plus clairs la valeur de retour réelle et le type de données
Les avantages d’une écriture structurée quand la logique se complexifie
- Dans les logiques complexes (long code Python avec
filter et lambda imbriqués)
- il faut vérifier à répétition le début et la fin du code, et les conditions ou parenthèses appariées entraînent une baisse de lisibilité et une compréhension plus difficile
- Dans la version JavaScript de la même logique, on peut lire et comprendre le code de façon séquentielle, de haut en bas et de gauche à droite
Principe fondamental
Le code doit être valide à chaque instant de la saisie
- Le programme reste valide même avec la seule saisie de
text
- Même après avoir écrit
text.split(" "), puis en poursuivant avec .map(word => word.length), l’état intermédiaire reste toujours valide dans son ensemble
- Ce type de codage augmente la possibilité d’un support en temps réel par l’éditeur et, dans un environnement REPL, permet aussi de voir immédiatement le résultat
Conclusion
- Les API et le design des langages doivent permettre de saisir naturellement le code de gauche à droite, tout en créant à chaque étape intermédiaire un programme valide
- Une bonne conception d’API est la clé de cette amélioration de l’expérience de programmation
Aucun commentaire pour le moment.