Re: Python
Thierry B.
>> La question que je me pose c'est : que sera Python dans 5 ans ?
>> Peut-être un langage complètement délaissé. Je ne vois pas qu'on
>> enseigne Python dans les facs ou dans les écoles, j'ai l'impression que
Pourtant, j'aimerais bien que ça soit enseigné dans les écoles.
C'est (opinion personnelle) un langage qui est à la fois facile:
on arrive très vite à faire des petits programmes qui marchent,
et didactique: pour que ça soit facile, il faut être un brin
rigoureux, un brin précis, il faut réfléchir avant d'écrire la
moindre ligne. Testé et approuvé par mes deux enfants (10 & 13).
Quand à son enseignement dans les facs, je dis oui aussi. Pour
les mêmes raisons, d'abord; et surtout pour les domaines couverts:
calcul scientifique, traitement du texte, interfaces graphiques,
interfaces avec d'autres langages/logiciels. On peut le voir comme
un langage "glue" qui permet de concentrer ses efforts sur le
résultat à atteindre, et pas sur les moyens à utiliser.
>> c'est un langage marginal voire déconsidéré. Par contre, Java, lui est
>> toujours là.
>
> Comment comparer Java et Python ????
En essayant les deux ? Ou mieux, en demandant à son gamin de
tester :)
> Java est utilisé dans des applications importantes qui requièrent
> fiabilité, évolutivité, etc. (comme les applications militaires).
Fiabilité et Java, mmm, j'ai un doute, là. (j'vais m'faire des
ennemis, je crois). Enfin, ça a peut-être changé depuis le
temps où j'en faisais sérieusement...
> Où est Python dans l'industrie ??? NULLE PART
Google, Yahoo, Zope/Plone, les jeux, que sais-je encore...
> Python est bien un langage marginal.
Entre la marge et la limite, quoi...
+++ et comme ça commence à devenir HC, je vais me permettre un
multipost d'enfer, avec un foutou à suivre pour ceux qui
veulent bien continuer à discuter des langages de demain,
et de leur utilisation dans l'enseignement.
--
rpm -q --qf "%{NAME}\t%{OS}\t%{ARCH}\n" -p /proc/kcore /dev/kmem
Wykaaa
> --{ wykaaa a plopé ceci: }--
>
>>> La question que je me pose c'est : que sera Python dans 5 ans ?
>>> Peut-être un langage complètement délaissé. Je ne vois pas qu'on
>>> enseigne Python dans les facs ou dans les écoles, j'ai l'impression que
>
> Pourtant, j'aimerais bien que ça soit enseigné dans les écoles.
> C'est (opinion personnelle) un langage qui est à la fois facile:
> on arrive très vite à faire des petits programmes qui marchent,
> et didactique: pour que ça soit facile, il faut être un brin
> rigoureux, un brin précis, il faut réfléchir avant d'écrire la
> moindre ligne. Testé et approuvé par mes deux enfants (10 & 13).
Ce serait beaucoup mieux, pour tes enfants et l'avenir de la
programmation qu'ils se mettent au langage Logo. Voilà un langage
vraiment didactique (il a été fait pour).
Je te conseille de consulter cette page :
http://www.ordiecole.com/logo/jail_espr.html
>
> Quand à son enseignement dans les facs, je dis oui aussi. Pour
> les mêmes raisons, d'abord; et surtout pour les domaines couverts:
> calcul scientifique, traitement du texte, interfaces graphiques,
> interfaces avec d'autres langages/logiciels. On peut le voir comme
> un langage "glue" qui permet de concentrer ses efforts sur le
> résultat à atteindre, et pas sur les moyens à utiliser.
Surtout ne pas l'enseigner dans les écoles !!
Un langage qui permet d'utiliser des variables sans les déclarer doit
être banni de l'enseignement de la programmation.
>
>>> c'est un langage marginal voire déconsidéré. Par contre, Java, lui est
>>> toujours là.
>> Comment comparer Java et Python ????
>
> En essayant les deux ? Ou mieux, en demandant à son gamin de
> tester :)
C'est sûr que Java n'est pas pour les enfants. Encore une fois le
meilleur langage pour eux est Logo.
>
>> Java est utilisé dans des applications importantes qui requièrent
>> fiabilité, évolutivité, etc. (comme les applications militaires).
>
> Fiabilité et Java, mmm, j'ai un doute, là. (j'vais m'faire des
> ennemis, je crois). Enfin, ça a peut-être changé depuis le
> temps où j'en faisais sérieusement...
Merci d'argumenter en nous donnant des exemples.
>
>> Où est Python dans l'industrie ??? NULLE PART
>
> Google, Yahoo, Zope/Plone, les jeux, que sais-je encore...
Combien de Python dans Google et Yahoo ?
Là encore, il faut des arguments.
>
>> Python est bien un langage marginal.
>
> Entre la marge et la limite, quoi...
>
> +++ et comme ça commence à devenir HC, je vais me permettre un
> multipost d'enfer, avec un foutou à suivre pour ceux qui
> veulent bien continuer à discuter des langages de demain,
> et de leur utilisation dans l'enseignement.
Très bonne initiative. Utilisons ce forum sous-utilisé qu'est
fr.comp.lang.general.
PS : perso, je n'aurais pas intitulé le sujet de cette manière mais
plutôt : langages pour l'enseignement de la programmation - langages
pour l'industrie ou quelque chose comme ça.
candide
> --{ wykaaa a plopé ceci: }--
>
>>> La question que je me pose c'est : que sera Python dans 5 ans ?
>>> Peut-être un langage complètement délaissé. Je ne vois pas qu'on
>>> enseigne Python dans les facs ou dans les écoles, j'ai l'impression que
>
> Pourtant, j'aimerais bien que ça soit enseigné dans les écoles.
Les écoles primaires ?
>
> Quand à son enseignement dans les facs, je dis oui aussi.
Tiens , je ferai un sondage à la prochaine réunion à la fac pour voir
combien connaissent Python. Sinon, je pense qu'il faudrait que les
étudiants des formations scientifiques, (enfin sciences dures parce que
je faisais au 1er semestre des TP pour le C2I aux étudiants de biologie,
wouah, faut s'accrocher) disposent d'UN SEUL langage appris très tôt
(dès le S1) pour qu'en licence L3 et au-delà, le langage soit réellement
utilisable parce que suffisamment dominé. Et il faut un langage qui soit
par exemple capable de monter facilement un GUI donc C n'est pas
vraiment le bon choix.
> En essayant les deux ? Ou mieux, en demandant à son gamin de
> tester :)
Bon, le mien est encore un peu jeune... Tiens, connais-tu ça :
Wykaaa
> Thierry B. a écrit :
>> --{ wykaaa a plopé ceci: }--
>>
>>>> La question que je me pose c'est : que sera Python dans 5 ans ?
>>>> Peut-être un langage complètement délaissé. Je ne vois pas qu'on
>>>> enseigne Python dans les facs ou dans les écoles, j'ai l'impression
>>>> que
>>
>> Pourtant, j'aimerais bien que ça soit enseigné dans les écoles.
>
> Les écoles primaires ?
Non, pitié, pas Python dans les écoles primaires, mais Logo oui!!
(voir : http://www.ordiecole.com/logo/jail_espr.html)
>
>
>>
>> Quand à son enseignement dans les facs, je dis oui aussi.
>
> Tiens , je ferai un sondage à la prochaine réunion à la fac pour voir
> combien connaissent Python. Sinon, je pense qu'il faudrait que les
> étudiants des formations scientifiques, (enfin sciences dures parce que
> je faisais au 1er semestre des TP pour le C2I aux étudiants de biologie,
> wouah, faut s'accrocher) disposent d'UN SEUL langage appris très tôt
> (dès le S1) pour qu'en licence L3 et au-delà, le langage soit réellement
> utilisable parce que suffisamment dominé. Et il faut un langage qui soit
> par exemple capable de monter facilement un GUI donc C n'est pas
> vraiment le bon choix.
>
>
>
>> En essayant les deux ? Ou mieux, en demandant à son gamin de
>> tester :)
>
>
> Bon, le mien est encore un peu jeune... Tiens, connais-tu ça :
>
> http://www.myflex.org/books/JavaKid8x11.pdf ?
Très bien ce document.
J'ai aimé :
int y=5;
y++;
Despite the two plus signs, JVM is still going to increment the value of
the variable y by one.
:-)))
Laurent Pointal
> Thierry B. a écrit :
>> --{ wykaaa a plopé ceci: }--
>>
>>>> La question que je me pose c'est : que sera Python dans 5 ans ?
>>>> Peut-être un langage complètement délaissé. Je ne vois pas qu'on
>>>> enseigne Python dans les facs ou dans les écoles, j'ai l'impression
>>>> que
Ca l'est - cf ci-dessous.
>> Pourtant, j'aimerais bien que ça soit enseigné dans les écoles. C'est
>> (opinion personnelle) un langage qui est à la fois facile: on arrive
>> très vite à faire des petits programmes qui marchent, et didactique:
>> pour que ça soit facile, il faut être un brin rigoureux, un brin
>> précis, il faut réfléchir avant d'écrire la moindre ligne. Testé et
>> approuvé par mes deux enfants (10 & 13).
>
> Ce serait beaucoup mieux, pour tes enfants et l'avenir de la
> programmation qu'ils se mettent au langage Logo. Voilà un langage
> vraiment didactique (il a été fait pour).
Logo est tout à fait appréciable, idéal pour apprendre à des enfants en
primaire les principes de la programmation.
Mais Python a lui-aussi été fait pour l'apprentissage de la
programmation, mais à un niveau un peu plus élevé (note, tu peux faire tu
LOGO en Python, il y a un module standard turtle ainsi qu'un module tiers
xturtle un peu plus puissant).
Voir le lien CP4E: http://www.python.org/doc/essays/cp4e.html
> Je te conseille de consulter cette page :
> http://www.ordiecole.com/logo/jail_espr.html
>>
>> Quand à son enseignement dans les facs, je dis oui aussi. Pour les
>> mêmes raisons, d'abord; et surtout pour les domaines couverts: calcul
>> scientifique, traitement du texte, interfaces graphiques, interfaces
>> avec d'autres langages/logiciels. On peut le voir comme un langage
>> "glue" qui permet de concentrer ses efforts sur le résultat à
>> atteindre, et pas sur les moyens à utiliser.
>
> Surtout ne pas l'enseigner dans les écoles !! Un langage qui permet
> d'utiliser des variables sans les déclarer doit être banni de
> l'enseignement de la programmation.
AMA il ne faut pas le prendre comme ça.
Si tu enseignes la programmation à des gens dont ça va être le métier, il
faut quelque chose qui soit éventuellement plus lourd, et oblige à
apprendre de bonnes méthodes (typiquement ADA).
Il leur faudra aussi apprendre des langages avec d'autres paradigmes, et
ils ne pourront passer à côté du C et de l'inévitable Java.
Si tu enseignes à des personnes pour qui la programmation n'est qu'une
unité de valeur obligatoire dans leur cursus, qui leur servira peut-être
plus tard (mais pas sûr), alors autant leur apprendre un langage qui leur
permette de faire simplement des choses puissantes,:interfaces
graphiques, accès fichiers, liens avec des bases de données, manipulation
des protocoles de l'internet...
Par exemple, à l'IUT d'Orsay en mesures physiques, le langage choisi pour
l'unité d'informatique scientifique est Python (avant c'était le C) et
l'enseignant en est très content.
Autre exemple, il y a quelques années un pote à moi a été chargé de faire
l'enseignement de programmation pour des étudiants en économie... il a
choisi Python, et leur a appris à manipuler une base de données, extraire
ce qu'ils en veulent, générer des fichiers, etc...
[et le duck-typing à l'exécution sur les variables ne pose pas de
problème - sauf aux personnes qui sont habituées à un typage statique
déclaré et qui ont érigé en dogme qu'on ne pouvait pas faire autrement]
>>>> c'est un langage marginal voire déconsidéré. Par contre, Java, lui
>>>> est toujours là.
Déconsidéré par les gens qui ne le considèrent pas :-)
Python monte doucement, il n'y a pas derrière la puissance commerciale
d'un Sun ou d'un Microsoft... et pourtant il s'installe.
Annecdote: des étudiants de l'IUT sus-cité discutaient de leurs cours
Python en rentrant chez eux dans le RER... un passager s'est dit
intéressé et leur a donné sa carte, il est directeur d'une boite qui
utilise Python et cherche des stagiaires qui connaissent ce langage...
>>> Comment comparer Java et Python ????
>>
>> En essayant les deux ? Ou mieux, en demandant à son gamin de tester
>> :)
>
> C'est sûr que Java n'est pas pour les enfants. Encore une fois le
> meilleur langage pour eux est Logo.
>>
>>> Java est utilisé dans des applications importantes qui requièrent
>>> fiabilité, évolutivité, etc. (comme les applications militaires).
>>
>> Fiabilité et Java, mmm, j'ai un doute, là. (j'vais m'faire des
>> ennemis, je crois). Enfin, ça a peut-être changé depuis le temps où
>> j'en faisais sérieusement...
>
> Merci d'argumenter en nous donnant des exemples.
>>
>>> Où est Python dans l'industrie ??? NULLE PART
>>
>> Google, Yahoo, Zope/Plone, les jeux, que sais-je encore...
http://www.python.org/about/quotes/
(petite liste)
C'est le problème de Python, les gens l'utilisent "naturellement", mais
ne le mettent pas en avant, et comme il n'y a pas une grosse boite
derrière pour faire la 'com'.
> Combien de Python dans Google et Yahoo ? Là encore, il faut des
> arguments.
>>> Python est bien un langage marginal.
>>
>> Entre la marge et la limite, quoi...
>>
>> +++ et comme ça commence à devenir HC, je vais me permettre un
>> multipost d'enfer, avec un foutou à suivre pour ceux qui veulent
>> bien continuer à discuter des langages de demain, et de leur
>> utilisation dans l'enseignement.
>
> Très bonne initiative. Utilisons ce forum sous-utilisé qu'est
> fr.comp.lang.general.
> PS : perso, je n'aurais pas intitulé le sujet de cette manière mais
> plutôt : langages pour l'enseignement de la programmation - langages
> pour l'industrie ou quelque chose comme ça.
Ca a été heureusement relayé, sinon je n'aurais pas vu cette intéressante
et si peu partisanne discussion ;-)
A+
Laurent.
--
Laurent POINTAL - laurent...@laposte.net
Thierry B.
>> C'est (opinion personnelle) un langage qui est à la fois facile:
>> on arrive très vite à faire des petits programmes qui marchent,
>> et didactique: pour que ça soit facile, il faut être un brin
>> rigoureux, un brin précis, il faut réfléchir avant d'écrire la
>> moindre ligne. Testé et approuvé par mes deux enfants (10 & 13).
>
> Ce serait beaucoup mieux, pour tes enfants et l'avenir de la
> programmation qu'ils se mettent au langage Logo. Voilà un langage
> vraiment didactique (il a été fait pour).
Oké, le Logo, je connais ça depuis 20 ans, et il a de bonnes
vertues didactiques, mais voilà, son utilité pratique est
assez limitée. Alors que Python est en prise directe avec
le monde réel: interface graphique, IPC, réseau, toussa...
Et si c'est pour jouer avec une tortue, Python a en standard
un module "turtle" assez bien foutu :)
> Je te conseille de consulter cette page :
> http://www.ordiecole.com/logo/jail_espr.html
>>
>> Quand à son enseignement dans les facs, je dis oui aussi. Pour
>
> Surtout ne pas l'enseigner dans les écoles !!
Attention, ne pas confondre école primaire et université,
hein. Et ne pas confondre enseignement d'un langage dans
un cursus "programmation" ou dans un cursus "autre".
> Un langage qui permet d'utiliser des variables sans les déclarer doit
> être banni de l'enseignement de la programmation.
Alors là, il va falloir argumenter un peu, parce que tu
viens de te contredire, il me semble. Ou alors tu n'est
qu'un troll qui se base sur des on-dit-que.
>> En essayant les deux ? Ou mieux, en demandant à son gamin de
>> tester :)
>
> C'est sûr que Java n'est pas pour les enfants. Encore une fois le
> meilleur langage pour eux est Logo.
Pourquoi ?
>> Fiabilité et Java, mmm, j'ai un doute, là. (j'vais m'faire des
>> ennemis, je crois). Enfin, ça a peut-être changé depuis le
>> temps où j'en faisais sérieusement...
>
> Merci d'argumenter en nous donnant des exemples.
J'ai de mauvais souvenirs avec le GC qui démarrait un peu
n'importe comment, et de subtiles incompatibilités entre
différentes générations de VM.
>> Google, Yahoo, Zope/Plone, les jeux, que sais-je encore...
>
> Combien de Python dans Google et Yahoo ?
> Là encore, il faut des arguments.
Il faut aller leur demander, ils en parlent assez.
--
http://tontonth.free.fr/plop/index.php/2007/12/29/36-voiture-de-course
Thierry B.
>> Pourtant, j'aimerais bien que ça soit enseigné dans les écoles.
>
> Les écoles primaires ?
>
Oui, pourquoi pas ? En fait, je pensais fin primaire/collège.
>> Quand à son enseignement dans les facs, je dis oui aussi.
>
> Tiens , je ferai un sondage à la prochaine réunion à la fac pour voir
> combien connaissent Python. Sinon, je pense qu'il faudrait que les
> étudiants des formations scientifiques, (enfin sciences dures parce que
> je faisais au 1er semestre des TP pour le C2I aux étudiants de biologie,
> wouah, faut s'accrocher) disposent d'UN SEUL langage appris très tôt
Pourquoi se limiter aux sciences dures ? De nos jours, la multipli-
cation des engins numériques en tout genre a presque fait oublier
aux gens qu'un ordinateur se peut aussi se programmer pour lui
demander quelque chose de particulier. Une initiation/présentation
d'un langage moderne pourrait être bénéfique, surtout si c'est
adapté à des sujets pratiques. Mais bon, on peut toujours réver...
> (dès le S1) pour qu'en licence L3 et au-delà, le langage soit réellement
> utilisable parce que suffisamment dominé. Et il faut un langage qui soit
> par exemple capable de monter facilement un GUI donc C n'est pas
> vraiment le bon choix.
Voilà une bonne démarche.
> Bon, le mien est encore un peu jeune... Tiens, connais-tu ça :
>
> http://www.myflex.org/books/JavaKid8x11.pdf ?
>
--
0000000 113 151 113 157 157 040 154 060 154 040 164 162 157 160 040 115
0000020 104 122 012
Wykaaa
> --{ Wykaaa a plopé ceci: }--
>
>>> C'est (opinion personnelle) un langage qui est à la fois facile:
>>> on arrive très vite à faire des petits programmes qui marchent,
>>> et didactique: pour que ça soit facile, il faut être un brin
>>> rigoureux, un brin précis, il faut réfléchir avant d'écrire la
>>> moindre ligne. Testé et approuvé par mes deux enfants (10 & 13).
>> Ce serait beaucoup mieux, pour tes enfants et l'avenir de la
>> programmation qu'ils se mettent au langage Logo. Voilà un langage
>> vraiment didactique (il a été fait pour).
>
> Oké, le Logo, je connais ça depuis 20 ans, et il a de bonnes
> vertues didactiques, mais voilà, son utilité pratique est
> assez limitée. Alors que Python est en prise directe avec
> le monde réel: interface graphique, IPC, réseau, toussa...
>
> Et si c'est pour jouer avec une tortue, Python a en standard
> un module "turtle" assez bien foutu :)
>
>> Je te conseille de consulter cette page :
>> http://www.ordiecole.com/logo/jail_espr.html
>>> Quand à son enseignement dans les facs, je dis oui aussi. Pour
>> Surtout ne pas l'enseigner dans les écoles !!
>
> Attention, ne pas confondre école primaire et université,
> hein. Et ne pas confondre enseignement d'un langage dans
> un cursus "programmation" ou dans un cursus "autre".
Je suis bien d'accord qu'il faut dissocier tous ces éléments.
>
>> Un langage qui permet d'utiliser des variables sans les déclarer doit
>> être banni de l'enseignement de la programmation.
>
> Alors là, il va falloir argumenter un peu, parce que tu
> viens de te contredire, il me semble. Ou alors tu n'est
> qu'un troll qui se base sur des on-dit-que.
>
Contredire pourquoi ?
Parce que en Logo on ne déclare pas non plus les variables ?
Il a tellement d'autres vertus pour les enfants. En particulier son côté
très ludique. J'ai vu des enfants de 9ans qui, grâce à Logo,
maîtrisaient parfaitement la récursivité et auraient pu en remontrer à
certains "professionnels".
Comme tu l'as dit précédemment, il faut distinguer l'enseignement en
primaire/collège, en université dans un cursus pour professionnels de
l'informatique et dans les autres cursus où la programmation (je ne
parle pas de l'informatique en général), donc le langage de
programmation ne doit être rien d'autre qu'un outil, au même titre que
la bureautique.
>>> En essayant les deux ? Ou mieux, en demandant à son gamin de
>>> tester :)
>> C'est sûr que Java n'est pas pour les enfants. Encore une fois le
>> meilleur langage pour eux est Logo.
>
> Pourquoi ?
Car ce langage a été fait pour eux. Il peut être enseigné dès la
maternelle (et certains le font !). Visite cette page :
http://www.ordiecole.com/logo/jail_espr.html et explore les liens (et
lis le bouquin de Seymour Papert qui est remarquable)
>
>>> Fiabilité et Java, mmm, j'ai un doute, là. (j'vais m'faire des
>>> ennemis, je crois). Enfin, ça a peut-être changé depuis le
>>> temps où j'en faisais sérieusement...
>> Merci d'argumenter en nous donnant des exemples.
>
> J'ai de mauvais souvenirs avec le GC qui démarrait un peu
> n'importe comment, et de subtiles incompatibilités entre
> différentes générations de VM.
>
Il y a eu effectivement des problèmes avec l'activation du GC au début.
Cela dépend des implémentations des JVM.
En ce qui concerne les différences dans les implémentations des JVM,
dans les projets, les outils utilisés font partie de la gestion de
configuration et on ne change pas d'outil sans justification (cela
n'excuse pas les mauvaises implémentations de JVM).
Cependant, tes deux arguments ne mettent pas en cause la fiabilité du
langage Java mais la fiabilité de ses implémentations (qui,
effectivement, ne respectent pas toujours les spécifications de la JVM
qui existent, elles)
>>> Google, Yahoo, Zope/Plone, les jeux, que sais-je encore...
>> Combien de Python dans Google et Yahoo ?
>> Là encore, il faut des arguments.
>
> Il faut aller leur demander, ils en parlent assez.
>
Soit. Je vais essayé de me renseigner plus avant...
Bruno Desthuilliers
>>>> La question que je me pose c'est : que sera Python dans 5 ans ?
>>>> Peut-être un langage complètement délaissé.
>>>> Je ne vois pas qu'on
>>>> enseigne Python dans les facs ou dans les écoles, j'ai l'impression
>>>> que
> Surtout ne pas l'enseigner dans les écoles !!
> Un langage qui permet d'utiliser des variables sans les déclarer doit
> être banni de l'enseignement de la programmation.
>>
>>>> c'est un langage marginal voire déconsidéré. Par contre, Java, lui
>>>> est toujours là.
>>> Java est utilisé dans des applications importantes qui requièrent
>>> fiabilité, évolutivité, etc. (comme les applications militaires).
>>
>>> Où est Python dans l'industrie ??? NULLE PART
>>
> Combien de Python dans Google et Yahoo ?
> Là encore, il faut des arguments.
>>
>>> Python est bien un langage marginal.
>>
j'ai rarement lu un tel ramassis de conneries.
Marc Boyer
> Le Mon, 31 Mar 2008 23:20:07 +0200, Wykaaa a écrit :
>> Thierry B. a écrit :
>>> mêmes raisons, d'abord; et surtout pour les domaines couverts: calcul
>>> scientifique, traitement du texte, interfaces graphiques, interfaces
>>> avec d'autres langages/logiciels. On peut le voir comme un langage
>>> "glue" qui permet de concentrer ses efforts sur le résultat à
>>> atteindre, et pas sur les moyens à utiliser.
>>
>> Surtout ne pas l'enseigner dans les écoles !! Un langage qui permet
>> d'utiliser des variables sans les déclarer doit être banni de
>> l'enseignement de la programmation.
>
> AMA il ne faut pas le prendre comme ça.
>
> Si tu enseignes la programmation à des gens dont ça va être le métier, il
> faut quelque chose qui soit éventuellement plus lourd, et oblige à
> apprendre de bonnes méthodes (typiquement ADA).
> Il leur faudra aussi apprendre des langages avec d'autres paradigmes, et
> ils ne pourront passer à côté du C et de l'inévitable Java.
Je partage ce constat (et je suis dans une école avec une bonne partie
informatique), mais il ammène une limite: une fois vu C et Java, il ne
reste plus forcément beaucoup d'heures.
> Si tu enseignes à des personnes pour qui la programmation n'est qu'une
> unité de valeur obligatoire dans leur cursus, qui leur servira peut-être
> plus tard (mais pas sûr), alors autant leur apprendre un langage qui leur
> permette de faire simplement des choses puissantes,:interfaces
> graphiques, accès fichiers, liens avec des bases de données, manipulation
> des protocoles de l'internet...
Tout à fait.
Mais l'enseignement de la programmation dans des cursus non
informatiques est un vrai problème: en fait, ce sont rarement
des informaticiens de formation qui les font, ce qui pose non
pas un problème de qualité (que des physiciens codent des scripts
python ou matlab comme des pieds, c'est pas très grave) mais
de positionnement (qu'est-ce que l'informatique, quels sont
ces enjeux en 2008, etc).
>> PS : perso, je n'aurais pas intitulé le sujet de cette manière mais
>> plutôt : langages pour l'enseignement de la programmation - langages
>> pour l'industrie ou quelque chose comme ça.
J'ai fait la modif.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Marc Boyer
>> Quand à son enseignement dans les facs, je dis oui aussi.
>
> Tiens , je ferai un sondage à la prochaine réunion à la fac pour voir
> combien connaissent Python. Sinon, je pense qu'il faudrait que les
> étudiants des formations scientifiques, (enfin sciences dures parce que
> je faisais au 1er semestre des TP pour le C2I aux étudiants de biologie,
> wouah, faut s'accrocher) disposent d'UN SEUL langage appris très tôt
> (dès le S1) pour qu'en licence L3 et au-delà, le langage soit réellement
> utilisable parce que suffisamment dominé.
Que signifie "science dure" pour toi ?
Je ne sais plus comment s'organise le cursus avec la réforme LMD.
Un problème est que le premier langage n'a pas forcément les
mêmes objectifs suivant que la suite ammène à la physique, la
chimie ou l'informatique.
Et si on doit avoir le même en L1 pour ces trois futurs distincts,
on se retrouve avec le "plus petit dénominateur commun", qui ne
satisfait pas grand monde.
> Et il faut un langage qui soit
> par exemple capable de monter facilement un GUI donc C n'est pas
> vraiment le bon choix.
Pourquoi ?
Il n'y a pas de GUI standard en C, mais une interface en Tk est-elle
si difficile à faire ?
Marc Boyer
> --{ candide a plopé ceci: }--
>> combien connaissent Python. Sinon, je pense qu'il faudrait que les
>> étudiants des formations scientifiques, (enfin sciences dures parce que
>> je faisais au 1er semestre des TP pour le C2I aux étudiants de biologie,
>> wouah, faut s'accrocher) disposent d'UN SEUL langage appris très tôt
>
> Pourquoi se limiter aux sciences dures ? De nos jours, la multipli-
> cation des engins numériques en tout genre a presque fait oublier
> aux gens qu'un ordinateur se peut aussi se programmer pour lui
> demander quelque chose de particulier. Une initiation/présentation
> d'un langage moderne pourrait être bénéfique, surtout si c'est
> adapté à des sujets pratiques. Mais bon, on peut toujours réver...
Tous les professionels que je connais pensent qu'introduire leur
domaine de compétence plus tôt dans les cursus scolaires serait
bénéfique: droit, psychologie, philo, technos diverses (méca automobile,
plomberie, espaces verts)...
Il n'y a que les enseignants qui trouvent que la barque est déjà assez
chargée...
Thierry B.
> Si tu enseignes à des personnes pour qui la programmation n'est qu'une
> unité de valeur obligatoire dans leur cursus, qui leur servira peut-être
> plus tard (mais pas sûr), alors autant leur apprendre un langage qui leur
> permette de faire simplement des choses puissantes,:interfaces
> graphiques, accès fichiers, liens avec des bases de données, manipulation
> des protocoles de l'internet...
Voilà, c'est exactement ce à quoi je pensais. Quand je repense à la
tête de mes gamins quand je leur ai montré les xmlrpc de Python, et
qu'ils ont compris en moins de vingt minutes comment mettre ça en
oeuvre dans les trucs qu'ils programment, je suis persuadé que dans
le contexte dont tu parles, le serpent est imbattable.
> Autre exemple, il y a quelques années un pote à moi a été chargé de faire
> l'enseignement de programmation pour des étudiants en économie... il a
> choisi Python, et leur a appris à manipuler une base de données, extraire
> ce qu'ils en veulent, générer des fichiers, etc...
On peut même réver, pour ces gens-là, à un Python embarqué dans un
tableur, avec connexion sur une vraie(1) base de donnée.
> Déconsidéré par les gens qui ne le considèrent pas :-)
>
Et *paf* :)
> http://www.python.org/about/quotes/
> (petite liste)
Assez inpressionnante, en fait.
> C'est le problème de Python, les gens l'utilisent "naturellement", mais
> ne le mettent pas en avant, et comme il n'y a pas une grosse boite
> derrière pour faire la 'com'.
Sans compter le nombre d'applications faite en Python (eventuellement
en surcouche d'autres langages) qui sont vendues-diffusées sans que
ce soit mentionné.
> Ca a été heureusement relayé, sinon je n'aurais pas vu cette intéressante
> et si peu partisanne discussion ;-)
En fait, je m'interresse à l'apprentissage de la programmation depuis
que mes gosses sont en age, et ont l'envie, de s'y mettre. J'avais
essayé de leur faire découvrir Perl, mais ils n'ont pas trop accroché,
trop jeunes, je pense. Le véritable déclic pour nous trois a été le
livre "Apprendre à programmer avec Python" qui mélange (dans le bon
sens du terme) l'algorithmique, la programmation et le langage, avec
des exemples et des exercices qui _parlent_ au lecteur. Maintenant,
le plus grand (13 ans) veut apprendre le C, pour faire comme Papa,
et utliser les bibliothèques qu'il fait. Avec ce qu'il a déja appris
en Python sur la façon de structurer un logiciel, les erreurs à
éviter, la nécessaire réflexion préalable, je ne me fais pas trop
de soucis...
(1) Attention, "troll inside", mais je pensais bien entendu à
Postgresql, qui peut également utiliser Python comme langage
pour ses procédures internes...
--
Ne serait-ce pas là la description d'un troll institutionnel ? Pochard a
juste oublié d'argumenter chacun des points. Mais ça, c'est justement pour ça
qu'est fait la fuferie. Il propose, la fuferie dispose.
--{ FF, in fufe }--
Jean-Marc Bourguet
> Tous les professionels que je connais pensent qu'introduire leur
> domaine de compétence plus tôt dans les cursus scolaires serait
> bénéfique: droit, psychologie, philo, technos diverses (méca automobile,
> plomberie, espaces verts)...
>
> Il n'y a que les enseignants qui trouvent que la barque est déjà assez
> chargée...
Mais non, il faut virer tout ce bagage inutile: <inserer ici ce qui n'est
pas du domaine de competence de la personne qui parle>.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Thierry B.
>> Et il faut un langage qui soit
>> par exemple capable de monter facilement un GUI donc C n'est pas
>> vraiment le bon choix.
>
> Pourquoi ?
> Il n'y a pas de GUI standard en C, mais une interface en Tk est-elle
> si difficile à faire ?
Je ne sais pas, je n'ai jamais essayé, mais elle n'est pas dans
les batteries, ce qui fait que les bouquins n'en parlent pas, que
c'est plus difficile à installer, et que ce sera probablement
bien plus difficile à utiliser.
Mais je peux me tromper, hein... J'ai le droit, le 1er avril,
c'est comme un super-vendredi.
--
Pourquoi le Poulet a traversé la rue ?
* Ernest Hemingway : Pour mourir. Sous la pluie.
Thierry B.
> Tous les professionels que je connais pensent qu'introduire leur
> domaine de compétence plus tôt dans les cursus scolaires serait
> bénéfique: droit, psychologie, philo, technos diverses (méca automobile,
> plomberie, espaces verts)...
D'un autre coté, régler un Lotus 3 arbres, c'est pas vraiment
indispensable pour le doctorant en sociologie.
> Il n'y a que les enseignants qui trouvent que la barque est déjà assez
> chargée...
Peut-être aussi la barque est-elle lestée de poids morts...
--
fsp est un boxon innommable: un stalinien n'y retrouvera pas son goulag.
--{ BP, in fm.divers }--
Thierry B.
>> Alors là, il va falloir argumenter un peu, parce que tu
>> viens de te contredire, il me semble. Ou alors tu n'est
>> qu'un troll qui se base sur des on-dit-que.
>>
> Contredire pourquoi ?
> Parce que en Logo on ne déclare pas non plus les variables ?
A vrai dire, je n'en ai pas l'impression. Là, je suis plongé dans
le doc de l'ucblogo, et c'est pas clair pour moi. Et mes souvenirs
du Logo remontent aux années 80 et au Logo (fort bien fait) de
l'Atari ST. Mais ce que je lis en ce moment dans le manuel de
l'ucblogo fait un peu peur quand même :)
However, if a Logo instruction includes an unquoted word that is *not*
the name of a procedure, Logo could look for a variable of that name
instead. This would allow a "punctuationless" Logo, ** PROVIDED THAT
USERS WHO WANT TO WORK WITHOUT COLONS FOR VARIABLES CHOOSE VARIABLE
NAMES THAT ARE NOT ALSO PROCEDURE NAMES. **
Ooupps... Pas très rigoureux, tout ça.
Et pour que tu te fasses une idée de ce qu'est le Logo que j'ai
ici, je te propose de lire sa documentation:
http://la.buvette.org/vrac/ucblogo.txt.gz
> Comme tu l'as dit précédemment, il faut distinguer l'enseignement en
> primaire/collège, en université dans un cursus pour professionnels de
> l'informatique et dans les autres cursus où la programmation (je ne
> parle pas de l'informatique en général), donc le langage de
> programmation ne doit être rien d'autre qu'un outil, au même titre que
> la bureautique.
Non, pas au même titre que la bureautique. La bureautique, c'est la
passivité devant un bloatware cliketi-clicketa. Ce que j'aimerais,
c'est un enseignement où on montre aux élèves/étudiants qu'ils ont
maintenant entre les mains des engins informatiques surpuissants,
et des briques logicielles utilisables; ils doivent donc ré-apprendre
à les domestiquer, à leur expliquer leur façon de voir les choses,
bref à utiliser un ordinateur pour ce qu'il est: une machine
programmable !
> Cependant, tes deux arguments ne mettent pas en cause la fiabilité du
> langage Java mais la fiabilité de ses implémentations (qui,
Dans la vie de tous les jours, les deux sont quand même intimement
liés, non ?
Bon, apéro-time, suivi d'une salade mexicaine...
--
La Corse pour un fonctionnaire du fisc, c'est l'endroit idéal pour des
vacances; comme l'Iran pour un charcutier ou le Vatican pour un gynécologue:
vous ne risquez pas d'être appelée au micro pour une urgence.
Marc Boyer
>>> Et il faut un langage qui soit
>>> par exemple capable de monter facilement un GUI donc C n'est pas
>>> vraiment le bon choix.
>>
>> Pourquoi ?
>> Il n'y a pas de GUI standard en C, mais une interface en Tk est-elle
>> si difficile à faire ?
>
> Je ne sais pas, je n'ai jamais essayé, mais elle n'est pas dans
> les batteries,
Tiens. Il me semblait avoir lu quelque part comme argument de
de Tk son interfaçage facile avec le C, mais je ne le retrouve pas
sur le site de TkDoc...
Comme quoi...
> Mais je peux me tromper, hein... J'ai le droit, le 1er avril,
> c'est comme un super-vendredi.
Tiens. Un jour à dire que les vrais programmeurs font du
C sous Vi alors que les mauvais font du Java sous Eclipse
et les nuls du python sous Notepad ?
Wykaaa
"conneries"
Wykaaa
Wykaaa
> --{ Wykaaa a plopé ceci: }--
>
>>> Alors là, il va falloir argumenter un peu, parce que tu
>>> viens de te contredire, il me semble. Ou alors tu n'est
>>> qu'un troll qui se base sur des on-dit-que.
>>>
>> Contredire pourquoi ?
>> Parce que en Logo on ne déclare pas non plus les variables ?
>
> A vrai dire, je n'en ai pas l'impression. Là, je suis plongé dans
> le doc de l'ucblogo, et c'est pas clair pour moi. Et mes souvenirs
> du Logo remontent aux années 80 et au Logo (fort bien fait) de
> l'Atari ST. Mais ce que je lis en ce moment dans le manuel de
> l'ucblogo fait un peu peur quand même :)
>
> However, if a Logo instruction includes an unquoted word that is *not*
> the name of a procedure, Logo could look for a variable of that name
> instead. This would allow a "punctuationless" Logo, ** PROVIDED THAT
> USERS WHO WANT TO WORK WITHOUT COLONS FOR VARIABLES CHOOSE VARIABLE
> NAMES THAT ARE NOT ALSO PROCEDURE NAMES. **
>
> Ooupps... Pas très rigoureux, tout ça.
En effet mais en Logo il y a 2 styles : le style formel "à la Lisp" et
le "relaxed Logo"
>
> Et pour que tu te fasses une idée de ce qu'est le Logo que j'ai
> ici, je te propose de lire sa documentation:
> http://la.buvette.org/vrac/ucblogo.txt.gz
Je n'ai pas encore été voir...
>
>> Comme tu l'as dit précédemment, il faut distinguer l'enseignement en
>> primaire/collège, en université dans un cursus pour professionnels de
>> l'informatique et dans les autres cursus où la programmation (je ne
>> parle pas de l'informatique en général), donc le langage de
>> programmation ne doit être rien d'autre qu'un outil, au même titre que
>> la bureautique.
>
> Non, pas au même titre que la bureautique. La bureautique, c'est la
> passivité devant un bloatware cliketi-clicketa. Ce que j'aimerais,
> c'est un enseignement où on montre aux élèves/étudiants qu'ils ont
> maintenant entre les mains des engins informatiques surpuissants,
> et des briques logicielles utilisables; ils doivent donc ré-apprendre
> à les domestiquer, à leur expliquer leur façon de voir les choses,
> bref à utiliser un ordinateur pour ce qu'il est: une machine
> programmable !
OK, ok, c'était juste une façon de parler...
>
>
>> Cependant, tes deux arguments ne mettent pas en cause la fiabilité du
>> langage Java mais la fiabilité de ses implémentations (qui,
>
> Dans la vie de tous les jours, les deux sont quand même intimement
> liés, non ?
Oui mais ce n'est pas de ma faute s'il y a, d'un côté, de bonnes
spécifications et, de l'autre, de mauvaises implémentations...
>
>
> Bon, apéro-time, suivi d'une salade mexicaine...
J'espère que tu as bien digéré tout ça :-)
Wykaaa
> On 2008-04-01, Thierry B. <t...@prout.stex.invalid> wrote:
>> --{ Marc Boyer a plopé ceci: }--
>>>> Et il faut un langage qui soit
>>>> par exemple capable de monter facilement un GUI donc C n'est pas
>>>> vraiment le bon choix.
>>> Pourquoi ?
>>> Il n'y a pas de GUI standard en C, mais une interface en Tk est-elle
>>> si difficile à faire ?
>> Je ne sais pas, je n'ai jamais essayé, mais elle n'est pas dans
>> les batteries,
>
> Tiens. Il me semblait avoir lu quelque part comme argument de
> de Tk son interfaçage facile avec le C, mais je ne le retrouve pas
> sur le site de TkDoc...
>
> Comme quoi...
>
>> Mais je peux me tromper, hein... J'ai le droit, le 1er avril,
>> c'est comme un super-vendredi.
>
> Tiens. Un jour à dire que les vrais programmeurs font du
> C sous Vi alors que les mauvais font du Java sous Eclipse
> et les nuls du python sous Notepad ?
>
> Marc Boyer
Quand je faisais des compilateurs, un 1er avril on avait mis une version
spéciale du compilateur du langage qui servait aux développements
internes (un genre de PL/1) qui émettait un "warning" sur chaque
affectation en disant que ce trait de langage disparaîtrait dans deux
"releases" (clin d'oeil aux langages purement fonctionnels).
Je ne vous dit pas le tollé auprès des développpeurs de la boîte !!
Bruno Desthuilliers
Effectivement, mes excuses sur ce point, nous devons également remercier
M. Candide pour la question initiale concernant l'avenir de Python et sa
visibilité par rapport à Java.
> et d'argumenter les
> "conneries"
Toi qui a audité des millions de lignes de code, tu devrais bien être
capable de trouvé par toi-même. A moins que tes oeillères ne t'en
empêche, bien sûr.
Laurent Pointal
Python comme langage d'introduction au "Computer Science":
http://www.amk.ca/diary/2006/11/mit_to_try_python_for_introduc.html
Il semble qu'ils ne le regrettent pas trop:
http://catherinedevlin.blogspot.com/2007/11/python-at-mit.html
D'autres liens via google:
http://www.google.fr/search?q=MIT+%2B+Python+%2B+student
Note: Je ne dis pas que c'est pas parce que l'exemple viens des US que
c'est obligatoirement à adopter. Voir comment ça s'est passé, et si c'est
adaptable aux modes d'enseignement en pratique en france, au profil des
étudiants, aux autres matières enseignées, aux besoins des étudiants...
Wykaaa
> On 2008-03-31, Laurent Pointal <laurent...@laposte.net> wrote:
>> Le Mon, 31 Mar 2008 23:20:07 +0200, Wykaaa a écrit :
>>> Thierry B. a écrit :
>>>> Quand à son enseignement dans les facs, je dis oui aussi. Pour les
>>>> mêmes raisons, d'abord; et surtout pour les domaines couverts: calcul
>>>> scientifique, traitement du texte, interfaces graphiques, interfaces
>>>> avec d'autres langages/logiciels. On peut le voir comme un langage
>>>> "glue" qui permet de concentrer ses efforts sur le résultat à
>>>> atteindre, et pas sur les moyens à utiliser.
>>> Surtout ne pas l'enseigner dans les écoles !! Un langage qui permet
>>> d'utiliser des variables sans les déclarer doit être banni de
>>> l'enseignement de la programmation.
>> AMA il ne faut pas le prendre comme ça.
>>
>> Si tu enseignes la programmation à des gens dont ça va être le métier, il
>> faut quelque chose qui soit éventuellement plus lourd, et oblige à
>> apprendre de bonnes méthodes (typiquement ADA).
>> Il leur faudra aussi apprendre des langages avec d'autres paradigmes, et
>> ils ne pourront passer à côté du C et de l'inévitable Java.
>
> Je partage ce constat (et je suis dans une école avec une bonne partie
> informatique), mais il ammène une limite: une fois vu C et Java, il ne
> reste plus forcément beaucoup d'heures.
Le débat entame ici le fond du problème pour l'enseignement de la
programmation.
Je vais donner mon point de vue personnel qu'on peut ne pas partager
(mais sans polémique SVP) :
1) Pour les futurs développeurs (en se cantonnant seulement à la
programmation et pas au reste du cycle de vie ni à la gestion de projet) :
Apprentissage des bases de la programmation, ce qui veut dire (pas
forcément dans l'ordre):
- notion de variable et de classe d'allocation mémoire (auto, statique,
externe, constante), valeurs littérales
- notion de sous-programme (procédure, fonction, méthode, appelons tout
cela sous ce nom générique) et de passage d'argument (par valeur, par
référence, par valeur d'adresse, par nom. Ce dernier à cause de certains
macro-processeurs principalement)
- notion de typage : types de base, types construits. Le typage
statique, le typage dynamique
- notion de programmation structurée (ce n'est pas parce que l'objet
que, hein ?) : structures itératives et alternatives
- notion de récursivité
- notion de modularité : package, classes (pour préparer les notions objets)
- Notion de compilation séparée (avec les différentes variantes. Par
exemple, séparation ou non de la spécification d'un module et de son
corps : .h et .c ou .cpp en C et C**, package et package body en ADA où
la notion de package n'est pas liée à la notion de fichier, package à la
Java)
- Comment structurer une application en énonçant les critères (notion
d'abstraction, forte cohésion interne, faible couplage)
- Notion d'héritage et de polymorphisme
- La généricité (les templates)
Tout ceci peut se faire avec Java comme langage support. Mais il faut
insister sur les concepts de programmation en insistant sur le fait que
Java (si c'est ce langage qui est utilisé comme support) n'est qu'une
mise en oeuvre de ces concepts
Si cette partie est bien faite, il devient beaucoup plus facile aux
étudiants d'apprendre d'autres langages (et pourquoi pas Python...)
Ensuite, doivent être abordés des notions plus sophistiquées comme la
programmation concurrente illustrée par les threads Java (ou les tâches
en ADA), les bases de données et la notion de donnée persistante, les
GUI et les kits de développement.
Les télécom : les librairies pour les différents protocoles, TCP/IP, etc.
Enfin les notions de qualité logicielle (elles seront évidemment
sous-jacentes à tout ce qui précède) : ce que ISO 9000 appelle les
exigences non fonctionnelles : réutilisabilité, évolutivité, etc.
2) Pour les scientifiques non informaticiens
- notion de variable, de valeurs litérales (sans les encombrer avec les
classes d'allocation mémoire (quoique des fois)
- notion de sous-programme (sans les subtilités de tous les types de
passage d'arguments)
- quelques notions de typage
- notion de récursivité
- notion de modularité
- notion d'héritage et de polymorphisme (peut-être même pas nécessaire.
Dépend du contexte)
Langage support : un langage utilisé en simulation permettant de faire
aisément des graphiques et de mettre en place une IHM, même rudimentaire
Un langage tel que le regretté HyperCard (sur Mac) était parfait pour
cela. Il faut trouver l'équivalent et, là, je fais appel à vos
suggestions à tous.
3) Pour les non scientifiques
Excel et VBA ??? (non pas taper...)
J'ai certainement oublié des trucs mais, pour tous ceux qui sont
impliqués dans l'enseignement de l'informatique au sens large dans des
cursus divers et variés, peut-être est-ce une base de discussion ?
>
>> Si tu enseignes à des personnes pour qui la programmation n'est qu'une
>> unité de valeur obligatoire dans leur cursus, qui leur servira peut-être
>> plus tard (mais pas sûr), alors autant leur apprendre un langage qui leur
>> permette de faire simplement des choses puissantes,:interfaces
>> graphiques, accès fichiers, liens avec des bases de données, manipulation
>> des protocoles de l'internet...
Entièrement d'accord mais je n'ai pas la réponse en terme de langage (je
sens que certains vont dire ... Python)
>
> Tout à fait.
> Mais l'enseignement de la programmation dans des cursus non
> informatiques est un vrai problème: en fait, ce sont rarement
> des informaticiens de formation qui les font, ce qui pose non
> pas un problème de qualité (que des physiciens codent des scripts
> python ou matlab comme des pieds, c'est pas très grave) mais
> de positionnement (qu'est-ce que l'informatique, quels sont
> ces enjeux en 2008, etc).
>
Je suis assez d'accord que la "propreté" de la programmation est très
secondaire dans ce contexte.
Cependant, une vraie réflexion est nécessaire sur la place de
l'informatique par grandes filières et les besoins par métier. Par
exemple, un architecte, un géologue ou un graphiste n'ont absolument pas
les mêmes besoins vis-à-vis de l'informatique. Sans parler des
historiens, des sociologues, etc.
>>> PS : perso, je n'aurais pas intitulé le sujet de cette manière mais
>>> plutôt : langages pour l'enseignement de la programmation - langages
>>> pour l'industrie ou quelque chose comme ça.
>
> J'ai fait la modif.
Merci Marc
Bruno Desthuilliers
(snip)
Et rien sur l'approche fonctionnelle ???
Laurent Pointal
<zip>
> Le débat entame ici le fond du problème pour l'enseignement de la
> programmation.
> Je vais donner mon point de vue personnel qu'on peut ne pas partager
> (mais sans polémique SVP) :
Il est partagé.
J'y ajouterais des langages à paradigmes différents (style Lisp, Prolog
et assimilés). C'est un truc qui me manque je trouve, j'ai fait un peu de
prolog au CNAM, mais c'est tout.
Note: mes collègues qui enseignent dans les cursus d'informatique en fac
ont de plus en plus de mal de trouver des étudiants intéressés par le
simple fait de programmer - la pluspart veulent devenir analystes, chefs
de projets... mais surtout pas mettre les mains dans le cambouis. Pas sûr
qu'à terme ça ne fasse pas de mauvaises surprises au niveau des cahiers
des charges qu'ils rédigeront...
<zip>
> 2) Pour les scientifiques non informaticiens - notion de variable, de
> valeurs litérales (sans les encombrer avec les classes d'allocation
> mémoire (quoique des fois) - notion de sous-programme (sans les
> subtilités de tous les types de passage d'arguments)
> - quelques notions de typage
> - notion de récursivité
> - notion de modularité
> - notion d'héritage et de polymorphisme (peut-être même pas nécessaire.
> Dépend du contexte)
+ évidemment les tableaux, structures de contrôle & Co, les entrées/
sorties...
AMA il est important de leur montrer la réutilisation de bibliothèques
existantes, de leur apprendre à chercher d'abord si ce dont ils ont
besoin n'a pas déjà été réalisé dans un langage/outil quelconque.
> Langage support : un langage utilisé en simulation permettant de faire
> aisément des graphiques et de mettre en place une IHM, même rudimentaire
> Un langage tel que le regretté HyperCard (sur Mac) était parfait pour
> cela. Il faut trouver l'équivalent et, là, je fais appel à vos
> suggestions à tous.
HyperCard... nostalgie (SuperCard aussi dans mon cas).
Il y a un soft (commercial) qui tourne de la même façon et permet de
faire des "piles" (certains de mes collègues l'utilisent pour monter des
manips simples).
Ah, j'ai trouvé sur Wikipedia:
http://en.wikipedia.org/wiki/HyperCard#External_links
Pour mes collègues, c'est "Revolution"
Il y a aussi PythonCard (mais non je ne fait pas de prosélytisme) qui est
l'utilisation de Python avec une architecture événementielle type pile
HyperCard (mais avec les nombreuses librairies Python dispos).
Je ne sais pas trop où il en est (voir si le dépôt versionné n'est pas
très en avance par rapport aux tgz téléchargeables).
http://pythoncard.sourceforge.net/
> 3) Pour les non scientifiques
> Excel et VBA ??? (non pas taper...)
>
> J'ai certainement oublié des trucs mais, pour tous ceux qui sont
> impliqués dans l'enseignement de l'informatique au sens large dans des
> cursus divers et variés, peut-être est-ce une base de discussion ?
Le premier problème avec Excel et VBA c'est un verrouillage certain sur
des outils propriétaires (et pas donnés - s'il faut que les étudiants y
aient accès il faut le prendre en compte... quoique Microsoft fasse des
tarifs très préférentiels aux étudiants afin d'élargir sa gamme
d'utilisateurs captifs).
Le second c'est que l'on préfère souvent utiliser ce que l'on connaît
déjà pour réaliser ce dont on a besoin (on serait peut-être/sûrement plus
efficace avec des outils plus adaptés... mais il y a la barrière/le temps
d'apprentissage).
Et comme outils génériques, Excel et VBA ne sont pas bons. Ce qui fait
que l'on se retrouve avec des trucs développés par des gens de bonne
volonté, mais qui sont des horreurs du point de vue informatique.
>>> Si tu enseignes à des personnes pour qui la programmation n'est qu'une
>>> unité de valeur obligatoire dans leur cursus, qui leur servira
>>> peut-être plus tard (mais pas sûr), alors autant leur apprendre un
>>> langage qui leur permette de faire simplement des choses
>>> puissantes,:interfaces graphiques, accès fichiers, liens avec des
>>> bases de données, manipulation des protocoles de l'internet...
>
> Entièrement d'accord mais je n'ai pas la réponse en terme de langage (je
> sens que certains vont dire ... Python)
Oui oui oui.
Bon, il faut dire que les gens qui font du Python un peu avancé ont
beaucoup de code écrit dans d'autres langages (réutilisation de
librairies C/C++ existantes, écriture de code de calcul optimisé...).
Tu n'iras pas faire un soft de traitement d'image complètement en Python,
ce n'est pas le but et ça serait particulièrement inefficace. Par contre
tu réutiliseras des librairies pour pouvoir profiter facilement de leurs
fonctionnalités et ajouter des services par dessus (GUI, réseau,
changements de formats...).
[pause] Si je reprend un exemple par rapport à ce que tu sembles avoir
fait (vu ce que j'ai pu lire du début de la discussion), tu n'iras pas
faire un soft embarqué d'assistance au pilotage d'un avion en Python, ça
n'aurais aucun sens. Par contre, tu peux très bien utiliser Python pour
automatiser les enchaînements de build et de tests unitaires de ton soft
écrit en ADA.
Pour cet usage, tu peux remplacer Python par Ruby, TCL, Perl ou tout
autre langage de script un peu avancé - mais Python est une excellente
glue - et il y a PyAda, dont le développement est malheureusement
abandonné: http://pyada.sourceforge.net/index.html
[/pause]
>>
>> Tout à fait.
>> Mais l'enseignement de la programmation dans des cursus non
>> informatiques est un vrai problème: en fait, ce sont rarement des
>> informaticiens de formation qui les font, ce qui pose non pas un
>> problème de qualité (que des physiciens codent des scripts python ou
>> matlab comme des pieds, c'est pas très grave)
Ouaif... sauf quand il faut les reprendre pour les adapter...
>> mais de positionnement
>> (qu'est-ce que l'informatique, quels sont ces enjeux en 2008, etc).
>>
> Je suis assez d'accord que la "propreté" de la programmation est très
> secondaire dans ce contexte.
> Cependant, une vraie réflexion est nécessaire sur la place de
> l'informatique par grandes filières et les besoins par métier. Par
> exemple, un architecte, un géologue ou un graphiste n'ont absolument pas
> les mêmes besoins vis-à-vis de l'informatique. Sans parler des
> historiens, des sociologues, etc.
Je leur trouverais en commun d'avoir à accéder à des bases de données et
à faire des traitements pour extraire ce dont ils ont besoin... des cours
de SQL?
Wykaaa
oublié des trucs" mais là, tu frappes où ça fait mal car mes langages
favoris sont ceux de la famille ML (Caml, OCaml). Dans le futur :
OCamlDuce ?
Bien sûr, il faut en parler, c'est, comment dire, incontournable :-)
Wykaaa
> Le Tue, 01 Apr 2008 20:54:13 +0200, Wykaaa a écrit :
>
> <zip>
>
>> Le débat entame ici le fond du problème pour l'enseignement de la
>> programmation.
>> Je vais donner mon point de vue personnel qu'on peut ne pas partager
>> (mais sans polémique SVP) :
>
> Il est partagé.
> J'y ajouterais des langages à paradigmes différents (style Lisp, Prolog
> et assimilés). C'est un truc qui me manque je trouve, j'ai fait un peu de
> prolog au CNAM, mais c'est tout.
Oui tu as raison, même si cette part est moindre, pour de futurs
informaticiens, il est nécessaire de parler un minimum de programmation
fonctionnelle et déclarative. Je savais bien que j'avais oublié des
"trucs"...
>
> Note: mes collègues qui enseignent dans les cursus d'informatique en fac
> ont de plus en plus de mal de trouver des étudiants intéressés par le
> simple fait de programmer - la pluspart veulent devenir analystes, chefs
> de projets... mais surtout pas mettre les mains dans le cambouis. Pas sûr
> qu'à terme ça ne fasse pas de mauvaises surprises au niveau des cahiers
> des charges qu'ils rédigeront...
C'est tout à fait vrai mais quand on sait qu'il y a des bataillons de
programmeurs en Inde et même en Roumanie avec les salaires que l'on sait...
>
> <zip>
>
>> 2) Pour les scientifiques non informaticiens - notion de variable, de
>> valeurs litérales (sans les encombrer avec les classes d'allocation
>> mémoire (quoique des fois) - notion de sous-programme (sans les
>> subtilités de tous les types de passage d'arguments)
>> - quelques notions de typage
>> - notion de récursivité
>> - notion de modularité
>> - notion d'héritage et de polymorphisme (peut-être même pas nécessaire.
>> Dépend du contexte)
>
> + évidemment les tableaux, structures de contrôle & Co, les entrées/
> sorties...
Encore un oubli. En fait, plus généralement, il faut parler de variable
scalaire, de structures homogènes homogène (tableau, vecteur) et de
structures hétérogènes (les "records" et "structures").
>
> AMA il est important de leur montrer la réutilisation de bibliothèques
> existantes, de leur apprendre à chercher d'abord si ce dont ils ont
> besoin n'a pas déjà été réalisé dans un langage/outil quelconque.
C'est même un besoin essentiel car, aujourd'hui, un développeur fait
plus un travail d'assemblage, via des bibliothèques, qu'un pur travail
de programmation à partir de la feuille blanche.
>
>> Langage support : un langage utilisé en simulation permettant de faire
>> aisément des graphiques et de mettre en place une IHM, même rudimentaire
>> Un langage tel que le regretté HyperCard (sur Mac) était parfait pour
>> cela. Il faut trouver l'équivalent et, là, je fais appel à vos
>> suggestions à tous.
>
> HyperCard... nostalgie (SuperCard aussi dans mon cas).
>
> Il y a un soft (commercial) qui tourne de la même façon et permet de
> faire des "piles" (certains de mes collègues l'utilisent pour monter des
> manips simples).
> Ah, j'ai trouvé sur Wikipedia:
> http://en.wikipedia.org/wiki/HyperCard#External_links
> Pour mes collègues, c'est "Revolution"
Merci. Je l'avais oublié celui-là. Je vais voir où ça en est...
>
> Il y a aussi PythonCard (mais non je ne fait pas de prosélytisme) qui est
> l'utilisation de Python avec une architecture événementielle type pile
> HyperCard (mais avec les nombreuses librairies Python dispos).
> Je ne sais pas trop où il en est (voir si le dépôt versionné n'est pas
> très en avance par rapport aux tgz téléchargeables).
>
> http://pythoncard.sourceforge.net/
>
Une piste intéressante (je ne suis pas sectaire, contrairement à ce que
peut penser Bruno Desthuilliers...
>> 3) Pour les non scientifiques
>> Excel et VBA ??? (non pas taper...)
>>
>> J'ai certainement oublié des trucs mais, pour tous ceux qui sont
>> impliqués dans l'enseignement de l'informatique au sens large dans des
>> cursus divers et variés, peut-être est-ce une base de discussion ?
>
> Le premier problème avec Excel et VBA c'est un verrouillage certain sur
> des outils propriétaires (et pas donnés - s'il faut que les étudiants y
> aient accès il faut le prendre en compte... quoique Microsoft fasse des
> tarifs très préférentiels aux étudiants afin d'élargir sa gamme
> d'utilisateurs captifs).
Oui mais j'ai un collègue qui a fait des fractals (pour voir) juste avec
des macros Excel (sans VBA).
> Le second c'est que l'on préfère souvent utiliser ce que l'on connaît
> déjà pour réaliser ce dont on a besoin (on serait peut-être/sûrement plus
> efficace avec des outils plus adaptés... mais il y a la barrière/le temps
> d'apprentissage).
> Et comme outils génériques, Excel et VBA ne sont pas bons. Ce qui fait
> que l'on se retrouve avec des trucs développés par des gens de bonne
> volonté, mais qui sont des horreurs du point de vue informatique.
Les horreurs sont-elles importantes, dans ce contexte, s'ils arrivent au
résultat attendu ?
>>>> Si tu enseignes à des personnes pour qui la programmation n'est qu'une
>>>> unité de valeur obligatoire dans leur cursus, qui leur servira
>>>> peut-être plus tard (mais pas sûr), alors autant leur apprendre un
>>>> langage qui leur permette de faire simplement des choses
>>>> puissantes,:interfaces graphiques, accès fichiers, liens avec des
>>>> bases de données, manipulation des protocoles de l'internet...
>> Entièrement d'accord mais je n'ai pas la réponse en terme de langage (je
>> sens que certains vont dire ... Python)
>
> Oui oui oui.
> Bon, il faut dire que les gens qui font du Python un peu avancé ont
> beaucoup de code écrit dans d'autres langages (réutilisation de
> librairies C/C++ existantes, écriture de code de calcul optimisé...).
> Tu n'iras pas faire un soft de traitement d'image complètement en Python,
> ce n'est pas le but et ça serait particulièrement inefficace. Par contre
> tu réutiliseras des librairies pour pouvoir profiter facilement de leurs
> fonctionnalités et ajouter des services par dessus (GUI, réseau,
> changements de formats...).
Alors dans ce cas, pourquoi pas, effectivement...
>
>
> [pause] Si je reprend un exemple par rapport à ce que tu sembles avoir
> fait (vu ce que j'ai pu lire du début de la discussion), tu n'iras pas
> faire un soft embarqué d'assistance au pilotage d'un avion en Python, ça
> n'aurais aucun sens. Par contre, tu peux très bien utiliser Python pour
> automatiser les enchaînements de build et de tests unitaires de ton soft
> écrit en ADA.
> Pour cet usage, tu peux remplacer Python par Ruby, TCL, Perl ou tout
> autre langage de script un peu avancé - mais Python est une excellente
> glue - et il y a PyAda, dont le développement est malheureusement
> abandonné: http://pyada.sourceforge.net/index.html
> [/pause]
Tu sembles privilégier l'aspect script de Python. Ne serait-il utile que
dans ces cas-là ?
>
>
>>> Tout à fait.
>>> Mais l'enseignement de la programmation dans des cursus non
>>> informatiques est un vrai problème: en fait, ce sont rarement des
>>> informaticiens de formation qui les font, ce qui pose non pas un
>>> problème de qualité (que des physiciens codent des scripts python ou
>>> matlab comme des pieds, c'est pas très grave)
>
> Ouaif... sauf quand il faut les reprendre pour les adapter...
Là c'est une tâche lourde.
Je me rappelle, dans un mastère, dans les années 80 quand on apprenait
la programmation à des étudiants non informaticiens. C'était le début de
la micro et certains croyaient que, parce qu'ils avaient fait quelques
petits programmes de 50 lignes en Basic (celui de l'époque !), ils
étaient programmeurs...
C'était très difficile de les "recadrer".
>
>>> mais de positionnement
>>> (qu'est-ce que l'informatique, quels sont ces enjeux en 2008, etc).
>>>
>> Je suis assez d'accord que la "propreté" de la programmation est très
>> secondaire dans ce contexte.
>> Cependant, une vraie réflexion est nécessaire sur la place de
>> l'informatique par grandes filières et les besoins par métier. Par
>> exemple, un architecte, un géologue ou un graphiste n'ont absolument pas
>> les mêmes besoins vis-à-vis de l'informatique. Sans parler des
>> historiens, des sociologues, etc.
>
> Je leur trouverais en commun d'avoir à accéder à des bases de données et
> à faire des traitements pour extraire ce dont ils ont besoin... des cours
> de SQL?
Après tout, pourquoi pas. Avec l'utilisation d'outils comme BO (Business
Object) aussi.
Wykaaa
Bruno Desthuilliers
Et pas vraiment évident à apprendre avec Java...
Je ne vois rien non plus concernant les structures de données et l'algo.
Ca te semble tellement secondaire ?-)
Wykaaa
C'est difficile de trouver un seul langage qui rassemble tous les
paradigmes de programmation.
>
> Je ne vois rien non plus concernant les structures de données et l'algo.
> Ca te semble tellement secondaire ?-)
Bien sur qu'il faut enseigner les structures de données et l'algo mais
je ne définissais pas un cursus entier concernant l'informatique mais
seulement l'apprentissage des langages de programmation.
L'algo c'est plutôt leur utilisation.
Et d'ailleurs, c'est très difficile pour les TP du cours programmation
car rapidement ils peuvent devenir des TP d'algo (ce qu'il faut éviter).
Pour cette raison, quand on donne un exo de programmation, sa conception
(détaillée) doit être fournie avec l'énoncé sinon, ça devient un TP d'algo.
Par contre, dans ce que j'ai décrit, il faut évidemment distinguer les
variables scalaires, les structures homogènes (tableau) et structures
hétérogènes (record, struct à la C, etc.).
Les types construits par le programmeur comme les listes chaînées, les
arbres, les collections en général, etc. font partie d'un cours de base
en algo.
Bruno Desthuilliers
Tu a au moins common lisp, OCaml et Python qui supportent la plupart des
concepts des approches procédurales, objet et fonctionnelle (avec plus
ou moins de bonheur - la pf en Python reste assez limitée - mais
suffisament pour exposer les concepts...).
>>
>> Je ne vois rien non plus concernant les structures de données et
>> l'algo. Ca te semble tellement secondaire ?-)
>
> Bien sur qu'il faut enseigner les structures de données et l'algo mais
> je ne définissais pas un cursus entier concernant l'informatique mais
> seulement l'apprentissage des langages de programmation.
Evidemment - au temps pour moi. Ceci étant, peut-on vraiment totalement
découpler l'algo et les structures de données du (des) langage(s)
utilisé(s) ? (question ouverte à quelqu'un ayant l'expérience de
l'enseignement - non, je ne fais pas que troller...)
Jean-Marc Bourguet
> C'est difficile de trouver un seul langage qui rassemble tous les
> paradigmes de programmation.
http://www.info.ucl.ac.be/people/PVR/paradigmsDIAGRAMeng101.pdfz
Wykaaa
Je vois mal apprendre la programmation (premier langage) à l'aide de
Common Lisp. Pour OCaml, faut voir (à une époque et peut-être encore
maintenant ?) au CNAM, ils utilisaient ADA et Caml.
Pour le coup, peut-être que Python est le mieux. Tu vois que je ne suis
pas sectaire :-)
Surtout avec l'expérience du MIT.
.
>
>>>
>>> Je ne vois rien non plus concernant les structures de données et
>>> l'algo. Ca te semble tellement secondaire ?-)
>>
>> Bien sur qu'il faut enseigner les structures de données et l'algo mais
>> je ne définissais pas un cursus entier concernant l'informatique mais
>> seulement l'apprentissage des langages de programmation.
>
> Evidemment - au temps pour moi. Ceci étant, peut-on vraiment totalement
> découpler l'algo et les structures de données du (des) langage(s)
> utilisé(s) ? (question ouverte à quelqu'un ayant l'expérience de
> l'enseignement - non, je ne fais pas que troller...)
C'est la partie délicate de l'apprentissage de la programmation...
Il faut, certainement une petite dose d'algo en parallèle mais la plus
minime possible.
Wykaaa
> Wykaaa <wyk...@yahoo.fr> writes:
>
>> C'est difficile de trouver un seul langage qui rassemble tous les
>> paradigmes de programmation.
>
> http://www.info.ucl.ac.be/people/PVR/paradigmsDIAGRAMeng101.pdfz
>
> A+
>
Tous les enseignants en programmation devraient l'avoir sous le coude.
Bruno Desthuilliers
> Bruno Desthuilliers a écrit :
>> Wykaaa a écrit :
>>> Bruno Desthuilliers a écrit :
>>>>>> Et rien sur l'approche fonctionnelle ???
>>>>>>
>>>>> Aïe, j'avais pris mes précautions en disant à la fin "J'ai
>>>>> certainement oublié des trucs" mais là, tu frappes où ça fait mal
>>>>> car mes langages favoris sont ceux de la famille ML (Caml, OCaml).
>>>>> Dans le futur : OCamlDuce ?
>>>>> Bien sûr, il faut en parler, c'est, comment dire, incontournable :-)
>>>>
>>>> Et pas vraiment évident à apprendre avec Java...
>>>
>>> C'est difficile de trouver un seul langage qui rassemble tous les
>>> paradigmes de programmation.
>>
>> Tu a au moins common lisp, OCaml et Python qui supportent la plupart
>> des concepts des approches procédurales, objet et fonctionnelle (avec
>> plus ou moins de bonheur - la pf en Python reste assez limitée - mais
>> suffisament pour exposer les concepts...)
>
> Je vois mal apprendre la programmation (premier langage) à l'aide de
> Common Lisp.
Mmm... Scheme, alors ? Je ne sais pas dans quelle mesure Scheme supporte
une approche procédurale, mais il y a au moins un support pour l'OO. Et
IIRC, c'est un langage couramment utilisé pour l'enseignement, non ?
Dans une certaine mesure - et si on compare à ton listing - ça pose la
question de savoir s'il vaut mieux commencer avec un langage de
haut-niveau, ou mettre tout de suite les mains dans le cambouis avec un
langage plus près de la machine (et donc avant tout procédural,
puiqu'aux dernières nouvelles c'est le fonctionnement de nos ordis
actuels...).
> Pour OCaml, faut voir (à une époque et peut-être encore
> maintenant ?) au CNAM, ils utilisaient ADA et Caml.
>
> Pour le coup, peut-être que Python est le mieux.
Tu n'y songe pas, malheureux ! Un langage à typage dynamique, cette
chose à bannir à tous prix ! (enfin, d'après tes propres propos, hein...)
> Tu vois que je ne suis
> pas sectaire :-)
<troll>
Je ne sais pas, mais entre d'autres propos que tu a tenu ici et
celui-ci, soit tu es parfois un peu excessif, soit tu souffres d'un
dédoublement de personnalité !-)
bon, ok, me ---->[]
</troll>
> Surtout avec l'expérience du MIT.
> .
>>
>>>>
>>>> Je ne vois rien non plus concernant les structures de données et
>>>> l'algo. Ca te semble tellement secondaire ?-)
>>>
>>> Bien sur qu'il faut enseigner les structures de données et l'algo
>>> mais je ne définissais pas un cursus entier concernant l'informatique
>>> mais seulement l'apprentissage des langages de programmation.
>>
>> Evidemment - au temps pour moi. Ceci étant, peut-on vraiment
>> totalement découpler l'algo et les structures de données du (des)
>> langage(s) utilisé(s) ? (question ouverte à quelqu'un ayant
>> l'expérience de l'enseignement - non, je ne fais pas que troller...)
>
> C'est la partie délicate de l'apprentissage de la programmation...
> Il faut, certainement une petite dose d'algo en parallèle mais la plus
> minime possible.
Je me posais plutôt la question dans l'autre sens : comment enseigner
l'algo indépendamment de certaines spécificités d'un langage (ou d'une
famille de langages).
<thinking-out-loud>
Le même couple algo/structure de données peut prendre des apparences
*très* différentes selon le langage utilisé - fut-il du pseudocode.
Quand on connait plusieurs langages suffisament différents, on peut voir
le concept (abstrait) derrière le code, mais pour un débutant, il est
probablement plus difficile de faire cette abstraction. Enfin, j'imagine.
</thinking-out-loud>
Laurent Pointal
>> Le second c'est que l'on préfère souvent utiliser ce que l'on connaît
>> déjà pour réaliser ce dont on a besoin (on serait peut-être/sûrement
>> plus efficace avec des outils plus adaptés... mais il y a la
>> barrière/le temps d'apprentissage).
>> Et comme outils génériques, Excel et VBA ne sont pas bons. Ce qui fait
>> que l'on se retrouve avec des trucs développés par des gens de bonne
>> volonté, mais qui sont des horreurs du point de vue informatique.
>
> Les horreurs sont-elles importantes, dans ce contexte, s'ils arrivent au
> résultat attendu ?
On pourrait dire "tant pis pour eux". Le problème est que ces langages
répondent bien à une certaine problématique, mais ne sont pas des
langages assez génériques - le langage ne devrait pas limiter ce que peut
faire le développeur.
Wykaaa
> Wykaaa a écrit :
>> Bruno Desthuilliers a écrit :
>>> Wykaaa a écrit :
>>>> Bruno Desthuilliers a écrit :
> (snip)
>>>>>>> Et rien sur l'approche fonctionnelle ???
>>>>>>>
>>>>>> Aïe, j'avais pris mes précautions en disant à la fin "J'ai
>>>>>> certainement oublié des trucs" mais là, tu frappes où ça fait mal
>>>>>> car mes langages favoris sont ceux de la famille ML (Caml, OCaml).
>>>>>> Dans le futur : OCamlDuce ?
>>>>>> Bien sûr, il faut en parler, c'est, comment dire, incontournable :-)
>>>>>
>>>>> Et pas vraiment évident à apprendre avec Java...
>>>>
>>>> C'est difficile de trouver un seul langage qui rassemble tous les
>>>> paradigmes de programmation.
>>>
>>> Tu a au moins common lisp, OCaml et Python qui supportent la plupart
>>> des concepts des approches procédurales, objet et fonctionnelle (avec
>>> plus ou moins de bonheur - la pf en Python reste assez limitée - mais
>>> suffisament pour exposer les concepts...)
>>
>> Je vois mal apprendre la programmation (premier langage) à l'aide de
>> Common Lisp.
>
> Mmm... Scheme, alors ? Je ne sais pas dans quelle mesure Scheme supporte
> une approche procédurale, mais il y a au moins un support pour l'OO. Et
> IIRC, c'est un langage couramment utilisé pour l'enseignement, non ?
Oui Scheme me paraît un bon compromis. D'ailleurs c'était très enseigné
au MIT à une époque, en particulier grâce au fameux bouquin "Structure
and Interpretation of Computer Programs" de Harold Abelson et Gerald jay
Sussman (que j'ai connu en 81, lors d'une université d'été de 2 semaines
à Newcastle sur la programmation fonctionnelle).
>
> Dans une certaine mesure - et si on compare à ton listing - ça pose la
> question de savoir s'il vaut mieux commencer avec un langage de
> haut-niveau, ou mettre tout de suite les mains dans le cambouis avec un
> langage plus près de la machine (et donc avant tout procédural,
> puiqu'aux dernières nouvelles c'est le fonctionnement de nos ordis
> actuels...).
En fait, mais c'est difficile à mettre en oeuvre dans les cursus
informatique, à cause du temps, il faudrait enseigner un langage genre
ADA (pas taper) pour apprendre la rigueur de programmation (je choisis
justement le plus rigide, comme tu dis par ailleurs, exprès) et u
langage interprété à typage dynamique (et pourquoi pas Python,
j'insiste). Les débutants informaticiens verraient de cette façon et
comprendraient pourquoi un seul langage de programmation ne peut pas
répondre à tous les besoins.
>
>> Pour OCaml, faut voir (à une époque et peut-être encore maintenant ?)
>> au CNAM, ils utilisaient ADA et Caml.
>>
>> Pour le coup, peut-être que Python est le mieux.
>
> Tu n'y songe pas, malheureux ! Un langage à typage dynamique, cette
> chose à bannir à tous prix ! (enfin, d'après tes propres propos, hein...)
Bon d'accord, mais ce n'est pas le typage dynamique qui me choque le
plus, c'est plutôt un certain "laxisme" ambiant du langage (bien que ce
soit certainement volontaire de la part des auteurs).
Ceci dit, bien que l'informatique ne tourne pas qu'autour de cet
univers, les applications requérant une très grande fiabilité et sûreté
de fonctionnement ne seront jamais codées avec des langages à typage
dynamique.
>
>> Tu vois que je ne suis pas sectaire :-)
>
> <troll>
> Je ne sais pas, mais entre d'autres propos que tu a tenu ici et
> celui-ci, soit tu es parfois un peu excessif, soit tu souffres d'un
> dédoublement de personnalité !-)
>
> bon, ok, me ---->[]
> </troll>
Voilà, désolé, mais je suis, effectivement, parfois un peu excessif.
>
>> Surtout avec l'expérience du MIT.
>> .
>>>
>>>>>
>>>>> Je ne vois rien non plus concernant les structures de données et
>>>>> l'algo. Ca te semble tellement secondaire ?-)
>>>>
>>>> Bien sur qu'il faut enseigner les structures de données et l'algo
>>>> mais je ne définissais pas un cursus entier concernant
>>>> l'informatique mais seulement l'apprentissage des langages de
>>>> programmation.
>>>
>>> Evidemment - au temps pour moi. Ceci étant, peut-on vraiment
>>> totalement découpler l'algo et les structures de données du (des)
>>> langage(s) utilisé(s) ? (question ouverte à quelqu'un ayant
>>> l'expérience de l'enseignement - non, je ne fais pas que troller...)
>>
>> C'est la partie délicate de l'apprentissage de la programmation...
>> Il faut, certainement une petite dose d'algo en parallèle mais la plus
>> minime possible.
>
> Je me posais plutôt la question dans l'autre sens : comment enseigner
> l'algo indépendamment de certaines spécificités d'un langage (ou d'une
> famille de langages).
Il y avait un très bon bouquin décrivant un langage de pseudo-code, fait
par des gens d'IBM (dont Mills, je crois, mais il y avait d'autres
auteurs) pour l'enseignement en interne. Ce bouquin (datant de 79)
s'appelait "Structured Programming". A une époque, j'utilisais ce
pseudo-code pour des cours d'algo (en entreprise, pas en faculté).
Après, j'ai utilisé un pseudo ADA et les participants, sans connaître
ADA, comprenait tout le pseudo-code sans problème.
Le meilleur bouquin d'algo (qui n'en est pas un) que je connaisse est
celui de Grady Booch : Software Engineering with Ada. Benjamin/Cummings,
1983. ISBN 0-8053-0604-8. Ce bouquin est vraiment remarquable car il
décrit tous les algos sur les structures de données classique et donne
la complexité de chacun.
>
> <thinking-out-loud>
> Le même couple algo/structure de données peut prendre des apparences
> *très* différentes selon le langage utilisé - fut-il du pseudocode.
> Quand on connait plusieurs langages suffisament différents, on peut voir
> le concept (abstrait) derrière le code, mais pour un débutant, il est
> probablement plus difficile de faire cette abstraction. Enfin, j'imagine.
> </thinking-out-loud>
Justement, en algo, il faut lui montrer les abstractions (voir le
bouquins d'algo : B. Froidevaux C., Gaudel M-C., Soria M., Types de
Données et Algorithmes, Mac Graw Hill France, Février 1990, 570 pages.
bruno desthuilliers
Une excellente référence au demeurant...
> de Harold Abelson et Gerald jay
> Sussman (que j'ai connu en 81, lors d'une université d'été de 2 semaines
> à Newcastle sur la programmation fonctionnelle).
>
> > Dans une certaine mesure - et si on compare à ton listing - ça pose la
> > question de savoir s'il vaut mieux commencer avec un langage de
> > haut-niveau, ou mettre tout de suite les mains dans le cambouis avec un
> > langage plus près de la machine (et donc avant tout procédural,
> > puiqu'aux dernières nouvelles c'est le fonctionnement de nos ordis
> > actuels...).
>
> En fait, mais c'est difficile à mettre en oeuvre dans les cursus
> informatique, à cause du temps, il faudrait enseigner un langage genre
> ADA (pas taper) pour apprendre la rigueur de programmation (je choisis
> justement le plus rigide, comme tu dis par ailleurs, exprès) et u
> langage interprété à typage dynamique (et pourquoi pas Python,
> j'insiste). Les débutants informaticiens verraient de cette façon et
> comprendraient pourquoi un seul langage de programmation ne peut pas
> répondre à tous les besoins.
Rien à redire là-dessus.
>
> >> Pour OCaml, faut voir (à une époque et peut-être encore maintenant ?)
> >> au CNAM, ils utilisaient ADA et Caml.
>
> >> Pour le coup, peut-être que Python est le mieux.
>
> > Tu n'y songe pas, malheureux ! Un langage à typage dynamique, cette
> > chose à bannir à tous prix ! (enfin, d'après tes propres propos, hein...)
>
> Bon d'accord, mais ce n'est pas le typage dynamique qui me choque le
> plus, c'est plutôt un certain "laxisme" ambiant du langage
Python est pourtant globalement moins permissif que Ruby.
Si ce qui te choque est l'absence de restriction d'accès aux
attributs, il y a AMHA une leçon à tirer de cette affaire, qui est que
globalement, les développeurs sont capable d'intelligence et
d'autodiscipline.
> (bien que ce
> soit certainement volontaire de la part des auteurs).
Le fait de considérer les programmeurs comme des adultes responsables
et de leur laisser la main sur une majorité de points est
effectivement un choix raisonné. Dans la pratique, il est surprenant
de voir à quel point les développeurs Python tendent à être
raisonnable dans leur utilisation des fonctionnalités "avancées" du
langage - là où la "culture" Ruby semble plutôt être d'encourager
l'usage des fonctionnalités similaires de Ruby (pas une critique,
juste une observation à caractère sociologique). Au point d'ailleurs
que pas mal d'utilisateurs de Ruby que j'ai croisé ignorent totalement
l'existence des fonctionnalités avancées de Python, pourtant
documentées.
> Ceci dit, bien que l'informatique ne tourne pas qu'autour de cet
> univers, les applications requérant une très grande fiabilité et sûreté
> de fonctionnement ne seront jamais codées avec des langages à typage
> dynamique.
Honnêtement, je n'ai pas de religion sur ce point. En ce qui me
concerne, l'intérêt premier (et la raison d'être originelle) du typage
statique (déclaratif ou par inférence) est de permettre au compilo
d'optimiser plus aggressivement. Après, il y a des avantages et des
inconvénients aux deux approches. Il est clair que le typage statique
peut aider à vérifier la correction d'un programme - sans que ce soit
pour autant suffisant à prouver cette correction (accessoirement,
l'exemple d'Ariane prouve bien que les risques existent à tous les
niveaux quelque soit la fiabilité de la technologie utilisée). D'un
autre côté, il semble que le rapport kloc/defects soit à peu près
constant, et le typage statique ajoutant à la complexité
"accidentelle" du code, il induit un risque de bugs qui n'existeraient
pas sinon.
Pour la petite histoire, j'ai été pendant un temps un fanatique du
typage statique (sans raison rationnelle - à ce stade, ça relevait
plus du cargo-culte que d'autre chose), et je ne considérais pas qu'un
langage à typage dynamique puisse être autre chose qu'un gadget. Le
fait de voir que des applis relativement conséquentes écrites sans le
moindre souçi à cet égard dans un langage à typage dynamique
pouvaient s'avérer au moins aussi fiables (et infiniment plus
simples) m'a ouvert les yeux. Le fait aussi de constater, à
l'expérience, que les problèmes de typage étaient bien plus rare que
je ne l'aurai craint, et généralement très rapidement et facilement
détectées. Bref, tout ça (et quelques autres expériences similaires)
m'a rendu assez méfiant quant aux Grands Principes, et globalement
assez pragmatique.
D'un autre côté, je n'ai jamais eu à codé quoi que ce soit qui mette
en cause la sécurité des personnes, et je refuserais d'ailleurs de le
faire, ne m'estimant pas assez compétant. Mais bon, c'est aussi le cas
de la grande majorité des programmeurs.
>
>
> >> Tu vois que je ne suis pas sectaire :-)
>
> > <troll>
> > Je ne sais pas, mais entre d'autres propos que tu a tenu ici et
> > celui-ci, soit tu es parfois un peu excessif, soit tu souffres d'un
> > dédoublement de personnalité !-)
>
> > bon, ok, me ---->[]
> > </troll>
>
> Voilà, désolé, mais je suis, effectivement, parfois un peu excessif.
Il ne t'aura pas échappé que nous sommes (au moins) deux dans ce
cas !-)
> >>>>> Je ne vois rien non plus concernant les structures de données et
> >>>>> l'algo. Ca te semble tellement secondaire ?-)
>
> >>>> Bien sur qu'il faut enseigner les structures de données et l'algo
> >>>> mais je ne définissais pas un cursus entier concernant
> >>>> l'informatique mais seulement l'apprentissage des langages de
> >>>> programmation.
>
> >>> Evidemment - au temps pour moi. Ceci étant, peut-on vraiment
> >>> totalement découpler l'algo et les structures de données du (des)
> >>> langage(s) utilisé(s) ? (question ouverte à quelqu'un ayant
> >>> l'expérience de l'enseignement - non, je ne fais pas que troller...)
>
> >> C'est la partie délicate de l'apprentissage de la programmation...
> >> Il faut, certainement une petite dose d'algo en parallèle mais la plus
> >> minime possible.
>
> > Je me posais plutôt la question dans l'autre sens : comment enseigner
> > l'algo indépendamment de certaines spécificités d'un langage (ou d'une
> > famille de langages).
>
> Il y avait un très bon bouquin décrivant un langage de pseudo-code, fait
> par des gens d'IBM (dont Mills, je crois, mais il y avait d'autres
> auteurs) pour l'enseignement en interne. Ce bouquin (datant de 79)
> s'appelait "Structured Programming". A une époque, j'utilisais ce
> pseudo-code pour des cours d'algo (en entreprise, pas en faculté).
Je parles bien sûr sans savoir, mais j'ai tendance à penser que ce
pseudo-langage doit être plus proche de Pascal que de Lisp ou
Haskell ?
> Après, j'ai utilisé un pseudo ADA et les participants, sans connaître
> ADA, comprenait tout le pseudo-code sans problème.
Idem.
> Le meilleur bouquin d'algo (qui n'en est pas un) que je connaisse est
> celui de Grady Booch : Software Engineering with Ada. Benjamin/Cummings,
> 1983. ISBN 0-8053-0604-8. Ce bouquin est vraiment remarquable car il
> décrit tous les algos sur les structures de données classique et donne
> la complexité de chacun.
>
>
>
> > <thinking-out-loud>
> > Le même couple algo/structure de données peut prendre des apparences
> > *très* différentes selon le langage utilisé - fut-il du pseudocode.
> > Quand on connait plusieurs langages suffisament différents, on peut voir
> > le concept (abstrait) derrière le code, mais pour un débutant, il est
> > probablement plus difficile de faire cette abstraction. Enfin, j'imagine.
> > </thinking-out-loud>
>
> Justement, en algo, il faut lui montrer les abstractions (voir le
> bouquins d'algo : B. Froidevaux C., Gaudel M-C., Soria M., Types de
> Données et Algorithmes, Mac Graw Hill France, Février 1990, 570 pages.
Pas lu, non plus que le Booch.
Laurent Pointal
>> [pause] Si je reprend un exemple par rapport à ce que tu sembles avoir
>> fait (vu ce que j'ai pu lire du début de la discussion), tu n'iras pas
>> faire un soft embarqué d'assistance au pilotage d'un avion en Python,
>> ça n'aurais aucun sens. Par contre, tu peux très bien utiliser Python
>> pour automatiser les enchaînements de build et de tests unitaires de
>> ton soft écrit en ADA.
>> Pour cet usage, tu peux remplacer Python par Ruby, TCL, Perl ou tout
>> autre langage de script un peu avancé - mais Python est une excellente
>> glue - et il y a PyAda, dont le développement est malheureusement
>> abandonné: http://pyada.sourceforge.net/index.html [/pause]
>
> Tu sembles privilégier l'aspect script de Python. Ne serait-il utile que
> dans ces cas-là ?
Non, pas seulement. Là c'était un exemple pour une utilisation autour
d'ADA.
[mode prosélytisme="on"]
Par exemple, il permet de réaliser rapidement un prototype, une maquette
d'un système... et dans bien des cas de pouvoir fonctionner avec (sachant
que l'on utilise beaucoup de modules Python qui sont en fait écrits en C
et souvent très efficaces). Si on n'a juste une petite partie qui pose
des problèmes de vitesse on peut même la réécrire (celle là seulement) en
C/C++ et l'intégrer de façon transparente au reste.
C'est juste un exemple.
[/mode]
A+
bruno desthuilliers
> Laurent Pointal a écrit :
(snip)
> > Il y a aussi PythonCard (mais non je ne fait pas de prosélytisme) qui est
> > l'utilisation de Python avec une architecture événementielle type pile
> > HyperCard (mais avec les nombreuses librairies Python dispos).
> > Je ne sais pas trop où il en est (voir si le dépôt versionné n'est pas
> > très en avance par rapport aux tgz téléchargeables).
>
> >http://pythoncard.sourceforge.net/
>
> Une piste intéressante (je ne suis pas sectaire, contrairement à ce que
> peut penser Bruno Desthuilliers...
Qui avait peut-être à un moment quelque raison de le penser, non ?-)
(snip)
> >>>> Si tu enseignes à des personnes pour qui la programmation n'est qu'une
> >>>> unité de valeur obligatoire dans leur cursus, qui leur servira
> >>>> peut-être plus tard (mais pas sûr), alors autant leur apprendre un
> >>>> langage qui leur permette de faire simplement des choses
> >>>> puissantes,:interfaces graphiques, accès fichiers, liens avec des
> >>>> bases de données, manipulation des protocoles de l'internet...
> >> Entièrement d'accord mais je n'ai pas la réponse en terme de langage (je
> >> sens que certains vont dire ... Python)
>
> > Oui oui oui.
> > Bon, il faut dire que les gens qui font du Python un peu avancé ont
> > beaucoup de code écrit dans d'autres langages (réutilisation de
> > librairies C/C++ existantes, écriture de code de calcul optimisé...).
> > Tu n'iras pas faire un soft de traitement d'image complètement en Python,
> > ce n'est pas le but et ça serait particulièrement inefficace. Par contre
> > tu réutiliseras des librairies pour pouvoir profiter facilement de leurs
> > fonctionnalités et ajouter des services par dessus (GUI, réseau,
> > changements de formats...).
>
> Alors dans ce cas, pourquoi pas, effectivement...
C'est effectivement un cas d'utilisation courant de Python: faire la
glue entre des composants de bas-niveau. Dans le développement de
jeux, par exemple, implémenter la logique du jeu en Python au dessus
d'un moteur codé en C ou C++.
> > [pause] Si je reprend un exemple par rapport à ce que tu sembles avoir
> > fait (vu ce que j'ai pu lire du début de la discussion), tu n'iras pas
> > faire un soft embarqué d'assistance au pilotage d'un avion en Python, ça
> > n'aurais aucun sens. Par contre, tu peux très bien utiliser Python pour
> > automatiser les enchaînements de build et de tests unitaires de ton soft
> > écrit en ADA.
> > Pour cet usage, tu peux remplacer Python par Ruby, TCL, Perl ou tout
> > autre langage de script un peu avancé - mais Python est une excellente
> > glue - et il y a PyAda, dont le développement est malheureusement
> > abandonné:http://pyada.sourceforge.net/index.html
> > [/pause]
>
> Tu sembles privilégier l'aspect script de Python. Ne serait-il utile que
> dans ces cas-là ?
Heureusement non. Python est un langage de développement d'application
complet, utilisable aussi bien pour des applis web, des applis de
bureau, des applis de gestion traditionnelles (gestion commerciale,
compta, suivi client etc), de la gestion de paquetages pour une
distrib linux (cf gentoo), et toutes sortes d'utilitaires. Un des
objectifs du langage (et AMHA un objectif pleinment atteint) était
d'être le chainon manquant entre le C et les scripts shell.
> >>> Tout à fait.
> >>> Mais l'enseignement de la programmation dans des cursus non
> >>> informatiques est un vrai problème: en fait, ce sont rarement des
> >>> informaticiens de formation qui les font, ce qui pose non pas un
> >>> problème de qualité (que des physiciens codent des scripts python ou
> >>> matlab comme des pieds, c'est pas très grave)
>
> > Ouaif... sauf quand il faut les reprendre pour les adapter...
>
> Là c'est une tâche lourde.
Guère plus que de reprendre du code Python pondu par un développeur
Java n'ayant pas pris la peine d'apprendre en quoi Python différait de
son référentiel habituel (expérience vécue). <troll>Il faut croire que
Java ne donne pas que des bonnes habitudes</troll>
Thierry B.
> aient accès il faut le prendre en compte... quoique Microsoft fasse des
> tarifs très préférentiels aux étudiants afin d'élargir sa gamme
> d'utilisateurs captifs).
Ahem, corruption, pots de vins, vente à perte, noyautage ?
Thierry B.
>> Evidemment - au temps pour moi. Ceci étant, peut-on vraiment totalement
>> découpler l'algo et les structures de données du (des) langage(s)
>> utilisé(s) ? (question ouverte à quelqu'un ayant l'expérience de
>> l'enseignement - non, je ne fais pas que troller...)
>
> C'est la partie délicate de l'apprentissage de la programmation...
Non. c'est pas la partie "délicate", c'est la partie "primordiale".
Je ne sais plus qui a dit un truc du genre <<montre moi tes données
je verrais de que fait ton code, montre moi ton code, je ne verrais
rien>>, mais bon, dans le monde moderne, je trouve ça assez vrai.
> Il faut, certainement une petite dose d'algo en parallèle mais la plus
> minime possible.
Bah non, pas du tout, efface. Ce qu'il y a de vraiment kw0l avec
Python, (ou vraiment chiant, ça dépend du point de vue) c'est que
tu ne peux pas vraiment coder à la va-vite. Faut réfléchir un petit
peu avant. Sinon, c'est galère. Et si tu as des soucis d'algo, parce
que ce que tu veux faire est un peu complexe, il y a le CookBook,
qui te remettra dans le chemin, avec des plats cuisinés qui te feront
gravir la prochaine marche.
--
On pourrait aussi se passer du 1 avec !0.
"0"[!0] == '\0'
Wykaaa
Oui mais justement pas des étudiants qui débutent...
Le fil porte sur les langage pour l'enseignement, je te le rappelle...
>
>> (bien que ce
>> soit certainement volontaire de la part des auteurs).
>
> Le fait de considérer les programmeurs comme des adultes responsables
> et de leur laisser la main sur une majorité de points est
> effectivement un choix raisonné. Dans la pratique, il est surprenant
> de voir à quel point les développeurs Python tendent à être
> raisonnable dans leur utilisation des fonctionnalités "avancées" du
> langage - là où la "culture" Ruby semble plutôt être d'encourager
> l'usage des fonctionnalités similaires de Ruby (pas une critique,
> juste une observation à caractère sociologique). Au point d'ailleurs
> que pas mal d'utilisateurs de Ruby que j'ai croisé ignorent totalement
> l'existence des fonctionnalités avancées de Python, pourtant
> documentées.
Je suis d'accord qu'en général, les programmeurs essaient de faire "du
mieux possibles" mais, ce faisant, ils commettent souvent des erreurs
presque irréparables car le mieux est souvent l'ennemi du bien.
Je t'assure que dans le type d'applications qui est ma spécialité
(systèmes complexes à logiciel prépondérant), on ne peut pas raisonner
comme tu le fais.
>
>> Ceci dit, bien que l'informatique ne tourne pas qu'autour de cet
>> univers, les applications requérant une très grande fiabilité et sûreté
>> de fonctionnement ne seront jamais codées avec des langages à typage
>> dynamique.
>
> Honnêtement, je n'ai pas de religion sur ce point. En ce qui me
> concerne, l'intérêt premier (et la raison d'être originelle) du typage
> statique (déclaratif ou par inférence) est de permettre au compilo
> d'optimiser plus aggressivement. Après, il y a des avantages et des
> inconvénients aux deux approches. Il est clair que le typage statique
> peut aider à vérifier la correction d'un programme - sans que ce soit
> pour autant suffisant à prouver cette correction (accessoirement,
> l'exemple d'Ariane prouve bien que les risques existent à tous les
> niveaux quelque soit la fiabilité de la technologie utilisée). D'un
> autre côté, il semble que le rapport kloc/defects soit à peu près
> constant, et le typage statique ajoutant à la complexité
> "accidentelle" du code, il induit un risque de bugs qui n'existeraient
> pas sinon.
Non, désolé, le but premier du typage statique n'est pas que le ompilo
puisse mieux optimiser (c'est juste un effet de bord du typage
statique). Le but premier, c'est la fiabilité.
Sais-tu que dans un logiciel pour missile, il est interdit de faire des
opérations sur la pile d'exécution (donc il n'y a même pas de variables
locales dans les fonctions...), alors le typage dynamique :-(((((
>
> Pour la petite histoire, j'ai été pendant un temps un fanatique du
> typage statique (sans raison rationnelle - à ce stade, ça relevait
> plus du cargo-culte que d'autre chose), et je ne considérais pas qu'un
> langage à typage dynamique puisse être autre chose qu'un gadget. Le
> fait de voir que des applis relativement conséquentes écrites sans le
> moindre souçi à cet égard dans un langage à typage dynamique
> pouvaient s'avérer au moins aussi fiables (et infiniment plus
> simples) m'a ouvert les yeux. Le fait aussi de constater, à
> l'expérience, que les problèmes de typage étaient bien plus rare que
> je ne l'aurai craint, et généralement très rapidement et facilement
> détectées. Bref, tout ça (et quelques autres expériences similaires)
> m'a rendu assez méfiant quant aux Grands Principes, et globalement
> assez pragmatique.
Ce n'est pas du tout mon expérience qui est que les problèmes de typage
sont absolument très fréquents.
Maintenant, tout dépend du nombre de type dans tes applications.
La dernière appli que j'ai auditée était en Java et il y avait plus de 9
000 classes et plus de 26 000 méthodes !
>
> D'un autre côté, je n'ai jamais eu à codé quoi que ce soit qui mette
> en cause la sécurité des personnes, et je refuserais d'ailleurs de le
> faire, ne m'estimant pas assez compétant. Mais bon, c'est aussi le cas
> de la grande majorité des programmeurs.
Le problème c'est qu'on manque de développeurs suffisamment compétents
pour ce genre d'applications...
Et que, donc, il faut coder dans des langages qui ne permettent pas
n'importe quoi parce que ce n'est pas une question de programmeur adulte
responsable, c'est une question, cruciale, de formation et de compétence
justement.
>
>>
>>>> Tu vois que je ne suis pas sectaire :-)
>>> <troll>
>>> Je ne sais pas, mais entre d'autres propos que tu a tenu ici et
>>> celui-ci, soit tu es parfois un peu excessif, soit tu souffres d'un
>>> dédoublement de personnalité !-)
>>> bon, ok, me ---->[]
>>> </troll>
>> Voilà, désolé, mais je suis, effectivement, parfois un peu excessif.
>
> Il ne t'aura pas échappé que nous sommes (au moins) deux dans ce
> cas !-)
=8-))
>
>>>>>>> Je ne vois rien non plus concernant les structures de données et
>>>>>>> l'algo. Ca te semble tellement secondaire ?-)
>>>>>> Bien sur qu'il faut enseigner les structures de données et l'algo
>>>>>> mais je ne définissais pas un cursus entier concernant
>>>>>> l'informatique mais seulement l'apprentissage des langages de
>>>>>> programmation.
>>>>> Evidemment - au temps pour moi. Ceci étant, peut-on vraiment
>>>>> totalement découpler l'algo et les structures de données du (des)
>>>>> langage(s) utilisé(s) ? (question ouverte à quelqu'un ayant
>>>>> l'expérience de l'enseignement - non, je ne fais pas que troller...)
>>>> C'est la partie délicate de l'apprentissage de la programmation...
>>>> Il faut, certainement une petite dose d'algo en parallèle mais la plus
>>>> minime possible.
>>> Je me posais plutôt la question dans l'autre sens : comment enseigner
>>> l'algo indépendamment de certaines spécificités d'un langage (ou d'une
>>> famille de langages).
>> Il y avait un très bon bouquin décrivant un langage de pseudo-code, fait
>> par des gens d'IBM (dont Mills, je crois, mais il y avait d'autres
>> auteurs) pour l'enseignement en interne. Ce bouquin (datant de 79)
>> s'appelait "Structured Programming". A une époque, j'utilisais ce
>> pseudo-code pour des cours d'algo (en entreprise, pas en faculté).
>
> Je parles bien sûr sans savoir, mais j'ai tendance à penser que ce
> pseudo-langage doit être plus proche de Pascal que de Lisp ou
> Haskell ?
Bien sûr.
>
>> Après, j'ai utilisé un pseudo ADA et les participants, sans connaître
>> ADA, comprenait tout le pseudo-code sans problème.
>
> Idem.
Tout juste !
>
>> Le meilleur bouquin d'algo (qui n'en est pas un) que je connaisse est
>> celui de Grady Booch : Software Engineering with Ada. Benjamin/Cummings,
>> 1983. ISBN 0-8053-0604-8. Ce bouquin est vraiment remarquable car il
>> décrit tous les algos sur les structures de données classique et donne
>> la complexité de chacun.
>>
>>
>>
>>> <thinking-out-loud>
>>> Le même couple algo/structure de données peut prendre des apparences
>>> *très* différentes selon le langage utilisé - fut-il du pseudocode.
>>> Quand on connait plusieurs langages suffisament différents, on peut voir
>>> le concept (abstrait) derrière le code, mais pour un débutant, il est
>>> probablement plus difficile de faire cette abstraction. Enfin, j'imagine.
>>> </thinking-out-loud>
>> Justement, en algo, il faut lui montrer les abstractions (voir le
>> bouquins d'algo : B. Froidevaux C., Gaudel M-C., Soria M., Types de
>> Données et Algorithmes, Mac Graw Hill France, Février 1990, 570 pages.
>
> Pas lu, non plus que le Booch.
Tu rates quelque chose, mais c'est sûr qu'on ne peut pas tout lire ...
Enfin, si tu as l'occasion ne serait-ce que les feuilleter...
Wykaaa
Wykaaa
> --{ Wykaaa a plopé ceci: }--
>
>>> Evidemment - au temps pour moi. Ceci étant, peut-on vraiment totalement
>>> découpler l'algo et les structures de données du (des) langage(s)
>>> utilisé(s) ? (question ouverte à quelqu'un ayant l'expérience de
>>> l'enseignement - non, je ne fais pas que troller...)
>> C'est la partie délicate de l'apprentissage de la programmation...
>
> Non. c'est pas la partie "délicate", c'est la partie "primordiale".
> Je ne sais plus qui a dit un truc du genre <<montre moi tes données
> je verrais de que fait ton code, montre moi ton code, je ne verrais
> rien>>, mais bon, dans le monde moderne, je trouve ça assez vrai.
Oui, je suis absolument d'accord que ce sont les structures de données
qui conditionnent le code et surtout pas l'inverse mais, justement, un
bon cours d'algo présente les algo qui vont bien pour chaque structure
de données alors que l'apprentissage d'un langage de programmation
montre les constructions syntaxiques permettant de construire des
structures de données.
Si tu veux, il faut apprendre le vocabulaire et la grammaire avant de
pouvoir écrire un roman et les 2 ne doivent pas s'apprendre totalement
en parallèle...
>
>> Il faut, certainement une petite dose d'algo en parallèle mais la plus
>> minime possible.
>
> Bah non, pas du tout, efface. Ce qu'il y a de vraiment kw0l avec
> Python, (ou vraiment chiant, ça dépend du point de vue) c'est que
> tu ne peux pas vraiment coder à la va-vite. Faut réfléchir un petit
> peu avant. Sinon, c'est galère. Et si tu as des soucis d'algo, parce
> que ce que tu veux faire est un peu complexe, il y a le CookBook,
> qui te remettra dans le chemin, avec des plats cuisinés qui te feront
> gravir la prochaine marche.
De toute façon, coder à la va-vite est une hérésie, Python ou pas. De
même que coder sans conception, ni spécification...
A vrai dire, les programmeurs ne sont pas démunis pour les algos avec
les centaines de bouquins qui existent, le Net, etc.
Un programmeur, dans l'industrie, n'invente jamais un algo mais utilise,
voire adapte, des algos existants.
Bruno Desthuilliers
>>>>> Pour OCaml, faut voir (à une époque et peut-être encore maintenant ?)
>>>>> au CNAM, ils utilisaient ADA et Caml.
>>>>> Pour le coup, peut-être que Python est le mieux.
>>>> Tu n'y songe pas, malheureux ! Un langage à typage dynamique, cette
>>>> chose à bannir à tous prix ! (enfin, d'après tes propres propos,
>>>> hein...)
>>> Bon d'accord, mais ce n'est pas le typage dynamique qui me choque le
>>> plus, c'est plutôt un certain "laxisme" ambiant du langage
>>
>> Python est pourtant globalement moins permissif que Ruby.
>>
>> Si ce qui te choque est l'absence de restriction d'accès aux
>> attributs, il y a AMHA une leçon à tirer de cette affaire, qui est que
>> globalement, les développeurs sont capable d'intelligence et
>> d'autodiscipline.
>
> Oui mais justement pas des étudiants qui débutent...
> Le fil porte sur les langage pour l'enseignement, je te le rappelle...
Etant essentiellement autodidacte, je n'ai guère l'expérience des
"étudiants qui débutent". Mais, outre que je ne vois pourquoi on
devrait les supposer plus c... que la moyenne, on pourrait aussi
argumenter qu'apprendre l'auto-discipline au plus tôt n'est pas
forcément une mauvaise chose...
Accessoirement, tu ne réponds pas à ma question première concernant les
niveaux de permissivités respectifs de Python et Ruby !-)
>>> (bien que ce
>>> soit certainement volontaire de la part des auteurs).
>>
>> Le fait de considérer les programmeurs comme des adultes responsables
>> et de leur laisser la main sur une majorité de points est
>> effectivement un choix raisonné. Dans la pratique, il est surprenant
>> de voir à quel point les développeurs Python tendent à être
>> raisonnable dans leur utilisation des fonctionnalités "avancées" du
>> langage - là où la "culture" Ruby semble plutôt être d'encourager
>> l'usage des fonctionnalités similaires de Ruby (pas une critique,
>> juste une observation à caractère sociologique). Au point d'ailleurs
>> que pas mal d'utilisateurs de Ruby que j'ai croisé ignorent totalement
>> l'existence des fonctionnalités avancées de Python, pourtant
>> documentées.
>
> Je suis d'accord qu'en général, les programmeurs essaient de faire "du
> mieux possibles"
Tu détournes mon propos, là. Je ne parlais pas de bonne volonté, mais de
modération et d'auto-discipline, ce qui est totalement différent.
> mais, ce faisant, ils commettent souvent des erreurs
> presque irréparables car le mieux est souvent l'ennemi du bien.
Ca j'ai déjà pu m'en rendre compte, merci - il est d'ailleurs courant,
en Python, que je commence par implémenter mon affaire en tirant au
maximum partie de l'expressivité du langage, puis que je revienne en
arrière pour avoir un code un poil plus "lourd" mais nettement plus
compréhensible au "commun des mortels" (dont je ferai partie quand je
reviendrai sur le code quelques mois plus tard...). Et c'est bien là une
spécificité de la "culture" de la communauté Python en général : il vaut
mieux faire lisible (donc maintenable) que de vouloir être trop
intelligent pour son propre bien.
Le fait est que la vraie simplicité - le niveau d'abstraction précis qui
permet de résoudre une classe de problèmes données d'une façon à la fois
efficace et compréhensible - est quelque chose de très dur à atteindre.
> Je t'assure que dans le type d'applications qui est ma spécialité
> (systèmes complexes à logiciel prépondérant), on ne peut pas raisonner
> comme tu le fais.
Je ne suis pas sûr que tu saches vraiment comment je raisonne.
>>> Ceci dit, bien que l'informatique ne tourne pas qu'autour de cet
>>> univers, les applications requérant une très grande fiabilité et sûreté
>>> de fonctionnement ne seront jamais codées avec des langages à typage
>>> dynamique.
>>
>> Honnêtement, je n'ai pas de religion sur ce point. En ce qui me
>> concerne, l'intérêt premier (et la raison d'être originelle) du typage
>> statique (déclaratif ou par inférence) est de permettre au compilo
>> d'optimiser plus aggressivement. Après, il y a des avantages et des
>> inconvénients aux deux approches. Il est clair que le typage statique
>> peut aider à vérifier la correction d'un programme - sans que ce soit
>> pour autant suffisant à prouver cette correction (accessoirement,
>> l'exemple d'Ariane prouve bien que les risques existent à tous les
>> niveaux quelque soit la fiabilité de la technologie utilisée). D'un
>> autre côté, il semble que le rapport kloc/defects soit à peu près
>> constant, et le typage statique ajoutant à la complexité
>> "accidentelle" du code, il induit un risque de bugs qui n'existeraient
>> pas sinon.
>
> Non, désolé, le but premier du typage statique n'est pas que le ompilo
> puisse mieux optimiser (c'est juste un effet de bord du typage
> statique). Le but premier, c'est la fiabilité.
Je ne suis pas historien et n'ait pas 50 ans d'expérience dans le
domaine (juste une dizaine), donc je peux bien sûr me tromper (auquel
cas merci de me pointer vers les chapitres et versets appropriés !-),
mais il me semble que tu inverses les causes et effets au regard de la
réalité historique.
<troll>
N'y aurait-il pas quelque chose d'un peu idéologique dans ta déclaration ?-)
(oui, ne le dis pas : pareil pour moi...)
</troll>
> Sais-tu que dans un logiciel pour missile, il est interdit de faire des
> opérations sur la pile d'exécution (donc il n'y a même pas de variables
> locales dans les fonctions...),
Uniquement des globales ???
Bon, je suppose que ça se tient par ailleurs - au moins ça évite les
débordements de pile ou autre c... similaires.
>> Pour la petite histoire, j'ai été pendant un temps un fanatique du
>> typage statique (sans raison rationnelle - à ce stade, ça relevait
>> plus du cargo-culte que d'autre chose), et je ne considérais pas qu'un
>> langage à typage dynamique puisse être autre chose qu'un gadget. Le
>> fait de voir que des applis relativement conséquentes écrites sans le
>> moindre souçi à cet égard dans un langage à typage dynamique
>> pouvaient s'avérer au moins aussi fiables (et infiniment plus
>> simples) m'a ouvert les yeux. Le fait aussi de constater, à
>> l'expérience, que les problèmes de typage étaient bien plus rare que
>> je ne l'aurai craint, et généralement très rapidement et facilement
>> détectées. Bref, tout ça (et quelques autres expériences similaires)
>> m'a rendu assez méfiant quant aux Grands Principes, et globalement
>> assez pragmatique.
>
> Ce n'est pas du tout mon expérience qui est que les problèmes de typage
> sont absolument très fréquents.
En C, oui, effectivement, j'en ai vu pas mal. En Java un peu moins (les
types étant moins dépendants de la plateforme), mais pas mal quand même.
En Python, bizarrement et à ma grande surprise, *beaucoup* moins. Ma
théorie (que d'autres ont certainement formulé avant moi, mieux que moi,
et avec plus de faits pour l'appuyer et plus de compétence pour la
démontrer) est que le typage dynamique - à l'instar de la gestion
automatique de la mémoire - réduit grandement la complexité
accidentelle, donc les risques d'erreur. En raccourci et d'une façon un
peu provocatrice, on pourrait dire qu'une part des erreurs de typages
provient justement du typage statique !-)
Ceci étant, on parle de typage statique et dynamique en faisant comme si
la notion même de "type" était la même dans les deux cas, ce que n'est
peut-être pas vraiment le cas. Du point du vue du typage statique, dans
des langages comme Python ou Ruby, il n'existe en fait qu'un seul type,
le type 'objet' - pas de types "primitifs", "scalaires" etc...
Accessoirement, un des points que je déteste le plus dans Java est cette
contradiction à se prétendre 100% objet tout en ayant des types
primitifs - donc des types qui ne sont *pas* des objets.
> Maintenant, tout dépend du nombre de type dans tes applications.
> La dernière appli que j'ai auditée était en Java et il y avait plus de 9
> 000 classes et plus de 26 000 méthodes !
Ce genre de métrique me fait un peu sourire. Pas qu'elle n'ait
absolument aucun sens, mais il est évident pour qui en a l'expérience
que la même appli en Python ou en Ruby nécessiterait au moins moitié
moins de code, *entre autres* en raison du typage dynamique.
>> D'un autre côté, je n'ai jamais eu à codé quoi que ce soit qui mette
>> en cause la sécurité des personnes, et je refuserais d'ailleurs de le
>> faire, ne m'estimant pas assez compétant. Mais bon, c'est aussi le cas
>> de la grande majorité des programmeurs.
>
> Le problème c'est qu'on manque de développeurs suffisamment compétents
> pour ce genre d'applications...
Je n'en doutes pas.
> Et que, donc, il faut coder dans des langages qui ne permettent pas
> n'importe quoi parce que ce n'est pas une question de programmeur adulte
> responsable, c'est une question, cruciale, de formation et de compétence
> justement.
L'un n'exclus pas l'autre, et pas seulement au niveau du développeur. Et
il est bien évident que si je devais bosser dans ce domaine, j'aurais
tendance à être un control freak totalement paranoïaque.
(snip)
>>>> Je me posais plutôt la question dans l'autre sens : comment enseigner
>>>> l'algo indépendamment de certaines spécificités d'un langage (ou d'une
>>>> famille de langages).
>>> Il y avait un très bon bouquin décrivant un langage de pseudo-code, fait
>>> par des gens d'IBM (dont Mills, je crois, mais il y avait d'autres
>>> auteurs) pour l'enseignement en interne. Ce bouquin (datant de 79)
>>> s'appelait "Structured Programming". A une époque, j'utilisais ce
>>> pseudo-code pour des cours d'algo (en entreprise, pas en faculté).
>>
>> Je parles bien sûr sans savoir, mais j'ai tendance à penser que ce
>> pseudo-langage doit être plus proche de Pascal que de Lisp ou
>> Haskell ?
>
> Bien sûr.
Et il te semble pas que ça influe quelque peu la façon dont l'algo est
enseignée ?
>>> Justement, en algo, il faut lui montrer les abstractions (voir le
>>> bouquins d'algo : B. Froidevaux C., Gaudel M-C., Soria M., Types de
>>> Données et Algorithmes, Mac Graw Hill France, Février 1990, 570 pages.
>>
>> Pas lu, non plus que le Booch.
>
> Tu rates quelque chose, mais c'est sûr qu'on ne peut pas tout lire ...
Bin non.
Thierry B.
>>> globalement, les développeurs sont capable d'intelligence et
>>> d'autodiscipline.
(je sais plus à qui je répond, là)
En fait, vu les contraintes du monde moderne, il y a deux catégories
de développeurs: ceux qui doivent faire des bons trucs et ce qui
doivent faire des trucs déja vendus. J'ai beaucoup réfléchi à ça
ces dernières semaines, n'étant ni bac+5, ni grd.écoles, ni jeune.
Quand tu as trois jours pour faire ce qui a été vendu pour cinq
alors qu'il en fallait dix, je suis désolé, mais tu laisses tomber
l'autodiscipline pour aller au plus vite. Moi, ça me gène beaucoup.
C'est pour ça que je ne veux plus travailler dans l'informatique.
Si un lurker me propose un poste de jardinier ou de balayeur, je
suis preneur. Mon esprit sera plus libre pour continuer à faire
des choses diverses avec mes 'dinateurs.
>>
>> Oui mais justement pas des étudiants qui débutent...
>> Le fil porte sur les langage pour l'enseignement, je te le rappelle...
>
> Etant essentiellement autodidacte, je n'ai guère l'expérience des
> "étudiants qui débutent".
Pour avoir l'expérience des "débutants", il suffit d'avoir deux
gosses qui viennent passer les week-ends chez Papa, qui a plein
de machines étranges chez lui :) Et de leur expliquer que faire
marcher les 'dinateurs, c'est comme apprendre à faire de la
mosaïque, du dessin, de la musique, il y a plein de règles qui
ont été construites par des gens très bien, et que pour devenir
aussi bon que ces gens, il faut apprendre à les contourner, sans
sortir de certaines limites, limites qui sont compréhensibles
quand elle t'ont proutée à la figure.
> Mais, outre que je ne vois pourquoi on
> devrait les supposer plus c... que la moyenne, on pourrait aussi
> argumenter qu'apprendre l'auto-discipline au plus tôt n'est pas
> forcément une mauvaise chose...
C'est justement pour ça que j'aime bien Python: il est très facile
de goretiser plein de choses, mais le "cadrage" du langage oblige
à une véritable auto-discipline. Si tu n'est pas vraiment discipliné,
ben la goretisation, elle ne marche tout simplement pas.
$CALL /SYS/SIGROT
Q : If someone has the code in python for a buffer overflow, please post it.
A : Python does not support buffer overflows, sorry.
>> Sais-tu que dans un logiciel pour missile, il est interdit de faire des
>> opérations sur la pile d'exécution (donc il n'y a même pas de variables
>> locales dans les fonctions...),
>
> Uniquement des globales ???
Oui. J'ai connu ça, mais ça passait par une sorte de macro-langage
qui prenait en charge le placement des données en mémoire.
Bon, à table, c'est prêt, beignet d'agneau au riz.
--
Grosse fatigue, là. J'ai pas réussi à faire passer le décret pour
doubler mes revenus...
Bruno Desthuilliers
> --{ Bruno Desthuilliers a plopé ceci: }--
>
>>>> globalement, les développeurs sont capable d'intelligence et
>>>> d'autodiscipline.
>
> (je sais plus à qui je répond, là)
A moi !-)
> En fait, vu les contraintes du monde moderne, il y a deux catégories
> de développeurs: ceux qui doivent faire des bons trucs et ce qui
> doivent faire des trucs déja vendus.
Les deux sont-ils nécessairement exclusifs ?
> J'ai beaucoup réfléchi à ça
> ces dernières semaines, n'étant ni bac+5, ni grd.écoles, ni jeune.
<aol />
> Quand tu as trois jours pour faire ce qui a été vendu pour cinq
> alors qu'il en fallait dix, je suis désolé, mais tu laisses tomber
> l'autodiscipline pour aller au plus vite. Moi, ça me gène beaucoup.
<aol />
> C'est pour ça que je ne veux plus travailler dans l'informatique.
C'est pour ça que je préfère un salaire moindre si en contrepartie j'ai
la possibilité de travailler dans des conditions acceptables selon mes
termes.
> Si un lurker me propose un poste de jardinier ou de balayeur, je
> suis preneur. Mon esprit sera plus libre pour continuer à faire
> des choses diverses avec mes 'dinateurs.
Je me suis posé la question à deux occasions depuis que j'ai pris
conscience de cette problématique il y a déjà quelques années. A chaque
fois, j'ai eu la chance de pouvoir retrouver des conditions qui me
permettent de continuer.
>>> Oui mais justement pas des étudiants qui débutent...
>>> Le fil porte sur les langage pour l'enseignement, je te le rappelle...
>> Etant essentiellement autodidacte, je n'ai guère l'expérience des
>> "étudiants qui débutent".
>
> Pour avoir l'expérience des "débutants", il suffit d'avoir deux
> gosses qui viennent passer les week-ends chez Papa, qui a plein
> de machines étranges chez lui :)
Je n'en ai qu'un, mais à plein temps. Ca compte ?-)
Ceci étant, je ne suis pas sûr que ce soit vraiment comparable.
>> Mais, outre que je ne vois pourquoi on
>> devrait les supposer plus c... que la moyenne, on pourrait aussi
>> argumenter qu'apprendre l'auto-discipline au plus tôt n'est pas
>> forcément une mauvaise chose...
>
> C'est justement pour ça que j'aime bien Python: il est très facile
> de goretiser plein de choses, mais le "cadrage" du langage oblige
> à une véritable auto-discipline. Si tu n'est pas vraiment discipliné,
> ben la goretisation, elle ne marche tout simplement pas.
Mmm... AMHA, c'est surtout une "culture" qui prévaut dans la communauté
Python, qui attire des développeurs relativement "responsables", ce qui
renforce cette culture etc...
> $CALL /SYS/SIGROT
> Q : If someone has the code in python for a buffer overflow, please post it.
> A : Python does not support buffer overflows, sorry.
Mouarf !-)
>>> Sais-tu que dans un logiciel pour missile, il est interdit de faire des
>>> opérations sur la pile d'exécution (donc il n'y a même pas de variables
>>> locales dans les fonctions...),
>> Uniquement des globales ???
>
> Oui. J'ai connu ça, mais ça passait par une sorte de macro-langage
> qui prenait en charge le placement des données en mémoire.
Bon, là (embarqué etc...), on est complètement en dehors de mon domaine
de toutes façons. A mon grand regret, d'ailleurs - j'aimerais bien
trouver le temps de m'intéresser aussi à ces aspects, mais voilà, y a
que 24h dans une journée.
>
> Bon, à table, c'est prêt, beignet d'agneau au riz.
>
Bon app.
Marc Boyer
> Wykaaa a écrit :
>>> Si ce qui te choque est l'absence de restriction d'accès aux
>>> attributs, il y a AMHA une leçon à tirer de cette affaire, qui est que
>>> globalement, les développeurs sont capable d'intelligence et
>>> d'autodiscipline.
>>
>> Oui mais justement pas des étudiants qui débutent...
>> Le fil porte sur les langage pour l'enseignement, je te le rappelle...
>
> Etant essentiellement autodidacte, je n'ai guère l'expérience des
> "étudiants qui débutent". Mais, outre que je ne vois pourquoi on
> devrait les supposer plus c... que la moyenne, on pourrait aussi
> argumenter qu'apprendre l'auto-discipline au plus tôt n'est pas
> forcément une mauvaise chose...
Ils ne sont pas plus cons, mais comme ils ne connaissent pas
les problèmes, ils ne voient pas l'intérêt des solutions.
La plupart des règles de codage viennent à essayer de permettre
le passage à l'échelle (cf autre longue discussion sur fclc et les
variables globales).
Par exemple, utiliser l'interface publique et non l'implantation
(privée), ça force à écrire plus de code (ex init_liste(&l)
au lieu de l=NULL), à se souvenir du nom de la méthode, tout ça...
Avec un peu d'expérience, on sait que ça rend le code plus
maintenable. Le débutant, lui, n'a pas cet expérience et prend
le prof pour un ch.eur.
>> Non, désolé, le but premier du typage statique n'est pas que le ompilo
>> puisse mieux optimiser (c'est juste un effet de bord du typage
>> statique). Le but premier, c'est la fiabilité.
>
> Je ne suis pas historien et n'ait pas 50 ans d'expérience dans le
> domaine (juste une dizaine), donc je peux bien sûr me tromper (auquel
> cas merci de me pointer vers les chapitres et versets appropriés !-),
> mais il me semble que tu inverses les causes et effets au regard de la
> réalité historique.
Ca dépend du point de vue...
Je pense que le typage "à la C" (int/float/char*) vient d'un
mappin efficace sur le processeur, contrairement à Lisp, où
l'interpréteur doit dynamiquement regarder ce qu'il manipule.
Mais ensuite, les ajouts de typage, à la Ada, C++, veulent
eux fiabiliser en évitant d'ajouter des pommes et des poires
(à moins de déclarer explicitement l'opérateur de compote).
>> Ce n'est pas du tout mon expérience qui est que les problèmes de typage
>> sont absolument très fréquents.
>
> En C, oui, effectivement, j'en ai vu pas mal. En Java un peu moins (les
> types étant moins dépendants de la plateforme), mais pas mal quand même.
> En Python, bizarrement et à ma grande surprise, *beaucoup* moins. Ma
> théorie (que d'autres ont certainement formulé avant moi, mieux que moi,
> et avec plus de faits pour l'appuyer et plus de compétence pour la
> démontrer) est que le typage dynamique - à l'instar de la gestion
> automatique de la mémoire - réduit grandement la complexité
> accidentelle, donc les risques d'erreur. En raccourci et d'une façon un
> peu provocatrice, on pourrait dire qu'une part des erreurs de typages
> provient justement du typage statique !-)
Quant aux débutants... Ils confondent (je prends la syntaxe C)
0, 0.0, "0", '0' et '\0'. Alors, si tu ne leur impose pas
de dire quel est le type de valeur qu'ils manipulent (lors de
la déclaration de variable), ben, c'est la panique.
J'ai fait d'ailleurs un TP édifiant sur le sujet il y a 3 jours:
on leur demande d'extraire une sous image d'une image PGM, dont le
format est
P5
largeur hauteur
profondeur
bitmap
Ben, le passage du stockage de valeurs 'humaines' à binaire
les rend extrèmement perplexe. Quand en projet je leur fait
envoyer des entier 32bits en grand boutiste, j'en ai qui
envoyent "0012" au lieu de 12...
Que le programmeur expérimenté puisse laisser le type comme
information implicite, pourquoi pas. Mais pas le débutant.
> Ceci étant, on parle de typage statique et dynamique en faisant comme si
> la notion même de "type" était la même dans les deux cas, ce que n'est
> peut-être pas vraiment le cas. Du point du vue du typage statique, dans
> des langages comme Python ou Ruby, il n'existe en fait qu'un seul type,
> le type 'objet' - pas de types "primitifs", "scalaires" etc...
Heuh... Faut quand même pas confondre les concepts et leur
implantation. Je suis 0 en python, mais je lis sur Wikipédia:
points = 3.2 # points est du type float
print "Tu as " + points + " points !" # Génère une erreur de typage
Que la notion de type (flottant, chaine) soit englobée dans un attribut
dynamique en python, ok, mais la notion reste là, non ?
>>> Je parles bien sûr sans savoir, mais j'ai tendance à penser que ce
>>> pseudo-langage doit être plus proche de Pascal que de Lisp ou
>>> Haskell ?
>>
>> Bien sûr.
>
> Et il te semble pas que ça influe quelque peu la façon dont l'algo est
> enseignée ?
C'est compliqué...
C'est un thread à lui tout seul.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Marc Boyer
> Le Tue, 01 Apr 2008 20:54:13 +0200, Wykaaa a écrit :
>
><zip>
>
>> Le débat entame ici le fond du problème pour l'enseignement de la
>> programmation.
>> Je vais donner mon point de vue personnel qu'on peut ne pas partager
>> (mais sans polémique SVP) :
>
> Il est partagé.
> J'y ajouterais des langages à paradigmes différents (style Lisp, Prolog
> et assimilés). C'est un truc qui me manque je trouve, j'ai fait un peu de
> prolog au CNAM, mais c'est tout.
>
> Note: mes collègues qui enseignent dans les cursus d'informatique en fac
> ont de plus en plus de mal de trouver des étudiants intéressés par le
> simple fait de programmer - la pluspart veulent devenir analystes, chefs
> de projets... mais surtout pas mettre les mains dans le cambouis. Pas sûr
> qu'à terme ça ne fasse pas de mauvaises surprises au niveau des cahiers
> des charges qu'ils rédigeront...
Petite anectode: cours de Pascal, premier semestre d'école d'ingé
"mais pourquoi on apprend à programmer finalement ? C'est pas un boulot
d'ingenieur, c'est un boulot de technicien sous payé."
Je me suis contenté de lui dire qu'il pouvait ajouter sur son CV
qu'il refuserait tout boulot demandant de coder, qu'il était libre...
Il a réalisé qu'il avait dit une connerie...
> AMA il est important de leur montrer la réutilisation de bibliothèques
> existantes, de leur apprendre à chercher d'abord si ce dont ils ont
> besoin n'a pas déjà été réalisé dans un langage/outil quelconque.
Oui et non.
Disons que si tu n'as pas quelques notions sur ce qu'est un
tableau, une liste, un arbre et une table de haschage, ben,
tu ne sais même pas qu'il existerait une structure de donnée
plus appropriée pour telle structure de donnée.
Après, oui, recoder un parseur XML depuis 0 en C...
>>> Mais l'enseignement de la programmation dans des cursus non
>>> informatiques est un vrai problème: en fait, ce sont rarement des
>>> informaticiens de formation qui les font, ce qui pose non pas un
>>> problème de qualité (que des physiciens codent des scripts python ou
>>> matlab comme des pieds, c'est pas très grave)
>
> Ouaif... sauf quand il faut les reprendre pour les adapter...
Là, faut reprendre l'article qui a été publié, et recoder de 0.
> Je leur trouverais en commun d'avoir à accéder à des bases de données et
> à faire des traitements pour extraire ce dont ils ont besoin... des cours
> de SQL?
D'Excel, ce serait suffisant ;-)
Bruno Desthuilliers
> Bruno Desthuilliers <bruno.42.de...@websiteburo.invalid> wrote:
>> Wykaaa a écrit :
>>>> Si ce qui te choque est l'absence de restriction d'accès aux
>>>> attributs, il y a AMHA une leçon à tirer de cette affaire, qui est que
>>>> globalement, les développeurs sont capable d'intelligence et
>>>> d'autodiscipline.
>>> Oui mais justement pas des étudiants qui débutent...
>>> Le fil porte sur les langage pour l'enseignement, je te le rappelle...
>> Etant essentiellement autodidacte, je n'ai guère l'expérience des
>> "étudiants qui débutent". Mais, outre que je ne vois pourquoi on
>> devrait les supposer plus c... que la moyenne, on pourrait aussi
>> argumenter qu'apprendre l'auto-discipline au plus tôt n'est pas
>> forcément une mauvaise chose...
>
> Ils ne sont pas plus cons, mais comme ils ne connaissent pas
> les problèmes, ils ne voient pas l'intérêt des solutions.
> La plupart des règles de codage viennent à essayer de permettre
> le passage à l'échelle (cf autre longue discussion sur fclc et les
> variables globales).
Pas vu - je ne suis plus fclc que sporadiquement.
>
> Par exemple, utiliser l'interface publique et non l'implantation
> (privée), ça force à écrire plus de code (ex init_liste(&l)
> au lieu de l=NULL), à se souvenir du nom de la méthode, tout ça...
>
> Avec un peu d'expérience, on sait que ça rend le code plus
> maintenable. Le débutant, lui, n'a pas cet expérience et prend
> le prof pour un ch.eur.
Comme je le disais, je n'ai guère l'expérience des "étudiants qui
débutent"... Vu mon parcours, je ne suis certainement pas une référence
dans ce domaine !-)
>>> Non, désolé, le but premier du typage statique n'est pas que le ompilo
>>> puisse mieux optimiser (c'est juste un effet de bord du typage
>>> statique). Le but premier, c'est la fiabilité.
>> Je ne suis pas historien et n'ait pas 50 ans d'expérience dans le
>> domaine (juste une dizaine), donc je peux bien sûr me tromper (auquel
>> cas merci de me pointer vers les chapitres et versets appropriés !-),
>> mais il me semble que tu inverses les causes et effets au regard de la
>> réalité historique.
>
> Ca dépend du point de vue...
> Je pense que le typage "à la C" (int/float/char*) vient d'un
> mappin efficace sur le processeur, contrairement à Lisp, où
> l'interpréteur doit dynamiquement regarder ce qu'il manipule.
>
> Mais ensuite, les ajouts de typage, à la Ada, C++, veulent
> eux fiabiliser en évitant d'ajouter des pommes et des poires
> (à moins de déclarer explicitement l'opérateur de compote).
C'était déjà le cas en Pascal, non ?
Bon, y a un historien dans la salle ?-)
>>> Ce n'est pas du tout mon expérience qui est que les problèmes de typage
>>> sont absolument très fréquents.
>> En C, oui, effectivement, j'en ai vu pas mal. En Java un peu moins (les
>> types étant moins dépendants de la plateforme), mais pas mal quand même.
>> En Python, bizarrement et à ma grande surprise, *beaucoup* moins. Ma
>> théorie (que d'autres ont certainement formulé avant moi, mieux que moi,
>> et avec plus de faits pour l'appuyer et plus de compétence pour la
>> démontrer) est que le typage dynamique - à l'instar de la gestion
>> automatique de la mémoire - réduit grandement la complexité
>> accidentelle, donc les risques d'erreur. En raccourci et d'une façon un
>> peu provocatrice, on pourrait dire qu'une part des erreurs de typages
>> provient justement du typage statique !-)
>
>
> Quant aux débutants... Ils confondent (je prends la syntaxe C)
> 0, 0.0, "0", '0' et '\0'. Alors, si tu ne leur impose pas
> de dire quel est le type de valeur qu'ils manipulent (lors de
> la déclaration de variable), ben, c'est la panique.
Heu... J'ai commencé à bricoler mes premiers bouts de code en 1990 avec
HyperCard / HyperTalk (typage dynamique, et pas spécialement fort). Sans
internet, et sans personne pour me mentorer. Et j'ai très vite appris à
faire la différence entre une chaine et un nombre (ne serait-ce qu'en
voyant le résultat des calculs...).
Bon, le langage suivant (si on omet un peu d'assembleur 68k) était un
basic objet à typage statique déclaratif, et je reconnais que dans un
premier temps, j'ai de moi-même considéré ça comme une aide et un
progrès par rapport à HyperTalk - peut-être simplement parce que ça
m'obligeait à structurer un peu plus ma réflexion vu que dans la
pratique je n'avais en fait guère de pb de typage, ayant déjà appris à
être attentif à ces aspects.
> J'ai fait d'ailleurs un TP édifiant sur le sujet il y a 3 jours:
> on leur demande d'extraire une sous image d'une image PGM, dont le
> format est
> P5
> largeur hauteur
> profondeur
> bitmap
>
> Ben, le passage du stockage de valeurs 'humaines' à binaire
> les rend extrèmement perplexe. Quand en projet je leur fait
> envoyer des entier 32bits en grand boutiste, j'en ai qui
> envoyent "0012" au lieu de 12...
>
> Que le programmeur expérimenté puisse laisser le type comme
> information implicite, pourquoi pas. Mais pas le débutant.
Tu a certainement plus d'expérience que moi dans ce domaine. D'un autre
côté, j'ai appris autrement, et je ne sais pas si j'aurais appris quoi
que ce soit s'il m'avait fallu me coltiner des déclarations de types et
autres boilerplate dès le début - j'aurais probablement laissé tombé en
me disant que c'était trop compliqué et trop chiant. Le fait d'avoir pu
réaliser dès les premiers jours avoir des petits programmes
*fonctionnels* est certainement pour beaucoup dans ma "vocation". Et une
fois motivé, je n'ai pas eu de problème majeur à passer à des technos
bien plus contraignantes.
>> Ceci étant, on parle de typage statique et dynamique en faisant comme si
>> la notion même de "type" était la même dans les deux cas, ce que n'est
>> peut-être pas vraiment le cas. Du point du vue du typage statique, dans
>> des langages comme Python ou Ruby, il n'existe en fait qu'un seul type,
>> le type 'objet' - pas de types "primitifs", "scalaires" etc...
>
> Heuh... Faut quand même pas confondre les concepts et leur
> implantation. Je suis 0 en python, mais je lis sur Wikipédia:
> points = 3.2 # points est du type float
> print "Tu as " + points + " points !" # Génère une erreur de typage
>
> Que la notion de type (flottant, chaine) soit englobée dans un attribut
> dynamique en python, ok, mais la notion reste là, non ?
La notion de "type" est là, oui, je ne dis pas le contraire. Mais
pointe-t-elle sur le même concept ?
En C, un "type" est une information précisant un offset à partir de
l'adresse mémoire de la variable, et la façon dont doivent être
interprétés les bits contenus entre cette adresse et l'offset.
En Python, un "type" (en tous cas ce que renvoie la fonction type()...)
est une référence sur un autre objet (la classe), lequel contient
d'autres références sur d'autres objets - les superclasses, la
metaclasse, et les attributs de classe, lesquels comprennent les
méthodes (je m'arrête là le but n'étant pas de détailler le modèle objet
de Python).
>>>> Je parles bien sûr sans savoir, mais j'ai tendance à penser que ce
>>>> pseudo-langage doit être plus proche de Pascal que de Lisp ou
>>>> Haskell ?
>>> Bien sûr.
>> Et il te semble pas que ça influe quelque peu la façon dont l'algo est
>> enseignée ?
>
> C'est compliqué...
> C'est un thread à lui tout seul.
Commence toujours, si ça déborde on continuera dans un autre thread. De
toutes façon, vu l'activitée ici ces derniers temps, on n'est pas près
de déranger grand monde (à part peut-être quelques spammeurs...)
Bruno Desthuilliers
>> Note: mes collègues qui enseignent dans les cursus d'informatique en fac
>> ont de plus en plus de mal de trouver des étudiants intéressés par le
>> simple fait de programmer - la pluspart veulent devenir analystes, chefs
>> de projets... mais surtout pas mettre les mains dans le cambouis. Pas sûr
>> qu'à terme ça ne fasse pas de mauvaises surprises au niveau des cahiers
>> des charges qu'ils rédigeront...
>
> Petite anectode: cours de Pascal, premier semestre d'école d'ingé
> "mais pourquoi on apprend à programmer finalement ? C'est pas un boulot
> d'ingenieur, c'est un boulot de technicien sous payé."
<mode="rant">
Le "technicien sous payé" que je suis emm... ce connard prétentieux qui
n'a rien à foutre dans notre profession, et qui sera toujours à mes yeux
un guignol, et tout document de conceptions, SFT etc venant de lui me
servirons au mieux à un usage que la décence m'empêche d'expliciter
d'avantage. Qu'il n'aime pas programmer, c'est son droit, mais qu'il
prenne les développeurs pour des pisseur de code est tout simplement
insupportable.
</mode>
> Je me suis contenté de lui dire qu'il pouvait ajouter sur son CV
> qu'il refuserait tout boulot demandant de coder, qu'il était libre...
> Il a réalisé qu'il avait dit une connerie...
Si tu le recroises, tu pourra lui transmettre le message ci-dessus,
parce que je crains qu'il ne réalise pas vraiment à quel point...
(snip)
Wykaaa
> Wykaaa a écrit :
>> bruno desthuilliers a écrit :
>>> On 2 avr, 19:50, Wykaaa <wyk...@yahoo.fr> wrote:
> (snip)
>>>>>> Pour OCaml, faut voir (à une époque et peut-être encore maintenant ?)
>>>>>> au CNAM, ils utilisaient ADA et Caml.
>>>>>> Pour le coup, peut-être que Python est le mieux.
>>>>> Tu n'y songe pas, malheureux ! Un langage à typage dynamique, cette
>>>>> chose à bannir à tous prix ! (enfin, d'après tes propres propos,
>>>>> hein...)
>>>> Bon d'accord, mais ce n'est pas le typage dynamique qui me choque le
>>>> plus, c'est plutôt un certain "laxisme" ambiant du langage
>>>
>>> Python est pourtant globalement moins permissif que Ruby.
>>>
>>> Si ce qui te choque est l'absence de restriction d'accès aux
>>> attributs, il y a AMHA une leçon à tirer de cette affaire, qui est que
>>> globalement, les développeurs sont capable d'intelligence et
>>> d'autodiscipline.
>>
>> Oui mais justement pas des étudiants qui débutent...
>> Le fil porte sur les langage pour l'enseignement, je te le rappelle...
>
> Etant essentiellement autodidacte, je n'ai guère l'expérience des
> "étudiants qui débutent". Mais, outre que je ne vois pourquoi on
> devrait les supposer plus c... que la moyenne, on pourrait aussi
> argumenter qu'apprendre l'auto-discipline au plus tôt n'est pas
> forcément une mauvaise chose...
>
programmation de côté...
> Accessoirement, tu ne réponds pas à ma question première concernant les
> niveaux de permissivités respectifs de Python et Ruby !-)
>
Je ne crois pas que Python soit moins permissif que Ruby. Il faudrait
une étude approfondie et je n'ai pas assez d'expérience dans ces deux
langages pour trancher.
Alors qu'est-ce qui me fait dire ça ?
Probablement "ma culture" qui est essentiellement objet puisque je
manipule les ADT (Abstract Data Type depuis 1977, donc avant l'objet, du
moins avant Grady Booch. Quoique le premier langage objet est SIMULA 67
: en 1967 donc...).
Il est indéniable que Ruby est "plus objet" que Python ce qui n'est pas
surprenant puisque l'objet a été ajouté à Python (ce qui n'est jamais
une bonne chose, cf. ADA).
J'ai donc une tendance naturelle à produire une "programmation sûre" en
Ruby (car je me retrouve totalement dans le paradigme objet) alors que
j'ai plus de difficulté en Python. C'est probablement ce qui me fait
dire qu'il est moins permissif, mais c'est peut-être seulement du à la
façon dont je l'utilise.
La philosophie de Ruby me semble assez proche de SmallTalk (que j'ai
pratiqué aussi) et je retrouve également un petit côté Eiffel (que je
connais bien également).
Bref, quand je considère Ruby, je me retrouve en terrain connu, plus
qu'avec Python.
Ca vaut ce que ça vaut mais j'ai trouvé ceci :
http://www.dmh2000.com/cjpr/index.shtml
>>>> (bien que ce
>>>> soit certainement volontaire de la part des auteurs).
>>>
>>> Le fait de considérer les programmeurs comme des adultes responsables
>>> et de leur laisser la main sur une majorité de points est
>>> effectivement un choix raisonné. Dans la pratique, il est surprenant
>>> de voir à quel point les développeurs Python tendent à être
>>> raisonnable dans leur utilisation des fonctionnalités "avancées" du
>>> langage - là où la "culture" Ruby semble plutôt être d'encourager
>>> l'usage des fonctionnalités similaires de Ruby (pas une critique,
>>> juste une observation à caractère sociologique). Au point d'ailleurs
>>> que pas mal d'utilisateurs de Ruby que j'ai croisé ignorent totalement
>>> l'existence des fonctionnalités avancées de Python, pourtant
>>> documentées.
>>
>> Je suis d'accord qu'en général, les programmeurs essaient de faire "du
>> mieux possibles"
>
> Tu détournes mon propos, là. Je ne parlais pas de bonne volonté, mais de
> modération et d'auto-discipline, ce qui est totalement différent.
Pour moi, "faire du mieux possible", ce n'est pas, ou pas seulement, de
la bonne volonté mais ça inclut forcément de la modération (par rapport
aux instincts de "codeur fou" ou d'ego surdimensionné) et de
l'auto-discipline.
>
>> mais, ce faisant, ils commettent souvent des erreurs presque
>> irréparables car le mieux est souvent l'ennemi du bien.
>
> Ca j'ai déjà pu m'en rendre compte, merci - il est d'ailleurs courant,
> en Python, que je commence par implémenter mon affaire en tirant au
> maximum partie de l'expressivité du langage, puis que je revienne en
> arrière pour avoir un code un poil plus "lourd" mais nettement plus
> compréhensible au "commun des mortels" (dont je ferai partie quand je
> reviendrai sur le code quelques mois plus tard...). Et c'est bien là une
> spécificité de la "culture" de la communauté Python en général : il vaut
> mieux faire lisible (donc maintenable) que de vouloir être trop
> intelligent pour son propre bien.
>
> Le fait est que la vraie simplicité - le niveau d'abstraction précis qui
> permet de résoudre une classe de problèmes données d'une façon à la fois
> efficace et compréhensible - est quelque chose de très dur à atteindre.
>
C'est pour cette raison que je privilégie des langages qui aident dans
cette tâche et, désolé, Python ne fait pas partie de ceux-là puisqu'il
ne permet pas de coder "spontanément" de façon efficace et lisible.
Sincèrement je ne crois pas.
Voir
pauillac.inria.fr/~xleroy/talks/compilation_typage_College_de_France.pdf
(slide 43)
Et d'autres choses intéressantes
http://web.cs.mun.ca/~ulf/pld/s/archi.html
http://www.xoltar.org/old_site/misc/static_typing_eckel.html
http://gnuvince.wordpress.com/2008/02/15/static-typing-%E2%88%A7-dynamic-typing/
> <troll>
> N'y aurait-il pas quelque chose d'un peu idéologique dans ta déclaration
> ?-)
>
> (oui, ne le dis pas : pareil pour moi...)
> </troll>
>
Ce n'est pas de l'idéologie dans les domaines dans lesquels j'interviens.
Par contre, dans l'absolu, oui (mais maintenant tout le monde le sais...)
>> Sais-tu que dans un logiciel pour missile, il est interdit de faire
>> des opérations sur la pile d'exécution (donc il n'y a même pas de
>> variables locales dans les fonctions...),
>
> Uniquement des globales ???
Hélas oui : obligé
>
> Bon, je suppose que ça se tient par ailleurs - au moins ça évite les
> débordements de pile ou autre c... similaires.
>
Et tu vois que, dans des bazars comme ça, tu ne peux pas interrompre le
programme pour une erreur de type à l'exécution !!!
Non, on ne peut pas dire ça. Le raccourci est rempli d'obstacles ;-)
>
> Ceci étant, on parle de typage statique et dynamique en faisant comme si
> la notion même de "type" était la même dans les deux cas, ce que n'est
> peut-être pas vraiment le cas. Du point du vue du typage statique, dans
> des langages comme Python ou Ruby, il n'existe en fait qu'un seul type,
> le type 'objet' - pas de types "primitifs", "scalaires" etc...
> Accessoirement, un des points que je déteste le plus dans Java est cette
> contradiction à se prétendre 100% objet tout en ayant des types
> primitifs - donc des types qui ne sont *pas* des objets.
>
Je suis tout à fait d'accord. Ca c'est raté dans Java (ils ont trop pris
sur C++ qui est pareil...
Microsoft n'a pas fait cette erreur dans C#.
>> Maintenant, tout dépend du nombre de type dans tes applications.
>> La dernière appli que j'ai auditée était en Java et il y avait plus de
>> 9 000 classes et plus de 26 000 méthodes !
>
> Ce genre de métrique me fait un peu sourire. Pas qu'elle n'ait
> absolument aucun sens, mais il est évident pour qui en a l'expérience
> que la même appli en Python ou en Ruby nécessiterait au moins moitié
> moins de code, *entre autres* en raison du typage dynamique.
>
Je te garantis que l'appli en question n'aurait pas pu utiliser le
typage dynamique (avionique militaire)
>>> D'un autre côté, je n'ai jamais eu à codé quoi que ce soit qui mette
>>> en cause la sécurité des personnes, et je refuserais d'ailleurs de le
>>> faire, ne m'estimant pas assez compétant. Mais bon, c'est aussi le cas
>>> de la grande majorité des programmeurs.
>>
>> Le problème c'est qu'on manque de développeurs suffisamment compétents
>> pour ce genre d'applications...
>
> Je n'en doutes pas.
>
D'ailleurs d'autres se posent la question (et pas seulement pour les
applis complexes) : http://news.bbc.co.uk/2/hi/technology/7324556.stm
>> Et que, donc, il faut coder dans des langages qui ne permettent pas
>> n'importe quoi parce que ce n'est pas une question de programmeur
>> adulte responsable, c'est une question, cruciale, de formation et de
>> compétence justement.
>
> L'un n'exclus pas l'autre, et pas seulement au niveau du développeur. Et
> il est bien évident que si je devais bosser dans ce domaine, j'aurais
> tendance à être un control freak totalement paranoïaque.
>
Et bien ça, il ne le faut pas non plus sinon on court aux catastrophes...
>
> (snip)
>
>>>>> Je me posais plutôt la question dans l'autre sens : comment enseigner
>>>>> l'algo indépendamment de certaines spécificités d'un langage (ou d'une
>>>>> famille de langages).
>>>> Il y avait un très bon bouquin décrivant un langage de pseudo-code,
>>>> fait
>>>> par des gens d'IBM (dont Mills, je crois, mais il y avait d'autres
>>>> auteurs) pour l'enseignement en interne. Ce bouquin (datant de 79)
>>>> s'appelait "Structured Programming". A une époque, j'utilisais ce
>>>> pseudo-code pour des cours d'algo (en entreprise, pas en faculté).
>>>
>>> Je parles bien sûr sans savoir, mais j'ai tendance à penser que ce
>>> pseudo-langage doit être plus proche de Pascal que de Lisp ou
>>> Haskell ?
>>
>> Bien sûr.
>
> Et il te semble pas que ça influe quelque peu la façon dont l'algo est
> enseignée ?
>
Non pas du tout.
Par exemple, j'ai coder un optimiseur sur un langage intermédiaire en
sortie de la phase d'analyse sémantique d'un compilo.
Ce ne sont que des transformations d'arbres, sans arrêt avec du
pattern-matching. Je devais coder dans un langage procédural de type
Pascal - PL/1. Et bien, chacune de mes transformations, pour
l'optimisation, utilisait les fonctions habituelles sur les arbres
n-aires, mais dans un style fonctionnel du type :
f(f1(arbre1, arbre2), f2 (f3 (arbre1), arbre2)) (c'est juste un
exemple). La fonction f retournant un arbre.
Mais les fonctions fi étaient toutes celles qu'on décrit dans les cours
d'algo.
Lier trop fortement l'apprentissage d'un langage de programmation et
l'algo est une erreur.
[snip]
Wykaaa
> Bruno Desthuilliers <bruno.42.de...@websiteburo.invalid> wrote:
>> Wykaaa a écrit :
[snip]
>>>> Je parles bien sûr sans savoir, mais j'ai tendance à penser que ce
>>>> pseudo-langage doit être plus proche de Pascal que de Lisp ou
>>>> Haskell ?
>>> Bien sûr.
>> Et il te semble pas que ça influe quelque peu la façon dont l'algo est
>> enseignée ?
>
> C'est compliqué...
> C'est un thread à lui tout seul.
>
> Marc Boyer
Je suis de l'avis de Bruno Desthuilliers. Ouvrons un thread sur le sujet
(enseignement de l'algo) sur fr.comp.algorithmes, il n'y a quasiment
personne...
Thierry B.
> Seulement si on colle une virgule à la place du point, voire si on
> rajoute un label pour avoir des boucles comme dieu les a créées :
>
> DO 10 I=1,10
> ....
> 10 CONTINUE
>
Mmmm, tout ça me rappelle que je devrais me remettre à la rédaction
de mon cours sur le F77, afin de préparer les devoirs de vacances
des pitchounes...
Ah mince, on est plus vendredi :( Hop, foutou.
--
+------------------------------------------------------------+
| Donc nunux pas au point pour le bios des carte mère PC ... |
+---------------------------------+ Ptilou, expert en pécé |
+--------------------------+
Thierry B.
>> En fait, vu les contraintes du monde moderne, il y a deux catégories
>> de développeurs: ceux qui doivent faire des bons trucs et ce qui
>> doivent faire des trucs déja vendus.
>
> Les deux sont-ils nécessairement exclusifs ?
Dans certains domaines, oui, ça en arrive à être exclusif.
>> Pour avoir l'expérience des "débutants", il suffit d'avoir deux
>> gosses qui viennent passer les week-ends chez Papa, qui a plein
>> de machines étranges chez lui :)
>
> Je n'en ai qu'un, mais à plein temps. Ca compte ?-)
Pourquoi pas ?
> Ceci étant, je ne suis pas sûr que ce soit vraiment comparable.
Non, certainement pas. Mais si tu veux que le(s) éleve(s) soient
heureux d'avoir appris quelque chose, sachent le mettre en oeuvre,
et aient, par la suite, l'envie de progresser d'eux-même, je crois
que les méthodes sont en gros les mêmes.
>> C'est justement pour ça que j'aime bien Python: il est très facile
>> de goretiser plein de choses, mais le "cadrage" du langage oblige
>> à une véritable auto-discipline. Si tu n'est pas vraiment discipliné,
>> ben la goretisation, elle ne marche tout simplement pas.
>
> Mmm... AMHA, c'est surtout une "culture" qui prévaut dans la communauté
> Python, qui attire des développeurs relativement "responsables", ce qui
> renforce cette culture etc...
Si il y a cette culture, c'est d'abord parce qu'elle a été "builtin"
le langage lui-même, qu'elle est assez facile à communiquer, et
qu'elle fonctionne. Et il me semble que cette culture peut ensuite
se transposer vers d'autres langages, d'autres méthodes de
conception. En tout cas, la découverte de Python m'a emmené à
voir et faire de façon différente des trucs en C, par exemple.
> Bon, là (embarqué etc...), on est complètement en dehors de mon domaine
> de toutes façons. A mon grand regret, d'ailleurs - j'aimerais bien
> trouver le temps de m'intéresser aussi à ces aspects, mais voilà, y a
> que 24h dans une journée.
Moi aussi, j'aimerais bien m'interesser aux petits systèmes, et
aux truc embarqués, mais pour le moment, c'est plutôt un problème
financier :( car les petites cartes de dev pour microcontroleur
ne sont pas données, et les composants à mettre autour si tu veux
fabriquer un truc sympa non plus.
--
> parce que maintenant linux tue tous les processus pour libérer de la
> mémoire, DONC pas de soucis hein ?
bah, il suffit d'augmenter la mémoire disponible avec
dd if=/dev/zero bs=1024 count=$((1024 * 512)) >> /dev/kcore
Thierry B.
> Petite anectode: cours de Pascal, premier semestre d'école d'ingé
> "mais pourquoi on apprend à programmer finalement ? C'est pas un boulot
> d'ingenieur, c'est un boulot de technicien sous payé."
Tu sais, c'est pas nouveau, ça. Il y a plus de vingt ans, j'ai
travaillé dans un labo de dev qui recevait pas mal de stagiaires
"grandes écoles". On en a eu un qui venait de Sup Télécom (si je
me souviens bien) et qui _refusait_ de toucher à un fer à souder
ou une wrappeuse. Le pauvre, ses manips prenaient trois fois plus
de temps que l'autre stagiaire (un X) qui n'hésitait pas à mettre
les mains dans le cambouis et fabriquait son null-modem en moins
de deux minutes :)
Je te laisse deviner lequel a le mieux réussi son stage chez nous !
> Après, oui, recoder un parseur XML depuis 0 en C...
/me est pétrifié de trouille !
>> Je leur trouverais en commun d'avoir à accéder à des bases de données et
>> à faire des traitements pour extraire ce dont ils ont besoin... des cours
>> de SQL?
>
> D'Excel, ce serait suffisant ;-)
Mais terriblement dangeureux, non ? J'ai lu dans le temps (et je
n'arrive pas à le retrouver) un article fameux qui avait estimé
à plus de 20% le taux de feuilles/macros Excel bugguées utilisées
en entreprise, avec de beaux exemples...
Ce qui laisse assez songeur, quand on sait qu'une bonne partie de
la vie de tous les jours est gérée par ce genre de trucs.
--
+------\
+----------> http://la.buvette.org/POV/stereo-2.html
+------/
Marc Boyer
> Marc Boyer a écrit :
>> La plupart des règles de codage viennent à essayer de permettre
>> le passage à l'échelle (cf autre longue discussion sur fclc et les
>> variables globales).
>
> Pas vu - je ne suis plus fclc que sporadiquement.
Ce fut un peu long en plus.
>>>> Non, désolé, le but premier du typage statique n'est pas que le ompilo
>>>> puisse mieux optimiser (c'est juste un effet de bord du typage
>>>> statique). Le but premier, c'est la fiabilité.
>>> Je ne suis pas historien et n'ait pas 50 ans d'expérience dans le
>>> domaine (juste une dizaine), donc je peux bien sûr me tromper (auquel
>>> cas merci de me pointer vers les chapitres et versets appropriés !-),
>>> mais il me semble que tu inverses les causes et effets au regard de la
>>> réalité historique.
>>
>> Ca dépend du point de vue...
>> Je pense que le typage "à la C" (int/float/char*) vient d'un
>> mappin efficace sur le processeur, contrairement à Lisp, où
>> l'interpréteur doit dynamiquement regarder ce qu'il manipule.
>>
>> Mais ensuite, les ajouts de typage, à la Ada, C++, veulent
>> eux fiabiliser en évitant d'ajouter des pommes et des poires
>> (à moins de déclarer explicitement l'opérateur de compote).
>
> C'était déjà le cas en Pascal, non ?
C'était semble-t-il l'intention. Mais on pouvait tout
à fait ajouter des pommes et des oranges.
http://www.cs.virginia.edu/~evans/cs655-S00/readings/bwk-on-pascal.html
type
apple = integer;
orange = integer;
then any arbitrary arithmetic expression involving apples and oranges is
perfectly legal.
>> Quant aux débutants... Ils confondent (je prends la syntaxe C)
>> 0, 0.0, "0", '0' et '\0'. Alors, si tu ne leur impose pas
>> de dire quel est le type de valeur qu'ils manipulent (lors de
>> la déclaration de variable), ben, c'est la panique.
>
> Heu... J'ai commencé à bricoler mes premiers bouts de code en 1990 avec
> HyperCard / HyperTalk (typage dynamique, et pas spécialement fort). Sans
> internet, et sans personne pour me mentorer. Et j'ai très vite appris à
> faire la différence entre une chaine et un nombre (ne serait-ce qu'en
> voyant le résultat des calculs...).
La question du "très vite" est toute relative, dépendante de la
personne, et de sa motivation.
> Bon, le langage suivant (si on omet un peu d'assembleur 68k) était un
> basic objet à typage statique déclaratif, et je reconnais que dans un
> premier temps, j'ai de moi-même considéré ça comme une aide et un
> progrès par rapport à HyperTalk - peut-être simplement parce que ça
> m'obligeait à structurer un peu plus ma réflexion vu que dans la
> pratique je n'avais en fait guère de pb de typage, ayant déjà appris à
> être attentif à ces aspects.
Ce qui va dans ce sens.
>> J'ai fait d'ailleurs un TP édifiant sur le sujet il y a 3 jours:
>> on leur demande d'extraire une sous image d'une image PGM, dont le
>> format est
>> P5
>> largeur hauteur
>> profondeur
>> bitmap
>>
>> Ben, le passage du stockage de valeurs 'humaines' à binaire
>> les rend extrèmement perplexe. Quand en projet je leur fait
>> envoyer des entier 32bits en grand boutiste, j'en ai qui
>> envoyent "0012" au lieu de 12...
>>
>> Que le programmeur expérimenté puisse laisser le type comme
>> information implicite, pourquoi pas. Mais pas le débutant.
>
> Tu a certainement plus d'expérience que moi dans ce domaine. D'un autre
> côté, j'ai appris autrement, et je ne sais pas si j'aurais appris quoi
> que ce soit s'il m'avait fallu me coltiner des déclarations de types et
> autres boilerplate dès le début - j'aurais probablement laissé tombé en
> me disant que c'était trop compliqué et trop chiant.
Toujours le problème de la "courbe d'apprentissage". Quand un
grand débutant à le choix entre le navigateur de fichiers gnome
et un shell, il choisit le clickodrome.
Dans le cadre d'une formation, on peut le contraindre à passer
par la partie pénible jusqu'au moment où l'investissement paye.
> Le fait d'avoir pu
> réaliser dès les premiers jours avoir des petits programmes
> *fonctionnels* est certainement pour beaucoup dans ma "vocation". Et une
> fois motivé, je n'ai pas eu de problème majeur à passer à des technos
> bien plus contraignantes.
Et oui... Si les étudiants choisissaient un cursus conforme à
leurs envies, l'enseignement supérieur serait plus simple.
>>> Ceci étant, on parle de typage statique et dynamique en faisant comme si
>>> la notion même de "type" était la même dans les deux cas, ce que n'est
>>> peut-être pas vraiment le cas. Du point du vue du typage statique, dans
>>> des langages comme Python ou Ruby, il n'existe en fait qu'un seul type,
>>> le type 'objet' - pas de types "primitifs", "scalaires" etc...
>>
>> Heuh... Faut quand même pas confondre les concepts et leur
>> implantation. Je suis 0 en python, mais je lis sur Wikipédia:
>> points = 3.2 # points est du type float
>> print "Tu as " + points + " points !" # Génère une erreur de typage
>>
>> Que la notion de type (flottant, chaine) soit englobée dans un attribut
>> dynamique en python, ok, mais la notion reste là, non ?
>
> La notion de "type" est là, oui, je ne dis pas le contraire. Mais
> pointe-t-elle sur le même concept ?
Ben, une variable transporte une donnée, qui est un couple
(valeur,type), un type étant l'ensemble des opérations permises
sur le type.
> En C, un "type" est une information précisant un offset à partir de
> l'adresse mémoire de la variable, et la façon dont doivent être
> interprétés les bits contenus entre cette adresse et l'offset.
Oui et non.
> En Python, un "type" (en tous cas ce que renvoie la fonction type()...)
> est une référence sur un autre objet (la classe), lequel contient
> d'autres références sur d'autres objets - les superclasses, la
> metaclasse, et les attributs de classe, lesquels comprennent les
> méthodes (je m'arrête là le but n'étant pas de détailler le modèle objet
> de Python).
Donc, de manière dynamique et complexe, tout celà dit comment
interpréter les bits contenus dans la variable.
Python fait des choses biens plus riches que le C, personne n'en
doute.
Marc Boyer
Non, pas la peine.
En fait, après quelques années entre nos mains, il a compris
la place de la programmation dans le développement de systèmes
automatiques (au sens large), et y a même peut être pris du
plaisir.
Mais il nous a fallu un peu de temps...
Marc Boyer
> --{ Marc Boyer a plopé ceci: }--
>
>> Petite anectode: cours de Pascal, premier semestre d'école d'ingé
>> "mais pourquoi on apprend à programmer finalement ? C'est pas un boulot
>> d'ingenieur, c'est un boulot de technicien sous payé."
>
> Tu sais, c'est pas nouveau, ça. Il y a plus de vingt ans, j'ai
> travaillé dans un labo de dev qui recevait pas mal de stagiaires
> "grandes écoles". On en a eu un qui venait de Sup Télécom (si je
> me souviens bien) et qui _refusait_ de toucher à un fer à souder
> ou une wrappeuse. Le pauvre, ses manips prenaient trois fois plus
> de temps que l'autre stagiaire (un X) qui n'hésitait pas à mettre
> les mains dans le cambouis et fabriquait son null-modem en moins
> de deux minutes :)
Ceci dit, le monde a changé en 20 ans.
De même qu'il fut un temps ou le "cadre" passait des notes manuscrites
à sa secrétaire, peut-être existait-il une époque ou la programmation
était réservée à une caste spécifique.
Actuellement, tous les cadres que je connais, et qui sont encore
dans la technique, programment.
>>> Je leur trouverais en commun d'avoir à accéder à des bases de données et
>>> à faire des traitements pour extraire ce dont ils ont besoin... des cours
>>> de SQL?
>>
>> D'Excel, ce serait suffisant ;-)
>
> Mais terriblement dangeureux, non ? J'ai lu dans le temps (et je
> n'arrive pas à le retrouver) un article fameux qui avait estimé
> à plus de 20% le taux de feuilles/macros Excel bugguées utilisées
> en entreprise, avec de beaux exemples...
Possible.
> Ce qui laisse assez songeur, quand on sait qu'une bonne partie de
> la vie de tous les jours est gérée par ce genre de trucs.
Tu sais, récemment, quelqu'un qui devait facturer des trucs horaires
ne comprennait pas pourquoi 2/3 de 2h donnait 1h20 et non 1h33. La
feuille Excel ne faisait que trahir ce qu'il ne savait pas faire
à la main.
bruno desthuilliers
wrote:
> On 2008-04-04, Bruno Desthuilliers wrote:
>
> > Marc Boyer a écrit :
(à propos de raisons premières du typage statique - optimisation ou
correction)
> >> Ca dépend du point de vue...
> >> Je pense que le typage "à la C" (int/float/char*) vient d'un
> >> mappin efficace sur le processeur, contrairement à Lisp, où
> >> l'interpréteur doit dynamiquement regarder ce qu'il manipule.
>
> >> Mais ensuite, les ajouts de typage, à la Ada, C++, veulent
> >> eux fiabiliser en évitant d'ajouter des pommes et des poires
> >> (à moins de déclarer explicitement l'opérateur de compote).
>
> > C'était déjà le cas en Pascal, non ?
>
> C'était semble-t-il l'intention. Mais on pouvait tout
> à fait ajouter des pommes et des oranges.
>
> http://www.cs.virginia.edu/~evans/cs655-S00/readings/bwk-on-pascal.html
> type
> apple = integer;
> orange = integer;
>
> then any arbitrary arithmetic expression involving apples and oranges is
> perfectly legal.
Tiens, il me semblait me souvenir que justement Pascal différait du C
sur ce point en faisant des typedef de vraies définitions de type et
non de simples alias ? IIRC aussi, en Pascal, un tableau de 10 entiers
n'est pas du même type qu'un tableau de 11 entiers... Mais bon, ça
dépend peut-être aussi des implémentations. Et puis mes souvenirs de
Pascal sont un peu floues (pas touché depuis 2000, sauf quelques
bricoles sur un utilitaire en Delphi l'année dernière).
> >> Quant aux débutants... Ils confondent (je prends la syntaxe C)
> >> 0, 0.0, "0", '0' et '\0'. Alors, si tu ne leur impose pas
> >> de dire quel est le type de valeur qu'ils manipulent (lors de
> >> la déclaration de variable), ben, c'est la panique.
>
> > Heu... J'ai commencé à bricoler mes premiers bouts de code en 1990 avec
> > HyperCard / HyperTalk (typage dynamique, et pas spécialement fort). Sans
> > internet, et sans personne pour me mentorer. Et j'ai très vite appris à
> > faire la différence entre une chaine et un nombre (ne serait-ce qu'en
> > voyant le résultat des calculs...).
>
> La question du "très vite" est toute relative, dépendante de la
> personne, et de sa motivation.
"très vite" = une après-midi à m'arracher les cheveux, sachant que
j'avais commencé la lecture du manuel hypertalk au début de la même
semaine et n'avait à ce moment *strictement aucune* connaissance /
expérience / whatever en programmation (et très peu d'expérience de
l'informatique tout court).
Quant à ma motivation, je dois être un peu cabochard, mais on peut la
résumer à : "c'est quand même pas cette putain de calculette géante
qui va avoir le dernier mot avec moi, putain de bordel de merdre !"
> > Bon, le langage suivant (si on omet un peu d'assembleur 68k) était un
> > basic objet à typage statique déclaratif, et je reconnais que dans un
> > premier temps, j'ai de moi-même considéré ça comme une aide et un
> > progrès par rapport à HyperTalk - peut-être simplement parce que ça
> > m'obligeait à structurer un peu plus ma réflexion vu que dans la
> > pratique je n'avais en fait guère de pb de typage, ayant déjà appris à
> > être attentif à ces aspects.
>
> Ce qui va dans ce sens.
Oui et non. On croise sur (f)cl.py pas mal de débutants complets, et
il ne semble pas que le typage dynamique les empêche de comprendre la
différence entre une chaine, un entier, un pseudo-réel, une liste ou
un dictionnaire (pour ne citer que les types 'de base' les plus
utilisés).
(snip)
> >> Que le programmeur expérimenté puisse laisser le type comme
> >> information implicite, pourquoi pas. Mais pas le débutant.
>
> > Tu a certainement plus d'expérience que moi dans ce domaine. D'un autre
> > côté, j'ai appris autrement, et je ne sais pas si j'aurais appris quoi
> > que ce soit s'il m'avait fallu me coltiner des déclarations de types et
> > autres boilerplate dès le début - j'aurais probablement laissé tombé en
> > me disant que c'était trop compliqué et trop chiant.
>
> Toujours le problème de la "courbe d'apprentissage". Quand un
> grand débutant à le choix entre le navigateur de fichiers gnome
> et un shell, il choisit le clickodrome.
Bien sûr. C'est plus facile à "découvrir". C'est bien l'avantage de ce
type d'interface par rapport aux lignes de commande.
> Dans le cadre d'une formation, on peut le contraindre à passer
> par la partie pénible jusqu'au moment où l'investissement paye.
La contrainte est-elle à ce point nécessaire ?
Nos graphistes viennent de passer de Windows à MacOS X. Et malgré les
qualités du clickodrome en question, ils sont en train, petit à petit,
de se mettre aux lignes de commande. Non par contrainte, mais d'une
part parce qu'ils nous voient utiliser l'outil, et voient donc en quoi
il peut être dans certains cas plus puissant qu'un clickodrome, et
d'autre part parce que cela leur permet aussi d'être autonomes sur les
serveurs linux quand ils ont besoin d'y accéder.
> > Le fait d'avoir pu
> > réaliser dès les premiers jours avoir des petits programmes
> > *fonctionnels* est certainement pour beaucoup dans ma "vocation". Et une
> > fois motivé, je n'ai pas eu de problème majeur à passer à des technos
> > bien plus contraignantes.
>
> Et oui... Si les étudiants choisissaient un cursus conforme à
> leurs envies, l'enseignement supérieur serait plus simple.
Je ne sais pas dans quelle mesure "envie" est le terme qui convient.
Je pense que c'est, plus généralement, lié au fait d'avoir réellement
*choisi* le cursus - quant aux raisons du choix, c'est autre chose.
Mais bon, ce qui est sûr, c'est que quelqu'un qui ne sait même pas
pourquoi il est là ne fait pas forcément le meilleur apprenant. Dans
cette perspective, la question n'est pas tant de savoir s'il vaut
mieux enseigner la programmation avec tel ou tel système de typage,
mais si ça vaut le coup d'enseigner quoi que ce soit à quelqu'un qui
fondamentalement s'en contrefiche.
>
> >>> Ceci étant, on parle de typage statique et dynamique en faisant comme si
> >>> la notion même de "type" était la même dans les deux cas, ce que n'est
> >>> peut-être pas vraiment le cas. Du point du vue du typage statique, dans
> >>> des langages comme Python ou Ruby, il n'existe en fait qu'un seul type,
> >>> le type 'objet' - pas de types "primitifs", "scalaires" etc...
>
> >> Heuh... Faut quand même pas confondre les concepts et leur
> >> implantation. Je suis 0 en python, mais je lis sur Wikipédia:
> >> points = 3.2 # points est du type float
> >> print "Tu as " + points + " points !" # Génère une erreur de typage
>
> >> Que la notion de type (flottant, chaine) soit englobée dans un attribut
> >> dynamique en python, ok, mais la notion reste là, non ?
>
> > La notion de "type" est là, oui, je ne dis pas le contraire. Mais
> > pointe-t-elle sur le même concept ?
>
> Ben, une variable transporte une donnée,
Pas dans des langages comme Python ou Ruby etc, où une "variable" ne
"transporte" rien, puisque c'est juste un nom permettant d'accéder à
un objet dont le cycle de vie est indépendant du périmètre de
visibilité du nom en question.
> qui est un couple
> (valeur,type), un type étant l'ensemble des opérations permises
> sur le type.
>
> > En C, un "type" est une information précisant un offset à partir de
> > l'adresse mémoire de la variable, et la façon dont doivent être
> > interprétés les bits contenus entre cette adresse et l'offset.
>
> Oui et non.
En schématisant, bien sûr !-)
> > En Python, un "type" (en tous cas ce que renvoie la fonction type()...)
> > est une référence sur un autre objet (la classe), lequel contient
> > d'autres références sur d'autres objets - les superclasses, la
> > metaclasse, et les attributs de classe, lesquels comprennent les
> > méthodes (je m'arrête là le but n'étant pas de détailler le modèle objet
> > de Python).
>
> Donc, de manière dynamique et complexe, tout celà dit comment
> interpréter les bits contenus dans la variable.
Non. Encore une fois, la notion de "variable" n'a ici rien à voir avec
celle de "contenant" - contrairement à ce qui se passe en C. A moins -
ce dont je doute - que tu ne considères que, dans un programme en C,
une clé dans une table de hachage "contienne" la valeur qui lui est
associée ? Ou, pour prendre l'exemple des pointeurs, un pointeur
"contient" une adresse mémoire, mais pas ce qui est contenu à cette
adresse mémoire.
Bon, j'admets que ma vision des chose est peut-être un peu teintée par
la connaissance de l'implémentation, mais même si on fait abstraction
de ces aspects, une 'variable' Python persiste à ne rien "contenir" -
réassigner un autre objet à cette variable n'effacera pas pour autant
l'objet qui lui était précédement associé (du moins pas
systématiquement, et pas directement). Alors qu'en C, en assignant
une nouvelle valeur à une variable, j'écrase la valeur précédemment
contenue.
> Python fait des choses biens plus riches que le C, personne n'en
> doute.
Là n'était pas le propos. J'essaie juste d'illustrer, malgré mes
lacunes en théorie informatique, en quoi il me semble que même s'il
existe dans les deux systèmes une notion de type, je ne suis pas sûr
qu'il s'agisse vraiment du même concept. Mais bon, étant incapable
d'exprimer ça plus clairement, je vais m'en tenir là pour le
moment :-/
Wykaaa
> On 7 avr, 10:10, Marc Boyer <Marc.Bo...@enseeiht.yahoo.fr.invalid>
> wrote:
>> On 2008-04-04, Bruno Desthuilliers wrote:
>>
>>> Marc Boyer a écrit :
bref il se sont échangé pleins de points de vue
>
et finalement, Marc Boyer à dit :
>> Python fait des choses biens plus riches que le C, personne n'en
>> doute.
Et Bruno Desthuilliers a répondu
>
> Là n'était pas le propos. J'essaie juste d'illustrer, malgré mes
> lacunes en théorie informatique, en quoi il me semble que même s'il
> existe dans les deux systèmes une notion de type, je ne suis pas sûr
> qu'il s'agisse vraiment du même concept. Mais bon, étant incapable
> d'exprimer ça plus clairement, je vais m'en tenir là pour le
> moment :-/
>
je ne dis pas que tout sera lumineux, mais visitez (je m'adresse à vous
deux) cette page : http://ralyx.inria.fr/2002/Raweb/cristal/uid6.html
C'est très orienté Caml, OCaml (ce qui devrait plaire à Bruno...)
Wykaaa
bruno desthuilliers
(snip)
> je ne dis pas que tout sera lumineux, mais visitez (je m'adresse à vous
> deux) cette page :http://ralyx.inria.fr/2002/Raweb/cristal/uid6.html
Heu... Si tu veux, je ne t'ai pas attendu pour lire ça. Ca fait
quelques année déjà que je connais cette resource.
En même temps, le problème (pour moi, mais donc probablement pour
d'autres aussi, je ne dois pas être le seul autodidacte pas
complètement obtus sur cette planète), c'est que certains aspects -
principalement ceux qu'il m'intéresseraient le plus de bien capter -
restent difficiles d'accès pour quelqu'un qui n'a pas le bagage
universitaire minimum prérequis (pour info, j'ai quitté l'école à 16
ans, alors même si mes quelques neurones survivants sont pleins de
bonne volonté, à 41 ans - oui, je sais, je suis resté très gamin
pour mon age - et avec un boulot à plus que plein temps, une femme et
un gosse, c'est pas facile de rattraper le retard).
> C'est très orienté Caml, OCaml (ce qui devrait plaire à Bruno...)
Bin... Comment dire.... Sur le papier, OCaml me plait beaucoup.
Vraiment. Dans la pratique, par contre, sa syntaxe me répugne pas mal
(putain, ces *doubles* points-virgules, quel est le crétin qui a été
inventer cette horreur). Ca fait 4 ans que je me promet de m'y mettre
sérieusement, mais sans jamais réussir à franchir le pas. C'est con
parce que le langage est manifestement plus qu'intéressant... Dans les
cousins, y a aussi Haskell, auquel je m'étais intéressé pour voir à
quoi pouvait ressembler un langage fonctionnel 'pur', mais là non
plus, je n'ai pas été au delà d'une "découverte" du langage. Un jour
peut-être...
Wykaaa
> On 7 avr, 21:12, Wykaaa <wyk...@yahoo.fr> wrote:
> (snip)
>> je ne dis pas que tout sera lumineux, mais visitez (je m'adresse à vous
>> deux) cette page :http://ralyx.inria.fr/2002/Raweb/cristal/uid6.html
>
> Heu... Si tu veux, je ne t'ai pas attendu pour lire ça. Ca fait
> quelques année déjà que je connais cette resource.
>
> En même temps, le problème (pour moi, mais donc probablement pour
> d'autres aussi, je ne dois pas être le seul autodidacte pas
> complètement obtus sur cette planète), c'est que certains aspects -
> principalement ceux qu'il m'intéresseraient le plus de bien capter -
> restent difficiles d'accès pour quelqu'un qui n'a pas le bagage
> universitaire minimum prérequis (pour info, j'ai quitté l'école à 16
> ans, alors même si mes quelques neurones survivants sont pleins de
> bonne volonté, à 41 ans - oui, je sais, je suis resté très gamin
> pour mon age - et avec un boulot à plus que plein temps, une femme et
> un gosse, c'est pas facile de rattraper le retard).
>
Je sais que ce n'est pas d'accès très facile et je te tire mon chapeau
pour le niveau auquel tu es arrivé "tout seul".
Moi, je vais sur 60 ans... mais je n'ai pas appris tout seul et, à la
base, j'ai une formation en sémantique des langage de programmation
(sémantique dénotationnelle (à une époque, Joseph E. Stoy, Denotational
Semantics: The Scott-Strachey Approach to Programming Language
Semantics, MIT Press, Cambridge, Massachusetts, 1977 était mon livre de
chevet...), sémantique opérationnelle, sémantique axiomatique
principalement.
>> C'est très orienté Caml, OCaml (ce qui devrait plaire à Bruno...)
>
> Bin... Comment dire.... Sur le papier, OCaml me plait beaucoup.
> Vraiment. Dans la pratique, par contre, sa syntaxe me répugne pas mal
> (putain, ces *doubles* points-virgules, quel est le crétin qui a été
> inventer cette horreur). Ca fait 4 ans que je me promet de m'y mettre
> sérieusement, mais sans jamais réussir à franchir le pas. C'est con
> parce que le langage est manifestement plus qu'intéressant... Dans les
> cousins, y a aussi Haskell, auquel je m'étais intéressé pour voir à
> quoi pouvait ressembler un langage fonctionnel 'pur', mais là non
> plus, je n'ai pas été au delà d'une "découverte" du langage. Un jour
> peut-être...
Haskell ça vaut vraiment le coup, mais je doute que cela te serve dans
ton boulot. Quand tu vois comment la recherche des nombres premiers
(Crible d'Eratosthènes) se programme dans ce langage, c'est magnifique :
primes = sieve [ 2.. ]
where
sieve (p:x) = p : sieve [ n | n <- x, n `mod` p > 0 ]
En Python :
def eratosthenes(n):
all = []
prime = 1
print 1, 2,
i = 3
while (i <= n):
if i not in all:
print i,
prime += 1
j = i
while (j <= (n / i)):
all.append(i * j)
j += 1
i += 2
print
eratosthenes(50)
En Ruby :
# sieve of Eratosthenes from the ruby distro
top = Integer(ARGV.shift || 100)
sieve = []
for i in 2 .. top
sieve[i] = i
end
for i in 2 .. Math.sqrt(top)
next unless sieve[i]
(i*i).step(top, i) do |j|
sieve[j] = nil
end
end
puts sieve.compact.join " "
Ces exemples sont tirés de : http://www.scriptol.org/crible.php
J'ai programmé (un peu) en Miranda (cf.
http://www.cs.kent.ac.uk/people/staff/dat/miranda/) qui a influencé le
langage Haskell et j'ai suivi des cours de David Turner en 81 (à
l'époque, c'était même l'ancêtre de Miranda qui s'appelait KRC pour Kent
Recursive Calculator). Voir :
http://www.chilton-computing.org.uk/acd/dcs/projects/p009.htm
Et cette page, tu la connais (comparaison de langages dont Python, Ruby,
PHP, C++, Java, etc.) ?
http://www.jvoegele.com/software/langcomp.html
A+
Wykaaa
bruno desthuilliers
> bruno desthuilliers a écrit :
>
> > On 7 avr, 21:12, Wykaaa <wyk...@yahoo.fr> wrote:
> > (snip)
>
> > cousins, y a aussi Haskell, auquel je m'étais intéressé pour voir à
> > quoi pouvait ressembler un langage fonctionnel 'pur', mais là non
> > plus, je n'ai pas été au delà d'une "découverte" du langage. Un jour
> > peut-être...
>
> Haskell ça vaut vraiment le coup, mais je doute que cela te serve dans
> ton boulot.
Directement, pas forcément, mais ça je m'en fiche totalement. Ce qui
compte, c'est en quoi ça étends mes horizons. Et puis bon, avec cette
logique là, je n'aurais pas pris la peine d'apprendre Python, qui est
pourtant une des compétences qui m'a valu mes derniers boulots.
> Quand tu vois comment la recherche des nombres premiers
> (Crible d'Eratosthènes) se programme dans ce langage, c'est magnifique :
>
> primes = sieve [ 2.. ]
> where
> sieve (p:x) = p : sieve [ n | n <- x, n `mod` p > 0 ]
>
> En Python :
>
> def eratosthenes(n):
>
> all = []
> prime = 1
A part être incrémentée dans la boucle, cette variable ne sert à rien.
> print 1, 2,
La version Haskell retourne une valeur, pourquoi ne pas en faire de
même ici ?
> i = 3
> while (i <= n):
> if i not in all:
> print i,
> prime += 1
> j = i
> while (j <= (n / i)):
> all.append(i * j)
> j += 1
> i += 2
> print
Soit c'est antédiluvien, soit celui qui a pondu ça ne connait pas
Python. En tout état de cause, un dev qui me pond ça, c'est poubelle
et interdiction de pondre une ligne de code en plus avant d'avoir
appris le langage.
Voilà une version un poil plus propre, avec évaluation paresseuse, et
qui m'a pris environ 1'30'' à pondre. Je n'ai pas vérifié la
correction de l'algo, mais là je décline toute responsabilité puisque
c'est le même...
def era2(n):
all = []
yield 1
yield 2
for i in xrange(3, n+1, 2):
if i not in all:
yield i
all.extend( i * j for j in xrange(i, (n / i) + 1))
print " ".join(map(str, era2(50)))
1 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47
Si j'ai le temps, je verrais dans quelle mesure on peut le recoder
plus intelligement.
> Ces exemples sont tirés de :http://www.scriptol.org/crible.php
Auquel j'irai jeter un oeil, mais avec un a priori très négatif.
(snip)
> Et cette page, tu la connais (comparaison de langages dont Python, Ruby,
> PHP, C++, Java, etc.) ?http://www.jvoegele.com/software/langcomp.html
Le mec qui a pondu ça ferait mieux d'apprendre de quoi il cause, ça
lui éviterait de se ridiculiser. Ok, allons-y:
"Object-Orientation Hybrid"
Toujours la même légende urbaine comme quoi Ruby serait "pur objet" et
pas Python, hein ? Bon, petit rappel, Python est orienté objet depuis
(au moins) la première release publique (la 0.91 si ma méoire est
bonne) en 1990. En l'état actuel, *tout* ce que tu peux trouver à la
droite d'une assignation est un objet. Les classes sont des objets,
les fonctions sont des objets, les modules sont des objets, même le
putain de byte-code des fonctions est exposé comme un objet. A part -
comme en Smalltalk - implémeter les messages comme des objets et les
structures de contrôle en tant que message, je vois mal comment faire
plus objet.
"Higher Order Functions Lambda Expressions"
Ca veut dire quoi, ça ? L'instruction (très mal nommée) lambda génère
un objet fonction parfaitement ordinaire, ce n'est qu'un sucre
syntaxique pour des petites fonctions qui ne justifient pas une
définition séparée. Pour le reste, une fonction Python est un objet,
donc un citoyen parfaitement ordinaire.
"Garbage Collection Reference Counting"
Ca fait plusieurs années déjà que le comptage de référence est doublé
d'un GC capable de détecter les cycles.
"Uniform Access No"
Si, et depuis toujours. Aux débuts en implémentant la méthode
__getattr__(self, name), et depuis plusieurs années via le protocole
descripteur - le plus souvent en utilisant le type 'property', qui
implémente ce protocole.
"Class Variables / Methods No"
Les variables de classe ont toujours été supportées, les méthodes de
classe le sont depuis longtemps - si mon souvenir est bon depuis la
2.0 ou 2.1, en tous cas une version antérieure à la rédaction de ce
document. A noter également que les classmethods Python, contrairement
aux méthodes "static" de Java, recoivent l'objet classe en premier
argument. Il existe aussi des staticmethods en Python, mais leur
emploi est rarissime puisque Python n'impose pas de tout caser dans
des classes, que ça ait un sens ou non.
"Access Control Name Mangling"
Le name mangling (effectué sur les attributs préfixés d'un double
underscore) n'a pas pour vocation d'interdire l'accès à l'attribut,
mais de protéger un attribut essentiel d'une classe de base d'une
surcharge accidentelle. Le "contrôle d'accès" en Python se fait sur la
base d'une simple convention: un attribut préfixé d'un underscore
relève de l'implémentation, donc si vous y touchez, c'est votre
problème, on vous aura prévenu. Dans la pratique, ça marche
remarquablement bien.
Je note par contre que le garçon ne mentionne nulle part les
métaclasses...
Si tu te bases sur des exemples et comparatifs pareils, pas de
surprise que tu ai une mauvaise image de Python. Franchement, tu
ferais mieux d'apprendre le langage et de te faire ta propre idée par
toi-même.
Wykaaa
> On 8 avr, 01:56, Wykaaa <wyk...@yahoo.fr> wrote:
>> bruno desthuilliers a écrit :
>>
>>> On 7 avr, 21:12, Wykaaa <wyk...@yahoo.fr> wrote:
>>>
>> En Python :
>>
>> def eratosthenes(n):
>>
>> all = []
>> prime = 1
>
> A part être incrémentée dans la boucle, cette variable ne sert à rien.
Je suis d'accord.
>
>> print 1, 2,
>
> La version Haskell retourne une valeur, pourquoi ne pas en faire de
> même ici ?
OK
OK. Ca me plaît déjà mieux.
[snip]
>> Et cette page, tu la connais (comparaison de langages dont Python, Ruby,
>> PHP, C++, Java, etc.) ?http://www.jvoegele.com/software/langcomp.html
>
> Le mec qui a pondu ça ferait mieux d'apprendre de quoi il cause, ça
> lui éviterait de se ridiculiser.
Je n'ai pas dit que cette page était bien. Outre qu'elle n'est pas à
jour par rapport aux versions de langages, il y a de nombreuses
approximation. Néanmoins c'est un effort méritant...
Ok, allons-y:
>
> "Object-Orientation Hybrid"
>
> Toujours la même légende urbaine comme quoi Ruby serait "pur objet" et
> pas Python, hein ? Bon, petit rappel, Python est orienté objet depuis
> (au moins) la première release publique (la 0.91 si ma méoire est
> bonne) en 1990. En l'état actuel, *tout* ce que tu peux trouver à la
> droite d'une assignation est un objet. Les classes sont des objets,
> les fonctions sont des objets, les modules sont des objets, même le
> putain de byte-code des fonctions est exposé comme un objet. A part -
> comme en Smalltalk - implémeter les messages comme des objets et les
> structures de contrôle en tant que message, je vois mal comment faire
> plus objet.
>
Oui mais la plupart des auteurs s'accordent à dire que Python est
hybride car il ne force pas le style objet. En première approche, on
peut même dire que le style est plus fonctionnel qu'objet (pour moi, cet
aspect là, n'est pas un inconvénient)
> "Higher Order Functions Lambda Expressions"
>
> Ca veut dire quoi, ça ? L'instruction (très mal nommée) lambda génère
> un objet fonction parfaitement ordinaire, ce n'est qu'un sucre
> syntaxique pour des petites fonctions qui ne justifient pas une
> définition séparée. Pour le reste, une fonction Python est un objet,
> donc un citoyen parfaitement ordinaire.
Mais ce n'est pas une critique !
C'est très bien que Python supporte les fonctions d'ordre supérieur par
des lambda expressions.
>
> "Garbage Collection Reference Counting"
>
> Ca fait plusieurs années déjà que le comptage de référence est doublé
> d'un GC capable de détecter les cycles.
C'est dit dans le texte. le tableau est un peu réducteur. je cite (j'ai
ajouté la flèche) :
"Reference counting is the simplest scheme and involves the language
keeping track of how many references there are to a particular object in
memory, and deleting that object when that reference count becomes zero.
This scheme, although it is simple and deterministic, is not without its
drawbacks, the most important being its inability to handle cycles.
Cycles occur when two objects reference each other, and thus there
reference counts will never become zero even if neither object is
referenced by any other part of the program.
==> This is the scheme that is utilized by Python and Visual Basic,
although in the case of Python an extra step is taken to ensure that
cycles are handled appropriately."
>
> "Uniform Access No"
>
> Si, et depuis toujours. Aux débuts en implémentant la méthode
> __getattr__(self, name), et depuis plusieurs années via le protocole
> descripteur - le plus souvent en utilisant le type 'property', qui
> implémente ce protocole.
tu veux dire comme ça ?
class Foo(object):
def __init__(self, x):
self.setx(x)
def getx(self):
return self.__x
def getx_times_5(self):
return self.x*5
x = property(getx, doc="getter for x")
x_times_5 = property(getx_times_5, doc="getter for x, times 5")
y = Foo(2)
print y.x
print y.x_times_5
En Ruby :
class Foo
attr_reader :x
def initialize(x)
@x = x
end
def x_times_5
return @x*5
end
end
y = Foo.new(2)
puts y.x
puts y.x_times_5
D'un autre côté, en C++ ou en Java, si l'on veut respecter
l'encapsulation (l'un des concepts majeur de l'objet), on définira tous
les attributs dans la partie privée d'une classe. Il y aura donc accès
uniforme puisqu'un attribut de classe ne pourra jamais être accédé
directement mais seulement par son "setter" et son "getter".
>
> "Class Variables / Methods No"
>
> Les variables de classe ont toujours été supportées, les méthodes de
> classe le sont depuis longtemps - si mon souvenir est bon depuis la
> 2.0 ou 2.1, en tous cas une version antérieure à la rédaction de ce
> document. A noter également que les classmethods Python, contrairement
> aux méthodes "static" de Java, recoivent l'objet classe en premier
> argument. Il existe aussi des staticmethods en Python, mais leur
> emploi est rarissime puisque Python n'impose pas de tout caser dans
> des classes, que ça ait un sens ou non.
Ben voilà...
>
> "Access Control Name Mangling"
>
> Le name mangling (effectué sur les attributs préfixés d'un double
> underscore) n'a pas pour vocation d'interdire l'accès à l'attribut,
> mais de protéger un attribut essentiel d'une classe de base d'une
> surcharge accidentelle. Le "contrôle d'accès" en Python se fait sur la
> base d'une simple convention: un attribut préfixé d'un underscore
> relève de l'implémentation, donc si vous y touchez, c'est votre
> problème, on vous aura prévenu. Dans la pratique, ça marche
> remarquablement bien.
Oui mais l'encapsulation est un concept majeur dans l'approche objet et
il est essentiel pour la fiabilité de la réutilisation et du
développement par composants.
Dans tout le code objet que j'ai écrit et que j'écris, il n'y a JAMAIS
d'attributs publics ni même "protected" dans les classes. C'est aussi
une règle que je regarde dans mes audits de code avec Logiscope (cette
règle existe d'ailleurs "en dur" dans cette outil)
>
> Je note par contre que le garçon ne mentionne nulle part les
> métaclasses...
Oui c'est un manque dans le comparatif.
>
> Si tu te bases sur des exemples et comparatifs pareils, pas de
> surprise que tu ai une mauvaise image de Python. Franchement, tu
> ferais mieux d'apprendre le langage et de te faire ta propre idée par
> toi-même.
>
Disons que je connais suffisamment le langage pour en parler et
suffisamment l'analyse, la conception et la programmation objet pour
effectivement voir que Python est laxiste vis-à-vis de cette approche,
en particulier pour l'encapsulation. Je suis désolé de te le dire...
Mais je le dis sans polémique.
D'ailleurs l'encapsulation (aui existe indépendamment de l'objet) est
bien plus importante que l'héritage, même dans l'approche objet, car
elle permet (utilisée conjointement avec les types paramétrés) la
réutilisation à grande échelle alors que l'héritage "n'adresse que" la
factorisation du code. Il le rend cependant plus maintenable puisque,
via le polymorphisme d'héritage, il permet de se dispenser des "switch".
La chasse aux switchs est à la programmation objet ce que la chasse aux
gotos est à la programmation structurée.
Sans rancune et A+
Wykaaa
Wykaaa
J'ai sucré tout le texte car c'est juste une référence à un article qui
te fera plaisir :
http://www.internetnews.com/dev-news/article.php/3738856/Python+Fans+Take+Aim+at+the+Enterprise.htm
Je viens juste d'avoir ce lien par le mail hebdo de developer.com.
Wykaaa
bruno desthuilliers
> bruno desthuilliers a écrit :> On 8 avr, 01:56, Wykaaa <wyk...@yahoo.fr> wrote:
> >> bruno desthuilliers a écrit :
>
> >>> On 7 avr, 21:12, Wykaaa <wyk...@yahoo.fr> wrote:
>
>
> >> Et cette page, tu la connais (comparaison de langages dont Python, Ruby,
> >> PHP, C++, Java, etc.) ?http://www.jvoegele.com/software/langcomp.html
>
> > Le mec qui a pondu ça ferait mieux d'apprendre de quoi il cause, ça
> > lui éviterait de se ridiculiser.
>
> Je n'ai pas dit que cette page était bien. Outre qu'elle n'est pas à
> jour par rapport aux versions de langages, il y a de nombreuses
> approximation. Néanmoins c'est un effort méritant...
Pour moi, c'est un manque de l'effort minimum consistant à se
documenter avant de publier.
> Ok, allons-y:
>
> > "Object-Orientation Hybrid"
>
> > Toujours la même légende urbaine comme quoi Ruby serait "pur objet" et
> > pas Python, hein ? Bon, petit rappel, Python est orienté objet depuis
> > (au moins) la première release publique (la 0.91 si ma méoire est
> > bonne) en 1990. En l'état actuel, *tout* ce que tu peux trouver à la
> > droite d'une assignation est un objet. Les classes sont des objets,
> > les fonctions sont des objets, les modules sont des objets, même le
> > putain de byte-code des fonctions est exposé comme un objet. A part -
> > comme en Smalltalk - implémeter les messages comme des objets et les
> > structures de contrôle en tant que message, je vois mal comment faire
> > plus objet.
>
> Oui mais la plupart des auteurs s'accordent à dire que Python est
> hybride car il ne force pas le style objet.
Dans le sens où on n'est pas obligé de tout coller dans classes ?
Désolé, je ne vois pas en quoi cela constitue un "style objet".
Python ne force pas le style "orienté classe" de Java, mais la notion
de classe n'est pas nécessaire à (ni constitutive de) celle d'objet.
Self et Javascript sont des langages objets, et la notion de classe en
est absente.
Accessoirement, si Python est "hybride" pour cette raison, alors Ruby
l'est aussi - entre une fonction Python et une "methode" (hem)
implicitement assignée à un "objet global" essentiellement invisible,
franchement, c'est jouer sur les mots. Et que dire du code directement
au top-level - comme dans le snippet Ruby que tu citais ?
Que Ruby soit plus proche que Python de SmallTalk ne fait aucun doute,
et c'est le seul point sur lequel je lui concède un aspect plus 'pur'.
Par contre, je ne vois pas en quoi Java serait "plus pur objet" que
Python - par contre, je vois très bien en quoi il l'est nettement
moins (des types non objet dans un langage 'objet', là, oui, c'est
hybride).
> En première approche, on
> peut même dire que le style est plus fonctionnel qu'objet
Pour une définition 'a minima' de 'langage fonctionnel' comme 'langage
dans lequel les fonctions sont des aussi des données', Python est un
langage fonctionnel.
Dans la pratique, ce support vient tout simplement du fait que tout en
Python est objet - donc les fonctions aussi - et qu'on peut définir
ses propres types 'fonctionnels' (appelables). Il est d'ailleurs
courant d'utiliser cette deuxième solution plutôt qu'une fermeture dès
que la complexité de l'état à gérer devient non-triviale (ie: voir
l'objet 'partial' dans Python 2.5, et l'implémentation exemple en
Python donnée dans le PEP correspondant).
> (pour moi, cet
> aspect là, n'est pas un inconvénient)
Pour
> > "Higher Order Functions Lambda Expressions"
>
> > Ca veut dire quoi, ça ? L'instruction (très mal nommée) lambda génère
> > un objet fonction parfaitement ordinaire, ce n'est qu'un sucre
> > syntaxique pour des petites fonctions qui ne justifient pas une
> > définition séparée. Pour le reste, une fonction Python est un objet,
> > donc un citoyen parfaitement ordinaire.
>
> Mais ce n'est pas une critique !
Moi si, je critique. Je critique l'auteur de la page citée, en ce
qu'il implique que le support de HOF en Python se *limite* au
expressions lambda (accessoirement, en Python, lambda est une
instruction, mais bon, passons). Là encore, ça dénote une
méconnaissance du langage qui décridibilise totalement la page en
question.
> C'est très bien que Python supporte les fonctions d'ordre supérieur par
> des lambda expressions.
Python supporte les fonctions d'ordre supérieur, point, barre, et
l'instruction lambda n'a rien à voir avec ça. Python supporte
tellement les HOF d'ailleurs qu'il y a depuis la 2.4 une syntaxe
spéciale pour "décorer" une fonction avec une autre dès sa définition:
def trace(func):
def traced(*args, **kw):
print "func %s called with %s %s" % (func, str(args), kw)
result = func(*args, **kw)
print "result : %s" % str(result)
return result
return traced
@trace
def say_hello(who):
return "hello, %s" % who
say_hello('wykaaa')
>
> > "Garbage Collection Reference Counting"
>
> > Ca fait plusieurs années déjà que le comptage de référence est doublé
> > d'un GC capable de détecter les cycles.
>
> C'est dit dans le texte. le tableau est un peu réducteur. je cite (j'ai
> ajouté la flèche) :
Pas été voir plus bas.
> "Reference counting is the simplest scheme and involves the language
> keeping track of how many references there are to a particular object in
> memory, and deleting that object when that reference count becomes zero.
> This scheme, although it is simple and deterministic, is not without its
> drawbacks, the most important being its inability to handle cycles.
> Cycles occur when two objects reference each other, and thus there
> reference counts will never become zero even if neither object is
> referenced by any other part of the program.
>
> ==> This is the scheme that is utilized by Python and Visual Basic,
> although in the case of Python an extra step is taken to ensure that
> cycles are handled appropriately."
Son "extra step" s'appelle un garbage collector. Ne pas le mentionner
dans le tableau (qui est ce à quoi la plupart des lecteurs
s'arrêterons) est de la malhonnêté.
> > "Uniform Access No"
>
> > Si, et depuis toujours. Aux débuts en implémentant la méthode
> > __getattr__(self, name), et depuis plusieurs années via le protocole
> > descripteur - le plus souvent en utilisant le type 'property', qui
> > implémente ce protocole.
>
> tu veux dire comme ça ?
>
> class Foo(object):
> def __init__(self, x):
> self.setx(x)
>
> def getx(self):
> return self.__x
>
> def getx_times_5(self):
> return self.x*5
>
> x = property(getx, doc="getter for x")
> x_times_5 = property(getx_times_5, doc="getter for x, times 5")
Tu a oublié le setter dans ta définiton de x. Qui t'aurais évité un
appel explicite dans l'initialiseur.
class Foo(object):
def __init__(self, x):
self.x = x
@apply
def x():
def fget(self):
return self._x
def fset(self, val):
self._x = val
return property(**locals())
@property
def x_5_times:
return self._x * 5
> En Ruby :
Oui, je connais Ruby.
>
> D'un autre côté, en C++ ou en Java, si l'on veut respecter
> l'encapsulation (l'un des concepts majeur de l'objet),
pas seulement de l'objet
> on définira tous
> les attributs dans la partie privée d'une classe. Il y aura donc accès
> uniforme puisqu'un attribut de classe ne pourra jamais être accédé
> directement mais seulement par son "setter" et son "getter".
Yep. Mais on est obligé de définir des accesseurs pour tous les
attributs qu'on veut exposer, et de se taper systématiquement un appel
de méthode. Ca marche, certes, mais c'est un poil primitif.
>
>
> > "Class Variables / Methods No"
>
> > Les variables de classe ont toujours été supportées, les méthodes de
> > classe le sont depuis longtemps - si mon souvenir est bon depuis la
> > 2.0 ou 2.1, en tous cas une version antérieure à la rédaction de ce
> > document. A noter également que les classmethods Python, contrairement
> > aux méthodes "static" de Java, recoivent l'objet classe en premier
> > argument. Il existe aussi des staticmethods en Python, mais leur
> > emploi est rarissime puisque Python n'impose pas de tout caser dans
> > des classes, que ça ait un sens ou non.
>
> Ben voilà...
>
>
>
> > "Access Control Name Mangling"
>
> > Le name mangling (effectué sur les attributs préfixés d'un double
> > underscore) n'a pas pour vocation d'interdire l'accès à l'attribut,
> > mais de protéger un attribut essentiel d'une classe de base d'une
> > surcharge accidentelle. Le "contrôle d'accès" en Python se fait sur la
> > base d'une simple convention: un attribut préfixé d'un underscore
> > relève de l'implémentation, donc si vous y touchez, c'est votre
> > problème, on vous aura prévenu. Dans la pratique, ça marche
> > remarquablement bien.
>
> Oui mais l'encapsulation est un concept majeur dans l'approche objet et
et n'a qu'un rapport très lointain avec les restricteurs d'accès. Le
principe de l'encapsulation, c'est de 1/ regrouper et 2/ masquer les
détails d'implémentation, d'une part pour éviter au code utilisateur
d'avoir à s'en soucier, et d'autre part pour permettre de modifier
l'implémentation sans casser le code client.
> il est essentiel pour la fiabilité de la réutilisation et du
> développement par composants.
Un domaine dans lequel Python se démerde assez bien, merci.
> Dans tout le code objet que j'ai écrit et que j'écris, il n'y a JAMAIS
> d'attributs publics ni même "protected" dans les classes.
Moi si. Tout plein. Mais ce n'est pas un problème, parce que Python
supporte les attributs calculés, donc je peux remplacer un accès
direct par un accès calculé sans impact pour le code client.
> C'est aussi
> une règle que je regarde dans mes audits de code avec Logiscope (cette
> règle existe d'ailleurs "en dur" dans cette outil)
Python existe depuis 1990, il est utilisé par des dizaines de milliers
de développeurs de tous niveaux, et pas seulement sur des applications
triviales. L'absence de restriction d'accès (imposée par le langage,
j'entends) n'est manifestement pas un problème. Il y a là une évidence
empirique qu'il serait irrationnel de nier.
Accessoirement encore, il est possible de contourner les restrictions
d'accès en C++ (avec un define et une recompilation - implique d'avoir
accès au source, bien sûr) ou en Java (via la réflection).
> > Je note par contre que le garçon ne mentionne nulle part les
> > métaclasses...
>
> Oui c'est un manque dans le comparatif.
>
> > Si tu te bases sur des exemples et comparatifs pareils, pas de
> > surprise que tu ai une mauvaise image de Python. Franchement, tu
> > ferais mieux d'apprendre le langage et de te faire ta propre idée par
> > toi-même.
>
> Disons que je connais suffisamment le langage pour en parler
Vu les exemples que tu m'a sorti jusque là, tu m'excusera si je n'en
suis pas convaincu.
> et
> suffisamment l'analyse, la conception et la programmation objet pour
> effectivement voir que Python est laxiste vis-à-vis de cette approche,
Parce qu'il ne t'oblige pas à tout mettre dans des classes ?-)
> en particulier pour l'encapsulation.
en particulier pour les restricteurs d'accès - ce à quoi
l'encapsulation ne se résume pas.
Excuse-moi, mais vu le nombre de classe Java que j'ai vu où *tous* les
attributs étaient accessibles - via des accesseurs, certes, mais à ce
stade je ne vois pas ce que ça change -, et je ne te parles pas des
classes composées uniquement de staticmethods - bref, des fonctions
dans un module -, je n'achète pas tes arguments sur la nécessité
absolue des restrictions d'accès dans le langage. Soit le développeur
comprends l'encapsulation, et il n'a pas besoin qu'on lui force la
main, soit il ne la comprends pas (et ajoute des accesseurs pour tous
ses attributs sans exception), et ça ne sert à rien de toutes façons.
On en revient toujours au même point : le code est écrit par des
humains, et utilisé par des humains, et il n'y a pas solutions
techniques aux problèmes (fatigue, pression, distraction, manque
d'expérience, manque d'éducation, ou tout simplement bêtise) humains.
Aucune (je répète : aucune) technologie ne te mettra jamais à l'abri
d'une erreur humaine. cf cette bonne vieille Ariane. Je comprend -
particulièrement dans ton domaine - qu'on cherche à limiter les
risques d'erreurs (et, encore plus, leurs conséquences !), mais faire
d'une bonne pratique une règle idéologique, sans moi.
Y a plein de règles comme ça (les globales sont mauvaises, les goto
sont mauvais, les attributs accessibles sont mauvais etc) qui relèvent
de l'éducation, pas d'autre chose. Quand mon fils était petiot, je lui
interdisais de jouer avec les prises électriques, parce que lui
expliquer en quoi c'est dangereux n'aurait servi à rien. Maintenant,
ce n'est plus la peine de lui interdire, il est assez grand pour
savoir pourquoi c'est une mauvaise idée d'aller jouer avec une prise
électrique *à moins d'être sûr que le courant est coupé*. Et il sait
où est le disjoncteur. Est-ce que ça le mets pour toujours à l'abri
d'un accident suite à un moment d'inattention ? Non, bien sûr. Mais
là, tant qu'il y aura besoin d'installer ou de réparer des prises
électriques, le risque existera. Le seul moyen absolument efficace
pour ne pas risquer de mourir, c'est d'être mort. Et le seul code
garanti sans bug, c'est pas de code. Ce qui pour moi est une raison
majeure pour éviter le code inutile, soit dis au passage.
> Je suis désolé de te le dire...
> Mais je le dis sans polémique.
pareil !-)
> D'ailleurs l'encapsulation (aui existe indépendamment de l'objet) est
> bien plus importante que l'héritage,
Tu prêches un converti. Mais pour une définition légèrement différente
d'encapsulation !-)
> même dans l'approche objet, car
> elle permet (utilisée conjointement avec les types paramétrés) la
> réutilisation à grande échelle alors que l'héritage "n'adresse que" la
> factorisation du code. Il le rend cependant plus maintenable puisque,
> via le polymorphisme d'héritage, il permet de se dispenser des "switch".
L'héritage (d'implémentation ou d'interface) ne conditionne le
dispatch polymorphisme des messages *que* dans les langages à typage
statique.
> La chasse aux switchs est à la programmation objet ce que la chasse aux
> gotos est à la programmation structurée.
Là encore, si tu veux, je ne t'ai pas attendu pour m'en rendre
compte !-)
Par contre, le "dispatch simple" de la plupart des modèles objet reste
très limité AMHA - à preuve, l'invention du pattern visiteur. CLOS,
avec son multidispatch, offre bien plus de possibilité - au prix, bien
sûr, d'une complexité intrinsèque plus grande, et vu la difficulté
qu'ont encore pas mal de développeurs à comprendre le single
dispatch... Enfin bon, c'est un autre troll^M^débat...
> Sans rancune
Rancune ? Pourquoi donc ?
Tu sais, ce n'est pas parce que je défends mes points de vues avec
conviction que j'attends des autres qu'ils les partagent, hein.
<troll>Enfin, pas immédiatement !-)))</troll>
Marc Boyer
Ben, visiblement non.
Ceci dit, de quels Pascal parlons nous ? Celui dont parle Kernigan
doit être un très ancien. Est-ce qu'il a évolué depuis...
> IIRC aussi, en Pascal, un tableau de 10 entiers
> n'est pas du même type qu'un tableau de 11 entiers...
Ca oui. Et dans la pratique, c'est extrèmement pénible.
> Mais bon, ça dépend peut-être aussi des implémentations.
Ben, il existe une norme ISO, mais si personne ne la
respecte, ça ne fixe pas grand chose. Ceci dit, j'arrête de
parler de Pascal. Le but s'était juste de dire que le typage
statique avait un but de correction et pas uniquement
d'optimisation.
>> >> Quant aux débutants... Ils confondent (je prends la syntaxe C)
>> >> 0, 0.0, "0", '0' et '\0'. Alors, si tu ne leur impose pas
>> >> de dire quel est le type de valeur qu'ils manipulent (lors de
>> >> la déclaration de variable), ben, c'est la panique.
>>
>> > Heu... J'ai commencé à bricoler mes premiers bouts de code en 1990 avec
>> > HyperCard / HyperTalk (typage dynamique, et pas spécialement fort). Sans
>> > internet, et sans personne pour me mentorer. Et j'ai très vite appris à
>> > faire la différence entre une chaine et un nombre (ne serait-ce qu'en
>> > voyant le résultat des calculs...).
>>
>> La question du "très vite" est toute relative, dépendante de la
>> personne, et de sa motivation.
>
> "très vite" = une après-midi à m'arracher les cheveux, sachant que
> j'avais commencé la lecture du manuel hypertalk au début de la même
> semaine et n'avait à ce moment *strictement aucune* connaissance /
> expérience / whatever en programmation (et très peu d'expérience de
> l'informatique tout court).
Et ben... En tant qu'enseignent, j'écrit un support de cours, je
le présente, je dis des choses à l'oral, au tableau et devant la
machine, et après, certaines choses ont été "oubliées", et je
retrouve des choses genre:
char* mes;
fgets(mes, 4, stdin);
et quand je demande à l'étudiant "mais 'mess', il pointe sur quelle
variable ?", il me répond "ben, 'mess[0]'"...
> Quant à ma motivation, je dois être un peu cabochard, mais on peut la
> résumer à : "c'est quand même pas cette putain de calculette géante
> qui va avoir le dernier mot avec moi, putain de bordel de merdre !"
Très forte motivation donc.
>> > Bon, le langage suivant (si on omet un peu d'assembleur 68k) était un
>> > basic objet à typage statique déclaratif, et je reconnais que dans un
>> > premier temps, j'ai de moi-même considéré ça comme une aide et un
>> > progrès par rapport à HyperTalk - peut-être simplement parce que ça
>> > m'obligeait à structurer un peu plus ma réflexion vu que dans la
>> > pratique je n'avais en fait guère de pb de typage, ayant déjà appris à
>> > être attentif à ces aspects.
>>
>> Ce qui va dans ce sens.
>
> Oui et non. On croise sur (f)cl.py pas mal de débutants complets, et
> il ne semble pas que le typage dynamique les empêche de comprendre la
> différence entre une chaine, un entier, un pseudo-réel, une liste ou
> un dictionnaire (pour ne citer que les types 'de base' les plus
> utilisés).
Faudrait que je m'y abonne peut-être.
>> Dans le cadre d'une formation, on peut le contraindre à passer
>> par la partie pénible jusqu'au moment où l'investissement paye.
>
> La contrainte est-elle à ce point nécessaire ?
>
> Nos graphistes viennent de passer de Windows à MacOS X. Et malgré les
> qualités du clickodrome en question, ils sont en train, petit à petit,
> de se mettre aux lignes de commande. Non par contrainte, mais d'une
> part parce qu'ils nous voient utiliser l'outil, et voient donc en quoi
> il peut être dans certains cas plus puissant qu'un clickodrome, et
> d'autre part parce que cela leur permet aussi d'être autonomes sur les
> serveurs linux quand ils ont besoin d'y accéder.
Il faudrait faire de la psychologie pour comprendre pourquoi
ça marche "par l'exemple" et pas chez nous.
Après 7 mois sur machine, il n'utilisent toujours pas la
completion automatique du shell....
>> > réaliser dès les premiers jours avoir des petits programmes
>> > *fonctionnels* est certainement pour beaucoup dans ma "vocation". Et une
>> > fois motivé, je n'ai pas eu de problème majeur à passer à des technos
>> > bien plus contraignantes.
>>
>> Et oui... Si les étudiants choisissaient un cursus conforme à
>> leurs envies, l'enseignement supérieur serait plus simple.
>
> Je ne sais pas dans quelle mesure "envie" est le terme qui convient.
> Je pense que c'est, plus généralement, lié au fait d'avoir réellement
> *choisi* le cursus - quant aux raisons du choix, c'est autre chose.
> Mais bon, ce qui est sûr, c'est que quelqu'un qui ne sait même pas
> pourquoi il est là ne fait pas forcément le meilleur apprenant. Dans
> cette perspective, la question n'est pas tant de savoir s'il vaut
> mieux enseigner la programmation avec tel ou tel système de typage,
> mais si ça vaut le coup d'enseigner quoi que ce soit à quelqu'un qui
> fondamentalement s'en contrefiche.
Vaste programme.
>> >>> Ceci étant, on parle de typage statique et dynamique en faisant comme si
>> >>> la notion même de "type" était la même dans les deux cas, ce que n'est
>> >>> peut-être pas vraiment le cas. Du point du vue du typage statique, dans
>> >>> des langages comme Python ou Ruby, il n'existe en fait qu'un seul type,
>> >>> le type 'objet' - pas de types "primitifs", "scalaires" etc...
>>
>> >> Heuh... Faut quand même pas confondre les concepts et leur
>> >> implantation. Je suis 0 en python, mais je lis sur Wikipédia:
>> >> points = 3.2 # points est du type float
>> >> print "Tu as " + points + " points !" # Génère une erreur de typage
>>
>> >> Que la notion de type (flottant, chaine) soit englobée dans un attribut
>> >> dynamique en python, ok, mais la notion reste là, non ?
>>
>> > La notion de "type" est là, oui, je ne dis pas le contraire. Mais
>> > pointe-t-elle sur le même concept ?
>>
>> Ben, une variable transporte une donnée,
>
> Pas dans des langages comme Python ou Ruby etc, où une "variable" ne
> "transporte" rien, puisque c'est juste un nom permettant d'accéder à
> un objet dont le cycle de vie est indépendant du périmètre de
> visibilité du nom en question.
Pardon, "désigne" une donnée.
C'est de la manipulation par référence et non par valeur.
[SNIP, longue explication sur référence vs valeur]
> Là n'était pas le propos. J'essaie juste d'illustrer, malgré mes
> lacunes en théorie informatique, en quoi il me semble que même s'il
> existe dans les deux systèmes une notion de type, je ne suis pas sûr
> qu'il s'agisse vraiment du même concept. Mais bon, étant incapable
> d'exprimer ça plus clairement, je vais m'en tenir là pour le
> moment :-/
C'est très claire: c'était une erreur de ma part.
Mon propos reste le même: une variable sert à manipuler (par valeur
ou par reference) une "donnée" d'un certain type (j'exclu de la
discution le sous-typage).
Il est important pour les débutants de comprendre ce qu'est
un type, et, quand il réfléchissent à un algo, de devoir
expliciter le type des variables manipulées.
Matthieu Villeneuve
> Je te garantis que l'appli en question n'aurait pas pu utiliser le
> typage dynamique (avionique militaire)
C'est intéressant, pouvez-vous expliquer un peu pourquoi ?
Merci,
--
Matthieu Villeneuve
Wykaaa
erreur de typage se traduise par un arrêt du programme à l'exécution.
Je l'ai déjà dit ailleurs, mais je le redit, dans un logiciel de guidage
de missile, il est interdit de faire des opérations sur la pile
d'exécution. Il n'y a donc même pas de déclaration de variables locales,
alors le typage dynamique....
Wykaaa
Bruno Desthuilliers
> Matthieu Villeneuve a écrit :
>> Wykaaa wrote:
>>> Je te garantis que l'appli en question n'aurait pas pu utiliser le
>>> typage dynamique (avionique militaire)
>>
>> C'est intéressant, pouvez-vous expliquer un peu pourquoi ?
>> Merci,
>>
>>
> Dans des applications de ce type, il est hors de question qu'une simple
> erreur de typage se traduise par un arrêt du programme à l'exécution.
>
> Je l'ai déjà dit ailleurs, mais je le redit, dans un logiciel de guidage
> de missile, il est interdit de faire des opérations sur la pile
> d'exécution. Il n'y a donc même pas de déclaration de variables locales,
> alors le typage dynamique....
Heu... je remets les choses dans le contexte:
"""
>> La dernière appli que j'ai auditée était en Java et il y avait plus
de 9 000 classes et plus de 26 000 méthodes !
"""
"""
Je te garantis que l'appli en question n'aurait pas pu utiliser le
typage dynamique (avionique militaire)
"""
Java, sans opérations sur la pile ???
Par ailleurs, je tiens à te rappeler que
1/ les erreurs de type à l'exécution, en Java, ça existe.
2/ la gestion d'exception, dans les langages à typage dynamique, ça
existe (sous-entendu : une erreur - de type ou non - à l'exécution
n'entraine pas nécessairement l'arrêt du programme)
3/ dans tous les cas, on ose espérer que les logiciels en question sont
soumis à des tests plus rigoureux que "ça compile, donc ça doit être ok".
Bref, si effectivement ton argument pour les logiciels de guidage -
quelque soit sa justification par ailleurs - exclus effectivement tout
langage *basé sur une machine virtuelle* (le typage étant un autre
problème), il ne peut s'appliquer à ta monstrueuse appli Java. Donc, tu
n'a aucun argument ici, hormis les habituelles rengaines d'ordre
idéologique concernant le prétendu manque de fiabilité du typage
dynamique, ce qui est un peu léger puisque le problème est le risque
d'erreur à l'exécution, *quelles que soient ces erreurs*, et que le
typage statique ne suffit pas en lui-même à éliminer ce risque (qu'il
puisse le réduire étant un autre débat).
lalala...
Matthieu Villeneuve
> Matthieu Villeneuve a écrit :
>> Wykaaa wrote:
>>> Je te garantis que l'appli en question n'aurait pas pu utiliser le
>>> typage dynamique (avionique militaire)
>>
>> C'est intéressant, pouvez-vous expliquer un peu pourquoi ?
>>
> erreur de typage se traduise par un arrêt du programme à l'exécution.
Je suis d'accord, mais pourquoi faire une différence entre erreurs de
typage et autres erreurs de programmation, pour lesquelles le typage
statique ne donne pas de solution ? Il me semble que quel que soit le
langage utilisé, l'application ne sera jamais utilisée si elle ne passe
pas une batterie exhaustive de tests. Et que ces tests couvrent tous
les scenarii possibles, incluant ceux qui pourraient provoquer une
erreur de typage.
Au passage, un compilateur pour un langage à typage statique n'est en
général capable de vérifier qu'un ensemble très réduit de conditions,
et laisse passer énormément d'erreurs de typage (dès que la définition
d'un type valide ne correspond pas exactement au découpage visible par
le compilateur). Par exemple, le calcul d'un arccos d'une valeur hors
de l'intervalle [-1, 1], l'utilisation d'un objet dans un état
incorrect, etc. etc.
--
Matthieu Villeneuve
Wykaaa
> Wykaaa a écrit :
>> Matthieu Villeneuve a écrit :
>>> Wykaaa wrote:
>>>> Je te garantis que l'appli en question n'aurait pas pu utiliser le
>>>> typage dynamique (avionique militaire)
>>>
>>> C'est intéressant, pouvez-vous expliquer un peu pourquoi ?
>>> Merci,
>>>
>>>
>
>> Dans des applications de ce type, il est hors de question qu'une
>> simple erreur de typage se traduise par un arrêt du programme à
>> l'exécution.
>>
>> Je l'ai déjà dit ailleurs, mais je le redit, dans un logiciel de
>> guidage de missile, il est interdit de faire des opérations sur la
>> pile d'exécution. Il n'y a donc même pas de déclaration de variables
>> locales, alors le typage dynamique....
>
> Heu... je remets les choses dans le contexte:
>
> """
> >> La dernière appli que j'ai auditée était en Java et il y avait plus
> de 9 000 classes et plus de 26 000 méthodes !
> """
> """
> Je te garantis que l'appli en question n'aurait pas pu utiliser le
> typage dynamique (avionique militaire)
> """
>
>
> Java, sans opérations sur la pile ???
Ouh la la !
A force de discussion, j'ai du mélangé plusieurs applications.
L'appli qui fait 9 000 classes est bien pour l'armée de l'air mais n'est
pas de l'informatique pour l'avion. C'est un socle technique pour
plusieurs systèmes de commandement. Il n'y a donc pas les contraintes
dont je parlais par ailleurs...
Pour le typage dynamique, je parlais d'une autre application où tout
doit être statique : aucune allocation dynamique, ni opérations sur la
pile (ce sont les directives du projet, qui elles-mêmes respectent les
directives OTAN et DoD pour ce type d'application). Celle-ci n'est
évidemment pas codée en Java...
>
>
> Par ailleurs, je tiens à te rappeler que
> 1/ les erreurs de type à l'exécution, en Java, ça existe.
> 2/ la gestion d'exception, dans les langages à typage dynamique, ça
> existe (sous-entendu : une erreur - de type ou non - à l'exécution
> n'entraine pas nécessairement l'arrêt du programme)
> 3/ dans tous les cas, on ose espérer que les logiciels en question sont
> soumis à des tests plus rigoureux que "ça compile, donc ça doit être ok".
Je n'ai jamais lié le typage statique et le fait que, du coup, on n'a
pas besoin de faire des tests...
Dans les milieux que je fréquente, les phases de tests représentent plus
de 60% du temps total de développement !
Les personnes (pas seulement toi) qui discutent dans ce fil doivent
savoir que le cycle de développement logiciel appliqué est, en gros l'un
de ceux définis par l'OTAN et le Dod (voire la NASA...). Je dis à tous,
ici, que mieux vaut dire que ça ne rigole pas, en particulier pour
l'avionique, où il y a des types de certification pour les logiciels.
>
> Bref, si effectivement ton argument pour les logiciels de guidage -
> quelque soit sa justification par ailleurs - exclus effectivement tout
> langage *basé sur une machine virtuelle* (le typage étant un autre
> problème), il ne peut s'appliquer à ta monstrueuse appli Java. Donc, tu
> n'a aucun argument ici, hormis les habituelles rengaines d'ordre
> idéologique concernant le prétendu manque de fiabilité du typage
> dynamique, ce qui est un peu léger puisque le problème est le risque
> d'erreur à l'exécution, *quelles que soient ces erreurs*, et que le
> typage statique ne suffit pas en lui-même à éliminer ce risque (qu'il
> puisse le réduire étant un autre débat).
>
> lalala...
Encore une fois, je n'ai jamais dit que si on franchissait le typage
statique alors il n'y avait plus d'erreur à l'exécution. Ce serait bien
naïf et pas digne d'un expert en logiciel.
Simplement, le typage statique renforce ce qu'on appelle la prévention
des défauts (il ne les élimine évidemment pas). Dans les domaines que je
cite, tout est fait pour se mettre en mode prévention des défauts en
applicant très rigoureusement toutes les procédures qualité, tout au
long du cycle de vie logiciel depuis l'ingénierie des exigences tout en
amont jusqu'aux phases d'exploitation et de maintenance (et même des
procédures sont prévues pour ce qu'on appelle le retrait de service car,
par exemple, on ne démantèle pas une centrale nucléaire comme on détruit
un vélo...
De plus, tu me fais dire des choses que je n'ai jamais dites.
Je ne dis pas que le typage dynamique n'est pas fiable, je dis, pour les
raisons évoquées précédemment, que ce n'est pas adéquat pour ce genre
d'application.
Il y a déjà assez de risques d'erreur à l'exécution, sans en rajouter
avec le contrôle de type...
Wykaaa
> Wykaaa wrote:
>> Matthieu Villeneuve a écrit :
>>> Wykaaa wrote:
>>>> Je te garantis que l'appli en question n'aurait pas pu utiliser le
>>>> typage dynamique (avionique militaire)
>>> C'est intéressant, pouvez-vous expliquer un peu pourquoi ?
>>>
>> Dans des applications de ce type, il est hors de question qu'une simple
>> erreur de typage se traduise par un arrêt du programme à l'exécution.
>
> Je suis d'accord, mais pourquoi faire une différence entre erreurs de
> typage et autres erreurs de programmation, pour lesquelles le typage
> statique ne donne pas de solution ? Il me semble que quel que soit le
> langage utilisé, l'application ne sera jamais utilisée si elle ne passe
> pas une batterie exhaustive de tests. Et que ces tests couvrent tous
> les scenarii possibles, incluant ceux qui pourraient provoquer une
> erreur de typage.
Voir ma réponse à Bruno dans ce même fil (en particulier sur les tests).
Enfin, je répète lier systématiquement typage statique et détection
d'erreur de programmation est une vue très étroite des bénéfices du
typage statique et que ce n'est même pas son but principal.
Le typage statique contribue surtout à augmenter la qualité de facteurs
comme l'évolutivité, la maintenabilité, la réutilisabilité, car on aura
des erreurs de compilation sur les types quand on déplacera un module ou
du code hors de son contexte sans avoir pris les précautions nécessaires.
>
> Au passage, un compilateur pour un langage à typage statique n'est en
> général capable de vérifier qu'un ensemble très réduit de conditions,
> et laisse passer énormément d'erreurs de typage (dès que la définition
> d'un type valide ne correspond pas exactement au découpage visible par
> le compilateur). Par exemple, le calcul d'un arccos d'une valeur hors
> de l'intervalle [-1, 1], l'utilisation d'un objet dans un état
> incorrect, etc. etc.
>
Le calcul d'une valeur en dehors d'un certain intervalle ne relève pas
forcément du typage (cf. fusée Ariane 5 programmée en ADA, l'un des
langages à plus fort typage statique).
L'utilisation d'un objet dans un état incorrect non plus. Ce genre de
problème se prévient (je ne dis pas qu'il est totalement résolu par,
hein ?) par les méthodes de la programmation sûre.
A ce propos, voici un petit guide pour le langage C :
ftp://ftp.laas.fr/pub/ii/matthieu/c-superflu/c-superflu.pdf
Bruno Desthuilliers
> Matthieu Villeneuve a écrit :
>> Wykaaa wrote:
>>> Matthieu Villeneuve a écrit :
>>>> Wykaaa wrote:
>>>>> Je te garantis que l'appli en question n'aurait pas pu utiliser le
>>>>> typage dynamique (avionique militaire)
>>>> C'est intéressant, pouvez-vous expliquer un peu pourquoi ?
>>>>
>>> Dans des applications de ce type, il est hors de question qu'une simple
>>> erreur de typage se traduise par un arrêt du programme à l'exécution.
>>
>> Je suis d'accord, mais pourquoi faire une différence entre erreurs de
>> typage et autres erreurs de programmation, pour lesquelles le typage
>> statique ne donne pas de solution ? Il me semble que quel que soit le
>> langage utilisé, l'application ne sera jamais utilisée si elle ne passe
>> pas une batterie exhaustive de tests. Et que ces tests couvrent tous
>> les scenarii possibles, incluant ceux qui pourraient provoquer une
>> erreur de typage.
>
> Voir ma réponse à Bruno dans ce même fil (en particulier sur les tests).
>
> Enfin, je répète lier systématiquement typage statique et détection
> d'erreur de programmation est une vue très étroite des bénéfices du
> typage statique et que ce n'est même pas son but principal.
Ah ? Tiens, il me semblait que tu avais affirmé plus haut que l'intérêt
premier du typage statique était la correction du typage ?-)
> Le typage statique contribue surtout à augmenter la qualité de facteurs
> comme l'évolutivité, la maintenabilité, la réutilisabilité,
Mouarf. Dans mon expérience, c'est exactement ce que le typage statique
déclaratif à la Java rend inutilement compliqué (et donc plus sujet à
erreur), et c'est précisément une des raisons pour lesquelles j'apprécie
le typage dynamique.
> car on aura
> des erreurs de compilation sur les types quand on déplacera un module ou
> du code hors de son contexte sans avoir pris les précautions nécessaires.
Mouais... On a beau dire, on crashe des fusées quand même.
>>
>> Au passage, un compilateur pour un langage à typage statique n'est en
>> général capable de vérifier qu'un ensemble très réduit de conditions,
>> et laisse passer énormément d'erreurs de typage (dès que la définition
>> d'un type valide ne correspond pas exactement au découpage visible par
>> le compilateur). Par exemple, le calcul d'un arccos d'une valeur hors
>> de l'intervalle [-1, 1], l'utilisation d'un objet dans un état
>> incorrect, etc. etc.
>>
> Le calcul d'une valeur en dehors d'un certain intervalle ne relève pas
> forcément du typage
IIRC, selon certaines théories, un type est défini par un ensemble de
valeurs et les opérations sur ces valeurs...
> (cf. fusée Ariane 5 programmée en ADA, l'un des
> langages à plus fort typage statique).
Le problème était, en l'occurrence et s'il me souvient bien, à la
combinaison d'un integer overflow ET de la désactivation de la gestion
d'erreur dans cette partie du code.
Wykaaa
Encore une fois, tu lies trop typage statique et erreur de programmation.
Pour la fusée, voir plus bas...
>
>>>
>>> Au passage, un compilateur pour un langage à typage statique n'est en
>>> général capable de vérifier qu'un ensemble très réduit de conditions,
>>> et laisse passer énormément d'erreurs de typage (dès que la définition
>>> d'un type valide ne correspond pas exactement au découpage visible par
>>> le compilateur). Par exemple, le calcul d'un arccos d'une valeur hors
>>> de l'intervalle [-1, 1], l'utilisation d'un objet dans un état
>>> incorrect, etc. etc.
>>>
>> Le calcul d'une valeur en dehors d'un certain intervalle ne relève pas
>> forcément du typage
>
> IIRC, selon certaines théories, un type est défini par un ensemble de
> valeurs et les opérations sur ces valeurs...
Tu IIRC bien :-), mais en l'occurrence, le corps des nombres réels (IR
hein, à ne pas confondre avec float ou double) possèdent bien les
opérations + et * mais ses valeurs sont dans l'intervalle ouvert
]-00,+00[, alors...
Ceci dit, en ADA, on sait se débrouiller pour faire un type dont les
valeurs respectent l'intervalle de arccos, qu'une exception soit levée
au cas ou la valeur n'est pas dans l'intervalle et que le code de
récupération de l'exception fasse ce qu'il faut.
>
>> (cf. fusée Ariane 5 programmée en ADA, l'un des langages à plus fort
>> typage statique).
>
> Le problème était, en l'occurrence et s'il me souvient bien, à la
> combinaison d'un integer overflow ET de la désactivation de la gestion
> d'erreur dans cette partie du code.
Le problème était surtout que Ariane 5 ne se comporte pas comme Ariane 4
au décollage. Ariane 4 a un V0 (vitesse par rapport au sol) de quasiment
zéro (elle décolle verticalement) alors que Ariane 5 s'incline
rapidement pour bénéficier de la force de Coriolis (enfin les effets
accélérateur) car elle est plus lourde que son ancêtre. Mais le module
logiciel de navigation de Ariane 5 a été repris intégralement de celui
de Ariane 4.
Le résultat est que le module logiciel, quand il a vu un V0 très
différent de celui attendu, a cherché à corriger la trajectoire (pour
que la fusée reste verticale). Sur le film du décollage, on voit
d'ailleurs, juste avant la désintégration, la fusée se redresser. Elle
était en pleine accélération et sa structure n'a donc pas résisté à la
correction de trajectoire.
C'est donc un défaut d'intégration logiciel/matériel (les procédures de
tests d'intégration n'ont pas été toutes respectées par le sous-traitant).
La version de la cause à laquelle tu fais référence n'est pas exacte
mais elle est plus facile à comprendre. En gros : le V0 serait devenu
suffisamment grand pour faire un overflow, qu'il n'était pas prévu de
récupérer dans le code puisque, "normalement" (pour Ariane 4), ce V0
devait être très petit (je ne sais pas en quelle unité il était exprimé).
Bruno Desthuilliers
Moi, non. Je constate juste, pour la ènième fois, que contrairement à un
ce qu'affirme un certain discours de façon quasi-idéologique, le typage
statique n'empêche pas les erreurs à l'exécution, et que par conséquent
la critique du typage dynamique sur cette base ne tient pas la route.
Qui disait dans un post précédent:
"""
Le typage statique contribue surtout à augmenter la qualité de facteurs
comme l'évolutivité, la maintenabilité, la réutilisabilité, car on aura
des erreurs de compilation sur les types quand on déplacera un module ou
du code hors de son contexte sans avoir pris les précautions nécessaires.
"""
Oui, je sais, ce n'est pas exactement le même mode de réutilisation.
Mais justement, ça démontre bien, encore une fois, qu'on ne peut régler
des problèmes essentiellement humains avec des solutions purement
technologiques.