J'ai un peu du mal à trouver une cohérence à l'ensemble de l'article mais bon y'a des réflexions intéressantes :)
Ca commence par un constat : y'a des bugs.
Oué bah oué. Au niveau langage on a déjà atteind l'objectif de perfection dans ce domaine : convertir tout programme en preuve mathématique.
Exemple : langage formel B. Tu peux t'assurer qu'il n'y a pas de bug dans le programme. Mais on arrive à un constat : bien que le programme est correct, on n'obtient pas le résultat escompté : pourquoi ?
L'article laisse sugérer des bugs "architecturaux". Les bugs sont tout simplement dans les spécifications elles-même. On s'en rend compte en utilisant les langages de type langage B : toute la difficulté consiste à poser sur le papier TOUTES les spécifications, et des spécifications justes.
Et là on sort des langages informatiques, les spécifications sont écrites (dans un premier temps avant d'êtres traduites en langaeg formel) en langage naturel. Difficile de trouver plus intuitif. Malheuresement si cette étape là n'est pas correcte, tout ce qui en découlera ne pourra pas l'être.
Hors plus un logiciel est complexe, plus ses spécifications sont conséquentes, et plus il est difficile de les appréhender et de les formaliser sur le papier.
D'où l'idée qui date pas d'hier de découper le problème en sous-problème, INDEPENDAMENT de tous langages informatique.
Après coder les spécifs reste relativement simple et automatique si celles-ci sont correctes.
Voilà tout ca pour dire qu'il ne faudrait pas faire l'erreur d'introduire trop de complexité dans le langage en introduisant de nouveaux concepts, alors que paradoxalement cela aurait été fait dans le but de mieux appréhender la complexité de la tâche à accomplir.
Un langage doit être là pour fournir des outils permettant au programmeur d'exprimer la plus large gammes de concepts et d'idée. La seule véritable contrainte, c'est de faciliter la solution n°1 : découper le problème en sous-problème. Bref, proposer la sémantique de grosses et petites boîtes. Le concept objet est parfait pour cela.
# dsqdsq
Posté par TImaniac (site web personnel) . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 9.
Ca commence par un constat : y'a des bugs.
Oué bah oué. Au niveau langage on a déjà atteind l'objectif de perfection dans ce domaine : convertir tout programme en preuve mathématique.
Exemple : langage formel B. Tu peux t'assurer qu'il n'y a pas de bug dans le programme. Mais on arrive à un constat : bien que le programme est correct, on n'obtient pas le résultat escompté : pourquoi ?
L'article laisse sugérer des bugs "architecturaux". Les bugs sont tout simplement dans les spécifications elles-même. On s'en rend compte en utilisant les langages de type langage B : toute la difficulté consiste à poser sur le papier TOUTES les spécifications, et des spécifications justes.
Et là on sort des langages informatiques, les spécifications sont écrites (dans un premier temps avant d'êtres traduites en langaeg formel) en langage naturel. Difficile de trouver plus intuitif. Malheuresement si cette étape là n'est pas correcte, tout ce qui en découlera ne pourra pas l'être.
Hors plus un logiciel est complexe, plus ses spécifications sont conséquentes, et plus il est difficile de les appréhender et de les formaliser sur le papier.
D'où l'idée qui date pas d'hier de découper le problème en sous-problème, INDEPENDAMENT de tous langages informatique.
Après coder les spécifs reste relativement simple et automatique si celles-ci sont correctes.
Voilà tout ca pour dire qu'il ne faudrait pas faire l'erreur d'introduire trop de complexité dans le langage en introduisant de nouveaux concepts, alors que paradoxalement cela aurait été fait dans le but de mieux appréhender la complexité de la tâche à accomplir.
Un langage doit être là pour fournir des outils permettant au programmeur d'exprimer la plus large gammes de concepts et d'idée. La seule véritable contrainte, c'est de faciliter la solution n°1 : découper le problème en sous-problème. Bref, proposer la sémantique de grosses et petites boîtes. Le concept objet est parfait pour cela.