Tu parles de protoypage en réduisant les langages dynamiques au rôle de langages de script.
Mais si on suit ton raisonnement , on prototype rapidement avec un tel langage et après on réecrit tout avec un langage fortement typé pour assurer performance et sécurité ( ou on regénère du code à partir d'UML). Autant développer le prototype directement avec le langage cible même s'il est fortement typé quitte à sacrifier à la souplesse et à la productivité.
La démarche que j'explicite est différente.
Tu prototypes sans contrainte de type au début ce qui te permet d'explorer différentes pistes ou architectures.Tu ecris tes tests unitaires en même temps mais tu introduis tes contrats progressivement et itérativement à mesure que ta conception se précise.
Tu ne livres pas de code non testé en prod puisque ton code est testé et validé par les contrats. Tu relâches les contraintes progressivement à mesure que la qualité de ton code s'améliore (tout comme les niveaux de logging ou les options de debug) et tu conserves malgré tout une plus grande souplesse durant la phase de conception.
Concernant les IDE :
Bien entendu les fonctionnalités que tu decris sont intéressantes même pour un langage dynamique. Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
La compilation JIT n'a d'utilité que pour des langages compilés comme Java.
L'expressivité et la concision de langage comme Python ou Ruby rendent moins crucial le besoin d'outils performants de refactoring, d'introspection.... Python a ses défauts inhérents à son design mais Java n'est pas exempt non plus.Relis mon post , j'ai bien précisé qu'il s'agissait d'un troll en réaction à tes à prioris
Bref tout est affaire de compromis entre performance et productivité.
Il faut donc définir sa stratégie en fonction des besoins.
Autant je t'accorde que Mono/J2EE s'impose pour des grands comptes, autant les solutions RAD type Ruby On Rails (Ai pas testé Ruby) me paraissent pertnentes lorsque le coût et le délai l'emporte sur les perfs.
cf. notre thread sur http://linuxfr.org/comments/589849,1.html(...)
[^] # Re: Ruby On Rails
Posté par golum . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
Mais si on suit ton raisonnement , on prototype rapidement avec un tel langage et après on réecrit tout avec un langage fortement typé pour assurer performance et sécurité ( ou on regénère du code à partir d'UML). Autant développer le prototype directement avec le langage cible même s'il est fortement typé quitte à sacrifier à la souplesse et à la productivité.
La démarche que j'explicite est différente.
Tu prototypes sans contrainte de type au début ce qui te permet d'explorer différentes pistes ou architectures.Tu ecris tes tests unitaires en même temps mais tu introduis tes contrats progressivement et itérativement à mesure que ta conception se précise.
Tu ne livres pas de code non testé en prod puisque ton code est testé et validé par les contrats. Tu relâches les contraintes progressivement à mesure que la qualité de ton code s'améliore (tout comme les niveaux de logging ou les options de debug) et tu conserves malgré tout une plus grande souplesse durant la phase de conception.
Concernant les IDE :
Bien entendu les fonctionnalités que tu decris sont intéressantes même pour un langage dynamique. Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
La compilation JIT n'a d'utilité que pour des langages compilés comme Java.
L'expressivité et la concision de langage comme Python ou Ruby rendent moins crucial le besoin d'outils performants de refactoring, d'introspection.... Python a ses défauts inhérents à son design mais Java n'est pas exempt non plus.Relis mon post , j'ai bien précisé qu'il s'agissait d'un troll en réaction à tes à prioris
Bref tout est affaire de compromis entre performance et productivité.
Il faut donc définir sa stratégie en fonction des besoins.
Autant je t'accorde que Mono/J2EE s'impose pour des grands comptes, autant les solutions RAD type Ruby On Rails (Ai pas testé Ruby) me paraissent pertnentes lorsque le coût et le délai l'emporte sur les perfs.
cf. notre thread sur
http://linuxfr.org/comments/589849,1.html(...)
Si tu es interessé par les contrats tu retrouveras un excellent article de synthèse sur le defunt "Développeur Reference"
http://web.archive.org/web/20031204022702/www.devreference.net/devr(...)
Perso je l'utilise au travers d'un module POA dans le cadre d'un petit dev associatif et j'e ne m'en plains pas:
http://www.logilab.org/projects/aspects/documentation/contracts(...)
Mais tu trouveras sûrement de meilleurs equivalents pour .net, java ou ruby