Via cet article sur Segment7, voici le lien vers une publication sur le développement de DRuby (DiamondBack Ruby) [:en, :pdf] : un outil (codé en OCaml) visant à autoriser le typage statique en Ruby. Le code source de cette application devrait être publié dans les mois à venir.
J'ai un avis assez mitigé sur ce genre de projet : d'un côté, j'apprécie la possibilité de choisir (cf. article précédent sur le typage en Groovy), et je reconnais tout à fait beaucoup des avantages du typage statique. Parmi eux, une certaine fiabilité et la détection précoce d'erreurs de développement.
Mais en Ruby (Perl, Python, etc...) ? L'un des avantages de ces langages dynamiques n'est-il pas d'"éluder" au maximum les contraintes de type pour un développement plus rapide et libre ? En Ruby en tout cas, la "philosophie" veut que l'on s'intéresse davantage au comportement d'un objet (no primitive type here !) qu'à sa classe (principe du "Duck Typing"). On croise donc plus souvent des foo.respond_to? :a_method que des foo.is_a? A_Class.
Il est cependant intéressant de se poser la question suivante (et pas seulement en Ruby !) :
J'ai un avis assez mitigé sur ce genre de projet : d'un côté, j'apprécie la possibilité de choisir (cf. article précédent sur le typage en Groovy), et je reconnais tout à fait beaucoup des avantages du typage statique. Parmi eux, une certaine fiabilité et la détection précoce d'erreurs de développement.
Mais en Ruby (Perl, Python, etc...) ? L'un des avantages de ces langages dynamiques n'est-il pas d'"éluder" au maximum les contraintes de type pour un développement plus rapide et libre ? En Ruby en tout cas, la "philosophie" veut que l'on s'intéresse davantage au comportement d'un objet (no primitive type here !) qu'à sa classe (principe du "Duck Typing"). On croise donc plus souvent des foo.respond_to? :a_method que des foo.is_a? A_Class.
Il est cependant intéressant de se poser la question suivante (et pas seulement en Ruby !) :
Comment et/ou avec quelles techniques, assurer la fiabilité d'un programme dans un langage dynamique ?
Je vais essayer de bientôt placer quelques petits exemples de code sur ce sujet.
4 commentaires:
après le chicken picking, voici le duck typing...
on va y passer la basse cour (turkey programing?)
au fait, j'ai recalé Analytics sans trop de problèmes...
Le typage statique n'empêche absolument pas de rester léger et de profiter du Duck Typing. Pourquoi ne pas par exemple faire des contraintes sur les messages que peut recevoir un objet ? Ça empêche déjà de passer un int là où on attend un fichier, mais ça laisse la possibilité de passer différentes classes se comportant comme des fichiers là où on en attend.
Par contre c'est clair que les isinstance ou autres doivent être évités à tous prix en Python ou Ruby.
Figure toi que j'ai essayé de réfléchir un peu à la question...
Merci de me donner la motivation pour écrire ce dernier article ^^
Enregistrer un commentaire