J'utilise slrn + vim correctement pouffiné
J'utilise slrn + vim correctement pouffiné
J'utilise slrn + vim correctement pouffiné
Pour ma part je peux m'en passer, je ne suis pas codeur à plein temps,
et le temps passé à apprendre à utiliser un IDE de-la-mort-qui-
increase-my-productivity sera trop important par rapport aux
bénéfices apportés.
Pour ma part je peux m'en passer, je ne suis pas codeur à plein temps,
et le temps passé à apprendre à utiliser un IDE de-la-mort-qui-
increase-my-productivity sera trop important par rapport aux
bénéfices apportés.
Pour ma part je peux m'en passer, je ne suis pas codeur à plein temps,
et le temps passé à apprendre à utiliser un IDE de-la-mort-qui-
increase-my-productivity sera trop important par rapport aux
bénéfices apportés.
Le 13/05/2011 10:54, totof01 a écrit :Le second point qui me fait détester python est que tout est trop
explicite, ce qui vient à compliquer les choses simples. Le fait
d'avoir un langage qui nécessite de tout indiquer explicitement n'est
pas le problème : ce qui me gène c'est que ce soit pour un langage
"duck typing" : ce n'est absolument pas cohérent. Si on veut un
langage contraignant, on utilise ADA, pas Python.
C'est un peu la même chose qui m'a fait abandonner le Python, outre le
soucis de refactoring.
Ce duck typing devient extrèmenent pénible à l'usage, surtout quand tu
utilises des API tierces.
Que dois-tu passer comme paramètres, et surtout avec quels attributs et
méthodes, pour appeler la méthode « foo(bar) » ? Aucun moyen de le
savoir, sauf à se taper le code-source de cette méthode pour voir ce
dont elle a besoin… Et même la documentation n'est bien souvent d'aucune
utilité ici.
Le 13/05/2011 10:54, totof01 a écrit :
Le second point qui me fait détester python est que tout est trop
explicite, ce qui vient à compliquer les choses simples. Le fait
d'avoir un langage qui nécessite de tout indiquer explicitement n'est
pas le problème : ce qui me gène c'est que ce soit pour un langage
"duck typing" : ce n'est absolument pas cohérent. Si on veut un
langage contraignant, on utilise ADA, pas Python.
C'est un peu la même chose qui m'a fait abandonner le Python, outre le
soucis de refactoring.
Ce duck typing devient extrèmenent pénible à l'usage, surtout quand tu
utilises des API tierces.
Que dois-tu passer comme paramètres, et surtout avec quels attributs et
méthodes, pour appeler la méthode « foo(bar) » ? Aucun moyen de le
savoir, sauf à se taper le code-source de cette méthode pour voir ce
dont elle a besoin… Et même la documentation n'est bien souvent d'aucune
utilité ici.
Le 13/05/2011 10:54, totof01 a écrit :Le second point qui me fait détester python est que tout est trop
explicite, ce qui vient à compliquer les choses simples. Le fait
d'avoir un langage qui nécessite de tout indiquer explicitement n'est
pas le problème : ce qui me gène c'est que ce soit pour un langage
"duck typing" : ce n'est absolument pas cohérent. Si on veut un
langage contraignant, on utilise ADA, pas Python.
C'est un peu la même chose qui m'a fait abandonner le Python, outre le
soucis de refactoring.
Ce duck typing devient extrèmenent pénible à l'usage, surtout quand tu
utilises des API tierces.
Que dois-tu passer comme paramètres, et surtout avec quels attributs et
méthodes, pour appeler la méthode « foo(bar) » ? Aucun moyen de le
savoir, sauf à se taper le code-source de cette méthode pour voir ce
dont elle a besoin… Et même la documentation n'est bien souvent d'aucune
utilité ici.
Soit tu sais très bien ce que fait la méthode que tu utilise et donc ses
paramètres, soit tu ne sais pas et dans ce cas c'est pernicieux de se
baser simplement sur le type de ses paramètres.
Ca explique pourquoi tu as du mal a envisager des programmes importants
en Python. Ca ne vient pas du langage mais de ta façon de l'aborder (je
ne dis pas qu'elle est mauvaise, elle n'est pas adapté).
Soit tu sais très bien ce que fait la méthode que tu utilise et donc ses
paramètres, soit tu ne sais pas et dans ce cas c'est pernicieux de se
baser simplement sur le type de ses paramètres.
Ca explique pourquoi tu as du mal a envisager des programmes importants
en Python. Ca ne vient pas du langage mais de ta façon de l'aborder (je
ne dis pas qu'elle est mauvaise, elle n'est pas adapté).
Soit tu sais très bien ce que fait la méthode que tu utilise et donc ses
paramètres, soit tu ne sais pas et dans ce cas c'est pernicieux de se
baser simplement sur le type de ses paramètres.
Ca explique pourquoi tu as du mal a envisager des programmes importants
en Python. Ca ne vient pas du langage mais de ta façon de l'aborder (je
ne dis pas qu'elle est mauvaise, elle n'est pas adapté).
Si je sais à quoi devrait servir une méthode « Socket.open (inetAddress)
» fournie par une API tierce en Python, je n'ai aucune manière de savoir
de ce à quoi s'attend à trouver comme méthodes et attribut s sur l'objet
« inetAddress » la méthode « open ».
Utilise-t-elle les attributs « addr » et « port », ou « address » et «
port », ou encore des getter « getAddress() » et « ge tPort() », ou pire
encore un tableau associatif « { addr: ⦠, port: ⦠} » comme en usent et
abusent les développeurs Python ?
Seul Dieu le saitâ¦
Et sur la valeur de retour, c'est encore pireâ¦
à comparer à « Socket Socket.open(InetAddr inetAddress) » de Java, où je
sais exactement ce que je dois lui passer, et ceci sans devoir aller
voir COMMENT est implémenté le « open ». Je me conten te de savoir ce que
j'ai à fournir (QUOI).
Et en cas de modif foireuses, pas de type safe, on lance, ça dé marre et
on est content ou ça plante et on pleure pendant des lustresâ¦
Si je sais à quoi devrait servir une méthode « Socket.open (inetAddress)
» fournie par une API tierce en Python, je n'ai aucune manière de savoir
de ce à quoi s'attend à trouver comme méthodes et attribut s sur l'objet
« inetAddress » la méthode « open ».
Utilise-t-elle les attributs « addr » et « port », ou « address » et «
port », ou encore des getter « getAddress() » et « ge tPort() », ou pire
encore un tableau associatif « { addr: ⦠, port: ⦠} » comme en usent et
abusent les développeurs Python ?
Seul Dieu le saitâ¦
Et sur la valeur de retour, c'est encore pireâ¦
à comparer à « Socket Socket.open(InetAddr inetAddress) » de Java, où je
sais exactement ce que je dois lui passer, et ceci sans devoir aller
voir COMMENT est implémenté le « open ». Je me conten te de savoir ce que
j'ai à fournir (QUOI).
Et en cas de modif foireuses, pas de type safe, on lance, ça dé marre et
on est content ou ça plante et on pleure pendant des lustresâ¦
Si je sais à quoi devrait servir une méthode « Socket.open (inetAddress)
» fournie par une API tierce en Python, je n'ai aucune manière de savoir
de ce à quoi s'attend à trouver comme méthodes et attribut s sur l'objet
« inetAddress » la méthode « open ».
Utilise-t-elle les attributs « addr » et « port », ou « address » et «
port », ou encore des getter « getAddress() » et « ge tPort() », ou pire
encore un tableau associatif « { addr: ⦠, port: ⦠} » comme en usent et
abusent les développeurs Python ?
Seul Dieu le saitâ¦
Et sur la valeur de retour, c'est encore pireâ¦
à comparer à « Socket Socket.open(InetAddr inetAddress) » de Java, où je
sais exactement ce que je dois lui passer, et ceci sans devoir aller
voir COMMENT est implémenté le « open ». Je me conten te de savoir ce que
j'ai à fournir (QUOI).
Et en cas de modif foireuses, pas de type safe, on lance, ça dé marre et
on est content ou ça plante et on pleure pendant des lustresâ¦
À (at) Fri, 13 May 2011 21:50:32 +0200,
Aéris écrivait (wrote):
> Si je sais à quoi devrait servir une méthode « Socket.open(inetAd dress)
> » fournie par une API tierce en Python, je n'ai aucune manière de s avoir
> de ce à quoi s'attend à trouver comme méthodes et attributs sur l 'objet
> « inetAddress » la méthode « open ».
> Utilise-t-elle les attributs « addr » et « port », ou « addre ss » et «
> port », ou encore des getter « getAddress() » et « getPort() », ou pire
> encore un tableau associatif « { addr: , port: } » comme en usent et
> abusent les développeurs Python ?
> Seul Dieu le sait
> Et sur la valeur de retour, c'est encore pire
Dieu ne sait rien... En revanche, la documentation de la méthode doit
tout vous dire. Si cette documentation n'existe pas, changez d'API. Si
elle existe mais que vous ne savez pas la retrouver... vous aurez le
même souci avec n'importe quel langage.
> À comparer à « Socket Socket.open(InetAddr inetAddress) » de Ja va, où je
> sais exactement ce que je dois lui passer, et ceci sans devoir aller
> voir COMMENT est implémenté le « open ». Je me contente de savo ir ce que
> j'ai à fournir (QUOI).
Mais comment faites-vous pour construire votre objet InetAddr ? Vous
irez bien lire la documentation de l'un de ses constructeurs... Et puis
en sachant ce que vous passez à cette méthode, cela ne vous dit pas c e
qu'elle en fera (même si vous croyez le savoir).
[...]
> Et en cas de modif foireuses, pas de type safe, on lance, ça démarr e et
> on est content ou ça plante et on pleure pendant des lustres
En résumant (peut-être trop), c'est le "strong typing" qui vous sembl e
indispensable. C'est l'avis de nombreux programmeurs. Mais d'autres,
tout aussi nombreux, s'en passent sans problème. Ceux-là arrivent tr ès
bien à utiliser Python (ou d'autres langages du même type) sur de gro s
projets.
À (at) Fri, 13 May 2011 21:50:32 +0200,
Aéris <ae...@imirhil.fr> écrivait (wrote):
> Si je sais à quoi devrait servir une méthode « Socket.open(inetAd dress)
> » fournie par une API tierce en Python, je n'ai aucune manière de s avoir
> de ce à quoi s'attend à trouver comme méthodes et attributs sur l 'objet
> « inetAddress » la méthode « open ».
> Utilise-t-elle les attributs « addr » et « port », ou « addre ss » et «
> port », ou encore des getter « getAddress() » et « getPort() », ou pire
> encore un tableau associatif « { addr: , port: } » comme en usent et
> abusent les développeurs Python ?
> Seul Dieu le sait
> Et sur la valeur de retour, c'est encore pire
Dieu ne sait rien... En revanche, la documentation de la méthode doit
tout vous dire. Si cette documentation n'existe pas, changez d'API. Si
elle existe mais que vous ne savez pas la retrouver... vous aurez le
même souci avec n'importe quel langage.
> À comparer à « Socket Socket.open(InetAddr inetAddress) » de Ja va, où je
> sais exactement ce que je dois lui passer, et ceci sans devoir aller
> voir COMMENT est implémenté le « open ». Je me contente de savo ir ce que
> j'ai à fournir (QUOI).
Mais comment faites-vous pour construire votre objet InetAddr ? Vous
irez bien lire la documentation de l'un de ses constructeurs... Et puis
en sachant ce que vous passez à cette méthode, cela ne vous dit pas c e
qu'elle en fera (même si vous croyez le savoir).
[...]
> Et en cas de modif foireuses, pas de type safe, on lance, ça démarr e et
> on est content ou ça plante et on pleure pendant des lustres
En résumant (peut-être trop), c'est le "strong typing" qui vous sembl e
indispensable. C'est l'avis de nombreux programmeurs. Mais d'autres,
tout aussi nombreux, s'en passent sans problème. Ceux-là arrivent tr ès
bien à utiliser Python (ou d'autres langages du même type) sur de gro s
projets.
À (at) Fri, 13 May 2011 21:50:32 +0200,
Aéris écrivait (wrote):
> Si je sais à quoi devrait servir une méthode « Socket.open(inetAd dress)
> » fournie par une API tierce en Python, je n'ai aucune manière de s avoir
> de ce à quoi s'attend à trouver comme méthodes et attributs sur l 'objet
> « inetAddress » la méthode « open ».
> Utilise-t-elle les attributs « addr » et « port », ou « addre ss » et «
> port », ou encore des getter « getAddress() » et « getPort() », ou pire
> encore un tableau associatif « { addr: , port: } » comme en usent et
> abusent les développeurs Python ?
> Seul Dieu le sait
> Et sur la valeur de retour, c'est encore pire
Dieu ne sait rien... En revanche, la documentation de la méthode doit
tout vous dire. Si cette documentation n'existe pas, changez d'API. Si
elle existe mais que vous ne savez pas la retrouver... vous aurez le
même souci avec n'importe quel langage.
> À comparer à « Socket Socket.open(InetAddr inetAddress) » de Ja va, où je
> sais exactement ce que je dois lui passer, et ceci sans devoir aller
> voir COMMENT est implémenté le « open ». Je me contente de savo ir ce que
> j'ai à fournir (QUOI).
Mais comment faites-vous pour construire votre objet InetAddr ? Vous
irez bien lire la documentation de l'un de ses constructeurs... Et puis
en sachant ce que vous passez à cette méthode, cela ne vous dit pas c e
qu'elle en fera (même si vous croyez le savoir).
[...]
> Et en cas de modif foireuses, pas de type safe, on lance, ça démarr e et
> on est content ou ça plante et on pleure pendant des lustres
En résumant (peut-être trop), c'est le "strong typing" qui vous sembl e
indispensable. C'est l'avis de nombreux programmeurs. Mais d'autres,
tout aussi nombreux, s'en passent sans problème. Ceux-là arrivent tr ès
bien à utiliser Python (ou d'autres langages du même type) sur de gro s
projets.
Pour ma part le "strong typing ne me parait pas indispensable, je m'en
accomode très bien en Ruby.
Par contre je trouve qu'un langage comme Python, qui est pénible sur
certains points (notamment le self à trainer partout), devrait
l'implémenter. Carendrait le langage un peu plus cohérent. Sino n,
est-ce que quelqu'un pourrait m'expliquer l'intéret de se trainer un
"self" systématique lorsqu'on crée une méthoe d'un objet ? Il y a
peut-être une raison qui m'échappe.
Pour ma part le "strong typing ne me parait pas indispensable, je m'en
accomode très bien en Ruby.
Par contre je trouve qu'un langage comme Python, qui est pénible sur
certains points (notamment le self à trainer partout), devrait
l'implémenter. Carendrait le langage un peu plus cohérent. Sino n,
est-ce que quelqu'un pourrait m'expliquer l'intéret de se trainer un
"self" systématique lorsqu'on crée une méthoe d'un objet ? Il y a
peut-être une raison qui m'échappe.
Pour ma part le "strong typing ne me parait pas indispensable, je m'en
accomode très bien en Ruby.
Par contre je trouve qu'un langage comme Python, qui est pénible sur
certains points (notamment le self à trainer partout), devrait
l'implémenter. Carendrait le langage un peu plus cohérent. Sino n,
est-ce que quelqu'un pourrait m'expliquer l'intéret de se trainer un
"self" systématique lorsqu'on crée une méthoe d'un objet ? Il y a
peut-être une raison qui m'échappe.
Le 14/05/2011 00:49, Paul Gaborit a écrit :Dieu ne sait rien... En revanche, la documentation de la méthode doit
tout vous dire. Si cette documentation n'existe pas, changez d'API. Si
elle existe mais que vous ne savez pas la retrouver... vous aurez le
même souci avec n'importe quel langage.
Sur des méthodes simples (les primitives Pythons en gros), la doc suffit
effectivement généralement, les arguments étant quasiment tous des types
primitifs (int, string, boolean…).
Sur des API plus costaud, tel que X.509
(http://packages.python.org/pyOpenSSL/openssl-x509.html), je vous met au
défi de me créer un certificat X.509 auto-signé uniquement à partir de
la doc et sans aller voir dans le code de l'API…
set_issuer(issuer)
Set the issuer of the certificate to issuer.
C'est quoi « issuer » ? Un string ? Un X509Name ? Un X509 ?
Les 3 sont potentiellement valables…
add_extensions(extensions)
Add the extensions in the sequence extensions to the certificate.
C'est quoi « extensions » ? Une liste de X509Extension ? Un tableau de
tableau d'identifiant ASN1 ? Idem, les 2 sont totalement valable…
Et dans les 2 cas, le seul moment où je saurais si j'ai fait le bon
choix, c'est à l'exécution.
En résumant (peut-être trop), c'est le "strong typing" qui vous semble
indispensable. C'est l'avis de nombreux programmeurs. Mais d'autres,
tout aussi nombreux, s'en passent sans problème. Ceux-là arrivent très
bien à utiliser Python (ou d'autres langages du même type) sur de gros
projets.
C'est pas trop mal résumé =)
Après, je ne suis pas là pour critiquer Python, qui est un langage que
j'apprécie beaucoup pour de petits scripts en remplacement des shells.
Je n'ai peut-être pas la bonne approche d'un langage comme Python, étant
donné que je suis plutôt un adepte des langages très fortement contraints.
Plus ça pète tôt en cas de soucis (si possible dès la compilation voire
dès l'IDE !), mieux je me porte.
J'ai déjà expérimenté Python sur un très gros projet (1.7Go de code
source, moitié Python moitié C++, assez voire pas du tout documenté…) et
j'avoue avoir pas mal lutté à cause de ces problèmes d'arguments et de
typage.
Sans l'aide du développeur qui a écrit une API quelconque, afin de
savoir exactement ce qu'il attendait comme types d'arguments et les
types de ce qu'il me retournait (vive les retours multiples autorisés
par Python !), c'était mission impossible de s'en servir.
Si vous avez des pistes ou des manières de penser pour bien appréhender
ces problèmes, je suis totalement preneur.
Le 14/05/2011 00:49, Paul Gaborit a écrit :
Dieu ne sait rien... En revanche, la documentation de la méthode doit
tout vous dire. Si cette documentation n'existe pas, changez d'API. Si
elle existe mais que vous ne savez pas la retrouver... vous aurez le
même souci avec n'importe quel langage.
Sur des méthodes simples (les primitives Pythons en gros), la doc suffit
effectivement généralement, les arguments étant quasiment tous des types
primitifs (int, string, boolean…).
Sur des API plus costaud, tel que X.509
(http://packages.python.org/pyOpenSSL/openssl-x509.html), je vous met au
défi de me créer un certificat X.509 auto-signé uniquement à partir de
la doc et sans aller voir dans le code de l'API…
set_issuer(issuer)
Set the issuer of the certificate to issuer.
C'est quoi « issuer » ? Un string ? Un X509Name ? Un X509 ?
Les 3 sont potentiellement valables…
add_extensions(extensions)
Add the extensions in the sequence extensions to the certificate.
C'est quoi « extensions » ? Une liste de X509Extension ? Un tableau de
tableau d'identifiant ASN1 ? Idem, les 2 sont totalement valable…
Et dans les 2 cas, le seul moment où je saurais si j'ai fait le bon
choix, c'est à l'exécution.
En résumant (peut-être trop), c'est le "strong typing" qui vous semble
indispensable. C'est l'avis de nombreux programmeurs. Mais d'autres,
tout aussi nombreux, s'en passent sans problème. Ceux-là arrivent très
bien à utiliser Python (ou d'autres langages du même type) sur de gros
projets.
C'est pas trop mal résumé =)
Après, je ne suis pas là pour critiquer Python, qui est un langage que
j'apprécie beaucoup pour de petits scripts en remplacement des shells.
Je n'ai peut-être pas la bonne approche d'un langage comme Python, étant
donné que je suis plutôt un adepte des langages très fortement contraints.
Plus ça pète tôt en cas de soucis (si possible dès la compilation voire
dès l'IDE !), mieux je me porte.
J'ai déjà expérimenté Python sur un très gros projet (1.7Go de code
source, moitié Python moitié C++, assez voire pas du tout documenté…) et
j'avoue avoir pas mal lutté à cause de ces problèmes d'arguments et de
typage.
Sans l'aide du développeur qui a écrit une API quelconque, afin de
savoir exactement ce qu'il attendait comme types d'arguments et les
types de ce qu'il me retournait (vive les retours multiples autorisés
par Python !), c'était mission impossible de s'en servir.
Si vous avez des pistes ou des manières de penser pour bien appréhender
ces problèmes, je suis totalement preneur.
Le 14/05/2011 00:49, Paul Gaborit a écrit :Dieu ne sait rien... En revanche, la documentation de la méthode doit
tout vous dire. Si cette documentation n'existe pas, changez d'API. Si
elle existe mais que vous ne savez pas la retrouver... vous aurez le
même souci avec n'importe quel langage.
Sur des méthodes simples (les primitives Pythons en gros), la doc suffit
effectivement généralement, les arguments étant quasiment tous des types
primitifs (int, string, boolean…).
Sur des API plus costaud, tel que X.509
(http://packages.python.org/pyOpenSSL/openssl-x509.html), je vous met au
défi de me créer un certificat X.509 auto-signé uniquement à partir de
la doc et sans aller voir dans le code de l'API…
set_issuer(issuer)
Set the issuer of the certificate to issuer.
C'est quoi « issuer » ? Un string ? Un X509Name ? Un X509 ?
Les 3 sont potentiellement valables…
add_extensions(extensions)
Add the extensions in the sequence extensions to the certificate.
C'est quoi « extensions » ? Une liste de X509Extension ? Un tableau de
tableau d'identifiant ASN1 ? Idem, les 2 sont totalement valable…
Et dans les 2 cas, le seul moment où je saurais si j'ai fait le bon
choix, c'est à l'exécution.
En résumant (peut-être trop), c'est le "strong typing" qui vous semble
indispensable. C'est l'avis de nombreux programmeurs. Mais d'autres,
tout aussi nombreux, s'en passent sans problème. Ceux-là arrivent très
bien à utiliser Python (ou d'autres langages du même type) sur de gros
projets.
C'est pas trop mal résumé =)
Après, je ne suis pas là pour critiquer Python, qui est un langage que
j'apprécie beaucoup pour de petits scripts en remplacement des shells.
Je n'ai peut-être pas la bonne approche d'un langage comme Python, étant
donné que je suis plutôt un adepte des langages très fortement contraints.
Plus ça pète tôt en cas de soucis (si possible dès la compilation voire
dès l'IDE !), mieux je me porte.
J'ai déjà expérimenté Python sur un très gros projet (1.7Go de code
source, moitié Python moitié C++, assez voire pas du tout documenté…) et
j'avoue avoir pas mal lutté à cause de ces problèmes d'arguments et de
typage.
Sans l'aide du développeur qui a écrit une API quelconque, afin de
savoir exactement ce qu'il attendait comme types d'arguments et les
types de ce qu'il me retournait (vive les retours multiples autorisés
par Python !), c'était mission impossible de s'en servir.
Si vous avez des pistes ou des manières de penser pour bien appréhender
ces problèmes, je suis totalement preneur.
L'inconvénient de cette démarche est que tu rajoute du code de
vérification au milieu de ton algo, ce qui le rend moins lisible et donc
plus sujet à bug de logique.
L'avantage de python est que le code est très concis, ça permet de se
concentrer d'avantage sur l'algo. Un truc tout bête, mais un code qui
tien sur l'écran sera beaucoup plus facile à comprendre que s'il faut
scroller.
Je préfère avoir à deboguer une erreur de type qu'une erreur d'algo !
L'inconvénient de cette démarche est que tu rajoute du code de
vérification au milieu de ton algo, ce qui le rend moins lisible et donc
plus sujet à bug de logique.
L'avantage de python est que le code est très concis, ça permet de se
concentrer d'avantage sur l'algo. Un truc tout bête, mais un code qui
tien sur l'écran sera beaucoup plus facile à comprendre que s'il faut
scroller.
Je préfère avoir à deboguer une erreur de type qu'une erreur d'algo !
L'inconvénient de cette démarche est que tu rajoute du code de
vérification au milieu de ton algo, ce qui le rend moins lisible et donc
plus sujet à bug de logique.
L'avantage de python est que le code est très concis, ça permet de se
concentrer d'avantage sur l'algo. Un truc tout bête, mais un code qui
tien sur l'écran sera beaucoup plus facile à comprendre que s'il faut
scroller.
Je préfère avoir à deboguer une erreur de type qu'une erreur d'algo !
Le 14/05/2011 14:23, William a écrit :L'inconvénient de cette démarche est que tu rajoute du code de
vérification au milieu de ton algo, ce qui le rend moins lisible et donc
plus sujet à bug de logique.
L'avantage de python est que le code est très concis, ça permet de se
concentrer d'avantage sur l'algo. Un truc tout bête, mais un code qui
tien sur l'écran sera beaucoup plus facile à comprendre que s'il faut
scroller.
Je préfère avoir à deboguer une erreur de type qu'une erreur d'algo !
C'est là que je ne te suis plus du tout.
Justement avec Java, je ne vais avoir aucun contrôle à réaliser avec mes
données, le compilateur va me garantir que le typage est correct et que
je manipule bien les données que j'attend, Y COMPRIS POUR DES
UTILISATIONS FUTURES:
Origine primaire du soucis : 15.000 lignes et 2 ans avant l'apparition
effective de l'erreur. Temps passé à débugguer et déplomber très (trop)
conséquent…
J'ai du mal à voir comment une application en Python un tant soit peu
conséquente peut se prémunir de ce type de problème, sans recourir :
— À du strong typing, même simulé (cf plus haut)
— À une doc qui devra déclarer quels sont les types d'arguments attendus
Et au final les 2 cumulés, j'ai l'impression qu'on tombe typiquement
dans de la Javadoc et du strong typing et que de rester en Python relève
de l'inconscience collective
Le 14/05/2011 14:23, William a écrit :
L'inconvénient de cette démarche est que tu rajoute du code de
vérification au milieu de ton algo, ce qui le rend moins lisible et donc
plus sujet à bug de logique.
L'avantage de python est que le code est très concis, ça permet de se
concentrer d'avantage sur l'algo. Un truc tout bête, mais un code qui
tien sur l'écran sera beaucoup plus facile à comprendre que s'il faut
scroller.
Je préfère avoir à deboguer une erreur de type qu'une erreur d'algo !
C'est là que je ne te suis plus du tout.
Justement avec Java, je ne vais avoir aucun contrôle à réaliser avec mes
données, le compilateur va me garantir que le typage est correct et que
je manipule bien les données que j'attend, Y COMPRIS POUR DES
UTILISATIONS FUTURES:
Origine primaire du soucis : 15.000 lignes et 2 ans avant l'apparition
effective de l'erreur. Temps passé à débugguer et déplomber très (trop)
conséquent…
J'ai du mal à voir comment une application en Python un tant soit peu
conséquente peut se prémunir de ce type de problème, sans recourir :
— À du strong typing, même simulé (cf plus haut)
— À une doc qui devra déclarer quels sont les types d'arguments attendus
Et au final les 2 cumulés, j'ai l'impression qu'on tombe typiquement
dans de la Javadoc et du strong typing et que de rester en Python relève
de l'inconscience collective
Le 14/05/2011 14:23, William a écrit :L'inconvénient de cette démarche est que tu rajoute du code de
vérification au milieu de ton algo, ce qui le rend moins lisible et donc
plus sujet à bug de logique.
L'avantage de python est que le code est très concis, ça permet de se
concentrer d'avantage sur l'algo. Un truc tout bête, mais un code qui
tien sur l'écran sera beaucoup plus facile à comprendre que s'il faut
scroller.
Je préfère avoir à deboguer une erreur de type qu'une erreur d'algo !
C'est là que je ne te suis plus du tout.
Justement avec Java, je ne vais avoir aucun contrôle à réaliser avec mes
données, le compilateur va me garantir que le typage est correct et que
je manipule bien les données que j'attend, Y COMPRIS POUR DES
UTILISATIONS FUTURES:
Origine primaire du soucis : 15.000 lignes et 2 ans avant l'apparition
effective de l'erreur. Temps passé à débugguer et déplomber très (trop)
conséquent…
J'ai du mal à voir comment une application en Python un tant soit peu
conséquente peut se prémunir de ce type de problème, sans recourir :
— À du strong typing, même simulé (cf plus haut)
— À une doc qui devra déclarer quels sont les types d'arguments attendus
Et au final les 2 cumulés, j'ai l'impression qu'on tombe typiquement
dans de la Javadoc et du strong typing et que de rester en Python relève
de l'inconscience collective