J'irais même plus loin : le typage statique c'est une optimisation prématurée.
En fait le typage est juste un contrat comme un autre (et un peu un problème de documentation ou de nommage). Les systèmes de typage statique qui fournissent une réelle assistance plutôt qu'une contrainte sont rares et complexes (O'Caml j'en suis pas fana, mais j'ai lu du bien de Haskell...)
Poser des contrats (pré/post-conditions surtout, invariants un peu moins) sur les méthodes est TRÈS efficace pour localiser les erreurs : quand ça explose, le contrat localise très vite l'origine de l'erreur (et pas sa conséquence, comme avec une backtrace).
À mon avis, une approche très efficace à la fois pour éviter les bugs techniques et les problèmes de compréhension des specs est une combinaison de méthodes agiles / XP / test-driven-development avec un langage typé dynamiquement encourageant la conception par contrats.
[^] # Re: Mon avis de moi
Posté par Damien . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 3.
J'irais même plus loin : le typage statique c'est une optimisation prématurée.
En fait le typage est juste un contrat comme un autre (et un peu un problème de documentation ou de nommage). Les systèmes de typage statique qui fournissent une réelle assistance plutôt qu'une contrainte sont rares et complexes (O'Caml j'en suis pas fana, mais j'ai lu du bien de Haskell...)
Poser des contrats (pré/post-conditions surtout, invariants un peu moins) sur les méthodes est TRÈS efficace pour localiser les erreurs : quand ça explose, le contrat localise très vite l'origine de l'erreur (et pas sa conséquence, comme avec une backtrace).
À mon avis, une approche très efficace à la fois pour éviter les bugs techniques et les problèmes de compréhension des specs est une combinaison de méthodes agiles / XP / test-driven-development avec un langage typé dynamiquement encourageant la conception par contrats.