Re: Langage d'enseignement (Was: Python)

Marc Boyer a écrit :

> Bruno Desthuilliers <bruno.42.desthuilliers@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...)