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.