Re: Langage d'enseignement (Was: Python)

Bruno Desthuilliers a écrit :
> 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...
> 
Certes mais pédagogiquement parlant, ça laisse plein de problèmes de 
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.
> 
>> 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.
> 
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 !!!

>>> 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 !-)

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]