totof01 writes:
La facilité d'implémentation. Une "méthode" n'est pas autre chose q u'une
fonction, et il suffit de replacer o.m(...) par m(o,...). Rien de
subtil, mais pour les développeurs du langage c'est "plus cohérent".
-- Alain.
totof01 <cdesques...@ifrance.com> writes:
La facilité d'implémentation. Une "méthode" n'est pas autre chose q u'une
fonction, et il suffit de replacer o.m(...) par m(o,...). Rien de
subtil, mais pour les développeurs du langage c'est "plus cohérent".
-- Alain.
totof01 writes:
La facilité d'implémentation. Une "méthode" n'est pas autre chose q u'une
fonction, et il suffit de replacer o.m(...) par m(o,...). Rien de
subtil, mais pour les développeurs du langage c'est "plus cohérent".
-- Alain.
On 14 mai, 11:34, Alain Ketterlin wrote:totof01 writes:La facilité d'implémentation. Une "méthode" n'est pas aut re chose qu'une
fonction, et il suffit de replacer o.m(...) par m(o,...). Rien de
subtil, mais pour les développeurs du langage c'est "plus cohé rent".
Tu perds par contre en lisibilité : cette façon de procéde r te permet
de déclarer une fonction en plein millieu d'une classe, cette foncti on
n'ayant rien à voir avec cette classe. On perd ainsi l'un des
avantages qu'est censé avoir Python qui est la lisbilité du cod e.
On 14 mai, 11:34, Alain Ketterlin <al...@dpt-info.u-strasbg.fr> wrote:
totof01 <cdesques...@ifrance.com> writes:
La facilité d'implémentation. Une "méthode" n'est pas aut re chose qu'une
fonction, et il suffit de replacer o.m(...) par m(o,...). Rien de
subtil, mais pour les développeurs du langage c'est "plus cohé rent".
Tu perds par contre en lisibilité : cette façon de procéde r te permet
de déclarer une fonction en plein millieu d'une classe, cette foncti on
n'ayant rien à voir avec cette classe. On perd ainsi l'un des
avantages qu'est censé avoir Python qui est la lisbilité du cod e.
On 14 mai, 11:34, Alain Ketterlin wrote:totof01 writes:La facilité d'implémentation. Une "méthode" n'est pas aut re chose qu'une
fonction, et il suffit de replacer o.m(...) par m(o,...). Rien de
subtil, mais pour les développeurs du langage c'est "plus cohé rent".
Tu perds par contre en lisibilité : cette façon de procéde r te permet
de déclarer une fonction en plein millieu d'une classe, cette foncti on
n'ayant rien à voir avec cette classe. On perd ainsi l'un des
avantages qu'est censé avoir Python qui est la lisbilité du cod e.
On 14 mai, 11:34, Alain Ketterlin wrote:totof01 writes:La facilité d'implémentation. Une "méthode" n'est pas autre chose qu'une
fonction, et il suffit de replacer o.m(...) par m(o,...). Rien de
subtil, mais pour les développeurs du langage c'est "plus cohérent".
Tu perds par contre en lisibilité : cette façon de procéder te permet
de déclarer une fonction en plein millieu d'une classe, cette fonction
n'ayant rien à voir avec cette classe. On perd ainsi l'un des
avantages qu'est censé avoir Python qui est la lisbilité du code.
On 14 mai, 11:34, Alain Ketterlin <al...@dpt-info.u-strasbg.fr> wrote:
totof01 <cdesques...@ifrance.com> writes:
La facilité d'implémentation. Une "méthode" n'est pas autre chose qu'une
fonction, et il suffit de replacer o.m(...) par m(o,...). Rien de
subtil, mais pour les développeurs du langage c'est "plus cohérent".
Tu perds par contre en lisibilité : cette façon de procéder te permet
de déclarer une fonction en plein millieu d'une classe, cette fonction
n'ayant rien à voir avec cette classe. On perd ainsi l'un des
avantages qu'est censé avoir Python qui est la lisbilité du code.
On 14 mai, 11:34, Alain Ketterlin wrote:totof01 writes:La facilité d'implémentation. Une "méthode" n'est pas autre chose qu'une
fonction, et il suffit de replacer o.m(...) par m(o,...). Rien de
subtil, mais pour les développeurs du langage c'est "plus cohérent".
Tu perds par contre en lisibilité : cette façon de procéder te permet
de déclarer une fonction en plein millieu d'une classe, cette fonction
n'ayant rien à voir avec cette classe. On perd ainsi l'un des
avantages qu'est censé avoir Python qui est la lisbilité du code.
C'est le piège, tu considère ne pas avoir à "réaliser de contrôle",
considérant qu'en sachant le type ça te suffit. Hors le type ne signifie
absolument pas que la donnée est celle que tu attends. Par exemple si tu
attends un age, si j'envoie 2035, c'est bien un nombre mais ça n'est
sûrement pas une donnée valide. Donc dans tous les cas il faudra
vérifier d'avantage que le type pour être vraiment rigoureux.
Par exemple
fonction imc(nombre poids, nombre taille)
Si tu inverse les arguments lors d'un refactoring, le compilateur ne
détectera rien, y a pas de miracle.
Après, je suis d'accord que ça évitera certaines erreurs, il n'y a pas
de doute la dessus. Mais il n'y a pas de raison de se focaliser
particulièrement sur ces erreurs plus que d'autres.
Avec des outils
comme pylint on détecte également énormément d'erreurs, mais je n'irai
pas choisir un langage pour ça, ni accuser un langage de ne pas l'avoir.
Globalement ce n'est pas du tout ce que j'ai vérifié quand j'ai réécris
toutes mes applis java en python. J'ai considérablement gagné en clarté
de code (diminué au moins de moitié en quantité) et en temps de
maintenance.
C'est le piège, tu considère ne pas avoir à "réaliser de contrôle",
considérant qu'en sachant le type ça te suffit. Hors le type ne signifie
absolument pas que la donnée est celle que tu attends. Par exemple si tu
attends un age, si j'envoie 2035, c'est bien un nombre mais ça n'est
sûrement pas une donnée valide. Donc dans tous les cas il faudra
vérifier d'avantage que le type pour être vraiment rigoureux.
Par exemple
fonction imc(nombre poids, nombre taille)
Si tu inverse les arguments lors d'un refactoring, le compilateur ne
détectera rien, y a pas de miracle.
Après, je suis d'accord que ça évitera certaines erreurs, il n'y a pas
de doute la dessus. Mais il n'y a pas de raison de se focaliser
particulièrement sur ces erreurs plus que d'autres.
Avec des outils
comme pylint on détecte également énormément d'erreurs, mais je n'irai
pas choisir un langage pour ça, ni accuser un langage de ne pas l'avoir.
Globalement ce n'est pas du tout ce que j'ai vérifié quand j'ai réécris
toutes mes applis java en python. J'ai considérablement gagné en clarté
de code (diminué au moins de moitié en quantité) et en temps de
maintenance.
C'est le piège, tu considère ne pas avoir à "réaliser de contrôle",
considérant qu'en sachant le type ça te suffit. Hors le type ne signifie
absolument pas que la donnée est celle que tu attends. Par exemple si tu
attends un age, si j'envoie 2035, c'est bien un nombre mais ça n'est
sûrement pas une donnée valide. Donc dans tous les cas il faudra
vérifier d'avantage que le type pour être vraiment rigoureux.
Par exemple
fonction imc(nombre poids, nombre taille)
Si tu inverse les arguments lors d'un refactoring, le compilateur ne
détectera rien, y a pas de miracle.
Après, je suis d'accord que ça évitera certaines erreurs, il n'y a pas
de doute la dessus. Mais il n'y a pas de raison de se focaliser
particulièrement sur ces erreurs plus que d'autres.
Avec des outils
comme pylint on détecte également énormément d'erreurs, mais je n'irai
pas choisir un langage pour ça, ni accuser un langage de ne pas l'avoir.
Globalement ce n'est pas du tout ce que j'ai vérifié quand j'ai réécris
toutes mes applis java en python. J'ai considérablement gagné en clarté
de code (diminué au moins de moitié en quantité) et en temps de
maintenance.
Le 16/05/2011 11:37, William a écrit :C'est le piège, tu considère ne pas avoir à "réaliser de contrôle",
considérant qu'en sachant le type ça te suffit. Hors le type ne signifie
absolument pas que la donnée est celle que tu attends. Par exemple si tu
attends un age, si j'envoie 2035, c'est bien un nombre mais ça n'est
sûrement pas une donnée valide. Donc dans tous les cas il faudra
vérifier d'avantage que le type pour être vraiment rigoureux.
Je suis d'accord avec toi, mais en Java, je n'ai justement pas à
m'occuper du typage, uniquement de la donnée.
Avec ton exemple, en Python, j'aurais l'obligation de d'abord tester si
l'argument est un nombre (sous peine que « < » plante lamentablement)
puis de vérifier s'il est bien inférieur à 150.
En Java, je sais que « < » fonctionnera à coup sûr, étant donné que
l'application a compilé. J'ai donc éliminé 50% des tests nécessaires à
une application robuste.
D'autant plus que pour moi « 0 < age < 150 » est une règle de gestion
métier, alors que « age instanceof Number » est une règle de
développement. Pour moi, il est normal de retrouver la 1ère dans le code
(et même dans la spec), pas la 2nde.
Par exemple
fonction imc(nombre poids, nombre taille)
Si tu inverse les arguments lors d'un refactoring, le compilateur ne
détectera rien, y a pas de miracle.
Là je suis d'accord avec toi.
Mais si je vais dans cette direction
fonction imc(Poids poids, Taille taille)
Java détecterait l'inversion des paramètres, pas Python.
Après, je suis d'accord que ça évitera certaines erreurs, il n'y a pas
de doute la dessus. Mais il n'y a pas de raison de se focaliser
particulièrement sur ces erreurs plus que d'autres.
Pour moi, ce type d'erreur n'est absolument pas anodin.
En méthode Agile, le concept est de refactorer le code à chaque
itération, les méthodes et les API évoluent constamment, quasiment tous
les jours.
S'il y a bien une source d'erreur qu'il faut absolument éviter avec
cette pratique, c'est bien celle-là.
Avec des outils
comme pylint on détecte également énormément d'erreurs, mais je n'irai
pas choisir un langage pour ça, ni accuser un langage de ne pas l'avoir.
Je n'accuse pas Python de ne pas l'avoir, mais j'essaie juste de
comprendre comment font les « vrais » développeurs Python pour éviter ce
genre de problèmes extrèmement courant sur les grosses applications avec
des équipes de plusieurs dizaines de personnes.
Pour avoir tenter, ça a été une catastrophe royale et certains membres
de l'équipe étaient même dédiés à plein temps à remettre d'aplomb les
appels des API après une refacto. Le temps (perdu) de débug a été
collossal comparé à un dev équivalent en Java.
Globalement ce n'est pas du tout ce que j'ai vérifié quand j'ai réécris
toutes mes applis java en python. J'ai considérablement gagné en clarté
de code (diminué au moins de moitié en quantité) et en temps de
maintenance.
Alors tu seras peut-être la bonne personne pour m'éclairer sur la
méthode à appliquer.
Même si je reste sceptique que le portage soit aussi robuste et fiable,
en ayant obligatoirement perdu tout contrôle de typage lors du portage
(sauf à avoir considérablement uglyfié le code…). Surtout pour de la
reprise de code future.
Je ne demande qu'à comprendre =)
Le 16/05/2011 11:37, William a écrit :
C'est le piège, tu considère ne pas avoir à "réaliser de contrôle",
considérant qu'en sachant le type ça te suffit. Hors le type ne signifie
absolument pas que la donnée est celle que tu attends. Par exemple si tu
attends un age, si j'envoie 2035, c'est bien un nombre mais ça n'est
sûrement pas une donnée valide. Donc dans tous les cas il faudra
vérifier d'avantage que le type pour être vraiment rigoureux.
Je suis d'accord avec toi, mais en Java, je n'ai justement pas à
m'occuper du typage, uniquement de la donnée.
Avec ton exemple, en Python, j'aurais l'obligation de d'abord tester si
l'argument est un nombre (sous peine que « < » plante lamentablement)
puis de vérifier s'il est bien inférieur à 150.
En Java, je sais que « < » fonctionnera à coup sûr, étant donné que
l'application a compilé. J'ai donc éliminé 50% des tests nécessaires à
une application robuste.
D'autant plus que pour moi « 0 < age < 150 » est une règle de gestion
métier, alors que « age instanceof Number » est une règle de
développement. Pour moi, il est normal de retrouver la 1ère dans le code
(et même dans la spec), pas la 2nde.
Par exemple
fonction imc(nombre poids, nombre taille)
Si tu inverse les arguments lors d'un refactoring, le compilateur ne
détectera rien, y a pas de miracle.
Là je suis d'accord avec toi.
Mais si je vais dans cette direction
fonction imc(Poids poids, Taille taille)
Java détecterait l'inversion des paramètres, pas Python.
Après, je suis d'accord que ça évitera certaines erreurs, il n'y a pas
de doute la dessus. Mais il n'y a pas de raison de se focaliser
particulièrement sur ces erreurs plus que d'autres.
Pour moi, ce type d'erreur n'est absolument pas anodin.
En méthode Agile, le concept est de refactorer le code à chaque
itération, les méthodes et les API évoluent constamment, quasiment tous
les jours.
S'il y a bien une source d'erreur qu'il faut absolument éviter avec
cette pratique, c'est bien celle-là.
Avec des outils
comme pylint on détecte également énormément d'erreurs, mais je n'irai
pas choisir un langage pour ça, ni accuser un langage de ne pas l'avoir.
Je n'accuse pas Python de ne pas l'avoir, mais j'essaie juste de
comprendre comment font les « vrais » développeurs Python pour éviter ce
genre de problèmes extrèmement courant sur les grosses applications avec
des équipes de plusieurs dizaines de personnes.
Pour avoir tenter, ça a été une catastrophe royale et certains membres
de l'équipe étaient même dédiés à plein temps à remettre d'aplomb les
appels des API après une refacto. Le temps (perdu) de débug a été
collossal comparé à un dev équivalent en Java.
Globalement ce n'est pas du tout ce que j'ai vérifié quand j'ai réécris
toutes mes applis java en python. J'ai considérablement gagné en clarté
de code (diminué au moins de moitié en quantité) et en temps de
maintenance.
Alors tu seras peut-être la bonne personne pour m'éclairer sur la
méthode à appliquer.
Même si je reste sceptique que le portage soit aussi robuste et fiable,
en ayant obligatoirement perdu tout contrôle de typage lors du portage
(sauf à avoir considérablement uglyfié le code…). Surtout pour de la
reprise de code future.
Je ne demande qu'à comprendre =)
Le 16/05/2011 11:37, William a écrit :C'est le piège, tu considère ne pas avoir à "réaliser de contrôle",
considérant qu'en sachant le type ça te suffit. Hors le type ne signifie
absolument pas que la donnée est celle que tu attends. Par exemple si tu
attends un age, si j'envoie 2035, c'est bien un nombre mais ça n'est
sûrement pas une donnée valide. Donc dans tous les cas il faudra
vérifier d'avantage que le type pour être vraiment rigoureux.
Je suis d'accord avec toi, mais en Java, je n'ai justement pas à
m'occuper du typage, uniquement de la donnée.
Avec ton exemple, en Python, j'aurais l'obligation de d'abord tester si
l'argument est un nombre (sous peine que « < » plante lamentablement)
puis de vérifier s'il est bien inférieur à 150.
En Java, je sais que « < » fonctionnera à coup sûr, étant donné que
l'application a compilé. J'ai donc éliminé 50% des tests nécessaires à
une application robuste.
D'autant plus que pour moi « 0 < age < 150 » est une règle de gestion
métier, alors que « age instanceof Number » est une règle de
développement. Pour moi, il est normal de retrouver la 1ère dans le code
(et même dans la spec), pas la 2nde.
Par exemple
fonction imc(nombre poids, nombre taille)
Si tu inverse les arguments lors d'un refactoring, le compilateur ne
détectera rien, y a pas de miracle.
Là je suis d'accord avec toi.
Mais si je vais dans cette direction
fonction imc(Poids poids, Taille taille)
Java détecterait l'inversion des paramètres, pas Python.
Après, je suis d'accord que ça évitera certaines erreurs, il n'y a pas
de doute la dessus. Mais il n'y a pas de raison de se focaliser
particulièrement sur ces erreurs plus que d'autres.
Pour moi, ce type d'erreur n'est absolument pas anodin.
En méthode Agile, le concept est de refactorer le code à chaque
itération, les méthodes et les API évoluent constamment, quasiment tous
les jours.
S'il y a bien une source d'erreur qu'il faut absolument éviter avec
cette pratique, c'est bien celle-là.
Avec des outils
comme pylint on détecte également énormément d'erreurs, mais je n'irai
pas choisir un langage pour ça, ni accuser un langage de ne pas l'avoir.
Je n'accuse pas Python de ne pas l'avoir, mais j'essaie juste de
comprendre comment font les « vrais » développeurs Python pour éviter ce
genre de problèmes extrèmement courant sur les grosses applications avec
des équipes de plusieurs dizaines de personnes.
Pour avoir tenter, ça a été une catastrophe royale et certains membres
de l'équipe étaient même dédiés à plein temps à remettre d'aplomb les
appels des API après une refacto. Le temps (perdu) de débug a été
collossal comparé à un dev équivalent en Java.
Globalement ce n'est pas du tout ce que j'ai vérifié quand j'ai réécris
toutes mes applis java en python. J'ai considérablement gagné en clarté
de code (diminué au moins de moitié en quantité) et en temps de
maintenance.
Alors tu seras peut-être la bonne personne pour m'éclairer sur la
méthode à appliquer.
Même si je reste sceptique que le portage soit aussi robuste et fiable,
en ayant obligatoirement perdu tout contrôle de typage lors du portage
(sauf à avoir considérablement uglyfié le code…). Surtout pour de la
reprise de code future.
Je ne demande qu'à comprendre =)
Pourquoi pas la 2nde, ça me semble au contraire plus important et plus
fréquent comme erreur vu que ça englobe aussi les erreurs utilisateurs.
Ce que je veux dire s'est que soit on teste soit on ne teste pas. Si on
ne teste que le type ça ne suffit pas et si on teste la valeur on teste
le type en même temps. Dans le cas d'un test unitaire, peu importe que
ça lève une exception à cause du type ou de la valeur.
En revanche, utiliser un objet Poids là où un simple entier suffirait va
rendre ton code 5x plus long...
Effectivement, si tu refactorise tous les jours ça sera pratique c'est
incontestable. Mais ça ne remplacera pas les tests unitaires qui eux
devraient couvrir aussi ces erreurs.
Au contraire, le code est beaucoup plus clair, c'est essentiellement
pour ça je pense que les applis sont plus fiables et plus faciles
à maintenir.
Il y a une étude qui a montré que le nombre de bug était
proportionnel au nombre de lignes quelque soit le langage. C'est bête
mais je le vérifie. Je viens de compter (avec sloccount) une appli que
j'ai réécrite quasiment à l'identique il n'y a pas longtemps, elle est
exactement 2x plus petite qu'en java.
Ce sont deux
optiques différentes. Je comprend que dans ton cas tu te dis qu'étant
donné qu'il y a énormément de développeurs ça ne sera jamais simple,
donc autant verrouiller, mais ça reste à prouver.
Comment expliques-tu que les applis en Java sont réputés si lentes alors
que le langage java lui-même est beaucoup plus rapide que python, de
très loin (plus pour très longtemps) ?
Pourquoi pas la 2nde, ça me semble au contraire plus important et plus
fréquent comme erreur vu que ça englobe aussi les erreurs utilisateurs.
Ce que je veux dire s'est que soit on teste soit on ne teste pas. Si on
ne teste que le type ça ne suffit pas et si on teste la valeur on teste
le type en même temps. Dans le cas d'un test unitaire, peu importe que
ça lève une exception à cause du type ou de la valeur.
En revanche, utiliser un objet Poids là où un simple entier suffirait va
rendre ton code 5x plus long...
Effectivement, si tu refactorise tous les jours ça sera pratique c'est
incontestable. Mais ça ne remplacera pas les tests unitaires qui eux
devraient couvrir aussi ces erreurs.
Au contraire, le code est beaucoup plus clair, c'est essentiellement
pour ça je pense que les applis sont plus fiables et plus faciles
à maintenir.
Il y a une étude qui a montré que le nombre de bug était
proportionnel au nombre de lignes quelque soit le langage. C'est bête
mais je le vérifie. Je viens de compter (avec sloccount) une appli que
j'ai réécrite quasiment à l'identique il n'y a pas longtemps, elle est
exactement 2x plus petite qu'en java.
Ce sont deux
optiques différentes. Je comprend que dans ton cas tu te dis qu'étant
donné qu'il y a énormément de développeurs ça ne sera jamais simple,
donc autant verrouiller, mais ça reste à prouver.
Comment expliques-tu que les applis en Java sont réputés si lentes alors
que le langage java lui-même est beaucoup plus rapide que python, de
très loin (plus pour très longtemps) ?
Pourquoi pas la 2nde, ça me semble au contraire plus important et plus
fréquent comme erreur vu que ça englobe aussi les erreurs utilisateurs.
Ce que je veux dire s'est que soit on teste soit on ne teste pas. Si on
ne teste que le type ça ne suffit pas et si on teste la valeur on teste
le type en même temps. Dans le cas d'un test unitaire, peu importe que
ça lève une exception à cause du type ou de la valeur.
En revanche, utiliser un objet Poids là où un simple entier suffirait va
rendre ton code 5x plus long...
Effectivement, si tu refactorise tous les jours ça sera pratique c'est
incontestable. Mais ça ne remplacera pas les tests unitaires qui eux
devraient couvrir aussi ces erreurs.
Au contraire, le code est beaucoup plus clair, c'est essentiellement
pour ça je pense que les applis sont plus fiables et plus faciles
à maintenir.
Il y a une étude qui a montré que le nombre de bug était
proportionnel au nombre de lignes quelque soit le langage. C'est bête
mais je le vérifie. Je viens de compter (avec sloccount) une appli que
j'ai réécrite quasiment à l'identique il n'y a pas longtemps, elle est
exactement 2x plus petite qu'en java.
Ce sont deux
optiques différentes. Je comprend que dans ton cas tu te dis qu'étant
donné qu'il y a énormément de développeurs ça ne sera jamais simple,
donc autant verrouiller, mais ça reste à prouver.
Comment expliques-tu que les applis en Java sont réputés si lentes alors
que le langage java lui-même est beaucoup plus rapide que python, de
très loin (plus pour très longtemps) ?
Le 20/05/2011 23:09, William a écrit :Pourquoi pas la 2nde, ça me semble au contraire plus important et plus
fréquent comme erreur vu que ça englobe aussi les erreurs utilisateurs.
Oui et non.
Si on s'en tient aux erreurs utilisateurs, la couche d'accès aux données
s'occupera de filtrer les valeurs aberrantes et renverra de jolis
messages d'erreur. De ce côté là, Python ou Java, c'est équivalent.
Le problème que j'ai rencontré a surtout été côté développement, avec
des développeurs qui se retrouvaient en face d'API dont ils n'avaient
aucune idée de quel type d'argument passer.
Je pense que l'exemple du « X509Certificate.setIssuer(issuer) » est un
très bon exemple. En Python, les développeurs de mon gros projet ont mis
une bonne heure à comprendre que l'issuer devait être un X509Name et non
un X509Certificate, et surtout que cette découverte n'a été possible que
par analyse du code de la librairie X509, la doc se contentant d'un
laminaire « set the issuer of the certificate ».
Ce que je veux dire s'est que soit on teste soit on ne teste pas. Si on
ne teste que le type ça ne suffit pas et si on teste la valeur on teste
le type en même temps. Dans le cas d'un test unitaire, peu importe que
ça lève une exception à cause du type ou de la valeur.
D'accord avec toi.
Et donc je préfère n'avoir que la partie data à vérifier, déléguant la
partie typage au compilateur. Il fera cela bien mieux que moi, avec
l'héritage et l'inférence de type en prime !
En revanche, utiliser un objet Poids là où un simple entier suffirait va
rendre ton code 5x plus long...
C'était juste un exemple =)
Le soucis en Python est que tout argument est permutable sans erreur et
la permutation ne sera visible qu'au runtime.
Effectivement, si tu refactorise tous les jours ça sera pratique c'est
incontestable. Mais ça ne remplacera pas les tests unitaires qui eux
devraient couvrir aussi ces erreurs.
Les méthodes Agile « imposent » de refactorer en continu.
Tout le process de dev est basé sur des itérations qui améliore au fur
et à mesure les fonctionnalités.
Donc oui, je refactore TRÈS souvent !
Et pour les tests U, 85% de couverture de code obligatoire !
Au contraire, le code est beaucoup plus clair, c'est essentiellement
pour ça je pense que les applis sont plus fiables et plus faciles
à maintenir.
Clair et concis, certes, Python est largement devant Java.
Mais le problème est toujours le même pour moi. Le code FINAL est clair,
concis et robuste grâce à des tests U efficaces, mais :
— les tests U sont généralisables à tout langage et tout projet
— le code INTERMEDIAIRE (en cours de dev) a demandé des efforts
surhumains aux développeurs pour en arriver à la version fiable.
Si je reprend l'exemple des certificats X509, le code obtenu a bien
évidemment testé unitairement et est fiable et robuste… sauf que les
devs ont mis une bonne heure à l'écrire…
En Java, j'arriverais au même résultat en quelques minutes, le typage
aidant dès le départ.Il y a une étude qui a montré que le nombre de bug était
proportionnel au nombre de lignes quelque soit le langage. C'est bête
mais je le vérifie. Je viens de compter (avec sloccount) une appli que
j'ai réécrite quasiment à l'identique il n'y a pas longtemps, elle est
exactement 2x plus petite qu'en java.
Là je suis d'accord aussi.
Mais le soucis est toujours le même : le code Python sera plus court
donc moins buggé, mais aura demandé des efforts considérables pour les
développeurs.
Ce sont deux
optiques différentes. Je comprend que dans ton cas tu te dis qu'étant
donné qu'il y a énormément de développeurs ça ne sera jamais simple,
donc autant verrouiller, mais ça reste à prouver.
Je ne parle pas forcément de grosses équipes.
Déjà à 2 personnes sur du Python, si l'autre n'est pas dispo pour
expliquer son API et ce qu'il attend.
Toujours sur X509, je te met au défi de me faire un certificat X509
valide avec l'API Python
(http://packages.python.org/pyOpenSSL/openssl-x509.html) uniquement avec
la doc et sans aller chercher de tuto et/ou regarder le code de la lib.
Je pense que c'est mission impossible ou alors j'ai raté un épisode dans
le dev Python…
Rien que de racrocher les bons types aux bonnes méthodes Python,
j'aurais fini le même en Java
(http://www.bouncycastle.org/docs/mdocs1.6/index.html)…Comment expliques-tu que les applis en Java sont réputés si lentes alors
que le langage java lui-même est beaucoup plus rapide que python, de
très loin (plus pour très longtemps) ?
Comme tu le dis, elles ne sont que « réputées » très lentes.
C'était essentiellement vrai il y a quelques années (Java ≤1.3), depuis
Java 1.4 et surtout 5 et 6, Java est quasiment à égalité avec C/C++ (en
moyenne 10% de perfs en moins).
Après en Java, c'est surtout la vitesse de développement qui est un
argument très important.
Le langage en lui-même (generic, enum…), les bonnes pratiques (méthodes
Agile, test U, coverage…), les outils (Maven, Gradle, Sonar, Jenkins,
SCM…) et les architectures (MVC, 3-tiers, IoC, ORM, programmation
aspect…) y sont très en avance sur les autres langages.
Java est un des seuls langages (voire le seul ?) à aborder le
développement de manière globale et non pas du simple point de vue code.
Depuis l'IDE (Eclipse la plupart du temps), tu peux contrôler
l'intégralité de ton cycle de vie projet, de la gestion de conf au
bugtracker en passant par la gestion des dépendances, la compilation, la
construction des bdd, les tests U ou la release, et le tout avec
quasiment un seul outil (Maven).
Et pour ça, un client est prêt à « perdre » 20% de perfs s'il peut
gagner 80% de temps de développement. Surtout qu'au final l'application
sera aussi robuste en Java qu'en Python.
Le 20/05/2011 23:09, William a écrit :
Pourquoi pas la 2nde, ça me semble au contraire plus important et plus
fréquent comme erreur vu que ça englobe aussi les erreurs utilisateurs.
Oui et non.
Si on s'en tient aux erreurs utilisateurs, la couche d'accès aux données
s'occupera de filtrer les valeurs aberrantes et renverra de jolis
messages d'erreur. De ce côté là, Python ou Java, c'est équivalent.
Le problème que j'ai rencontré a surtout été côté développement, avec
des développeurs qui se retrouvaient en face d'API dont ils n'avaient
aucune idée de quel type d'argument passer.
Je pense que l'exemple du « X509Certificate.setIssuer(issuer) » est un
très bon exemple. En Python, les développeurs de mon gros projet ont mis
une bonne heure à comprendre que l'issuer devait être un X509Name et non
un X509Certificate, et surtout que cette découverte n'a été possible que
par analyse du code de la librairie X509, la doc se contentant d'un
laminaire « set the issuer of the certificate ».
Ce que je veux dire s'est que soit on teste soit on ne teste pas. Si on
ne teste que le type ça ne suffit pas et si on teste la valeur on teste
le type en même temps. Dans le cas d'un test unitaire, peu importe que
ça lève une exception à cause du type ou de la valeur.
D'accord avec toi.
Et donc je préfère n'avoir que la partie data à vérifier, déléguant la
partie typage au compilateur. Il fera cela bien mieux que moi, avec
l'héritage et l'inférence de type en prime !
En revanche, utiliser un objet Poids là où un simple entier suffirait va
rendre ton code 5x plus long...
C'était juste un exemple =)
Le soucis en Python est que tout argument est permutable sans erreur et
la permutation ne sera visible qu'au runtime.
Effectivement, si tu refactorise tous les jours ça sera pratique c'est
incontestable. Mais ça ne remplacera pas les tests unitaires qui eux
devraient couvrir aussi ces erreurs.
Les méthodes Agile « imposent » de refactorer en continu.
Tout le process de dev est basé sur des itérations qui améliore au fur
et à mesure les fonctionnalités.
Donc oui, je refactore TRÈS souvent !
Et pour les tests U, 85% de couverture de code obligatoire !
Au contraire, le code est beaucoup plus clair, c'est essentiellement
pour ça je pense que les applis sont plus fiables et plus faciles
à maintenir.
Clair et concis, certes, Python est largement devant Java.
Mais le problème est toujours le même pour moi. Le code FINAL est clair,
concis et robuste grâce à des tests U efficaces, mais :
— les tests U sont généralisables à tout langage et tout projet
— le code INTERMEDIAIRE (en cours de dev) a demandé des efforts
surhumains aux développeurs pour en arriver à la version fiable.
Si je reprend l'exemple des certificats X509, le code obtenu a bien
évidemment testé unitairement et est fiable et robuste… sauf que les
devs ont mis une bonne heure à l'écrire…
En Java, j'arriverais au même résultat en quelques minutes, le typage
aidant dès le départ.
Il y a une étude qui a montré que le nombre de bug était
proportionnel au nombre de lignes quelque soit le langage. C'est bête
mais je le vérifie. Je viens de compter (avec sloccount) une appli que
j'ai réécrite quasiment à l'identique il n'y a pas longtemps, elle est
exactement 2x plus petite qu'en java.
Là je suis d'accord aussi.
Mais le soucis est toujours le même : le code Python sera plus court
donc moins buggé, mais aura demandé des efforts considérables pour les
développeurs.
Ce sont deux
optiques différentes. Je comprend que dans ton cas tu te dis qu'étant
donné qu'il y a énormément de développeurs ça ne sera jamais simple,
donc autant verrouiller, mais ça reste à prouver.
Je ne parle pas forcément de grosses équipes.
Déjà à 2 personnes sur du Python, si l'autre n'est pas dispo pour
expliquer son API et ce qu'il attend.
Toujours sur X509, je te met au défi de me faire un certificat X509
valide avec l'API Python
(http://packages.python.org/pyOpenSSL/openssl-x509.html) uniquement avec
la doc et sans aller chercher de tuto et/ou regarder le code de la lib.
Je pense que c'est mission impossible ou alors j'ai raté un épisode dans
le dev Python…
Rien que de racrocher les bons types aux bonnes méthodes Python,
j'aurais fini le même en Java
(http://www.bouncycastle.org/docs/mdocs1.6/index.html)…
Comment expliques-tu que les applis en Java sont réputés si lentes alors
que le langage java lui-même est beaucoup plus rapide que python, de
très loin (plus pour très longtemps) ?
Comme tu le dis, elles ne sont que « réputées » très lentes.
C'était essentiellement vrai il y a quelques années (Java ≤1.3), depuis
Java 1.4 et surtout 5 et 6, Java est quasiment à égalité avec C/C++ (en
moyenne 10% de perfs en moins).
Après en Java, c'est surtout la vitesse de développement qui est un
argument très important.
Le langage en lui-même (generic, enum…), les bonnes pratiques (méthodes
Agile, test U, coverage…), les outils (Maven, Gradle, Sonar, Jenkins,
SCM…) et les architectures (MVC, 3-tiers, IoC, ORM, programmation
aspect…) y sont très en avance sur les autres langages.
Java est un des seuls langages (voire le seul ?) à aborder le
développement de manière globale et non pas du simple point de vue code.
Depuis l'IDE (Eclipse la plupart du temps), tu peux contrôler
l'intégralité de ton cycle de vie projet, de la gestion de conf au
bugtracker en passant par la gestion des dépendances, la compilation, la
construction des bdd, les tests U ou la release, et le tout avec
quasiment un seul outil (Maven).
Et pour ça, un client est prêt à « perdre » 20% de perfs s'il peut
gagner 80% de temps de développement. Surtout qu'au final l'application
sera aussi robuste en Java qu'en Python.
Le 20/05/2011 23:09, William a écrit :Pourquoi pas la 2nde, ça me semble au contraire plus important et plus
fréquent comme erreur vu que ça englobe aussi les erreurs utilisateurs.
Oui et non.
Si on s'en tient aux erreurs utilisateurs, la couche d'accès aux données
s'occupera de filtrer les valeurs aberrantes et renverra de jolis
messages d'erreur. De ce côté là, Python ou Java, c'est équivalent.
Le problème que j'ai rencontré a surtout été côté développement, avec
des développeurs qui se retrouvaient en face d'API dont ils n'avaient
aucune idée de quel type d'argument passer.
Je pense que l'exemple du « X509Certificate.setIssuer(issuer) » est un
très bon exemple. En Python, les développeurs de mon gros projet ont mis
une bonne heure à comprendre que l'issuer devait être un X509Name et non
un X509Certificate, et surtout que cette découverte n'a été possible que
par analyse du code de la librairie X509, la doc se contentant d'un
laminaire « set the issuer of the certificate ».
Ce que je veux dire s'est que soit on teste soit on ne teste pas. Si on
ne teste que le type ça ne suffit pas et si on teste la valeur on teste
le type en même temps. Dans le cas d'un test unitaire, peu importe que
ça lève une exception à cause du type ou de la valeur.
D'accord avec toi.
Et donc je préfère n'avoir que la partie data à vérifier, déléguant la
partie typage au compilateur. Il fera cela bien mieux que moi, avec
l'héritage et l'inférence de type en prime !
En revanche, utiliser un objet Poids là où un simple entier suffirait va
rendre ton code 5x plus long...
C'était juste un exemple =)
Le soucis en Python est que tout argument est permutable sans erreur et
la permutation ne sera visible qu'au runtime.
Effectivement, si tu refactorise tous les jours ça sera pratique c'est
incontestable. Mais ça ne remplacera pas les tests unitaires qui eux
devraient couvrir aussi ces erreurs.
Les méthodes Agile « imposent » de refactorer en continu.
Tout le process de dev est basé sur des itérations qui améliore au fur
et à mesure les fonctionnalités.
Donc oui, je refactore TRÈS souvent !
Et pour les tests U, 85% de couverture de code obligatoire !
Au contraire, le code est beaucoup plus clair, c'est essentiellement
pour ça je pense que les applis sont plus fiables et plus faciles
à maintenir.
Clair et concis, certes, Python est largement devant Java.
Mais le problème est toujours le même pour moi. Le code FINAL est clair,
concis et robuste grâce à des tests U efficaces, mais :
— les tests U sont généralisables à tout langage et tout projet
— le code INTERMEDIAIRE (en cours de dev) a demandé des efforts
surhumains aux développeurs pour en arriver à la version fiable.
Si je reprend l'exemple des certificats X509, le code obtenu a bien
évidemment testé unitairement et est fiable et robuste… sauf que les
devs ont mis une bonne heure à l'écrire…
En Java, j'arriverais au même résultat en quelques minutes, le typage
aidant dès le départ.Il y a une étude qui a montré que le nombre de bug était
proportionnel au nombre de lignes quelque soit le langage. C'est bête
mais je le vérifie. Je viens de compter (avec sloccount) une appli que
j'ai réécrite quasiment à l'identique il n'y a pas longtemps, elle est
exactement 2x plus petite qu'en java.
Là je suis d'accord aussi.
Mais le soucis est toujours le même : le code Python sera plus court
donc moins buggé, mais aura demandé des efforts considérables pour les
développeurs.
Ce sont deux
optiques différentes. Je comprend que dans ton cas tu te dis qu'étant
donné qu'il y a énormément de développeurs ça ne sera jamais simple,
donc autant verrouiller, mais ça reste à prouver.
Je ne parle pas forcément de grosses équipes.
Déjà à 2 personnes sur du Python, si l'autre n'est pas dispo pour
expliquer son API et ce qu'il attend.
Toujours sur X509, je te met au défi de me faire un certificat X509
valide avec l'API Python
(http://packages.python.org/pyOpenSSL/openssl-x509.html) uniquement avec
la doc et sans aller chercher de tuto et/ou regarder le code de la lib.
Je pense que c'est mission impossible ou alors j'ai raté un épisode dans
le dev Python…
Rien que de racrocher les bons types aux bonnes méthodes Python,
j'aurais fini le même en Java
(http://www.bouncycastle.org/docs/mdocs1.6/index.html)…Comment expliques-tu que les applis en Java sont réputés si lentes alors
que le langage java lui-même est beaucoup plus rapide que python, de
très loin (plus pour très longtemps) ?
Comme tu le dis, elles ne sont que « réputées » très lentes.
C'était essentiellement vrai il y a quelques années (Java ≤1.3), depuis
Java 1.4 et surtout 5 et 6, Java est quasiment à égalité avec C/C++ (en
moyenne 10% de perfs en moins).
Après en Java, c'est surtout la vitesse de développement qui est un
argument très important.
Le langage en lui-même (generic, enum…), les bonnes pratiques (méthodes
Agile, test U, coverage…), les outils (Maven, Gradle, Sonar, Jenkins,
SCM…) et les architectures (MVC, 3-tiers, IoC, ORM, programmation
aspect…) y sont très en avance sur les autres langages.
Java est un des seuls langages (voire le seul ?) à aborder le
développement de manière globale et non pas du simple point de vue code.
Depuis l'IDE (Eclipse la plupart du temps), tu peux contrôler
l'intégralité de ton cycle de vie projet, de la gestion de conf au
bugtracker en passant par la gestion des dépendances, la compilation, la
construction des bdd, les tests U ou la release, et le tout avec
quasiment un seul outil (Maven).
Et pour ça, un client est prêt à « perdre » 20% de perfs s'il peut
gagner 80% de temps de développement. Surtout qu'au final l'application
sera aussi robuste en Java qu'en Python.
C'est clairement un problème de doc là...
Au niveau du test, un assert poids < 150 va vérifier en même temps le
type et la valeur, inutile de rajouter quoique ce soit à la main.
Encore une fois, c'est sûrement un cas bien particulier. Pour ma part
s'est plutôt un facteur 2 ou 3 en faveur de python et c'est ce que j'ai
toujours observé ailleurs.
Ce sont deux optiques différentes. Je préfère utiliser plusieurs petits
outils bien spécifiques qu'une seule grosse usine à gaz.
Je suis d'accord mais c'est encore plus vrai en python ;-)
C'est clairement un problème de doc là...
Au niveau du test, un assert poids < 150 va vérifier en même temps le
type et la valeur, inutile de rajouter quoique ce soit à la main.
Encore une fois, c'est sûrement un cas bien particulier. Pour ma part
s'est plutôt un facteur 2 ou 3 en faveur de python et c'est ce que j'ai
toujours observé ailleurs.
Ce sont deux optiques différentes. Je préfère utiliser plusieurs petits
outils bien spécifiques qu'une seule grosse usine à gaz.
Je suis d'accord mais c'est encore plus vrai en python ;-)
C'est clairement un problème de doc là...
Au niveau du test, un assert poids < 150 va vérifier en même temps le
type et la valeur, inutile de rajouter quoique ce soit à la main.
Encore une fois, c'est sûrement un cas bien particulier. Pour ma part
s'est plutôt un facteur 2 ou 3 en faveur de python et c'est ce que j'ai
toujours observé ailleurs.
Ce sont deux optiques différentes. Je préfère utiliser plusieurs petits
outils bien spécifiques qu'une seule grosse usine à gaz.
Je suis d'accord mais c'est encore plus vrai en python ;-)
Le 21/05/2011 16:58, William a écrit :C'est clairement un problème de doc là...
Peut-être bien.
Mais dans ce cas, c'est un problème énorme et général pour Python car la
plupart des docs que j'ai pu trouver sur ce langage, toutes sont plus ou
moins du même style.
Encore une fois, c'est sûrement un cas bien particulier. Pour ma part
s'est plutôt un facteur 2 ou 3 en faveur de python et c'est ce que
j'ai toujours observé ailleurs.
Après, c'est aussi peut-être une histoire d'ordre de grandeur.
Je suis d'accord mais c'est encore plus vrai en python ;-)
Ben pour le moment je ne l'ai pas encore vu =)
Après comme je te l'ai dis, je suis ici surtout pour apprendre et
comprendre les bonnes méthodes en Python sur de gros projets.
Le 21/05/2011 16:58, William a écrit :
C'est clairement un problème de doc là...
Peut-être bien.
Mais dans ce cas, c'est un problème énorme et général pour Python car la
plupart des docs que j'ai pu trouver sur ce langage, toutes sont plus ou
moins du même style.
Encore une fois, c'est sûrement un cas bien particulier. Pour ma part
s'est plutôt un facteur 2 ou 3 en faveur de python et c'est ce que
j'ai toujours observé ailleurs.
Après, c'est aussi peut-être une histoire d'ordre de grandeur.
Je suis d'accord mais c'est encore plus vrai en python ;-)
Ben pour le moment je ne l'ai pas encore vu =)
Après comme je te l'ai dis, je suis ici surtout pour apprendre et
comprendre les bonnes méthodes en Python sur de gros projets.
Le 21/05/2011 16:58, William a écrit :C'est clairement un problème de doc là...
Peut-être bien.
Mais dans ce cas, c'est un problème énorme et général pour Python car la
plupart des docs que j'ai pu trouver sur ce langage, toutes sont plus ou
moins du même style.
Encore une fois, c'est sûrement un cas bien particulier. Pour ma part
s'est plutôt un facteur 2 ou 3 en faveur de python et c'est ce que
j'ai toujours observé ailleurs.
Après, c'est aussi peut-être une histoire d'ordre de grandeur.
Je suis d'accord mais c'est encore plus vrai en python ;-)
Ben pour le moment je ne l'ai pas encore vu =)
Après comme je te l'ai dis, je suis ici surtout pour apprendre et
comprendre les bonnes méthodes en Python sur de gros projets.
Je pense qu'on va finir par se comprendre...
C'est clair que les moyens mis en œuvre autour de Python sont sans
commune mesure avec Java et ça se voit sur les docs. Et inversement Java
est très bien fourni à ce niveau, il y a des règles très bien
respectées, j'ai beaucoup appris à l'époque où je l'utilisais.
Par contre, généralement, quand il n'y a pas beaucoup de doc c'est que
le code est explicite, il ne faut pas hésiter à le consulter. Je sais,
ça fait drôle, mais ça se fait et on s'y habitue (je ne l'aurai jamais
tenté en Java).
Quand j'utilise une nouvelle librairie je commence par créer tout un tas
de petits bouts de code pour l'essayer et ensuite je m'en sert comme
doc. Pour mes applis je fait un peu pareil, certains tests unitaires
servent de doc.
Ca doit aussi dépendre de l'expérience de chacun, j'imagine facilement
qu'avec plusieurs développeurs c'est encore plus compliqué.
Je pense qu'on va finir par se comprendre...
C'est clair que les moyens mis en œuvre autour de Python sont sans
commune mesure avec Java et ça se voit sur les docs. Et inversement Java
est très bien fourni à ce niveau, il y a des règles très bien
respectées, j'ai beaucoup appris à l'époque où je l'utilisais.
Par contre, généralement, quand il n'y a pas beaucoup de doc c'est que
le code est explicite, il ne faut pas hésiter à le consulter. Je sais,
ça fait drôle, mais ça se fait et on s'y habitue (je ne l'aurai jamais
tenté en Java).
Quand j'utilise une nouvelle librairie je commence par créer tout un tas
de petits bouts de code pour l'essayer et ensuite je m'en sert comme
doc. Pour mes applis je fait un peu pareil, certains tests unitaires
servent de doc.
Ca doit aussi dépendre de l'expérience de chacun, j'imagine facilement
qu'avec plusieurs développeurs c'est encore plus compliqué.
Je pense qu'on va finir par se comprendre...
C'est clair que les moyens mis en œuvre autour de Python sont sans
commune mesure avec Java et ça se voit sur les docs. Et inversement Java
est très bien fourni à ce niveau, il y a des règles très bien
respectées, j'ai beaucoup appris à l'époque où je l'utilisais.
Par contre, généralement, quand il n'y a pas beaucoup de doc c'est que
le code est explicite, il ne faut pas hésiter à le consulter. Je sais,
ça fait drôle, mais ça se fait et on s'y habitue (je ne l'aurai jamais
tenté en Java).
Quand j'utilise une nouvelle librairie je commence par créer tout un tas
de petits bouts de code pour l'essayer et ensuite je m'en sert comme
doc. Pour mes applis je fait un peu pareil, certains tests unitaires
servent de doc.
Ca doit aussi dépendre de l'expérience de chacun, j'imagine facilement
qu'avec plusieurs développeurs c'est encore plus compliqué.