Très récemment est sortie une nouvelle version de coffeescript, la 1.5. Entre autres choses, cette version introduit le principe de Literate CoffeeScript. Il s'agit tout simplement de mixer dans un même fichier documentations — commentaires, même si c'est plus que ça en réalité — et code, comme on peut le voir dans le literate programming.
Le Literate programming est une approche de la programmation où le but est d'écrire le programme non plus en premier lieu pour la machine, mais pour l'humain. L'objectif est que ce soit le plus lisible possible, qu'il y ait le moins de différence entre la documentation et le code. Ainsi la relecture, la maintenance, et même l'écriture s'en trouvent simplifiés, plus agréable.
En programmation classique, on écrit le code et on rajoute les commentaire par dessus. On utilise souvent diverses notations, mais la principale reste calquée sur le principe de la javadoc. Dans le literate programming c'est finalement l'inverse. On insère le code dans la documentation. Voici par exemple une introduction au literate programming faite par Nicolas Roard en Mai 2008 au Google OpenSource Jam.
En coffeescript il était possible de s'en rapprocher en utilisant, par exemple, docco. Néanmoins, la source se trouvais peu lisible car la documentation était dans des blocs de commentaires. Ce n'est pas trop gênant mais ça pouvait être mieux.
Désormais en coffeescript il devient possible de le réaliser très simplement, avec des fichiers portant l'extension .litcoffee. Je ne vais pas rentrer dans le détail de l'implémentation, le mieux étant de voir l'exemple fourni :
- voici le fichier version document
- voici la source
- voici la source colorée
C'est, je trouve, assez parlant et ça donne plutôt envie.
Franchement je trouve que le literate programming est réellement une bonne chose. Mais il reste un problème. C'est en effet très bien pour des scripts, mais comment le mettre en place lorsqu'on utilise des langages objets ? Comment rendre le tout fluide avec de telles constructions ? Si jamais on arrive à répondre à cette question, je pense que c'est alors la meilleur façon de documenter le code, car la documentation — et le code — sont alors réellement à destination des développeurs, des humains.