Discussion :

[Eusebius]

Bonjour
Je me pose des questions sur les langages à typage dynamique, c'est à dire qui permettent ce genre de chose :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
a := 123
a := "Bonjour"

Les premiers que j'ai rencontrés, c'étaient des langages plutôt pour le web, genre PHP ou JavaScript, et qui pouvaient être destinés à des gens n'appartenant pas à la caste des "vrais" programmeurs. J'avais l'impression que c'était juste un truc pour éviter d'avoir des tas d'erreurs d'exécution inutiles, mais je gardais comme opinion qu'une programmation propre et saine nécessitait un typage fort.
Très récemment, j'ai découvert le langage python, et bien qu'il soit (puisse être) destiné aux applications web, il ne m'apparaît pas (pas autant que PHP en tout cas) destiné à être un langage "grand public". Et python est un langage à typage dynamique. Du coup, interrogation et doute : Y-a-t-il un avantage conceptuel au typage dynamique, qui m'aurait échappé ? J'aimerais avoir un peu votre avis...
Merci d'avance !

PS : si on pouvait éviter les avis personnels sur les langages pour s'en tenir à la question du typage...

[Eusebius]

Une idée qui me vient : est-ce que ça aurait un rapport avec le fait que tous ces langages sont à la base destinés à être interprétés ?

[richard]

il y a quelques avantages au typage dynamique :

• Pas besoin de transtypage pour contourner les types (comme en C ou en Pascal), des types simples qui peuvent être plus génériques ( ex: listes ou dictionnaires en Python)
  
  Rapidité de programmation
  
  Et surtout souplesse qui permet une évolution du programme aisée (pas besoin de recoder une partie importante du programme quand un type de donnée change, you know what I mean )
  

Il faut bien faire la différence entre le typage dynamique qui ne présente que peu de problèmes - notamment en Python puisque tout est objet en Python y compris les types de données (et oui !) - et la déclaration automatique comme dans certains langages ( VB me semble-t-il mais peut-être me tromp-je...). Ca c'est très mauvais ! (à mon avis). Quand un programme déclare de lui-même à l'exécution un type de donnée que le programmeur a "oublié" de déclarer au moment du codage alors là bonjour la maintenance ... Gros Bugs à l'horizon !

Pour Python, y'en avoir aucun problème. Python y'en a être excellent langage, demande donc à Google

[Eusebius]

Souplesse, rapidité de programmation, certes, mais est-ce que ce n'est pas une source d'erreur, quand tu codes, de ne pas savoir quel est le type de ta variable (ex. tu as oublié, ou elle a été modifiée derrière ton dos) ?
Si tu la modifies par erreur avec un truc complètement idiot, tu ne t'en rends même pas compte ?

[HRS]

dans un langage comme TCL, le typage semble dynamique. En fait, toutes
les données sont des chaînes de caractères. on peut avoir :

set titi 123
set titi "bonjour"

on peut faire des calculs sur titi, dès lors où le contenu de la chaîne
est numérique au moment ou l'instruction est exécutée. Il y a en
fait une conversion interne, transparente au programmeur

bien sûr au détriment de la performance; mais est-ce important
si cette "lenteur" est non perceptible par l'utilisateur

[richard]

tout système a à la fois des avantages et des inconvénients mais il semble juste de dire que les langages à typage fort (exemple Pascal - ISO - et Ada) sont plus pénibles à utiliser que le C ou le C++ qui sont plus permissifs. Si les pointeurs sont utilisés dans les langages compilés c'est souvent pour s'affranchir de la contraintes des types - du moins parfois.

Quant à la question que tu posais il faudrait trouver un exemple précis parce que là dans le vague et le général : "tout est dans tout et réciproquement" comme disait Pierre Dac...

Si tu fais attention à tes variables, à priori je ne vois pas où est le problème. Si une fonction modifie une de tes variables, censée être un nombre, en chaîne (string) par ex. ; à mon avis tu t'en apercevras rapidement, ou alors c'est que ça devient grave, grave.

Si tu déclares

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 a= 125

tu verras bien si ton calcul sur cette variable est cohérent ou pas, si tu as changé le type en cours de route. De plus, il te suffit d'une notation préfixée du type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 Int_a= 125
Str_nom= "toto"

pour t'y retrouver si tu n'es pas sûr de toi. C'est une discipline à se donner. Beaucoup de langages utilisant des GUI (C++, Pascal Objet Delphi etc.) utilisent une sorte de transtypage pour affecter le type de donnée entré par l'utilisateur (par défaut c'est un string).

Le typage statique de Java lui donne plus de rapidité - pas énormément non plus mais un peu quand même - mais moins de souplesse que Python, le tout est de savoir ce que tu veux. Il n'existe pas de langage parfait (ça se saurait) mais des choix qui font qu'on peut préférer un langage plutôt qu'un autre, l'idéal étant d'en maîtriser plusieurs si on en a le temps et les possibilités. Refuser à priori un langage parce qu'il utilise le typage dynamique est une attitude qui n'a pas beaucoup de sens. Il faut utiliser le langage et voir s'il correspond aux besoins et aux attentes ou pas.

Python semble avoir fait largement ses preuves, typage dynamique ou non. Il n'est pas adapté pour tous les projets, mais aucun langage ne l'est.

[Eusebius]

J'entends bien tout ce que tu me dis, mais il n'empêche : pour tout ce qui est "discipline de programmation", on a beau en avoir, lorsqu'on développe des composants qui doivent être réutilisables par une aute équipe, ou même vendus comme produit en tant que tel, on doit considérer je pense les autres programmeurs comme un client ou un utilisateur, susceptible de ne pas respecter les normes de programmation. Dans ce cas, préfixer un nom de variable ne suffit pas, et ça ne me paraît pas très sain de multiplier les tests de types à chaque fois qu'une variable est susceptible d'avoir été modifiée. Pour moi la solution se situerait plutôt dans une utilisation raisonnée de la protection et de la visibilité des objets. Je ne m'y connais pas encore suffisamment en Python pour être très sûr de moi là-dedans, donc ça m'inquiète un peu, mais j'ai l'impression que la vérité est quelque part par là...
Mais ne vous méprenez pas sur mes intentions : mon but n'a jamais été de descendre le typage dynamique, j'en fait grand usage... Et effectivement, plus j'utilise Python et plus je comprends l'utilité d'avoir des variables un peu "polymorphes"...
Bref ça s'éclaircit petit à petit, merci de votre participation !

[GnuVince]

Le typage dynamique n'est pas une grande source d'erreur à condition d'avoir des tests automatisés à jour et qui soient exécutés souvent. De plus, souvent les possibilités que ça ouvre en valent souvent la peine. Il y a bien des choses qui sont impossibles (ou du moins, très difficile) dans des langages à typage statiques qui sont triviales dans un langage dynamique.

[richard]

Je suis entièrement d'accord avec le message précédent et j'ajoute que le fait d'avoir des tests automatisés à jour decrait être une saine habitude pour tous les projets (y compris les langages à typage statique).

Le seul vrai inconvénient du typage dynamique - à condition qu'il ne soit pas confondu avec la déclaration automatique de variables (je me répète) - c'est un certain ralentissement de l'interpréteur. Mais sur les architectures actuelles, c'est preque imperceptibles pour les application "triviales". Evidemment si c'est du temps réel, là ...

[mat.M]

Bonjour ,
je pense que ce méchanisme est foncièrement et basiquement mauvais.

Avantage : grande souplesse pour programmer.
Inconvénients : comme il a été déclaré précedemment , risque très élevé de confusion pour l'utilisation et l'affectation des variables.
Sans compter une pénalisation des performances en exécution .

Je vais expliquer pourquoi :
il faut essayer de comprendre ce qui se passe au niveau du code machine ou assembleur.
Avec ce genre de facilité , on déclare
des entiers set a=128
des réels set a=12111.005558
des chaînes de caractêres set a="toto"
Et même des instances de classes.
A chaque fois en interne , il faut convertir le type de données .
Donc quelque part dans le programme il y a une procédure en code machine qui est dédiée à cela et qui affecte une valeur à une variable après avoir transformé cette valeur au format adéquat.

Or lorsqu'on fait cela dans une boucle avec nombre d'itérations élevé, c'est à chaque fois la même procédure de conversion ou transtypage qui est appelée ce qui peut demander du temps selon le type de données.
D'où diminution des performances du programme ;
Je ne veux pas relancer un éniéme débat sur VB mais c'est du vécu sur un projet professionnel en VB avec utilisation de variant .

Mais parfois on est obligé à avoir recours à ce type de méchanisme ; notamment avec des curseurs sur une table de base de donées ( comme les "recordset" avec Microsoft) .
Par exemple Microsoft a crée le type VARIANT en C++ /COM ou variant en VB.

et la déclaration automatique comme dans certains langages ( VB me semble-t-il mais peut-être me tromp-je...). Ca c'est très mauvais ! (à mon avis).

Oui tout à fait d'accord , cf au-dessus

[doof]

Je suis pas sur que le typage dynamique soit la vrai source de problemes.

Les risques de confusion interviennent si un language est faiblement typé, dans lequel cas, il ferat un transtypage automatiquement => sources de problemes.

Dans le cas de python (je debute, donc je peux me tromper), apparement, bien que le typage soit dynamique, il reste néamoins fortement typé, contrairement a VB. Le typage automatique se fait a la declaration, s'il doit y avoir un transtypage apres, il doit se faire manuellement, ca me parait etre un bon compromis, il allie le meilleur des chaques méthodes.

J'ai trouvé cette explication dans "dive into python" qui est librement téléchargeable :

En Java, C++ et autres langage à typage statique, vous devez spécifier les types de données de la valeur de retour
dune fonction ainsi que de chaque paramètre. En Python, vous ne spécifiez jamais de manière explicite le type de
quoi que ce soit. En se basant sur la valeur que vous lui assignez, Python gère les types de données en interne.
Addendum. Un lecteur erudit propose lexplication suivante pour comparer Python et les autres langages de
programmation :

langage à typage statique
Un langage dans lequel les types sont fixés à la compilation. La plupart des langages à typage statique
obtiennent cela en exigeant la déclaration de toutes les variables et de leur type avant leur utilisation. Java et C
sont des langages à typage statique.
langage à typage dynamique
Un langage dans lequel les types sont découverts à lexécution, linverse du typage statique. VBScript et
Python sont des langages à typage dynamique, ils déterminent le type dune variable la première fois que
vous lui assignez une valeur.
langage fortement typé
Un langage dans lequel les types sont toujours appliqués. Java et Python sont fortement typés. Un entier ne
peut être traité comme une chaîne sans conversion explicite (nous verrons plus loin dans ce chapitre comment
le faire).
langage faiblement typé
Un langage dans lequel les types peuvent être ignorés, linverse de fortement typé. VBScript est faiblement
typé. En VBScript, vous pouvez concaténer la chaîne '12' et lentier 3 pour obtenir la chaîne '123', et
traiter le résultat comme lentier 123, le tout sans faire de conversion explicite.

Python est donc à la fois à typage dynamique (il nutilise pas de déclaration de type explicite) et fortement typé (une
fois quune variable a un type, cela a une importance).

Donc un language a typage dynamique n'empeche pas d'etre fortement typé, et dans ce cas, je vois mal d'où pourrait venir la confusion.

L'execution serat peut-etre plus lente et c'est peut etre pour ca que les languages de scripts en général (où la rapidité n'est pas la priorité) ont un typage dynamique.

[GnuVince]

L'execution serat peut-etre plus lente et c'est peut etre pour ca que les languages de scripts en général (où la rapidité n'est pas la priorité) ont un typage dynamique.

Pas vraiment. Regarde certaines implémentation de Common Lisp (notamment SBCL et CMUCL) qui sont plus rapides dans certains tests que le C. Un typage dynamique n'empêche pas du tout une rapidité d'exécution.

[Guigui_]

J'espère ne pas dire une énormité, mais l'avantage du typage dynamique, c'est qu'on peut programmer une unique fonction qui prend un paramètre qui peut être de tout type, ce qui se rapprocherait du template du C++. Moi qui suit plus un programmeur en Delphi, dès que je veux créer une fonction qui utilise par exemple des tableaux d'entiers, de doubles ..., je suis obligé recréer plusieurs fois la même fonction en changeant simplement la déclarationdu type. Ca fait une surcharge de code assez inutile je trouve.

[Yabo]

J'espère ne pas dire une énormité, mais l'avantage du typage dynamique, c'est qu'on peut programmer une unique fonction qui prend un paramètre qui peut être de tout type, ce qui se rapprocherait du template du C++. Moi qui suit plus un programmeur en Delphi, dès que je veux créer une fonction qui utilise par exemple des tableaux d'entiers, de doubles ..., je suis obligé recréer plusieurs fois la même fonction en changeant simplement la déclarationdu type. Ca fait une surcharge de code assez inutile je trouve.

Et dieu (Bjarne Stroustrup ) inventa le template<> comme tu le dis

[MelloW]

un autre avantage du typage dynamique:
- on peut créer des tableaux, listes, etc. de ce style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[["toto1" , 1],["toto2",2],..]

-> donc des strings et des chiffres dans le même tableau.
En C++ on est obligé d'utilser des "void*" et de type-caster vers le bon type -> ce qui peut être source de problèmes.
En Java on est obliger d'utiliser des tableaux d"Object" pour ce genre de choses.
Sinon pour en revenir aux inconvénients de mat.M:

Inconvénients : comme il a été déclaré précedemment , risque très élevé de confusion pour l'utilisation et l'affectation des variables.
Sans compter une pénalisation des performances en exécution .

- l'affectation des variables se fait éssentielement dans les langages impératifs (OO (c++, java, etc.), et procédural (c, etc.)). Dans les langages fonctionnels par exemple les affectations sont quasiment inéxistentes, donc le problème des affectations ne s'y pose presque pas.
- en ce qui concerne les performances je serais pas si sûr -> http://shootout.alioth.debian.org/craps.php
scheme et common lisp (tout 2 avec typage dynamique) sont dans le top des langages les lpus performants.
- puis finalement il existe des techniques de programmation pour éviter le genre de problème créer par le typage dynamique -> tests unitaires, mock objects, etc. dans lequel on testerait le type des variables.