A la Fac, on nous enseigne des langages, mais pas Python.
Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un
truc "récursif terminal" permet de faire de la récursivité "très
profonde", en repoussant les limites du stack overflow.
J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).
Le problème:
Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je
suis plutot dans une boite où c'est Python qui règne en maître. Ce
n'est pas un mal, mais je recherche des exemples à difficulté
progressive de cas de recursivité terminale, et je cherche à savoir si
faire de la récursivité terminale sous Python procure (presque) les
mêmes avantages.
Auriez-vous des pistes?
PS: Je programme, c'est tout. Je ne connais pas _exactement_ pourquoi la
récursivité terminale permet ceci ou cela. Cela viendra un jour,
peut-etre, mais pour l'instant j'apprends :-)
--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/
Maintenant, comme il y a des langages qui ne spécifient pas la dérécursivation terminale automatique, et comme il y a des algorithmes récursifs non-terminaux, un programmeur doit savoir dérécursiver manuellement de toutes façons. (C'est trivial si on utilise une pile explicite).
A répéter 10 fois le plus vite possible: "Un bon programmeur doit savoir dérécursiver une récursion sans son dérécursivateur terminal automatique"
Ok, je sors ---> []
(snip)
Maintenant, comme il y a des langages qui ne spécifient pas la
dérécursivation terminale automatique, et comme il y a des algorithmes
récursifs non-terminaux, un programmeur doit savoir dérécursiver
manuellement de toutes façons. (C'est trivial si on utilise une pile
explicite).
A répéter 10 fois le plus vite possible:
"Un bon programmeur doit savoir dérécursiver une récursion sans son
dérécursivateur terminal automatique"
Maintenant, comme il y a des langages qui ne spécifient pas la dérécursivation terminale automatique, et comme il y a des algorithmes récursifs non-terminaux, un programmeur doit savoir dérécursiver manuellement de toutes façons. (C'est trivial si on utilise une pile explicite).
A répéter 10 fois le plus vite possible: "Un bon programmeur doit savoir dérécursiver une récursion sans son dérécursivateur terminal automatique"
Ok, je sors ---> []
Blaise Li
Bruno Desthuilliers wrote in message <43137373$0$27517$:
Traduction Python def factorielle(n): def factorielle_aux(accu, n): if n == 0: return accu else: return factorielle_aux(n * accu, n - 1) return factorielle_aux(1, n)
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
C'est réellement plus efficace de faire comme ça ou bien c'est limité par l'intelligence du compilateur ?
bli
Bruno Desthuilliers wrote in message
<43137373$0$27517$636a15ce@news.free.fr>:
Traduction Python
def factorielle(n):
def factorielle_aux(accu, n):
if n == 0:
return accu
else:
return factorielle_aux(n * accu, n - 1)
return factorielle_aux(1, n)
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
C'est réellement plus efficace de faire comme ça ou bien c'est limité
par l'intelligence du compilateur ?
Bruno Desthuilliers wrote in message <43137373$0$27517$:
Traduction Python def factorielle(n): def factorielle_aux(accu, n): if n == 0: return accu else: return factorielle_aux(n * accu, n - 1) return factorielle_aux(1, n)
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
C'est réellement plus efficace de faire comme ça ou bien c'est limité par l'intelligence du compilateur ?
bli
Jerome
Blaise Li wrote:
Bruno Desthuilliers wrote in message <43137373$0$27517$:
Traduction Python def factorielle(n): def factorielle_aux(accu, n): if n == 0: return accu else: return factorielle_aux(n * accu, n - 1) return factorielle_aux(1, n)
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
C'est réellement plus efficace de faire comme ça ou bien c'est limité par l'intelligence du compilateur ?
bli
L'intérêt principal est surtout de limiter la portée de la fonction factorielle_aux à la fonction factorielle. Tu ne peux pas l'utiliser en dehors ce qui est meileur pour la lisibilité et le premier pas vers la programmation objet ;-)
Jérôme
Blaise Li wrote:
Bruno Desthuilliers wrote in message
<43137373$0$27517$636a15ce@news.free.fr>:
Traduction Python
def factorielle(n):
def factorielle_aux(accu, n):
if n == 0:
return accu
else:
return factorielle_aux(n * accu, n - 1)
return factorielle_aux(1, n)
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
C'est réellement plus efficace de faire comme ça ou bien c'est limité
par l'intelligence du compilateur ?
bli
L'intérêt principal est surtout de limiter la portée de la fonction
factorielle_aux à la fonction factorielle. Tu ne peux pas l'utiliser en
dehors ce qui est meileur pour la lisibilité et le premier pas vers la
programmation objet ;-)
Bruno Desthuilliers wrote in message <43137373$0$27517$:
Traduction Python def factorielle(n): def factorielle_aux(accu, n): if n == 0: return accu else: return factorielle_aux(n * accu, n - 1) return factorielle_aux(1, n)
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
C'est réellement plus efficace de faire comme ça ou bien c'est limité par l'intelligence du compilateur ?
bli
L'intérêt principal est surtout de limiter la portée de la fonction factorielle_aux à la fonction factorielle. Tu ne peux pas l'utiliser en dehors ce qui est meileur pour la lisibilité et le premier pas vers la programmation objet ;-)
Jérôme
Christophe Cavalaria
R12y wrote:
[ Attention: Xpost + follow-up ]
Bonjour,
A la Fac, on nous enseigne des langages, mais pas Python. Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un truc "récursif terminal" permet de faire de la récursivité "très profonde", en repoussant les limites du stack overflow.
J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).
Le problème: Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je suis plutot dans une boite où c'est Python qui règne en maître. Ce n'est pas un mal, mais je recherche des exemples à difficulté progressive de cas de recursivité terminale, et je cherche à savoir si faire de la récursivité terminale sous Python procure (presque) les mêmes avantages.
Auriez-vous des pistes?
PS: Je programme, c'est tout. Je ne connais pas _exactement_ pourquoi la récursivité terminale permet ceci ou cela. Cela viendra un jour, peut-etre, mais pour l'instant j'apprends :-)
Il est très simple d'ajouter le support de la "tail recursion" en Python. Quelqu'un avait fournit un patch pour cela mais il a été refusé car la tail recursion rend les piles pratiquement inutilisables quand une fonction tail recursive est mise en jeu.
R12y wrote:
[ Attention: Xpost + follow-up ]
Bonjour,
A la Fac, on nous enseigne des langages, mais pas Python.
Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un
truc "récursif terminal" permet de faire de la récursivité "très
profonde", en repoussant les limites du stack overflow.
J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).
Le problème:
Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je
suis plutot dans une boite où c'est Python qui règne en maître. Ce
n'est pas un mal, mais je recherche des exemples à difficulté
progressive de cas de recursivité terminale, et je cherche à savoir si
faire de la récursivité terminale sous Python procure (presque) les
mêmes avantages.
Auriez-vous des pistes?
PS: Je programme, c'est tout. Je ne connais pas _exactement_ pourquoi la
récursivité terminale permet ceci ou cela. Cela viendra un jour,
peut-etre, mais pour l'instant j'apprends :-)
Il est très simple d'ajouter le support de la "tail recursion" en Python.
Quelqu'un avait fournit un patch pour cela mais il a été refusé car la tail
recursion rend les piles pratiquement inutilisables quand une fonction tail
recursive est mise en jeu.
A la Fac, on nous enseigne des langages, mais pas Python. Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un truc "récursif terminal" permet de faire de la récursivité "très profonde", en repoussant les limites du stack overflow.
J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).
Le problème: Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je suis plutot dans une boite où c'est Python qui règne en maître. Ce n'est pas un mal, mais je recherche des exemples à difficulté progressive de cas de recursivité terminale, et je cherche à savoir si faire de la récursivité terminale sous Python procure (presque) les mêmes avantages.
Auriez-vous des pistes?
PS: Je programme, c'est tout. Je ne connais pas _exactement_ pourquoi la récursivité terminale permet ceci ou cela. Cela viendra un jour, peut-etre, mais pour l'instant j'apprends :-)
Il est très simple d'ajouter le support de la "tail recursion" en Python. Quelqu'un avait fournit un patch pour cela mais il a été refusé car la tail recursion rend les piles pratiquement inutilisables quand une fonction tail recursive est mise en jeu.
Bruno Desthuilliers
Bruno Desthuilliers wrote in message <43137373$0$27517$:
Traduction Python def factorielle(n): def factorielle_aux(accu, n): if n == 0: return accu else: return factorielle_aux(n * accu, n - 1) return factorielle_aux(1, n)
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
Dans ce domaine là, il y a des trucs beaucoups plus amusants... Comme retourner une fonction depuis une autre fonction, composer des fonctions etc.
C'est réellement plus efficace de faire comme ça
Je ne suis pas sûr que ça fasse une différence notable au point de vue perfs, mais ça évite de polluer l'espace de nommage avec des détails d'implémentation.
ou bien c'est limité par l'intelligence du compilateur ?
???
Bruno Desthuilliers wrote in message
<43137373$0$27517$636a15ce@news.free.fr>:
Traduction Python
def factorielle(n):
def factorielle_aux(accu, n):
if n == 0:
return accu
else:
return factorielle_aux(n * accu, n - 1)
return factorielle_aux(1, n)
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
Dans ce domaine là, il y a des trucs beaucoups plus amusants... Comme
retourner une fonction depuis une autre fonction, composer des fonctions
etc.
C'est réellement plus efficace de faire comme ça
Je ne suis pas sûr que ça fasse une différence notable au point de vue
perfs, mais ça évite de polluer l'espace de nommage avec des détails
d'implémentation.
ou bien c'est limité
par l'intelligence du compilateur ?
Bruno Desthuilliers wrote in message <43137373$0$27517$:
Traduction Python def factorielle(n): def factorielle_aux(accu, n): if n == 0: return accu else: return factorielle_aux(n * accu, n - 1) return factorielle_aux(1, n)
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
Dans ce domaine là, il y a des trucs beaucoups plus amusants... Comme retourner une fonction depuis une autre fonction, composer des fonctions etc.
C'est réellement plus efficace de faire comme ça
Je ne suis pas sûr que ça fasse une différence notable au point de vue perfs, mais ça évite de polluer l'espace de nommage avec des détails d'implémentation.
ou bien c'est limité par l'intelligence du compilateur ?
???
Encolpe Degoute
[ Attention: Xpost + follow-up ]
Bonjour,
A la Fac, on nous enseigne des langages, mais pas Python. Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un truc "récursif terminal" permet de faire de la récursivité "très profonde", en repoussant les limites du stack overflow.
J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).
Le problème: Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je suis plutot dans une boite où c'est Python qui règne en maître. Ce n'est pas un mal, mais je recherche des exemples à difficulté progressive de cas de recursivité terminale, et je cherche à savoir si faire de la récursivité terminale sous Python procure (presque) les mêmes avantages.
Auriez-vous des pistes?
En Python je ne sais pas, En LISP/Scheme j'en suis sûr ;) Un truc amusant que j'ai eu à faire en scheme qui peut te permettre de tester la récursivité: Implémenter un moteur qui trouve la solution des 'chiffres' dans les chiffres et les lettres. Il y a six plaques tirées entre [1, 2, 3, 4, 5 ,6, 7, 8, 9, 10, 25, 50, 100] et un résultat à obtenir ou approcher compris entre 100 et 999 inclus. La contrainte: aucun stockage variable n'est admis, le but est de créer un arbre des possibilité et voir quelle est la branche qui s'approche le plus du résultat.
Dans un deuxième temps il est possible d'optimiser la construction de l'arbre et d'augmenter le nombre de plaques tirées.
C'était un exercice à faire en un mois de temps en première année de DEUG. Cela a été un massacre.
Amusez-vous bien ;) -- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
[ Attention: Xpost + follow-up ]
Bonjour,
A la Fac, on nous enseigne des langages, mais pas Python.
Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un
truc "récursif terminal" permet de faire de la récursivité "très
profonde", en repoussant les limites du stack overflow.
J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).
Le problème:
Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je
suis plutot dans une boite où c'est Python qui règne en maître. Ce
n'est pas un mal, mais je recherche des exemples à difficulté
progressive de cas de recursivité terminale, et je cherche à savoir si
faire de la récursivité terminale sous Python procure (presque) les
mêmes avantages.
Auriez-vous des pistes?
En Python je ne sais pas, En LISP/Scheme j'en suis sûr ;)
Un truc amusant que j'ai eu à faire en scheme qui peut te permettre de
tester la récursivité:
Implémenter un moteur qui trouve la solution des 'chiffres' dans les
chiffres et les lettres.
Il y a six plaques tirées entre [1, 2, 3, 4, 5 ,6, 7, 8, 9, 10, 25, 50,
100] et un résultat à obtenir ou approcher compris entre 100 et 999 inclus.
La contrainte: aucun stockage variable n'est admis, le but est de créer
un arbre des possibilité et voir quelle est la branche qui s'approche le
plus du résultat.
Dans un deuxième temps il est possible d'optimiser la construction de
l'arbre et d'augmenter le nombre de plaques tirées.
C'était un exercice à faire en un mois de temps en première année de
DEUG. Cela a été un massacre.
Amusez-vous bien ;)
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
A la Fac, on nous enseigne des langages, mais pas Python. Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un truc "récursif terminal" permet de faire de la récursivité "très profonde", en repoussant les limites du stack overflow.
J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).
Le problème: Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je suis plutot dans une boite où c'est Python qui règne en maître. Ce n'est pas un mal, mais je recherche des exemples à difficulté progressive de cas de recursivité terminale, et je cherche à savoir si faire de la récursivité terminale sous Python procure (presque) les mêmes avantages.
Auriez-vous des pistes?
En Python je ne sais pas, En LISP/Scheme j'en suis sûr ;) Un truc amusant que j'ai eu à faire en scheme qui peut te permettre de tester la récursivité: Implémenter un moteur qui trouve la solution des 'chiffres' dans les chiffres et les lettres. Il y a six plaques tirées entre [1, 2, 3, 4, 5 ,6, 7, 8, 9, 10, 25, 50, 100] et un résultat à obtenir ou approcher compris entre 100 et 999 inclus. La contrainte: aucun stockage variable n'est admis, le but est de créer un arbre des possibilité et voir quelle est la branche qui s'approche le plus du résultat.
Dans un deuxième temps il est possible d'optimiser la construction de l'arbre et d'augmenter le nombre de plaques tirées.
C'était un exercice à faire en un mois de temps en première année de DEUG. Cela a été un massacre.
Amusez-vous bien ;) -- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
R12y
On Tue, 30 Aug 2005 16:27:22 +0000, Blaise Li wrote:
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
Hey! j'avais même pas vu! :-) J'étais plongé dans l'analyse de la recursivité...
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
On Tue, 30 Aug 2005 16:27:22 +0000, Blaise Li wrote:
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
Hey! j'avais même pas vu! :-)
J'étais plongé dans l'analyse de la recursivité...
--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/
On Tue, 30 Aug 2005 16:27:22 +0000, Blaise Li wrote:
Tiens, on peut définir une fonction dans une fonction ? C'est joli.
Hey! j'avais même pas vu! :-) J'étais plongé dans l'analyse de la recursivité...
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
Jacti
[ Attention: Xpost + follow-up ]
Bonjour,
A la Fac, on nous enseigne des langages, mais pas Python. Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un truc "récursif terminal" permet de faire de la récursivité "très profonde", en repoussant les limites du stack overflow.
J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).
Le problème: Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je suis plutot dans une boite où c'est Python qui règne en maître. Ce n'est pas un mal, mais je recherche des exemples à difficulté progressive de cas de recursivité terminale, et je cherche à savoir si faire de la récursivité terminale sous Python procure (presque) les mêmes avantages.
Auriez-vous des pistes?
PS: Je programme, c'est tout. Je ne connais pas _exactement_ pourquoi la récursivité terminale permet ceci ou cela. Cela viendra un jour, peut-etre, mais pour l'instant j'apprends :-)
La récursivité terminale peut toujours être transformée en boucle par l'interprèteur ou le compilateur, ce qui n'est pas le cas de la récursivité non terminale (cf., par exemple, http://cermics.enpc.fr/polys/info1/main/node22.html)
D'après ce post (http://mail.python.org/pipermail/python-dev/2004-July/046150.html) il ne semble pas que Python dérécursive la récursion terminale. De toute façon, je considère Python comme un très mauvais langage (je sais je vais à contre courant de l'avis de beaucoup de gens...) mais j'ai travailler dans les compilateurs et je connais plus de 30 langages de programmation et, donc, je sais de quoi je parle... Pourquoi les informaticiens ont-ils toujours des attirances pour les plus mauvais langages (C, C++, Python, Visual Basic, par exemple) ? Seraient-ils tous d'infâmes bidouilleurs ?
Jacti
PS :Ocaml est un très bon langage, mais j'ai un faible pour les langages fonctionnels... C'est certainement d'avoir fait trop de lambda-calcul ;-)
Jacti
[ Attention: Xpost + follow-up ]
Bonjour,
A la Fac, on nous enseigne des langages, mais pas Python.
Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un
truc "récursif terminal" permet de faire de la récursivité "très
profonde", en repoussant les limites du stack overflow.
J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).
Le problème:
Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je
suis plutot dans une boite où c'est Python qui règne en maître. Ce
n'est pas un mal, mais je recherche des exemples à difficulté
progressive de cas de recursivité terminale, et je cherche à savoir si
faire de la récursivité terminale sous Python procure (presque) les
mêmes avantages.
Auriez-vous des pistes?
PS: Je programme, c'est tout. Je ne connais pas _exactement_ pourquoi la
récursivité terminale permet ceci ou cela. Cela viendra un jour,
peut-etre, mais pour l'instant j'apprends :-)
La récursivité terminale peut toujours être transformée en boucle par
l'interprèteur
ou le compilateur, ce qui n'est pas le cas de la récursivité non terminale
(cf., par exemple, http://cermics.enpc.fr/polys/info1/main/node22.html)
D'après ce post
(http://mail.python.org/pipermail/python-dev/2004-July/046150.html)
il ne semble pas que Python dérécursive la récursion terminale.
De toute façon, je considère Python comme un très mauvais langage
(je sais je vais à contre courant de l'avis de beaucoup de gens...) mais
j'ai travailler dans les compilateurs et je connais plus de 30 langages de
programmation et, donc,
je sais de quoi je parle...
Pourquoi les informaticiens ont-ils toujours des attirances pour les plus
mauvais langages
(C, C++, Python, Visual Basic, par exemple) ? Seraient-ils tous d'infâmes
bidouilleurs ?
Jacti
PS :Ocaml est un très bon langage, mais j'ai un faible pour les langages
fonctionnels...
C'est certainement d'avoir fait trop de lambda-calcul ;-)
A la Fac, on nous enseigne des langages, mais pas Python. Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un truc "récursif terminal" permet de faire de la récursivité "très profonde", en repoussant les limites du stack overflow.
J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).
Le problème: Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je suis plutot dans une boite où c'est Python qui règne en maître. Ce n'est pas un mal, mais je recherche des exemples à difficulté progressive de cas de recursivité terminale, et je cherche à savoir si faire de la récursivité terminale sous Python procure (presque) les mêmes avantages.
Auriez-vous des pistes?
PS: Je programme, c'est tout. Je ne connais pas _exactement_ pourquoi la récursivité terminale permet ceci ou cela. Cela viendra un jour, peut-etre, mais pour l'instant j'apprends :-)
La récursivité terminale peut toujours être transformée en boucle par l'interprèteur ou le compilateur, ce qui n'est pas le cas de la récursivité non terminale (cf., par exemple, http://cermics.enpc.fr/polys/info1/main/node22.html)
D'après ce post (http://mail.python.org/pipermail/python-dev/2004-July/046150.html) il ne semble pas que Python dérécursive la récursion terminale. De toute façon, je considère Python comme un très mauvais langage (je sais je vais à contre courant de l'avis de beaucoup de gens...) mais j'ai travailler dans les compilateurs et je connais plus de 30 langages de programmation et, donc, je sais de quoi je parle... Pourquoi les informaticiens ont-ils toujours des attirances pour les plus mauvais langages (C, C++, Python, Visual Basic, par exemple) ? Seraient-ils tous d'infâmes bidouilleurs ?
Jacti
PS :Ocaml est un très bon langage, mais j'ai un faible pour les langages fonctionnels... C'est certainement d'avoir fait trop de lambda-calcul ;-)
Jacti
bruno modulix
Jacti wrote:
[ Attention: Xpost + follow-up ]
(snip)
D'après ce post (http://mail.python.org/pipermail/python-dev/2004-July/046150.html) il ne semble pas que Python dérécursive la récursion terminale.
Non, mais c'est un choix volontaire. Le patch pour ça existe (en tous cas il eu existé).
De toute façon, je considère Python comme un très mauvais langage
Heu... Tu a bien lu le warning en haut du message, et regardé sur quel ng tu postais ?-)
(je sais je vais à contre courant de l'avis de beaucoup de gens...)
Oui, particulièrement ici...
mais j'ai travailler dans les compilateurs et je connais plus de 30 langages de programmation et, donc, je sais de quoi je parle...
Au lieu d'affirmer péremptoirement, tu pourrais peut-être argumenter ?
Pourquoi les informaticiens ont-ils toujours des attirances pour les plus mauvais langages (C, C++, Python, Visual Basic, par exemple) ?
Cherchez l'intrus... Si tu place Python et VB dans la même catégorie, je crains que tu ne saches pas si bien que ça de quoi tu parles...
Sinon, pour répondre à ta question: http://www.laputan.org/gabriel/worse-is-better.html
Seraient-ils tous d'infâmes bidouilleurs ?
Oui, bien sûr. C'est évident.
Ou peut-être trouvent-ils juste que l'ambiance sur comp.lang.lisp est trop saturée de prétention, de suffisance et d'arrogance ?-)
En ce qui me concerne, Python me permet de faire ce que j'ai à faire simplement et rapidement. Effectivement avec d'infâmes bidouilles, comme par exemple : - les fonctions en tant qu'objets de première classe - les fermetures - les expressions de liste - les générateurs - les descripteurs - les métaclasses
Bref, si l'on mets de côté les deux derniers points, d'infâmes bidouilles très ouvertements inspirées des langages fonctionnels...
Ah, oui, c'est vrai, pas de macros, pas de joli modèle mathématique, une préférence marquée pour la simplicité et la lisibilité... C'est vrai que c'est minable, Python, quand on y pense.
-- bruno desthuilliers Infâme Bidouilleur et fier de l'être. python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Jacti wrote:
[ Attention: Xpost + follow-up ]
(snip)
D'après ce post
(http://mail.python.org/pipermail/python-dev/2004-July/046150.html)
il ne semble pas que Python dérécursive la récursion terminale.
Non, mais c'est un choix volontaire. Le patch pour ça existe (en tous
cas il eu existé).
De toute façon, je considère Python comme un très mauvais langage
Heu... Tu a bien lu le warning en haut du message, et regardé sur quel
ng tu postais ?-)
(je sais je vais à contre courant de l'avis de beaucoup de gens...)
Oui, particulièrement ici...
mais
j'ai travailler dans les compilateurs et je connais plus de 30 langages de
programmation et, donc,
je sais de quoi je parle...
Au lieu d'affirmer péremptoirement, tu pourrais peut-être argumenter ?
Pourquoi les informaticiens ont-ils toujours des attirances pour les plus
mauvais langages
(C, C++, Python, Visual Basic, par exemple) ?
Cherchez l'intrus... Si tu place Python et VB dans la même catégorie, je
crains que tu ne saches pas si bien que ça de quoi tu parles...
Sinon, pour répondre à ta question:
http://www.laputan.org/gabriel/worse-is-better.html
Seraient-ils tous d'infâmes
bidouilleurs ?
Oui, bien sûr. C'est évident.
Ou peut-être trouvent-ils juste que l'ambiance sur comp.lang.lisp est
trop saturée de prétention, de suffisance et d'arrogance ?-)
En ce qui me concerne, Python me permet de faire ce que j'ai à faire
simplement et rapidement. Effectivement avec d'infâmes bidouilles, comme
par exemple :
- les fonctions en tant qu'objets de première classe
- les fermetures
- les expressions de liste
- les générateurs
- les descripteurs
- les métaclasses
Bref, si l'on mets de côté les deux derniers points, d'infâmes
bidouilles très ouvertements inspirées des langages fonctionnels...
Ah, oui, c'est vrai, pas de macros, pas de joli modèle mathématique, une
préférence marquée pour la simplicité et la lisibilité... C'est vrai que
c'est minable, Python, quand on y pense.
--
bruno desthuilliers
Infâme Bidouilleur et fier de l'être.
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
D'après ce post (http://mail.python.org/pipermail/python-dev/2004-July/046150.html) il ne semble pas que Python dérécursive la récursion terminale.
Non, mais c'est un choix volontaire. Le patch pour ça existe (en tous cas il eu existé).
De toute façon, je considère Python comme un très mauvais langage
Heu... Tu a bien lu le warning en haut du message, et regardé sur quel ng tu postais ?-)
(je sais je vais à contre courant de l'avis de beaucoup de gens...)
Oui, particulièrement ici...
mais j'ai travailler dans les compilateurs et je connais plus de 30 langages de programmation et, donc, je sais de quoi je parle...
Au lieu d'affirmer péremptoirement, tu pourrais peut-être argumenter ?
Pourquoi les informaticiens ont-ils toujours des attirances pour les plus mauvais langages (C, C++, Python, Visual Basic, par exemple) ?
Cherchez l'intrus... Si tu place Python et VB dans la même catégorie, je crains que tu ne saches pas si bien que ça de quoi tu parles...
Sinon, pour répondre à ta question: http://www.laputan.org/gabriel/worse-is-better.html
Seraient-ils tous d'infâmes bidouilleurs ?
Oui, bien sûr. C'est évident.
Ou peut-être trouvent-ils juste que l'ambiance sur comp.lang.lisp est trop saturée de prétention, de suffisance et d'arrogance ?-)
En ce qui me concerne, Python me permet de faire ce que j'ai à faire simplement et rapidement. Effectivement avec d'infâmes bidouilles, comme par exemple : - les fonctions en tant qu'objets de première classe - les fermetures - les expressions de liste - les générateurs - les descripteurs - les métaclasses
Bref, si l'on mets de côté les deux derniers points, d'infâmes bidouilles très ouvertements inspirées des langages fonctionnels...
Ah, oui, c'est vrai, pas de macros, pas de joli modèle mathématique, une préférence marquée pour la simplicité et la lisibilité... C'est vrai que c'est minable, Python, quand on y pense.
-- bruno desthuilliers Infâme Bidouilleur et fier de l'être. python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Do Re Mi chel La Si Do
Bonsoir !
Ocaml est un très bon langage
OCaML a été développé avec des fonds publics français, et quelques capitaux privés français. Cela n'a guère influencé ses créateurs de réaliser les annonces aux USA d'abord, de ne produire que des versions et documentations en anglais (le livre en français est une initiative privée de quelques personnes, comme les rares textes et tutoriaux en français).
Je ne critique pas le fait de publier anglais, mais l'absence de publication simultanée en français.
De plus, il faut voir comment est reçu, par l'INRIA, un développeur indépendant (français, et qui paye ses impôts), qui voudrait quelques renseignements. On lui suggère simplement de s'adresser ailleurs.
Tout ça n'encourage pas à regarder ce langage. De même, ce comportement discrédite un pan entier de la recherche française...
@-salutations
Michel Claveau
Bonsoir !
Ocaml est un très bon langage
OCaML a été développé avec des fonds publics français, et quelques capitaux
privés français. Cela n'a guère influencé ses créateurs de réaliser les
annonces aux USA d'abord, de ne produire que des versions et documentations
en anglais (le livre en français est une initiative privée de quelques
personnes, comme les rares textes et tutoriaux en français).
Je ne critique pas le fait de publier anglais, mais l'absence de publication
simultanée en français.
De plus, il faut voir comment est reçu, par l'INRIA, un développeur
indépendant (français, et qui paye ses impôts), qui voudrait quelques
renseignements. On lui suggère simplement de s'adresser ailleurs.
Tout ça n'encourage pas à regarder ce langage. De même, ce comportement
discrédite un pan entier de la recherche française...
OCaML a été développé avec des fonds publics français, et quelques capitaux privés français. Cela n'a guère influencé ses créateurs de réaliser les annonces aux USA d'abord, de ne produire que des versions et documentations en anglais (le livre en français est une initiative privée de quelques personnes, comme les rares textes et tutoriaux en français).
Je ne critique pas le fait de publier anglais, mais l'absence de publication simultanée en français.
De plus, il faut voir comment est reçu, par l'INRIA, un développeur indépendant (français, et qui paye ses impôts), qui voudrait quelques renseignements. On lui suggère simplement de s'adresser ailleurs.
Tout ça n'encourage pas à regarder ce langage. De même, ce comportement discrédite un pan entier de la recherche française...
