Ah ce point-là ?
J'avais déjà entendu des gens-que-je-connais râler contre python, mais
moi qui cherche un langage sympa à apprendre, je me sens tout refroidi
par cette ineptie... Par simple curiosité, les pythoniens justifie cette
bétise comment ?
Ah ce point-là ?
J'avais déjà entendu des gens-que-je-connais râler contre python, mais
moi qui cherche un langage sympa à apprendre, je me sens tout refroidi
par cette ineptie... Par simple curiosité, les pythoniens justifie cette
bétise comment ?
Ah ce point-là ?
J'avais déjà entendu des gens-que-je-connais râler contre python, mais
moi qui cherche un langage sympa à apprendre, je me sens tout refroidi
par cette ineptie... Par simple curiosité, les pythoniens justifie cette
bétise comment ?
Tu peux encore apprendre lua qui est un truc encore plus minimal que
python, très performant, très à la mode.
Tu peux encore apprendre lua qui est un truc encore plus minimal que
python, très performant, très à la mode.
Tu peux encore apprendre lua qui est un truc encore plus minimal que
python, très performant, très à la mode.
Le Wed, 11 May 2011 19:35:53 +0200,
Hugolino écrivait :
> Le 11-05-2011, JKB a écrit :
>
>> JKB
> (qui pourrait arrêter de quoter comme un gorêt... steupl..)
Ce sont les réglages par défaut de slrn. Je sens le troll pas loin
et je vais éviter de marcher dedans...
Le Wed, 11 May 2011 19:35:53 +0200,
Hugolino <hugolino@free.fr> écrivait :
> Le 11-05-2011, JKB <jkb@koenigsberg.invalid> a écrit :
>
>> JKB
> (qui pourrait arrêter de quoter comme un gorêt... steupl..)
Ce sont les réglages par défaut de slrn. Je sens le troll pas loin
et je vais éviter de marcher dedans...
Le Wed, 11 May 2011 19:35:53 +0200,
Hugolino écrivait :
> Le 11-05-2011, JKB a écrit :
>
>> JKB
> (qui pourrait arrêter de quoter comme un gorêt... steupl..)
Ce sont les réglages par défaut de slrn. Je sens le troll pas loin
et je vais éviter de marcher dedans...
Hugolino wrote:
>> Ah ce point-là ?
> J'avais déjà entendu des gens-que-je-connais râler contre python, mais
> moi qui cherche un langage sympa à apprendre, je me sens tout refroidi
> par cette ineptie... Par simple curiosité, les pythoniens justifie cette
> bétise comment ?
Au lieu d'avoir des idées stupides à priori sur le sujet, <...>
apprends le python, ça te prend max une journée tellement c'est
simple, utilises le sur un problème un peu conséquent qui
t'intéresses, et tu comprendras tout seul les choix qui ont été
faits.
Si tu veux la jouer cador, <...>
Tu peux encore apprendre lua qui est un truc encore plus minimal que
python, très performant, très à la mode.
Hugolino <hugolino@free.fr> wrote:
>> Ah ce point-là ?
> J'avais déjà entendu des gens-que-je-connais râler contre python, mais
> moi qui cherche un langage sympa à apprendre, je me sens tout refroidi
> par cette ineptie... Par simple curiosité, les pythoniens justifie cette
> bétise comment ?
Au lieu d'avoir des idées stupides à priori sur le sujet, <...>
apprends le python, ça te prend max une journée tellement c'est
simple, utilises le sur un problème un peu conséquent qui
t'intéresses, et tu comprendras tout seul les choix qui ont été
faits.
Si tu veux la jouer cador, <...>
Tu peux encore apprendre lua qui est un truc encore plus minimal que
python, très performant, très à la mode.
Hugolino wrote:
>> Ah ce point-là ?
> J'avais déjà entendu des gens-que-je-connais râler contre python, mais
> moi qui cherche un langage sympa à apprendre, je me sens tout refroidi
> par cette ineptie... Par simple curiosité, les pythoniens justifie cette
> bétise comment ?
Au lieu d'avoir des idées stupides à priori sur le sujet, <...>
apprends le python, ça te prend max une journée tellement c'est
simple, utilises le sur un problème un peu conséquent qui
t'intéresses, et tu comprendras tout seul les choix qui ont été
faits.
Si tu veux la jouer cador, <...>
Tu peux encore apprendre lua qui est un truc encore plus minimal que
python, très performant, très à la mode.
Si l'éditeur fait des remplacements identiques sur tout le fichier
source, tu ne devrais pas rencontrer de problème. Enfin, il me semble.
Après si ton éditeur remplace un coup tes espaces pas une tabulation, un
autre coup par 2 tabulations (et réciproquement), c'est qu'il est temps
de changer d'éditeur ;-)
Si l'éditeur fait des remplacements identiques sur tout le fichier
source, tu ne devrais pas rencontrer de problème. Enfin, il me semble.
Après si ton éditeur remplace un coup tes espaces pas une tabulation, un
autre coup par 2 tabulations (et réciproquement), c'est qu'il est temps
de changer d'éditeur ;-)
Si l'éditeur fait des remplacements identiques sur tout le fichier
source, tu ne devrais pas rencontrer de problème. Enfin, il me semble.
Après si ton éditeur remplace un coup tes espaces pas une tabulation, un
autre coup par 2 tabulations (et réciproquement), c'est qu'il est temps
de changer d'éditeur ;-)
Sauf que tracker du whitespace, c'est pas évident, surtout pour faire la
diff entre 4 espaces et une tabulation…
Sauf que tracker du whitespace, c'est pas évident, surtout pour faire la
diff entre 4 espaces et une tabulation…
Sauf que tracker du whitespace, c'est pas évident, surtout pour faire la
diff entre 4 espaces et une tabulation…
Essaie le brainfuck ;-)
Tiens sur la page :
http://fr.wikipedia.org/wiki/Brainfuck
On parle du Ook, "un langage Turing-complet, conçu pour être
parfaitement lisible par un orang-outan" :-D
Essaie le brainfuck ;-)
Tiens sur la page :
http://fr.wikipedia.org/wiki/Brainfuck
On parle du Ook, "un langage Turing-complet, conçu pour être
parfaitement lisible par un orang-outan" :-D
Essaie le brainfuck ;-)
Tiens sur la page :
http://fr.wikipedia.org/wiki/Brainfuck
On parle du Ook, "un langage Turing-complet, conçu pour être
parfaitement lisible par un orang-outan" :-D
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 12/05/2011 10:29, Doug713705 a écrit :
> Si l'éditeur fait des remplacements identiques sur tout le fichier
> source, tu ne devrais pas rencontrer de problème. Enfin, il me semble .
> Après si ton éditeur remplace un coup tes espaces pas une tabulatio n, un
> autre coup par 2 tabulations (et réciproquement), c'est qu'il est tem ps
> de changer d'éditeur ;-)
Le soucis survient surtout quand tu taffes à plusieurs sur un projet.
Il est rare d'avoir TOUS les développeurs respecter les mêmes règle s
d'indentation.
Certains préfèrent 4 espaces, d'autres 3, les autres 2 et certains le s
tabutalions.
À ceci est aussi à ajouter les différents IDE utilisés, de PyDev à
Notepad++ en passant par IDLE, qui tous traitent l'identation différeme nt.
Et pour finir survient encore un intrus, le gestionnaire de conf, qui a
parfois tendance à faire un gros ignore sur les whitespaces en début de
ligne sur ses diffs s'il est mal configuré (comprendre pas configuré
pour Python).
Et AMA, un des plus gros défauts de la délimitation de bloc par
indentation se trouve essentiellement dans la refactorisation de code.
Je suis un adepte de la méthode Agile et Python est très fortement à
proscrire dans ce genre de méthode, la moindre refacto ou complément de
code (introduction d'une boucle ou d'un test supplémentaire, gestion
d'un nouveau cas dégradé ) demande souvent de revoir des portions
entières de code juste pour se retaper l'identation.
Au final après un sprint Agile, on se retrouve souvent à grepper dans le
code et la scm pour voir où un « abruti » a oublié de réindente r après
refactoring ou y a mis des tabulations au lieu d'espace, parce que la
nouvelle version se plante joyeusement dès le lancement
Sauf que tracker du whitespace, c'est pas évident, surtout pour faire l a
diff entre 4 espaces et une tabulation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 12/05/2011 10:29, Doug713705 a écrit :
> Si l'éditeur fait des remplacements identiques sur tout le fichier
> source, tu ne devrais pas rencontrer de problème. Enfin, il me semble .
> Après si ton éditeur remplace un coup tes espaces pas une tabulatio n, un
> autre coup par 2 tabulations (et réciproquement), c'est qu'il est tem ps
> de changer d'éditeur ;-)
Le soucis survient surtout quand tu taffes à plusieurs sur un projet.
Il est rare d'avoir TOUS les développeurs respecter les mêmes règle s
d'indentation.
Certains préfèrent 4 espaces, d'autres 3, les autres 2 et certains le s
tabutalions.
À ceci est aussi à ajouter les différents IDE utilisés, de PyDev à
Notepad++ en passant par IDLE, qui tous traitent l'identation différeme nt.
Et pour finir survient encore un intrus, le gestionnaire de conf, qui a
parfois tendance à faire un gros ignore sur les whitespaces en début de
ligne sur ses diffs s'il est mal configuré (comprendre pas configuré
pour Python).
Et AMA, un des plus gros défauts de la délimitation de bloc par
indentation se trouve essentiellement dans la refactorisation de code.
Je suis un adepte de la méthode Agile et Python est très fortement à
proscrire dans ce genre de méthode, la moindre refacto ou complément de
code (introduction d'une boucle ou d'un test supplémentaire, gestion
d'un nouveau cas dégradé ) demande souvent de revoir des portions
entières de code juste pour se retaper l'identation.
Au final après un sprint Agile, on se retrouve souvent à grepper dans le
code et la scm pour voir où un « abruti » a oublié de réindente r après
refactoring ou y a mis des tabulations au lieu d'espace, parce que la
nouvelle version se plante joyeusement dès le lancement
Sauf que tracker du whitespace, c'est pas évident, surtout pour faire l a
diff entre 4 espaces et une tabulation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 12/05/2011 10:29, Doug713705 a écrit :
> Si l'éditeur fait des remplacements identiques sur tout le fichier
> source, tu ne devrais pas rencontrer de problème. Enfin, il me semble .
> Après si ton éditeur remplace un coup tes espaces pas une tabulatio n, un
> autre coup par 2 tabulations (et réciproquement), c'est qu'il est tem ps
> de changer d'éditeur ;-)
Le soucis survient surtout quand tu taffes à plusieurs sur un projet.
Il est rare d'avoir TOUS les développeurs respecter les mêmes règle s
d'indentation.
Certains préfèrent 4 espaces, d'autres 3, les autres 2 et certains le s
tabutalions.
À ceci est aussi à ajouter les différents IDE utilisés, de PyDev à
Notepad++ en passant par IDLE, qui tous traitent l'identation différeme nt.
Et pour finir survient encore un intrus, le gestionnaire de conf, qui a
parfois tendance à faire un gros ignore sur les whitespaces en début de
ligne sur ses diffs s'il est mal configuré (comprendre pas configuré
pour Python).
Et AMA, un des plus gros défauts de la délimitation de bloc par
indentation se trouve essentiellement dans la refactorisation de code.
Je suis un adepte de la méthode Agile et Python est très fortement à
proscrire dans ce genre de méthode, la moindre refacto ou complément de
code (introduction d'une boucle ou d'un test supplémentaire, gestion
d'un nouveau cas dégradé ) demande souvent de revoir des portions
entières de code juste pour se retaper l'identation.
Au final après un sprint Agile, on se retrouve souvent à grepper dans le
code et la scm pour voir où un « abruti » a oublié de réindente r après
refactoring ou y a mis des tabulations au lieu d'espace, parce que la
nouvelle version se plante joyeusement dès le lancement
Sauf que tracker du whitespace, c'est pas évident, surtout pour faire l a
diff entre 4 espaces et une tabulation
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.
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.
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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 l e
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'auc une
utilité ici.
Ça rend aussi très pénible de coder, n'ayant aucune complétion
automatique digne de ce nom (la plupart des IDE se contempte de vous
proposer toutes les méthodes et les paramètres que vous avez déjà
appelés ailleurs dans le script courant, et non tous ceux réellement
accessibles vu qu'il n'y a aucun moyen de le savoir avant l'exécution).
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 l e
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'auc une
utilité ici.
Ça rend aussi très pénible de coder, n'ayant aucune complétion
automatique digne de ce nom (la plupart des IDE se contempte de vous
proposer toutes les méthodes et les paramètres que vous avez déjà
appelés ailleurs dans le script courant, et non tous ceux réellement
accessibles vu qu'il n'y a aucun moyen de le savoir avant l'exécution).
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 l e
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'auc une
utilité ici.
Ça rend aussi très pénible de coder, n'ayant aucune complétion
automatique digne de ce nom (la plupart des IDE se contempte de vous
proposer toutes les méthodes et les paramètres que vous avez déjà
appelés ailleurs dans le script courant, et non tous ceux réellement
accessibles vu qu'il n'y a aucun moyen de le savoir avant l'exécution).