Autant développer le prototype directement avec le langage cible même s'il est fortement typé quitte à sacrifier à la souplesse et à la productivité.
Sauf qu'en général le prototype c'est pas une "référence". C'est pas forcement "bien" de partir de son code, il faut mieux parfois reprendre tout à 0 de façon plus propre, lorsque les différentes idées dans le prototype commence à se mettre en place.
Toi tu proposes d'améliorer au fure et à mesure la qualité du code de ton prototype. Pourquoi pas. Je ne suis pas partisan de cette manière de faire, je préfères faire le plus propre possible dès le début, en me basant sur un modèle plus abstrait validé "théoriquement".
Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
A l'arrivé on est parfois plus productif puisque l'IDE propose automatiquement les méthodes qui s'applique à un objet. Dans un langage où le type n'est connu qu'à l'exécution ca va être "balèze". Souligner les fautes est également productif à mon goût.
Bref tout est affaire de compromis entre performance et productivité.
Je ne parlais pas de performances, là j'aurai trop epru de troller ;)
Je préfères me contenter de parler de compromis entre productivité et "qualité".
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.
Très bonne conclusion avec laquelle je suis d'accord. Cela va assez dans mon sens : les grands comptes qui font de "grosses" applis ont besoin du maximum d'outils pour vérifier et valider des bouzins énormes. D'où l'idée qu'un typage statique fort va dans le sens de la qualité (et avec un bon IDE sans rien sacrifier à la productivité à mon goût).
J2EE va vraiment dans le sens des grosses applis, Python/Ruby pour le RAD. Mono je le situerais bien entre les 2. Peut être pas parfait dans un cas ni dans l'autre, mais à "l'aise" dans les 2.
Pour la prog par contrat je n'avais regarder que du côté de Eiffel.
Sinon une variante de Python avec typage fort et statique : Boo pour Mono.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
Sauf qu'en général le prototype c'est pas une "référence". C'est pas forcement "bien" de partir de son code, il faut mieux parfois reprendre tout à 0 de façon plus propre, lorsque les différentes idées dans le prototype commence à se mettre en place.
Toi tu proposes d'améliorer au fure et à mesure la qualité du code de ton prototype. Pourquoi pas. Je ne suis pas partisan de cette manière de faire, je préfères faire le plus propre possible dès le début, en me basant sur un modèle plus abstrait validé "théoriquement".
Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
A l'arrivé on est parfois plus productif puisque l'IDE propose automatiquement les méthodes qui s'applique à un objet. Dans un langage où le type n'est connu qu'à l'exécution ca va être "balèze". Souligner les fautes est également productif à mon goût.
Bref tout est affaire de compromis entre performance et productivité.
Je ne parlais pas de performances, là j'aurai trop epru de troller ;)
Je préfères me contenter de parler de compromis entre productivité et "qualité".
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.
Très bonne conclusion avec laquelle je suis d'accord. Cela va assez dans mon sens : les grands comptes qui font de "grosses" applis ont besoin du maximum d'outils pour vérifier et valider des bouzins énormes. D'où l'idée qu'un typage statique fort va dans le sens de la qualité (et avec un bon IDE sans rien sacrifier à la productivité à mon goût).
J2EE va vraiment dans le sens des grosses applis, Python/Ruby pour le RAD. Mono je le situerais bien entre les 2. Peut être pas parfait dans un cas ni dans l'autre, mais à "l'aise" dans les 2.
Pour la prog par contrat je n'avais regarder que du côté de Eiffel.
Sinon une variante de Python avec typage fort et statique : Boo pour Mono.