Re: Décalage

C'est justement ce que je conteste. La notion de type est une notion technique induite par la manière dont l'ordinateur stocke les données et par l'utilisation que tu peux en faire.

Malheureusement, on ne code pas encore sur des pizzas mais sur des ordinateurs, donc savoir ce qu'est capable de faire un ordinateur pour lui donner les bonnes instructions, c'est ça la programmation.

Pour un débutant, il pourrait n'exister que deux types de données : les nombres et les chaines de caractères.

Je vais te donner un problème simple : tu as un tonneau de x litres et des bouteilles de y litres, combien de bouteilles te faut-il pour vider le tonneau ? Et bien si tu ne sais pas si ton nombre est un entier ou un flottant, tu pourrais très bien ne pas savoir résoudre ce problème.

Il ne faut pas prendre le débutant pour un débile.

Ce n'est pas mon cas, moi je veux lui apprendre les types et la manière de les choisir pour résoudre un problème, pas lui faire croire que tout est pareil et que l'ordinateur va bien se débrouiller pour comprendre ce qu'il a voulu dire. Il y a un exercice classique qu'on donne en première année, c'est la calculatrice : il faut rentrer deux nombres (donc deux variables, mettons a et b) et un opérateur (qu'on stocke dans un caractère qu'on appelle op). Et bien c'est généralement là qu'on voit ceux qui ont compris et ceux qui restent à «l'ordinateur doit comprendre ce que je lui dit». Ces derniers écrivent : res = a op b qui n'a absolument aucun sens. Et qui est du même acabit que 4 + "4" à mon avis. Et souvent, même quand on leur a expliqué, ils ont du mal à comprendre pourquoi ça ne marche pas.

C'est pareil que pour la différence entre un int et un float ; la différence n'existe qu'à cause d'une contrainte technique.

Absolument pas. Voir mon problème simple ci-dessus avec les bouteilles. C'est fondamentalement différent, même sans aller jusqu'à parler des limites des entiers ou des floats.

Mais je vois ça comme un défaut inhérent à la formalisation d'un programme, ça n'est pas intuitif, et ça n'est pas important pour comprendre la logique d'un programme.

J'insiste, un programme, ce n'est pas qu'une «logique», c'est également un choix adéquat de types et de structures de données et ce n'est pas une nouveauté !

À mon avis, l'intérêt du typage fort ne saute aux yeux qu'après des années à avoir expérimenté les bugs dus aux ambiguités du typage faible.

Ce ne sont pas des ambiguïtés, c'est une manière erronée d'apprendre les choses. Ça va beaucoup mieux dans le sens inverse : quand on a compris les types, on sait mieux utiliser les langages faiblement typés.

"C'est compliqué et ça vous gêne maintenant, mais vous verrez plus tard que c'est important" est un argument très faible ; c'est un argument d'autorité, souvent d'ailleurs employé pour justifier une pédagogie archaïque

Premièrement, ce n'est pas compliqué, c'est même plutôt naturel. Deuxièmement, ça a des applications très concrètes et très rapidement, aucun argument d'autorité derrière. On peut montrer que c'est utile (et j'ai donné deux exemples qui montrent que ça a du sens comparé à une approche trop empirique !) et que ça ne gêne personne, au contraire, ça permet d'avoir une meilleure maîtrise de ce qu'on fait.