Une histoire de typage

Les premières lignes de code que j’ai écrites étaient en PHP. J’ai utilisé uniquement ce langage pendant mes premières années de développement sur PHPBoost. Puis, pour ma culture, j’ai suivi les cours de C de l’ex-Site du Zéro. Le passage d’un langage dynamique de haut niveau à un langage statique de bas niveau m’a fait un gros choc, et ma première réaction a été la suivante :

A quoi bon typer son code si ce n’est pas nécessaire pour que le programme fonctionne ?

L’intérêt du typage statique

Depuis, j’ai quelque peu évolué, et c’est sans doute la découverte de Java qui m’a donné le déclic.  Je me suis rendu compte à quoi pouvait servir le typage statique, et depuis, je ne peux franchement plus m’en passer. Pour moi, le typage statique a, entre autres, les avantages suivants :

• L’étape de compilation apporte une sécurité : lorsqu’on a un code qui compile, on a déjà fait la moité du boulot, on sait déjà qu’il n’y a pas de grosse incohérence dans le code, même si ça ne garantit pas l’absence de bugs
• Les IDEs comprennent intégralement le code et donc :
  • d’aider à l’écrire à travers par exemple une auto-complétion pertinente
  • d’avoir un retour immédiat lorsqu’on écrit un code qui n’a pas de sens avec en plus des propositions d’actions qui permettent de régler le problème
  • de manipuler le code à notre place vite et sans erreur (refactoring)

Je ressens une très grande frustration lorsque je dois quitter le monde des langages statiquement typés pour aller vers un langage dynamique.  J’ai l’habitude de faire travailler mon IDE à ma place. Avec un langage dynamique, un IDE, aussi bon soit-il, n’a pas la possibilité d’être aussi efficace qu’avec un langage à typage statique. Par exemple, il ne me détecte pas vraiment les erreurs à la volée et il ne me propose pas souvent une auto-complétion pertinente. L’expérience m’a également bien montré lorsque je faisais du PHP, ou plus récemment du Javascript ou du Python, qu’on ne peut jamais vraiment être sûr de ne rien avoir cassé lorsqu’on modifie un bout de code susceptible d’être utilisé ailleurs. Pour moi, avec un langage dynamique, il est indispensable d’avoir une très grosse couverture de code dans les tests, mais ça ne suffit pas toujours. J’ai récemment eu un problème en faisant un refactoring en Python sur du code pourtant couvert par des tests. Le code modifié était sous la forme de mock dans le test d’un composant qui l’utilisait, je n’ai pas pensé à modifier le mock en conséquence, et il continuait à se comporter comme avant et les tests passaient avec succès. Pourtant, une fois tous les composants assemblés, ça ne fonctionnait pas, le mock n’étant pas conforme au composant qu’il est censé remplacer. Le typage statique permet de s’assurer par exemple qu’un mock respecte bien le prototype de l’objet qu’il remplace.

L’inférence de type

Mais alors, que penser de l’inférence de type ? Je n’ai jamais eu l’occasion d’utiliser de manière industrielle un langage à typage statique inféré. Mais spontanément j’aurais tendance à dire que cela ne pose pas spécialement de problème dans la mesure où cela ne compromet pas les points cités ci-dessus. En revanche, l’utilisation d’un IDE me semble encore plus nécessaire qu’avec un langage à typage explicite pour avoir une inférence des types à la volée, ce qui permet finalement de se ramener à des conditions similaires à un typage explicite.

Et la productivité dans tout ça ?

On qualifie souvent les langages dynamiques de hautement productifs. Si on prend un langage comme Python, il est clair que la syntaxe est élégante, peu verbeuse et très expressive. L’API disponible est très complète et on peut faire de belles choses en peu de temps et de lignes de code.

Oui, mais cela suppose d’être familier avec l’ensemble du code qu’on utilise, parce qu’on dispose de peu d’aide de la part de l’IDE. Lorsqu’on s’interface avec du code peu connu, on passe beaucoup de temps à parcourir la documentation et le code pour savoir quelles sont les fonctions, objets et modules à notre disposition. On peut rajouter à cela le temps passé à faire manuellement les opérations de refactoring et à corriger les bugs dus à un refactoring malheureux. Tout cela est bien entendu exponentiel lorsque la base de code et la taille des équipes augmente.

Je pense que les pénalités dues à l’aspect dynamique d’un langage sont telles que la productivité avec un langage statique devient assez vite plus intéressante.

Conclusion

Vous l’aurez compris, pour moi il n’y a pas d’hésitation possible, je vote statique ! Les langages dynamiques c’est bon pour le prototypage ou des tout petits projets comme des scripts, c’est tout !

Je pense que tout ce que j’ai pu endurer en maintenant une grosse base de code en PHP dans ma jeunesse n’y est pas pour rien. Je suis vacciné contre les langages dynamiques !

L’image d’en-être provient de Flickr et représente un puzzle dans lequel les pièces sont typées en fonction de leur forme.