Ce qui est contre productif c'est d'être obligé de mettre des déclarations de type partout alors qu'on veut simplement tester une idée.
Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.
Ce qui est contre productif c'est d'être obligé de créer des templates et de les instancier en générant du code pour pouvoir s'en servir (pile d'entier, pile de float, ...) alors qu'il est tellemnet plus simple de s'en servir sans contrainte de type.
On a inventé les génériques :
Pile maPile;
De même disposer de pile de n'importe quoi (si je veux ajouter un entier puis un float) est plus interessant que d'être obligé de passer par des void* en C ou des Object ce qui revient à contourner le typage statique et ouvre la porte aux erreurs qu'on est sensé eviter.
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?
Tu developpes ta classe et ton test unitaire associé en même temps..
Genre toi humain t'es beaucoup plus fiable pour générer des tests unitaires exhaustifs en pouvant te permettre de te passer des vérifs qu'apporte un typage fort et statique.
Si encore tu me disais : moi je tests jamais les progs je comprendrais, t'assumerais effectivement jusqu'au bout, mais là non.
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), alors bon question productivité je préfères faire confiance au compilo et garder mes tests unitaires pour ce qu'il ne sait pas faire.
Une voie de progrès serait d'introduire le typage statique à posteriori lors des phases d'integration du produit.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme pour les tests unitaires : il est fortement conseillé de les écrire D'ABORD. Tout va toujours dans le même sens : on met le maximum de contraintes (tests unitaires, typage, etc.) et on code APRES.
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.
'intêret de la compilation est dans les performances qui peuvent être améliorée dans le cadre de l'execution et là aussi on dispose d'outils d'optimisation pour les langages dynamiques (psyco ...)
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.
Par contre les inconvénients du typage fort subsistent.
C'est quoi déjà les inconvénients ?
Ah oui tu peux pas mettre n'importe quoi dans ta pile, et c'est super long à taper le type.
PS : déclarer le type d'un objet c'est aussi une forme de documentation pour celui qui relis le code.
Taper le mot "int" ou "MaClasse" c'est une part négligeable de la rédaction du code et cela permet de gagner un peu plus loin : l'IDE ayant le type il peut te proposer les méthodes applications à ton objet , et ca question productivité c'est un gain beaucoup plus important.
[^] # 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é à 0.
Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.
Ce qui est contre productif c'est d'être obligé de créer des templates et de les instancier en générant du code pour pouvoir s'en servir (pile d'entier, pile de float, ...) alors qu'il est tellemnet plus simple de s'en servir sans contrainte de type.
On a inventé les génériques :
Pile maPile;
De même disposer de pile de n'importe quoi (si je veux ajouter un entier puis un float) est plus interessant que d'être obligé de passer par des void* en C ou des Object ce qui revient à contourner le typage statique et ouvre la porte aux erreurs qu'on est sensé eviter.
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?
Tu developpes ta classe et ton test unitaire associé en même temps..
Genre toi humain t'es beaucoup plus fiable pour générer des tests unitaires exhaustifs en pouvant te permettre de te passer des vérifs qu'apporte un typage fort et statique.
Si encore tu me disais : moi je tests jamais les progs je comprendrais, t'assumerais effectivement jusqu'au bout, mais là non.
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), alors bon question productivité je préfères faire confiance au compilo et garder mes tests unitaires pour ce qu'il ne sait pas faire.
Une voie de progrès serait d'introduire le typage statique à posteriori lors des phases d'integration du produit.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme pour les tests unitaires : il est fortement conseillé de les écrire D'ABORD. Tout va toujours dans le même sens : on met le maximum de contraintes (tests unitaires, typage, etc.) et on code APRES.
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.
'intêret de la compilation est dans les performances qui peuvent être améliorée dans le cadre de l'execution et là aussi on dispose d'outils d'optimisation pour les langages dynamiques (psyco ...)
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.
Par contre les inconvénients du typage fort subsistent.
C'est quoi déjà les inconvénients ?
Ah oui tu peux pas mettre n'importe quoi dans ta pile, et c'est super long à taper le type.
PS : déclarer le type d'un objet c'est aussi une forme de documentation pour celui qui relis le code.
Taper le mot "int" ou "MaClasse" c'est une part négligeable de la rédaction du code et cela permet de gagner un peu plus loin : l'IDE ayant le type il peut te proposer les méthodes applications à ton objet , et ca question productivité c'est un gain beaucoup plus important.