Re: Langage d'enseignement (Was: Python)

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