Re: Langage d'enseignement (Was: Python)

On 7 avr, 10:10, Marc Boyer <Marc.Bo...@enseeiht.yahoo.fr.invalid>
wrote:
> On 2008-04-04, Bruno Desthuilliers wrote:
>
> > Marc Boyer a écrit :

(à propos de raisons premières du typage statique - optimisation ou
correction)
> >>   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 ?
>
>   C'était semble-t-il l'intention. Mais on pouvait tout
> à fait ajouter des pommes et des oranges.
>
> http://www.cs.virginia.edu/~evans/cs655-S00/readings/bwk-on-pascal.html
>      type
>              apple = integer;
>              orange = integer;
>
> then any arbitrary arithmetic expression involving apples and oranges is
> perfectly legal.

Tiens, il me semblait me souvenir que justement Pascal différait du C
sur ce point en faisant des typedef de vraies définitions de type et
non de simples alias ? IIRC aussi, en Pascal, un tableau de 10 entiers
n'est pas du même type qu'un tableau de 11 entiers... Mais bon, ça
dépend peut-être aussi des implémentations. Et puis mes souvenirs de
Pascal sont un peu floues (pas touché depuis 2000, sauf quelques
bricoles sur un utilitaire en Delphi l'année dernière).

> >>   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...).
>
>   La question du "très vite" est toute relative, dépendante de la
> personne, et de sa motivation.

"très vite" = une après-midi à m'arracher les cheveux, sachant que
j'avais commencé la lecture du manuel hypertalk au début de la même
semaine et n'avait à ce moment *strictement aucune* connaissance /
expérience / whatever en programmation (et très peu d'expérience de
l'informatique tout court).

Quant à ma motivation, je dois être un peu cabochard, mais on peut la
résumer à : "c'est quand même pas cette putain de calculette géante
qui va avoir le dernier mot avec moi, putain de bordel de merdre !"

> > 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.
>
>   Ce qui va dans ce sens.

Oui et non. On croise sur (f)cl.py pas mal de débutants complets, et
il ne semble pas que le typage dynamique les empêche de comprendre la
différence entre une chaine, un entier, un pseudo-réel, une liste ou
un dictionnaire (pour ne citer que les types 'de base' les plus
utilisés).

(snip)
> >>    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.
>
>   Toujours le problème de la "courbe d'apprentissage". Quand un
> grand débutant à le choix entre le navigateur de fichiers gnome
> et un shell, il choisit le clickodrome.

Bien sûr. C'est plus facile à "découvrir". C'est bien l'avantage de ce
type d'interface par rapport aux lignes de commande.

>   Dans le cadre d'une formation, on peut le contraindre à passer
> par la partie pénible jusqu'au moment où l'investissement paye.

La contrainte est-elle à ce point nécessaire ?

Nos graphistes viennent de passer de Windows à MacOS X. Et malgré les
qualités du clickodrome en question, ils sont en train, petit à petit,
de se mettre aux lignes de commande. Non par contrainte, mais d'une
part parce qu'ils nous voient utiliser l'outil, et voient donc en quoi
il peut être dans certains cas plus puissant qu'un clickodrome, et
d'autre part parce que cela leur permet aussi d'être autonomes sur les
serveurs linux quand ils ont besoin d'y accéder.

> > 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.
>
>   Et oui... Si les étudiants choisissaient un cursus conforme à
> leurs envies, l'enseignement supérieur serait plus simple.

Je ne sais pas dans quelle mesure "envie" est le terme qui convient.
Je pense que c'est, plus généralement, lié au fait d'avoir réellement
*choisi* le cursus - quant aux raisons du choix, c'est autre chose.
Mais bon, ce qui est sûr, c'est que quelqu'un qui ne sait même pas
pourquoi il est là ne fait pas forcément le meilleur apprenant. Dans
cette perspective, la question n'est pas tant de savoir s'il vaut
mieux enseigner la programmation avec tel ou tel système de typage,
mais si ça vaut le coup d'enseigner quoi que ce soit à quelqu'un qui
fondamentalement s'en contrefiche.

>
> >>> 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 ?
>
>   Ben, une variable transporte une donnée,

Pas dans des langages comme Python ou Ruby etc, où une "variable" ne
"transporte" rien, puisque c'est juste un nom permettant d'accéder à
un objet dont le cycle de vie est indépendant du périmètre de
visibilité du nom en question.

> qui est un couple
> (valeur,type), un type étant l'ensemble des opérations permises
> sur le type.
>
> > 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.
>
>   Oui et non.

En schématisant, bien sûr !-)

> > 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).
>
>   Donc, de manière dynamique  et complexe, tout celà dit comment
> interpréter les bits contenus dans la variable.

Non. Encore une fois, la notion de "variable" n'a ici rien à voir avec
celle de "contenant" - contrairement à ce qui se passe en C. A moins -
ce dont je doute - que tu ne considères que, dans un programme en C,
une clé dans une table de hachage "contienne" la valeur qui lui est
associée ? Ou, pour prendre l'exemple des pointeurs, un pointeur
"contient" une adresse mémoire, mais pas ce qui est contenu à cette
adresse mémoire.

Bon, j'admets que ma vision des chose est peut-être un peu teintée par
la connaissance de l'implémentation, mais même si on fait abstraction
de ces aspects, une 'variable' Python persiste à ne rien "contenir" -
réassigner un autre objet à cette variable n'effacera pas pour autant
l'objet qui lui était précédement associé (du moins pas
systématiquement, et pas directement).  Alors qu'en C, en assignant
une nouvelle valeur à une variable, j'écrase la valeur précédemment
contenue.

>   Python fait des choses biens plus riches que le C, personne n'en
> doute.

Là n'était pas le propos. J'essaie juste d'illustrer, malgré mes
lacunes en théorie informatique, en quoi il me semble que même s'il
existe dans les deux systèmes une notion de type, je ne suis pas sûr
qu'il s'agisse vraiment du même concept. Mais bon, étant incapable
d'exprimer ça plus clairement, je vais m'en tenir là pour le
moment :-/