Justement, l'objectif de la programmation lettrée est de créer ce plan. Certes, de manière plus verbeuse qu'avec juste des schémas. Mais le programme se présentant comme un livre, il peut inclure des schémas.
J'avais commencé à écrire un programme assez conséquent (pas terminé, même s'il est juste en pause). La majeure partie de l'effort s'est retrouvée à penser, puis décrire l'architecture. Il y avait des schémas inclut.
Knuth est avant tout un mathématicien, et si le langage de l'ordinateur est celui des mathématiques, sa propositions est tout à fait pertinente : ce que j'ai lu qui ressemble le plus à de la programmation lettrée, c'est les travaux de mathématiciens décrivant des algorithmes (celui-ci par exemple).
En fait, j'ai l'impression que la programmation lettrée se rapproche plus de la conception logicielle « à l'ancienne », où on réfléchit, spécifie, etc. énormément avant la moindre ligne de code, et où les spécifications ne vont pas changer. Dans ce cas, on obtient un livre, qui décrit de bout en bout l'implémentation du programme, de manière précise, avec schéma… Ce livre traite à la fois de l'architecture du programme, des détails d'implémentation, des pièges à éviter… C'est à la fois la description du programme et un traité sur comment résoudre le problème auquel le programme répond.
La programmation lettrée me semble toutefois moins adaptée à des spécifications en continuelle évolution, comme on croise dans les méthodes agiles, programmation extrême, etc. (et quoi que vous pensiez des méthodes en question, le problème auquel elles veulent répondre existe et est inévitable dans certains domaines). Ces méthodologies étant très courantes de nos jours, et pertinentes dans les domaines pour lesquels je programme, j'aurais aimé savoir si quelqu'un avait réussit à les concilier à la programmation lettrée.
Je me pose d'autant plus cette question que je croise de plus en plus de propositions quant à cette pratique (comme cette nouvelle implémentation par CoffeeScript). La programmation lettrée « des origines » date d'une époque où les besoins d'un programme étaient fixée avant l'écriture, et avec l'avènement de la programmation extrême est entrée en hibernation. L'éveil/évolution de cette pratique dans un nouveau contexte peut signifier qu'un début de réponse se met en place, visant à concilier ces deux mondes.
Pour ma part, je suis passé à autre chose, influencé par Forth (dans ma recherche de la « méthode parfaite », l'approche de la programmation lettrée et l'approche de Forth sont les deux réponses qui m'ont le plus convaincues, bien que d'apparence totalement opposées). Je continuerais d'utiliser la programmation lettrée pour les problèmes « finit » (utilitaire shell, programme qui ne fait qu'une chose mais le fait bien), mais je n'essaye même plus pour les problèmes « créatifs » (site web, programme évolutif…).
Et je suis donc intéressé par l'avis de ceux qui ont pratiqué, ou pratiquent encore, la programmation lettrée dans le cadre instable devenu courant de nos jours.
[^] # Re: 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é à 1.
Justement, l'objectif de la programmation lettrée est de créer ce plan. Certes, de manière plus verbeuse qu'avec juste des schémas. Mais le programme se présentant comme un livre, il peut inclure des schémas.
J'avais commencé à écrire un programme assez conséquent (pas terminé, même s'il est juste en pause). La majeure partie de l'effort s'est retrouvée à penser, puis décrire l'architecture. Il y avait des schémas inclut.
Knuth est avant tout un mathématicien, et si le langage de l'ordinateur est celui des mathématiques, sa propositions est tout à fait pertinente : ce que j'ai lu qui ressemble le plus à de la programmation lettrée, c'est les travaux de mathématiciens décrivant des algorithmes (celui-ci par exemple).
En fait, j'ai l'impression que la programmation lettrée se rapproche plus de la conception logicielle « à l'ancienne », où on réfléchit, spécifie, etc. énormément avant la moindre ligne de code, et où les spécifications ne vont pas changer. Dans ce cas, on obtient un livre, qui décrit de bout en bout l'implémentation du programme, de manière précise, avec schéma… Ce livre traite à la fois de l'architecture du programme, des détails d'implémentation, des pièges à éviter… C'est à la fois la description du programme et un traité sur comment résoudre le problème auquel le programme répond.
La programmation lettrée me semble toutefois moins adaptée à des spécifications en continuelle évolution, comme on croise dans les méthodes agiles, programmation extrême, etc. (et quoi que vous pensiez des méthodes en question, le problème auquel elles veulent répondre existe et est inévitable dans certains domaines). Ces méthodologies étant très courantes de nos jours, et pertinentes dans les domaines pour lesquels je programme, j'aurais aimé savoir si quelqu'un avait réussit à les concilier à la programmation lettrée.
Je me pose d'autant plus cette question que je croise de plus en plus de propositions quant à cette pratique (comme cette nouvelle implémentation par CoffeeScript). La programmation lettrée « des origines » date d'une époque où les besoins d'un programme étaient fixée avant l'écriture, et avec l'avènement de la programmation extrême est entrée en hibernation. L'éveil/évolution de cette pratique dans un nouveau contexte peut signifier qu'un début de réponse se met en place, visant à concilier ces deux mondes.
Pour ma part, je suis passé à autre chose, influencé par Forth (dans ma recherche de la « méthode parfaite », l'approche de la programmation lettrée et l'approche de Forth sont les deux réponses qui m'ont le plus convaincues, bien que d'apparence totalement opposées). Je continuerais d'utiliser la programmation lettrée pour les problèmes « finit » (utilitaire shell, programme qui ne fait qu'une chose mais le fait bien), mais je n'essaye même plus pour les problèmes « créatifs » (site web, programme évolutif…).
Et je suis donc intéressé par l'avis de ceux qui ont pratiqué, ou pratiquent encore, la programmation lettrée dans le cadre instable devenu courant de nos jours.