Personnellement, je fais la distinction entre louvre fini et le cheminement aboutissant a celle-ci. Dans le monde du développement, très peux douvres fini (des programmes) sont des uvres que lont pourrais qualifier dartistique. On peux citer par exemple les demo-makers ou certains jeux vidéos. La technique ici est support de lart. Mais ces exemple ne constituent pas la majorité, a plus forte raison dans le petit monde du Libre/OpenSource.
Il en ais autrement pour les moyens qui mènent aux logiciel. Quelquun un peu plus la très clairement exprimé, « apache nest pas une uvre dart ». Bien sur il est possible dapporter un jugement qualitatif sur un logiciel, mais ce jugement est conditionné par un besoin fonctionnel. En fait quand je parle de « moyens qui mènent aux logiciel » jentend le code source, le design, larchitecture. Je trouve personnellement que designer un logiciel ( dans le sens design objet), a quelque chose de la démarche artistique. On retrouve dailleurs souvent dans la littérature informatique les termes « un design élégant », « une solution élégante ». En regardant un diagramme UML, il mest déjà arrivé de trouver la structure esthétiquement belle. En regardant un code source, on est capable de dire que ce code est beau (ou élégant) ou sil est moche, mal écrit ou maladroit. Jai écrit un article récemment ou je comparais les design patterns aux figure de style. Il y a pas mal de point commun. Par exemple quand une jeune personne commence à faire des rédactions, elle emploi des figures de style sans sen rendre compte, sans même savoir quelle existe, ni même le nom de celle-ci. Plus tard quand en français il les étudiera, apprendra à les reconnaître, comprendra les effets quelles produisent, elles améliorerons sa compréhension des textes ainsi que son style personnel. Il en va de même pour les design patterns : Quelquun qui apprend le Java et qui lit la Javadoc voit plein de chose intéressante et astucieuse comme les factory ou les écouteurs (je prend lexemple de la Javadoc car elle est truffé de design patterns). Plus tard, il essaiera lui même «dinventer » des méthodes astucieuse de ce genre. Et puis il étudiera les design patterns et apprendra à mettre un nom a ces « choses astucieuse ». Et comme pour les figures de styles, apprendra à les reconnaître et comprendra les intentions de lauteur de ce code. Car finalement il y a une différence entre comprendre la syntaxe dun code source ( apprendre a lire pour continuer la comparaison avec lélève), et comprendre la finalité de celui-ci.
Je ne suis pas sur, mais il me semble que cest Alan Cox qui disait que la programmation était proche de la poésie car tout deux sont de la pensé pure.
Je conçois que lesthétisme soit présent dans la programmation, mais de la a considérer que cest un art, je ne sais pas, je préfère dire « chacun son opinions » De toutes façons cest un faux débat, tout les films ne sont pas des uvres dart Il ne suffit pas de faire (ou dessayer de faire) de la musique pour être un artiste. Si vous nêtes pas convaincu, il suffit de regarder TF1 vers 19H ;).
# Re: La programmation est un art
Posté par Keos . En réponse à la dépêche La programmation est un art. Évalué à 4.
Il en ais autrement pour les moyens qui mènent aux logiciel. Quelquun un peu plus la très clairement exprimé, « apache nest pas une uvre dart ». Bien sur il est possible dapporter un jugement qualitatif sur un logiciel, mais ce jugement est conditionné par un besoin fonctionnel. En fait quand je parle de « moyens qui mènent aux logiciel » jentend le code source, le design, larchitecture. Je trouve personnellement que designer un logiciel ( dans le sens design objet), a quelque chose de la démarche artistique. On retrouve dailleurs souvent dans la littérature informatique les termes « un design élégant », « une solution élégante ». En regardant un diagramme UML, il mest déjà arrivé de trouver la structure esthétiquement belle. En regardant un code source, on est capable de dire que ce code est beau (ou élégant) ou sil est moche, mal écrit ou maladroit. Jai écrit un article récemment ou je comparais les design patterns aux figure de style. Il y a pas mal de point commun. Par exemple quand une jeune personne commence à faire des rédactions, elle emploi des figures de style sans sen rendre compte, sans même savoir quelle existe, ni même le nom de celle-ci. Plus tard quand en français il les étudiera, apprendra à les reconnaître, comprendra les effets quelles produisent, elles améliorerons sa compréhension des textes ainsi que son style personnel. Il en va de même pour les design patterns : Quelquun qui apprend le Java et qui lit la Javadoc voit plein de chose intéressante et astucieuse comme les factory ou les écouteurs (je prend lexemple de la Javadoc car elle est truffé de design patterns). Plus tard, il essaiera lui même «dinventer » des méthodes astucieuse de ce genre. Et puis il étudiera les design patterns et apprendra à mettre un nom a ces « choses astucieuse ». Et comme pour les figures de styles, apprendra à les reconnaître et comprendra les intentions de lauteur de ce code. Car finalement il y a une différence entre comprendre la syntaxe dun code source ( apprendre a lire pour continuer la comparaison avec lélève), et comprendre la finalité de celui-ci.
Je ne suis pas sur, mais il me semble que cest Alan Cox qui disait que la programmation était proche de la poésie car tout deux sont de la pensé pure.
Je conçois que lesthétisme soit présent dans la programmation, mais de la a considérer que cest un art, je ne sais pas, je préfère dire « chacun son opinions » De toutes façons cest un faux débat, tout les films ne sont pas des uvres dart Il ne suffit pas de faire (ou dessayer de faire) de la musique pour être un artiste. Si vous nêtes pas convaincu, il suffit de regarder TF1 vers 19H ;).