Depuis que j'ai découvert la programmation lettrée, j'ai beaucoup accroché avec le concept. J'ai même traduit l'article Wikipédia anglais en français, afin de pouvoir faire profiter mes amis anglophobes du concept.
J'ai écrit quelques programmes en utilisant des outils comme noweb, mais mon expérience est que cela mène à un code assez rigide :
Quand on écrit un programme assez conséquent, on écrit encore plus de documentation. La conception du programme ressemble dans mon cas à l'écriture d'un livre. On organise notre documentation (qui n'est pas comment utiliser le code, mais quel est le contexte du code, pourquoi il est là, quel est son but réel) comme un livre, en le découpant en chapitre, suivant les différentes tâches à accomplir et les différents modules.
Lors de la refactorisation, on n'a plus juste un petit morceau de code à déplacer, mais aussi toute une documentation à mettre à jour.
Dans le cas d'un code extrêmement factorisé, la documentation devient quasiment inutile (une fonction parle d'elle même), ou – pour un problème complexe – a une meilleure place dans un document annexe décrivant le problème. Au pire, cette documentation peut se trouver au début du code, comme préambule. Elle n'est pas destinée à changer (elle décrit le problème), et n'est plus mélangée au code (ce n'est donc pas de la programmation lettrée).
L'article de blog lié dans la dépêche pose la question de la programmation objet mixée à la programmation lettrée. J'ai remarqué dans ma manière de faire (et pour un programme écrit dès le départ en programmation lettrée, par contraste avec des codes déjà écrit et documentés/réorganisés après coup) que ce n'était pas très différent du fonctionnement headers/code que l'on trouve en C++. J'aurais par exemple une partie décrivant mon objet, puis plus loin la définition des méthodes (dans leur propres chapitres).
Malgré tout l'enthousiasme que j'éprouve envers cette pratique, j'ai la sensation qu'elle ne fonctionne que dans le cas de petits programmes. Mon expérience porte sur un environnement de développement plus « complet » que ceux proposés par Haskell, CoffeeScript et Docco, c'est à dire des environnements où l'on peut vraiment séparer et déplacer le code suivant notre propre logique (les possibilités de factorisation offertes par Haskell et Coffeescript diminuent le besoin de réorganisation, mais je ne factorisais pas autant à l'époque, et cette réorganisation me semble encore pertinente dans le cas de la programmation objet). Et je n'ai pas trouvé d'exemple de code vraiment conséquent et en perpétuelle évolution écrit en programmation lettrée.
Je parle de petits/gros programmes, mais mon véritable questionnement porte sur les programmes « jamais finit » : si le programme a une tâche à effectuer, et le fait bien, il n'a plus de raison d'évoluer. Dans ce cas, la programmation lettrée permet d'avoir un travail définitif et bien documenté. Mais pour les programmes plus « vivants » (par exemple, le code de LinuxFR n'a jamais arrêté d'évoluer), quelqu'un a t'il déjà utilisé avec succès cette méthode ?
# Programmation lettrée, des retours d'expérience ?
Posté par daeldir . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #10. Évalué à 6.
Depuis que j'ai découvert la programmation lettrée, j'ai beaucoup accroché avec le concept. J'ai même traduit l'article Wikipédia anglais en français, afin de pouvoir faire profiter mes amis anglophobes du concept.
J'ai écrit quelques programmes en utilisant des outils comme noweb, mais mon expérience est que cela mène à un code assez rigide :
Quand on écrit un programme assez conséquent, on écrit encore plus de documentation. La conception du programme ressemble dans mon cas à l'écriture d'un livre. On organise notre documentation (qui n'est pas comment utiliser le code, mais quel est le contexte du code, pourquoi il est là, quel est son but réel) comme un livre, en le découpant en chapitre, suivant les différentes tâches à accomplir et les différents modules.
Lors de la refactorisation, on n'a plus juste un petit morceau de code à déplacer, mais aussi toute une documentation à mettre à jour.
Dans le cas d'un code extrêmement factorisé, la documentation devient quasiment inutile (une fonction parle d'elle même), ou – pour un problème complexe – a une meilleure place dans un document annexe décrivant le problème. Au pire, cette documentation peut se trouver au début du code, comme préambule. Elle n'est pas destinée à changer (elle décrit le problème), et n'est plus mélangée au code (ce n'est donc pas de la programmation lettrée).
L'article de blog lié dans la dépêche pose la question de la programmation objet mixée à la programmation lettrée. J'ai remarqué dans ma manière de faire (et pour un programme écrit dès le départ en programmation lettrée, par contraste avec des codes déjà écrit et documentés/réorganisés après coup) que ce n'était pas très différent du fonctionnement headers/code que l'on trouve en C++. J'aurais par exemple une partie décrivant mon objet, puis plus loin la définition des méthodes (dans leur propres chapitres).
Malgré tout l'enthousiasme que j'éprouve envers cette pratique, j'ai la sensation qu'elle ne fonctionne que dans le cas de petits programmes. Mon expérience porte sur un environnement de développement plus « complet » que ceux proposés par Haskell, CoffeeScript et Docco, c'est à dire des environnements où l'on peut vraiment séparer et déplacer le code suivant notre propre logique (les possibilités de factorisation offertes par Haskell et Coffeescript diminuent le besoin de réorganisation, mais je ne factorisais pas autant à l'époque, et cette réorganisation me semble encore pertinente dans le cas de la programmation objet). Et je n'ai pas trouvé d'exemple de code vraiment conséquent et en perpétuelle évolution écrit en programmation lettrée.
Je parle de petits/gros programmes, mais mon véritable questionnement porte sur les programmes « jamais finit » : si le programme a une tâche à effectuer, et le fait bien, il n'a plus de raison d'évoluer. Dans ce cas, la programmation lettrée permet d'avoir un travail définitif et bien documenté. Mais pour les programmes plus « vivants » (par exemple, le code de LinuxFR n'a jamais arrêté d'évoluer), quelqu'un a t'il déjà utilisé avec succès cette méthode ?