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).
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.
>> 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).
>> 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.
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.
> 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 ?
>>> 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.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)