Re: Langage d'enseignement (Was: Python)

bruno desthuilliers a écrit :
> 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.

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