tail recursivity - recursivite terminale

Bonjour la simplicité syntaxique de Python !!
On ne peut pas faire un VRAI système d'exploitation sans un mécanisme
de macros (bien que je n'aime pas ça, mais c'est un mal nécessaire...).

Qui a dit que Python servait à faire des systèmes d'exploitation ? Et qui a
dis qu'il fallait un système de macro pour faire un OS de toute façon ?
Tellement d'erreurs en si peu de mots. Celui là aussi mérite une fortune !

Tu interprète à ta façon mes remarques (on pourrait appeler cela du "forcing
sémantique").
Je n'ai jamais dit que Python servait à faire des OS.
Par contre oui, j'affirme que pour faire un OS il préférable de disposer d'un
macroprocesseur

Quel rapport avec la choucroute ? La question d'origine ne porte même
pas sur les OS...

Il n'y a donc pas "tellement d'erreurs"...

Non juste une mauvaise foi dantesque.

--
Hervé Cauwelier
http://www.oursours.net/

Jacti wrote:

(snip)

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 ?

Un langage qui utilise l'indentation comme forme syntaxique de bloc
ne peut pas être un "bon" langage... (c'est inexprimable en BNF).

Ce n'est pas la première fois que tu nous la sors, celle-là !-)

Bon, à part que *tu* n'aimes pas ce principe - ce qui es ton droit le
plus strict-, la seule chose que ça prouve est le formalisme BNF est
limité. Je pense que tu connais assez la POO et des langages comme
Smalltalk ou CLOS pour avoir sous la main des idiomes courant dans ces
langages qui sont à peu près inexprimables en UML. Si oui, celà
implique-t'il que Smalltalk et CLOS soient de mauvais langages objets ?-)

Non ça prouve que c'est UML qui n'a pas su s'adapter car ces langages existaient
avant

PAQJS, il existait aussi des langages avant la BNF...

et comme l'approche OO s'est construite de façon bottom-up...

Et donc, le fait que le formalisme BNF ne permette pas d'exprimer
l'utilisation de l'indentation dans la syntaxe prouve seulement que le
formalisme BNF ne permet pas d'exprimer l'utilisation de l'indentation
dans la syntaxe (oui, c'est une tautologie...). Ca ne dit rien des
qualités et défauts de Python.

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...

Bien sûr que VB n'est pas sur le même plan que Python (tout de même !), VB
étant le "Canada Dry" des LOO

<hs>
Crois-le ou non, mais il y a pire que VB. Si si, c'est possible...
</hs>

mais du point de vue qui nous occupe ici,
ils sont aussi "sales" (même si ce n'est pas le même type de saletés).

Jugement de valeur encore. 30 ans d'expérience ne suffisent pas à faire
passer un jugement de valeur pour une critique argumentée.

On verra bien quand il faudra, dans le moyen terme, maintenir tout le code qui
s'écrit avec ces langages. Sauf à considérer que tout ça c'est jetable...

Python existe depuis 1990, ça fait donc maintenant 15 ans. C'est
suffisant comme moyen terme ? Parce que pour le moment, ça ne semble pas
poser de problèmes majeurs. Quant à la maintenance de programmes en C,
ce n'est pas une nouveauté...

<troll mode="wha l'autre eh moi aussi je peux le faire">
Si tu veux un langage qui pose des problèmes de maintenance, regarde
plutôt du côté de Perl
</troll>

(snip)

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

C'est vraiment la redécouverte de la poudre !

Non, pas la "redécouverte", juste l'utilisation. PAQJS, il n'y a rien de
nouveau en Python - et je n'ai jamais vu personne le prétendre (en tout
cas personne ayant un minimum de culture dans ce domaine). Là encore, je
te trouve de bien mauvaise foi.

Ce n'est pas de la mauvaise foi, c'est un constat.

Quel "constat" ? Le constat que Python se démerdre pour intégrer des
bonnes idées venant d'autres langages ? je ne vois toujours pas le
rapport avec ton commentaire sur la poudre.

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.

Bonjour la simplicité syntaxique de Python !!

Je n'ai pas parlé de "simplicité syntaxique", mais de simplicité
d'utilisation. Mais si tu veux aller sur ce terrain, je veux bien que tu
me démontre en quoi l'utilisation de *deux* point-virgules à la fin
d'une expression relève de la "simplicité syntaxique" !-)

Contrairement à ce que tu crois, je ne suis pas forcément un farouche partisan de la
syntaxe
de Caml.

Ce qui n'empêche pas que ce soit un de tes langages préférés... Bref,
ton commentaire sur la simplicité syntaxique de Python était là aussi de
mauvaise foi (si si, j'insiste).

Par contre c'est un très bon langage du point de vue de la puissance
d'expression (sémantique).

Comme quoi l'un n'empêche pas l'autre...

<ironie>
Quant à la simplicité d'utilisation, il faut bien avouer que les
entrées/sorties en Haskell sont d'une simplicité remarquables
</ironie>

On est d'accord...

Bref, le purisme, c'est bien beau, mais ça a des limites...

Je ne suis pas puriste

Ah bon ?

mais il y a des limites aux arguments des défenseurs du
"pragmatisme".

<troll> Oui, Perl par exemple !-p </troll>

On ne peut pas faire un VRAI système d'exploitation

C'est quoi un "VRAI" système d'exploitation ?-)

Ben des choses comme UNIX par exemple.

Bien... Et tu peux nous rappeller quels sont les principaux langages
utilisés pour implémenter la plupart des systèmes de type UNIX existant?

Je voulais exclure des "choses" comme Windows.

<ot destinataire="do re michel la si do">
Michel, toi qui me soupçonne de troller à chaque fois je parles de MS...
</ot>

sans un mécanisme
de macros

Lequel ? Celui du préprocesseur C ?-)

M'en fiche, je ne fais pas d'OS. Ni de contrôle de missiles, d'ailleurs.

Oui mais pas moi car j'en ai fait.

Et alors ? Ce n'est parce qu'un tournevis n'est pas vraiment adapté au
plantage de clou que ça en fait un mauvais outil, non ?

(snip)

Mais bon, on a déjà eu plusieurs fois l'occasion de troller^Mdébattre de
ces sujets, et, hélas, la seule chose que ça m'a appris est que tu a 30
ans d'expérience et que tu sais de quoi tu parles...

Il me semblait pourtant avoir argumenté suffisamment, au moins par le passé,

Hem... Pour le moment, ton argumentation se résume à "Python est un
mauvais langage parce qu'il n'est pas exprimable en BNF et qu'il ne
correspond pas à mes besoins, et je sais de quoi je parles parce que
j'ai trente d'expérience et que j'ai lu l'intégrale de Knuth".

J'ai bien peur de ne pas être vraiment convaincu...

et rappelé certaines connaissances

fourni des liens vers des papiers écrits par d'autres, oui, à l'occasion...

que certains semblent avoir oubliées (pour rester
optimiste).

Reste optimiste, reste optimiste... Avec un peu de chance, on va bientôt
faire passer une loi pour interdire à toute personne n'ayant pas trente
ans d'expérience et ne connaissant pas l'intégrale de Knuth sur le bout
des doigts l'exercice de la profession de développeur. Comme ça, tu aura
de quoi t'occuper, ça t'évitera de perdre ton temps a essayer de ramener
dans le droit chemin les infâmes bidouilleurs que nous sommes.

Candidat suivant, s'il vous plait ?

--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"

j'ai beau essayer de me retenir à deux mains depuis quelques jours, je
craques. cela ne donne pas envie d'avoir 30 ans d'expérience et de
sortir des chomsky 3-0 à tour de bras.

Jacti wrote:

Bon, à part que *tu* n'aimes pas ce principe - ce qui es ton droit le
plus strict-, la seule chose que ça prouve est le formalisme BNF est
limité. Je pense que tu connais assez la POO et des langages comme
Smalltalk ou CLOS pour avoir sous la main des idiomes courant dans ces
langages qui sont à peu près inexprimables en UML. Si oui, celà
implique-t'il que Smalltalk et CLOS soient de mauvais langages objets ?-)

Non ça prouve que c'est UML qui n'a pas su s'adapter car ces langages existaient
avant et comme l'approche OO s'est construite de façon bottom-up...

UML s'adapter aux langages objets... eh ben, on est pas dans la merde.
UML est une *notation* pour exprimer des éléments de *conceptions* alors
que les autres langages sont de *programmation*. moralité, autant
comparer une truelle et une table à dessin... oui la truelle était là
avant...

mes excuses d'avoir craqué... je suis faible

--
rafi

"Imagination is more important than knowledge."
(Albert Einstein)

j'ai beau essayer de me retenir à deux mains depuis quelques jours, je
craques. cela ne donne pas envie d'avoir 30 ans d'expérience et de
sortir des chomsky 3-0 à tour de bras.

Jacti wrote:

Ah non, ça c'est moi qui l'ai écrit.

Bon, à part que *tu* n'aimes pas ce principe - ce qui es ton droit le
plus strict-, la seule chose que ça prouve est le formalisme BNF est
limité. Je pense que tu connais assez la POO et des langages comme
Smalltalk ou CLOS pour avoir sous la main des idiomes courant dans ces
langages qui sont à peu près inexprimables en UML. Si oui, celà
implique-t'il que Smalltalk et CLOS soient de mauvais langages objets
?-)

Là, effectivement, c'est bien Jacti...

Non ça prouve que c'est UML qui n'a pas su s'adapter car ces langages
existaient
avant et comme l'approche OO s'est construite de façon bottom-up...

UML s'adapter aux langages objets...
eh ben, on est pas dans la merde.
UML est une *notation* pour exprimer des éléments de *conceptions* alors
que les autres langages sont de *programmation*.

Dans les deux cas, ce sont des langages... Il y a une théorie - pas
dénuée d'intérêt d'ailleurs - selon laquelle le code source d'un
programme est lui-même une spécification détaillée - le produit fini
étant le process durant son exécution. Sans forcément aller aussi loin,
il faut bien reconnaître qu'entre un source Python et le langage machine
généré lors de l'exécution de ce source, il y a une marge très
importante, et qu'on peut aussi bien considérer le source Python comme
une notation pour exprimer une conception *détaillée* plus que comme un
produit fini.

Le problème avec UML - langage destiné, donc, à exprimer des conceptions
- est qu'il ne permet pas - ou, en tous cas, je n'ai pas trouvé le
moyen de le faire, mais je ne dois pas être le seul - d'exprimer
lisiblement certains idiomes/modèles de conceptions couramment employés
dans des langages de haut niveau comme Python, Ruby ou CLOS - sans
parler des langages à prototype (Self, Io, Javascript, ...). Dans
certains cas, le code source exprime mieux (au sens de plus lisiblement)
la conception que le modèle UML.

moralité, autant
comparer une truelle et une table à dessin...

Euh... Les deux sont des outils ? J'ai bon là ?-)

oui la truelle était là
avant...

Je ne suis pas sûr que ton analogie soit si pertinente. Mais bon, c'est
un point de vue, n'est-ce pas ?

mes excuses d'avoir craqué... je suis faible

Mais non, mais non...

Jacti wrote:

Un langage qui utilise l'indentation comme forme syntaxique de bloc
ne peut pas être un "bon" langage... (c'est inexprimable en BNF).

Celle là, il faut la coller dans un fortune consacré à Python.

Mais faites donc, c'est fait pour ça justement.

Il l'a fait... Voilà, tu es entré dans l'Histoire. Heureux ?-)

Bruno Desthuilliers wrote:

UML est une *notation* pour exprimer des éléments de *conceptions*
alors que les autres langages sont de *programmation*.

Dans les deux cas, ce sont des langages...

oui c'est vrai, mais avec des finalités différentes donc (à mon humble
avis) non comparable. ce serait comme comparer Python et le français: ce
sont des langages.

Il y a une théorie - pas
dénuée d'intérêt d'ailleurs - selon laquelle le code source d'un
programme est lui-même une spécification détaillée

je suis d'accord sur ce point

importante, et qu'on peut aussi bien considérer le source Python comme
une notation pour exprimer une conception *détaillée* plus que comme un
produit fini.

je suis toujours d'accord, bien que je remplacerait conception par
spécification somme tu le faisais au début de ce paragraphe.

Le problème avec UML - langage destiné, donc, à exprimer des conceptions
- est qu'il ne permet pas - ou, en tous cas, je n'ai pas trouvé le
moyen de le faire, mais je ne dois pas être le seul - d'exprimer
lisiblement certains idiomes/modèles de conceptions couramment employés
dans des langages de haut niveau comme Python, Ruby ou CLOS - sans
parler des langages à prototype (Self, Io, Javascript, ...). Dans

je suis toujours d'accord avec toi, mais ici encore je pense que les
finalités sont différentes, et c'est pour cela que je trouve ton
utilisation d'idiome pertinente par opposition aux patrons de conception
en UML. idiomes et patrons de conception sont deux choses distincts à
deux niveaux différents. et UML n'est pas fait pour exprimer des
idiomes, ni même des traitements (ou si peu). c'est pour cela que la
comparaison UML / langage de programmation me surprend.

je suis d'accord aussi que d'un point de vue plus théorique UML peut
être considéré comme exécutable, puisqu'il est possible de faire un
interpréteur d'UML qui va produire une nouvelle spécification d'un
système dans un espace technologique différent. c'est une des bases de
l'ingénierie dirigée par les modèles (comme MDA) avec les
transformations de modèles.

certains cas, le code source exprime mieux (au sens de plus lisiblement)
la conception que le modèle UML.

hmmm j'ai du mal à acheter ici, mais c'est peut être due à ma définition
de 'conception' qui est distincte de 'réalisation' ou 'mise en oeuvre'.
désolé, je suis parfois un peu rigide.

moralité, autant comparer une truelle et une table à dessin...

Je ne suis pas sûr que ton analogie soit si pertinente. Mais bon, c'est
un point de vue, n'est-ce pas ?

il est vrai que toute analogie a ses limites, mais le message était: uml
permet de faire des plans des sytèmes comme la table des plans de murs,
alors que python permet de construire les systèmes comme la truelle des
murs.

et il reste plus simple d'appréhender un diagramme de classe uml de 20
boîtes qu'un programme python de 2000 lignes. (je suis toujours d'accord
avec toi pour dire que dans le second il y aura plus de détails)

mes excuses d'avoir craqué... je suis faible

Mais non, mais non...

"la meilleur façon de ne pas perdre un combat est de l'éviter" (devise
de kung fu) ;-)

--
rafi

"Imagination is more important than knowledge."
(Albert Einstein)

rafi wrote:

Bruno Desthuilliers wrote:

NB : xpost et fu2 fr.comp.objet. On devient vraiment HS ici...

NB2 : Tout ce que j'énonce dans ce post ne saurait être qu'un avis
personnel, et comme seuls les imbéciles ne changent pas d'avis, je me
réserve le droit de me contredire à l'avenir. Vous voilà prévenus !-)

UML est une *notation* pour exprimer des éléments de *conceptions*
alors que les autres langages sont de *programmation*.

Dans les deux cas, ce sont des langages...

oui c'est vrai, mais avec des finalités différentes donc (à mon humble
avis) non comparable. ce serait comme comparer Python et le français: ce
sont des langages.

UML et les langages de programmation ont tout de même bien de plus de
point communs, que ce soit dans le formalisme ou dans les finalités,
qu'un langage informatique (quelqu'il soit : programmation, requete,
description, conception etc) et un langage 'naturel'.

Il y a une théorie - pas dénuée d'intérêt d'ailleurs - selon laquelle
le code source d'un programme est lui-même une spécification détaillée

je suis d'accord sur ce point

importante, et qu'on peut aussi bien considérer le source Python comme
une notation pour exprimer une conception *détaillée* plus que comme
un produit fini.

je suis toujours d'accord, bien que je remplacerait conception par
spécification somme tu le faisais au début de ce paragraphe.

La frontière entre les deux est ténue. Très ténue.

Le problème avec UML - langage destiné, donc, à exprimer des
conceptions - est qu'il ne permet pas - ou, en tous cas, je n'ai pas
trouvé le moyen de le faire, mais je ne dois pas être le seul -
d'exprimer lisiblement certains idiomes/modèles de conceptions
couramment employés dans des langages de haut niveau comme Python,
Ruby ou CLOS - sans parler des langages à prototype (Self, Io,
Javascript, ...). Dans

je suis toujours d'accord avec toi, mais ici encore je pense que les
finalités sont différentes, et c'est pour cela que je trouve ton
utilisation d'idiome pertinente par opposition aux patrons de conception
en UML.

Mais je n'oppose pas les deux... Certains modèles "de conception" n'ont
guère de sens quand le langage fournit déjà le support nécessaire. Relis
attentivement le pattern Visiteur dans le GoF, les auteurs précisent en
toutes lettres que ce pattern n'a aucun sens en CLOS qui fournit
nativement le multidispatch. De même, si on prend la description du
pattern Etat, on voit que ce pattern n'a pas lieu d'être en Python où
l'on peut très simplement changer la classe d'un objet à l'exécution.
Encore un: les décorateurs de fonction Python : idiome ou pattern ? Et
les itérateurs ?

En fait, une grande partie des modèles présentés dans le GoF ont pour
finalité d'introduire un peu de dynamisme dans des langages statiques,
et ce n'est certainement pas un hasard si la plupart sont illustrés par
des exemples en C++, et seulement quelques uns en Smalltalk.

idiomes et patrons de conception sont deux choses distincts à
deux niveaux différents.

Pas tant que ça... Quoi qu'en pensent certains, il n'y a pas de
frontière claire entre conception et implémentation, et l'idée même
qu'une conception puisse être *totalement* indépendante du langage
d'implémentation me semble parfaitement surréaliste. <AMHA>Au mieux, on
aura une conception suffisament générique pour pouvoir être implémentée
avec plus ou moins de bonheur dans un nombre fini de langages</AMHA>.

et UML n'est pas fait pour exprimer des
idiomes,

C'est pourtant ainsi qu'il est utilisé dans le GoF. Le modèle itérateur
en est un exemple flagrant: tel qu'il est décrit, c'est typiquement un
idiome C++/Java. En Python, les itérateurs sont partie intégrante du
langage - et je veux bien que tu me modélise ça en UML...

ni même des traitements (ou si peu).

Effectivement, tenter de décrire un traitement en UML relève plus du
masochisme que d'autre chose... (enfin, ça dépend bien sûr de la
granularité souhaitées...)

c'est pour cela que la
comparaison UML / langage de programmation me surprend.

Personnellemnt, je la trouve évidente. Ce sont (ou ce devraient être)
des niveaux d'abstraction successifs, et c'est toute l'histoire de
l'informatique. Le problème étant ici que (toujours AMHA), UML est trop
empêtré dans un modèle spécifique à un petit sous-ensemble de l'OO pour
permettre d'exprimer certains modèles, et évacue le problème en
considérant ces modèles comme des idiomes...

je suis d'accord aussi que d'un point de vue plus théorique UML peut
être considéré comme exécutable, puisqu'il est possible de faire un
interpréteur d'UML qui va produire une nouvelle spécification d'un
système dans un espace technologique différent. c'est une des bases de
l'ingénierie dirigée par les modèles (comme MDA) avec les
transformations de modèles.

Je crains que tout cela ne relève plus du fantasme marketing que de la
réalité effective... Quand on voit le fiasco qu'on été les CASE tools...

certains cas, le code source exprime mieux (au sens de plus
lisiblement) la conception que le modèle UML.

hmmm j'ai du mal à acheter ici, mais c'est peut être due à ma définition
de 'conception' qui est distincte de 'réalisation' ou 'mise en oeuvre'.

Pour moi, la mise en oeuvre, c'est un programme en cours d'exécution.
Tout le reste relève de la spécification - à un niveau d'abstraction ou
à un autre. Même le code binaire n'est qu'une spécification, que l'on
fournit au processeur, lequel exécute (réalise) cette spécification...

désolé, je suis parfois un peu rigide.

Mais non, mais non !-)

moralité, autant comparer une truelle et une table à dessin...

Je ne suis pas sûr que ton analogie soit si pertinente. Mais bon,
c'est un point de vue, n'est-ce pas ?

il est vrai que toute analogie a ses limites, mais le message était: uml
permet de faire des plans des sytèmes comme la table des plans de murs,
alors que python permet de construire les systèmes comme la truelle des
murs.

Le mien est: uml permet (éventuellement...) de faire un crobard, Python
permet de faire les plans, et le processeur réalise le tout.

et il reste plus simple d'appréhender un diagramme de classe uml de 20
boîtes qu'un programme python de 2000 lignes.

Il est aussi bien plus simple d'appréhender un crobard qu'un plan
d'architecte.

mes deux centimes...
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"