Ben c'est plus long que de ne pas l'indiquer
Pour le prototypage je reconnais qu'un langage sans typage peut être "pratique". Mais ca reste du prototypage. Ca rejoint l'idée première de ces langages qui restent des langages de "script", pas pou faire des grosses applis.
Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Les templates en C++ c'est un peu affreux, j'en convient.
En Java le compilo remplace partout la référence au type par object avec un cast. Il n'y a donc pas de génération spécifique.
En C#, le typage est conservé dans le bytecode, le code spécifique est généré à la volée, tout en conservant toutes les informations sur la "généricité".
En C# non seulement c'est un gain non négligeable en terme de fiabilité (puiqu'il permet d'éviter de nombreux casts tout en permettant au compilo d'effectuer des vérifications), mais c'est aussi un gain de temps à l'exécution (une pile d'entier est allouée sur la pile, alors qu'une pile d'objet ne l'est pas).
Enfin pour te montrer que le typage est si "important", il a constitué pour Java et C# une des principales améliorations et atouts de leur évolution, parcque réclamé par les dev.
(cf le lien sur la page de Bruce Eckel que j'ai donné)
J'ai du mal à comprendre son point de vue. Je vois pas pouquoi il posse 2 notions qui sont complémentaires. Tout est bon pour améliorer la qualité du code, que ce soit le typage statique et fort, les tests unitaires, les contrats, etc.
Le but étant d'automatiser le maximum de tâche (une machine se trompe rarement), c'est pourquoi sont apparus les Garbage collector entre autre.
Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Arf effectivement si tu poses bien tes contrats tu vas résoudre pas mal de problème.
Mais on en revient toujours au même point : c'est l'humain qui rédige les contrats, et à moins d'avoir des outils comme le langage B pour formaliser tout ca et s'assurer de la validifé des contrats, il restera toujours une marge d'erreur.
Si tu rédiges des contrats en Python, ils te péteront à la tronche à l'exécution. J'espère que ca ne sera pas chez le client le jour où un contrat aura été mal rédigé.
Enfin tu me fais sourir quand même : tu veux pas écrire le type de tes variables par "gain de temps", et tu consommes une bonne partie de celui-ci à la rédaction des contrats. Cette reflexion sur les contrats doit en plus t'amner bien souvent à "réfléchir" sur le type à l'exécution de tes variables.
De plus préciser le type d'un paramètre par exemple fait parti de la signature d'une méthode, si tu mets plusieurs méthodes dans un même "conteneur", t'as une interface, qui constitue déjà une sorte de contrat, qui lui a l'avantage d'être checkable à la compilation, et donc qui sera vérifier par un outil avant d'aller péter le cas échéant chez le client.
C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Ben dans le cas d'un langage typé fort et statiquement, si c'est une des finalités. Si pour toi contribuer à améliorer la qualité du code produit n'est pas dans les objectifs d'un compilo...
C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Je te ferais remarquer que gcj tourne sur un peu plus d'architecture, et il est tout à fait capable de compiler "à la volée" (JIT) le code intermédiaire : tu ne perds pas la portabilié. Et ayant généré un exécutable pour la machine cible, c'est celui-ci qui sera de nouveau exécuté. Non là tu ne perds pas la portabilité.
En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.
Genre le refactoring tu trouves pas ca pratique ? En python t'as jamais envie d'extraire une interface d'une classe ? Ah ben non désolé y'a même pas la notion d'interface :) T'as jamais besoin de renommer une variable ? Et là tu vois un parfait exemple d'utilité du refactoring : tu modifies le type d'une variable, le refactoring applique les modifs partout, et bien le compilo te gueuleras dessus si jamais une erreur de typage a été introduite quelque part.
EN Python t'as intérêt de te rappeler quelles sont les conséquences de tes changements.
Si pour toi la complétion automatique de méthode n'est pas un gain de productivité je ne cherche plus à comprendre... Le typage fort instaurant de plus de nombreux tests automatique, il permet d'obtenir un peu plus de fiabilité, au final de bugs en moins et donc de la productivité en plus.
Enfin franchement j'ai du mal à te suivre : tu semble "fan" des contrats (j'abonde dans ton sens), mais tu refuses le typage statique, alors que les 2 notions cherchent le même but et sont complémentaire : assurer une certaine qualité du code. Enfin tu sembles préférer faire confiance exclusivement à ta rédaction des contrats plutôt que de confier des vérifications de base à un outil dont c'est en parti le boulot.
[^] # 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é à 1.
Pour le prototypage je reconnais qu'un langage sans typage peut être "pratique". Mais ca reste du prototypage. Ca rejoint l'idée première de ces langages qui restent des langages de "script", pas pou faire des grosses applis.
Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Les templates en C++ c'est un peu affreux, j'en convient.
En Java le compilo remplace partout la référence au type par object avec un cast. Il n'y a donc pas de génération spécifique.
En C#, le typage est conservé dans le bytecode, le code spécifique est généré à la volée, tout en conservant toutes les informations sur la "généricité".
En C# non seulement c'est un gain non négligeable en terme de fiabilité (puiqu'il permet d'éviter de nombreux casts tout en permettant au compilo d'effectuer des vérifications), mais c'est aussi un gain de temps à l'exécution (une pile d'entier est allouée sur la pile, alors qu'une pile d'objet ne l'est pas).
Enfin pour te montrer que le typage est si "important", il a constitué pour Java et C# une des principales améliorations et atouts de leur évolution, parcque réclamé par les dev.
(cf le lien sur la page de Bruce Eckel que j'ai donné)
J'ai du mal à comprendre son point de vue. Je vois pas pouquoi il posse 2 notions qui sont complémentaires. Tout est bon pour améliorer la qualité du code, que ce soit le typage statique et fort, les tests unitaires, les contrats, etc.
Le but étant d'automatiser le maximum de tâche (une machine se trompe rarement), c'est pourquoi sont apparus les Garbage collector entre autre.
Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Arf effectivement si tu poses bien tes contrats tu vas résoudre pas mal de problème.
Mais on en revient toujours au même point : c'est l'humain qui rédige les contrats, et à moins d'avoir des outils comme le langage B pour formaliser tout ca et s'assurer de la validifé des contrats, il restera toujours une marge d'erreur.
Si tu rédiges des contrats en Python, ils te péteront à la tronche à l'exécution. J'espère que ca ne sera pas chez le client le jour où un contrat aura été mal rédigé.
Enfin tu me fais sourir quand même : tu veux pas écrire le type de tes variables par "gain de temps", et tu consommes une bonne partie de celui-ci à la rédaction des contrats. Cette reflexion sur les contrats doit en plus t'amner bien souvent à "réfléchir" sur le type à l'exécution de tes variables.
De plus préciser le type d'un paramètre par exemple fait parti de la signature d'une méthode, si tu mets plusieurs méthodes dans un même "conteneur", t'as une interface, qui constitue déjà une sorte de contrat, qui lui a l'avantage d'être checkable à la compilation, et donc qui sera vérifier par un outil avant d'aller péter le cas échéant chez le client.
C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Ben dans le cas d'un langage typé fort et statiquement, si c'est une des finalités. Si pour toi contribuer à améliorer la qualité du code produit n'est pas dans les objectifs d'un compilo...
C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Je te ferais remarquer que gcj tourne sur un peu plus d'architecture, et il est tout à fait capable de compiler "à la volée" (JIT) le code intermédiaire : tu ne perds pas la portabilié. Et ayant généré un exécutable pour la machine cible, c'est celui-ci qui sera de nouveau exécuté. Non là tu ne perds pas la portabilité.
En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.
Genre le refactoring tu trouves pas ca pratique ? En python t'as jamais envie d'extraire une interface d'une classe ? Ah ben non désolé y'a même pas la notion d'interface :) T'as jamais besoin de renommer une variable ? Et là tu vois un parfait exemple d'utilité du refactoring : tu modifies le type d'une variable, le refactoring applique les modifs partout, et bien le compilo te gueuleras dessus si jamais une erreur de typage a été introduite quelque part.
EN Python t'as intérêt de te rappeler quelles sont les conséquences de tes changements.
Si pour toi la complétion automatique de méthode n'est pas un gain de productivité je ne cherche plus à comprendre... Le typage fort instaurant de plus de nombreux tests automatique, il permet d'obtenir un peu plus de fiabilité, au final de bugs en moins et donc de la productivité en plus.
Enfin franchement j'ai du mal à te suivre : tu semble "fan" des contrats (j'abonde dans ton sens), mais tu refuses le typage statique, alors que les 2 notions cherchent le même but et sont complémentaire : assurer une certaine qualité du code. Enfin tu sembles préférer faire confiance exclusivement à ta rédaction des contrats plutôt que de confier des vérifications de base à un outil dont c'est en parti le boulot.