1/ Tout le monde n'est pas capable de maîtriser B et même les bases de la logique. Tu fait partie d'une élite, ne l'oublie pas :-) Voir mes posts plus haut.
C'est justement là où je voulais en venir : la difficulté n'est pas de coder en soit, mais de réussir à formaliser toutes les spécifs, parcque la plupart du temps on fait confiance à notre intuition qui nous "vas y fonce t'as à peu prêt capter, code !"
B nous force à écrire ce qu'on croit savoir de manière intuitive, et c'est là que justement on tombe sur de nombreux problèmes : spécifs foireuses, absente ou partielle, etc.
Soit on veut un truc sans bug, c'est possible mais ca prend ouachement de temps (à poser nickel les spécifs), soit on prend une solution intermédiaire, en posant plus ou moins bien les spécifs.
Ce que je veux dire, c'est qu'il n'y pas de miracle : tant qu'on n'a pas réussi à mettre "carr"" les spécifs, on ne codera rien sans bug. Et l'intuition va souvent à l'encontre de cet objectif en court-circuitant l'étape de la mise au "carré".
2/ Les spécifications peuvent être limitatives en soi, par exemple UML qui t'impose de découper en hiérarchie d'objets avec mono-héritage.
gni ? Tu peux faire du multi-héritage. Et je vois pas trop le rapport avec UML, UML est un langage de modélisation, pas de spécification.
l'OO oblige souvent à des contortionnement pas possible pour gérer des choses simple
? Un exemple ?
Non parcque en objet tu peux tout modéliser, à n'importe quel niveau d'abstraction. Un objet peut être une entité de donnée comme une entitée manipulant des données ou un concept de baeucoup plus haut niveau, il peut encapsuler un protocole, une notion temporelle, il y a une liberté totale.
Donne moi un exemple qui demande des contorsions en objet.
[^] # Re: dsqdsq
Posté par TImaniac (site web personnel) . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 6.
C'est justement là où je voulais en venir : la difficulté n'est pas de coder en soit, mais de réussir à formaliser toutes les spécifs, parcque la plupart du temps on fait confiance à notre intuition qui nous "vas y fonce t'as à peu prêt capter, code !"
B nous force à écrire ce qu'on croit savoir de manière intuitive, et c'est là que justement on tombe sur de nombreux problèmes : spécifs foireuses, absente ou partielle, etc.
Soit on veut un truc sans bug, c'est possible mais ca prend ouachement de temps (à poser nickel les spécifs), soit on prend une solution intermédiaire, en posant plus ou moins bien les spécifs.
Ce que je veux dire, c'est qu'il n'y pas de miracle : tant qu'on n'a pas réussi à mettre "carr"" les spécifs, on ne codera rien sans bug. Et l'intuition va souvent à l'encontre de cet objectif en court-circuitant l'étape de la mise au "carré".
2/ Les spécifications peuvent être limitatives en soi, par exemple UML qui t'impose de découper en hiérarchie d'objets avec mono-héritage.
gni ? Tu peux faire du multi-héritage. Et je vois pas trop le rapport avec UML, UML est un langage de modélisation, pas de spécification.
l'OO oblige souvent à des contortionnement pas possible pour gérer des choses simple
? Un exemple ?
Non parcque en objet tu peux tout modéliser, à n'importe quel niveau d'abstraction. Un objet peut être une entité de donnée comme une entitée manipulant des données ou un concept de baeucoup plus haut niveau, il peut encapsuler un protocole, une notion temporelle, il y a une liberté totale.
Donne moi un exemple qui demande des contorsions en objet.