Re: Langage d'enseignement (Was: Python)

On 2 avr, 19:50, Wykaaa <wyk...@yahoo.fr> wrote:
> Bruno Desthuilliers a écrit :
>
>
>
> > 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"

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.