Certes, ce que tu dis est vrai ...
mais ce n'est que les différences entre 2 types de langage ...
il y a vraiment 2 écoles ...
(moi pour eviter ce genre de problème en aval, j'ai tendance à mettre des assert, ça evite d'avoir des surprises plus loin (mais c au runtime : on est d'accord))
> le typage explicite et uniforme montre sa supériorité.
Comme disait qqu'un dans le thread ... ça permet surtout à un programmeur de ne pas faire des erreurs bêtes (sinon ça compile pas). Ce qui permet de prendre des devs moins "experimentés" (dans le sens, suffit de lire le message d'erreur du compilateur, puis de corriger)
On est d'accord, ça donne un certain gage de "qualité" ... le dev est corrigé en amont !
Mais, vraiment, pour faire du csharp(~=java) à longueur de journée, ça apporte aussi énormément de bruit, et d'obligations (déclaration de type, castage toutes les 2 lignes) .... pour des choses souvent simples/triviales. Ca a aussi tendance à augmenter énormément le nb de lignes (5 à 10x) pour un même algo. ça prends du temps !
J'aurai tendance à penser qu'on est en permanence en train de lutter avec ces obligations et ces syntaxes, ce qui empêche réellement de se concentrer sur l'algorithme qu'on est en train d'implémenter. Le cerveau est en permanence agacé par ce bruit. (oui, les habitudes et un bon ide aident énormément)
En python, tu as cette liberté qui est énorme, le cerveau est totallement libre pour se concentrer sur l'essentiel : l'algorithme à implémenter.
Après c'est des conventions de codage, et de documentation. On doit plus faire confiance à l'humain, au dev.
Certes en statiquement typé, tu peux aussi faire du "dynamique", travailler avec des "objects" et caster à tout bout de champs. Mais dès que t'as besoin de faire de l'introspection, de créer des class dynamiquement, et toutes ces genres de choses : ça rentre très vite dans du code complexe, voire très tordu. (genre appelé dynamiquement une méthode d'une instance de classe que tu ne connais pas).
Maintenant dans la vraie vie pythonesque, j'utilise énormément de libs que j'ai pas codé et même pas vu le code .... et je peux te dire que c'est très très rare de tomber sur le genre d'erreur que tu décris (même si c'est techniquement possible)
Tu tombes bien plus souvent sur des "null object reference" que sur des erreurs de type ... et ça j'ai aussi avec des assemblies externes que je n'ai pas codé, en csharp (et dont je ne peux pas voir le code, en passant ;-)
L'avantage de python : c'est la vitesse de développement, bien supérieure aux langages statiquement typé.
Mais au boulot, quand je dois concevoir un "algo complexe" (embriquement d'algo), je le fais vite fait en python pour voir si ça roule, et je le traduis après en cs. C'est bien plus rapide que le faire en CS. Quand je dis complexe : c pas qqchose de pondable en "one shot", donc ça necessite qques tatonnements, et avec les languages compilés tu perds déjà 50% du temps à compiler avant de tester rellement l'algo ... et 30% du temps à batailler avec les syntaxes/obligations.
(bon quand ça compile, ça me laisse le temps de surfer ;-)
[^] # Re: Excellente nouvelle
Posté par manatlan (site web personnel) . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 3.
mais ce n'est que les différences entre 2 types de langage ...
il y a vraiment 2 écoles ...
(moi pour eviter ce genre de problème en aval, j'ai tendance à mettre des assert, ça evite d'avoir des surprises plus loin (mais c au runtime : on est d'accord))
> le typage explicite et uniforme montre sa supériorité.
Comme disait qqu'un dans le thread ... ça permet surtout à un programmeur de ne pas faire des erreurs bêtes (sinon ça compile pas). Ce qui permet de prendre des devs moins "experimentés" (dans le sens, suffit de lire le message d'erreur du compilateur, puis de corriger)
On est d'accord, ça donne un certain gage de "qualité" ... le dev est corrigé en amont !
Mais, vraiment, pour faire du csharp(~=java) à longueur de journée, ça apporte aussi énormément de bruit, et d'obligations (déclaration de type, castage toutes les 2 lignes) .... pour des choses souvent simples/triviales. Ca a aussi tendance à augmenter énormément le nb de lignes (5 à 10x) pour un même algo. ça prends du temps !
J'aurai tendance à penser qu'on est en permanence en train de lutter avec ces obligations et ces syntaxes, ce qui empêche réellement de se concentrer sur l'algorithme qu'on est en train d'implémenter. Le cerveau est en permanence agacé par ce bruit. (oui, les habitudes et un bon ide aident énormément)
En python, tu as cette liberté qui est énorme, le cerveau est totallement libre pour se concentrer sur l'essentiel : l'algorithme à implémenter.
Après c'est des conventions de codage, et de documentation. On doit plus faire confiance à l'humain, au dev.
Certes en statiquement typé, tu peux aussi faire du "dynamique", travailler avec des "objects" et caster à tout bout de champs. Mais dès que t'as besoin de faire de l'introspection, de créer des class dynamiquement, et toutes ces genres de choses : ça rentre très vite dans du code complexe, voire très tordu. (genre appelé dynamiquement une méthode d'une instance de classe que tu ne connais pas).
Maintenant dans la vraie vie pythonesque, j'utilise énormément de libs que j'ai pas codé et même pas vu le code .... et je peux te dire que c'est très très rare de tomber sur le genre d'erreur que tu décris (même si c'est techniquement possible)
Tu tombes bien plus souvent sur des "null object reference" que sur des erreurs de type ... et ça j'ai aussi avec des assemblies externes que je n'ai pas codé, en csharp (et dont je ne peux pas voir le code, en passant ;-)
L'avantage de python : c'est la vitesse de développement, bien supérieure aux langages statiquement typé.
Mais au boulot, quand je dois concevoir un "algo complexe" (embriquement d'algo), je le fais vite fait en python pour voir si ça roule, et je le traduis après en cs. C'est bien plus rapide que le faire en CS. Quand je dis complexe : c pas qqchose de pondable en "one shot", donc ça necessite qques tatonnements, et avec les languages compilés tu perds déjà 50% du temps à compiler avant de tester rellement l'algo ... et 30% du temps à batailler avec les syntaxes/obligations.
(bon quand ça compile, ça me laisse le temps de surfer ;-)