Discussion :

[yahiko]

Le typage faible évite d'écrire les conversions explicites il me semble. Est-ce faux ?

Sinon, le typage faible qui est le sujet du topic, dans tout le discours qui est utilisé par l'auteur dans son premier post engloble non seulement le typage faible au sens fort () du terme, mais aussi le typage dynamique.

Je ne pense pas qu'il soit nécessaire de s'offusquer pour si peu sur une utilisation large du mot faible dans ce topic, d'autant que pour ma part je souhaitais surtout rebondir sur la notion de performance qui avait été mentionnée juste avant.

[Loceka]

Si l'on choisit un langage fortement typé, on va contraindre chaque variable sur un type. Le contrôle du typage sera donc implicite. Mais il sera quand même nécessaire de catcher les erreurs de type et de les traiter.

Non, il n'y a rien besoin de catcher vu que ça plante à la compilation, pas à l'exécution.

Les seuls moments où tu as besoin de catcher sont lorsque tu "castes" un type en un autre type (String en int par exemple) car là il peut y avoir des valeurs non définies (l'ensemble des String n'a pas forcément d'équivalent sur l'ensemble des entier).

[grim7reaper]

Le typage faible évite d'écrire les conversions explicites il me semble. Est-ce faux ?

Certes.
Cela dit, même lorsque je programme dans des langages à typage plutôt fort, j’ai rarement des conversions explicites dans tout les sens (si c’est le cas, ça sent le code foireux de base).

Sinon, le typage faible qui est le sujet du topic, dans tout le discours qui est utilisé par l'auteur dans son premier post engloble non seulement le typage faible au sens fort () du terme, mais aussi le typage dynamique.

Ce n‘est pas parce que l’auteur fait un amalgame erroné qu’il faut le faire aussi.

Je ne pense pas qu'il soit nécessaire de s'offusquer pour si peu sur une utilisation large du mot faible dans ce topic, d'autant que pour ma part je souhaitais surtout rebondir sur la notion de performance qui avait été mentionnée juste avant.

Je ne m‘offusque pas, je remarque.
Car j’ai souvent l’impression que les gens mélange un peu les notions de typage faible/fort avec les notions de typage statique/dynamique.
Donc quand je vois des trucs pas clair, je relève. Histoire de clarifier les choses et de ne pas contribuer à cet amalgame

[yahiko]

Certes.
Cela dit, même lorsque je programme dans des langages à typage plutôt fort, j’ai rarement des conversions explicites dans tout les sens (si c’est le cas, ça sent le code foireux de base).

Peut-être, mais en même temps, les conversions implicites en JS sont bien utiles quand tout ce que renvoie les fonctions DOM pour parser le HTML ce sont des chaînes de caractères qu'il faudrait caster régulièrement en nombre en cas de typage fort par exemple.

Ce n‘est pas parce que l’auteur fait un amalgame erroné qu’il faut le faire aussi.

Je ne m‘offusque pas, je remarque.
Car j’ai souvent l’impression que les gens mélange un peu les notions de typage faible/fort avec les notions de typage statique/dynamique.
Donc quand je vois des trucs pas clair, je relève. Histoire de clarifier les choses et de ne pas contribuer à cet amalgame

Même si ce sont deux concepts distincts sur le plan technique, ils restent liées puisqu'il s'agit d'apporter une facilité syntaxique pour le développeur sur la notion de type.

Quand on a dans du code

Code :

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

a = 1

puis plus loin (même scope)

Code :

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

a = "1"

un nouveau langage pourrait résoudre le problème à la fois par la conversion implicite de 1 (nombre) en "1" (chaine) ou par le typage dynamique de la variable a de nombre à chaine.

Sinon à titre d'infos, j'ai trouvé cette définition de typage faible sur ce forum
http://dico.developpez.com/html/1653...age-faible.php

Typage par lequel on autorise le programme à stocker des valeurs dont le type de données diffère (au moins légèrement) de celui définit initialement pour une variable. Ainsi, l'espace mémoire stockant la valeur pourra varier au cours de l'exécution du programme.

L'information de type d'une variable est stockée avec la valeur, nécessitant alors une glus grande quantité de données pour son stockage en mémoire. Cette information supplémentaire a également tendance à ralentir tout traitement de la valeur.

Comme quoi, la notion de typage faible n'a pas qu'une seule et unique définition.

[Uther]

Le pire code que j'ai vu jusque là, c'est pas en JS ou PHP, mais en Java. Le typage fort n’empêche pas de faire n'importe quoi. Si le dév est mauvais, quelque soit le langage, ça peut vite tourner à la catastrophe...

J'ai aussi vu beaucoup d'horreurs en Java, mais c'est plutôt exceptionnel alors que j'ai l'impression que c'est la norme en JS.
Avoir un langage qui donne des cadres plus strict aide quand même bien à avoir du code propre.

Personnellement quand je parle à des développeur web de POO alors catastrophe (trop compliqué, KISS my app ... ). Quand je parle de Design Pattern j'ai l'air d'un extra-terrestre . Quand je parle d'héritage, c'est l'apocalyse complet . Alors le polymorphisme Kezako ... .

Je pense qu'il va falloir t'inquiéter un peu du niveau de compétence de ta boite. La POO n'est certes pas l'alpha et l'oméga de l'informatique, mais si ça parait hors de porté de tes collègues, je m’inquiéterais vraiment du niveau de compétence.

Si l'on choisit un langage fortement typé, on va contraindre chaque variable sur un type. Le contrôle du typage sera donc implicite. Mais il sera quand même nécessaire de catcher les erreurs de type et de les traiter.

La principale différence s'est que les problèmes de typage seront détecté à la compilation et que le développeurs sera obligé de les corriger pour que l'application compile. Avec un langage dynamique le programme pourrait donner l'illusion de bien fonctionner puis se mettre a planter dans un cas particulier que le programmeur n'aurait pas pensé à gérer.

Jusqu'à présent, la seule différence notable que j'ai vu, c'est dans l'art et la manière de ne pas gérer erreurs de type. Dans un langage comme Perl, on ne fait rien et on voit ce qui se passe. Dans un langage comme Java, on catche les erreurs et on les masque pour que le programme ne plante surtout pas à l'exécution...

Java a fait sont boulot en te montrant l'endroit ou il y avait l'exception, si tu choisis de l'ignorer c'est soit que tu as une bonne raison (c'est rare mais ca peux arriver), soi que tu es un idiot qui espère que ça ne te retomberas pas dessus.
Bref ignorer les exception en Java est certes possible, mais ce n'est clairement pas a faire, et heureusement pas la pratique habituelle.

Dans tout les cas, pour moi ce sont des erreurs de conception et de développement.

Bien sur que c'est des erreurs, mais je n'ai pas encore croisé de développeur qui ne faisait pas d'erreur. Alors quand on a un moyen de détecter facilement tout une classe d'erreurs très courante, c'est un gros plus.

Tout ça pour poser cette simple question : en quoi le typage (fort, faible, statique, dynamique) est-il un critère pour définir si un langage est bon ou mauvais, sachant qu'un bon concepteur/développeur sera toujours capable de produire un code propre et fonctionnel quelque soit le langage ?

Le bon développeur est une denrée bien plus rare que l'on ne le croit et même les meilleurs ne sont pas infaillibles.
Enfin il y a d'autre problématiques comme les performances évoquées ci-dessus.

[asfez]

"Un grand pouvoir implique de grandes responsabilités." C'est le cas avec javascript.

A propos du typage fort/faible, il me semble que ce concept s'applique plutôt à des langages compilés. En tout cas pas à un langage ou une variable est déclarée sans type. De mon point de vue, les variables n'ont jamais de type en javascript, ce sont simplement des pointeurs vers des objets. Les conversions implicites n'ont pas lieu entre des variables mais entre des objets.

On ne peut pas non plus comparer le "var" de c# avec celui de javascript. Celui de c# est du sucre syntaxique, le type est déduit mais est déterminé.

[ptah35]

La principale différence s'est que les problèmes de typage seront détecté à la compilation et que le développeurs sera obligé de les corriger pour que l'application compile. Avec un langage dynamique le programme pourrait donner l'illusion de bien fonctionner puis se mettre a planter dans un cas particulier que le programmeur n'aurait pas pensé à gérer.

C'est vrai, mais selon mon expérience, un langage à typage statique peut également donner un faut sentiment de sécurité; le seul fait qu'il n'y ait pas d'erreur de type n'implique pas que le programme soit correct et les erreurs de programmation les plus graves sont rarement des erreurs détectables par un compilateur.

Le typage statique a certes des avantages, mais je ne pense pas que l'on puisse démontrer qu'il y ait plus d'erreurs par ligne avec un langage à typage dynamique qu'avec un langage à typage statique.

Enfin, puisque c'est sujet, qu'il s'agisse d'un langage à typage statique ou dynamique, je suis partisan d'un typage aussi fort que possible et JavaScript n'a, encore une fois, définitivement pas un typage fort.

[Uther]

Je n'ai jamais dit qu'il n'y avait pas d'erreur du tout, juste pas d'erreur de typage au moment de l’exécution ce qui est déjà un énorme avantage.

[ptah35]

Je n'ai jamais dit qu'il n'y avait pas d'erreur du tout [...]

Et moi je n'ai jamais dis que vous aviez dit cela; j'ai juste rebondi sur un argument très souvent avancé en faveur des langages à typage statique et cet argument est tout à fait valable.

[...] juste pas d'erreur de typage au moment de l’exécution ce qui est déjà un énorme avantage.

Et c'est là toute la question : est-ce vraiment un "énorme avantage"? Comme je l'écrivais, il n'y a à ma connaissance pas de démonstration qu'un langage à typage statique permet de réduire le nombre d'erreurs par ligne par rapport à un langage à typage dynamique et il se trouve que les fautes les plus graves ne sont pas de cet ordre.

Je suis bien sûr d'accord pour dire qu'avoir une exception à l'exécution à cause d'un problème de type n'est, pour dire le moins, pas une bonne chose, mais la compilation n'est pas seul phase de la construction du logiciel dans laquelle cela peut être vérifié. Si les tests sont complets et conformes à la spécification, il permettent de détecter ce genre d'erreurs de manière tout aussi efficace. En outre, une batterie de tests unitaires bien faite favorise bien plus la maintenance et la documentation que la spécification de types, même si, je l'admets volontiers, cette dernière est un apport appréciable.

[sjrd]

C'est évident, JavaScript est un langage fortement dynamiquement typé. Ces deux concepts sont orthogonaux :

• JavaScript : fortement dynamiquement typé
• Java : fortement statiquement typé
• C/C++ : faiblement statiquement typé
• Assembleur x86_64 : faiblement dynamiquement typé

Un langage est statiquement typé si et seulement si le compilateur vérifie que toutes les manipulations des variables correspondent à un type system non trivial [1] donné, en supposant qu'il n'y a pas de cast non vérifiés au runtime (il peut y avoir des conversions). Si le type system est valide (sound en anglais), alors il ne peut y avoir d'erreur de type au runtime, par construction (il existe des type systems non valides, comme celui de TypeScript). C++ est donc statiquement typé, ainsi que Java, mais bien entendu, pas JavaScript, ni l'Assembleur (puisque RAX peut contenir tantôt un entier, tantôt un flottant, tantôt un pointeur).

Un langage est faiblement typé si et seulement si les casts non vérifiés au runtime sont autorisés. C++, par exemple, a des casts non vérifiés. Java, bien qu'ayant des casts, est fortement typé car tous les casts sont vérifiés valides au runtime.
JavaScript n'a pas du tout de cast (il n'a que des conversions), donc a fortiori tous ses casts sont vérifiés.

Les langages faiblement dynamiquement typés sont très rares, car la seule chose qui permet au runtime de "savoir" comment considérer telle ou telle donnée, c'est par les opérations appliquées dessus. C'est ainsi que l'assembleur a des opérations différentes pour multiplier deux entiers signés ou deux entiers non signés.

Je terminerai en précisant que tout ceci n'a rien à voir avec les conversions, et en particulier le fait qu'elles soient implicites ou explicites. Scala, par exemple, supporte les conversions implicites (même définies par le programmeur), pourtant je pense que personne n'oserait prétendre que Scala n'est pas un langage fortement statiquement typé.

[1] Par non trivial, j'entends un type system avec au moins deux types de données. Sinon on peut dire que même JavaScript est statiquement typé, avec un type system composé d'un unique type de données, qui supporte toutes les opérations de l'univers.

[Uther]

Et c'est là toute la question : est-ce vraiment un "énorme avantage"? Comme je l'écrivais, il n'y a à ma connaissance pas de démonstration qu'un langage à typage statique permet de réduire le nombre d'erreurs par ligne par rapport à un langage à typage dynamique et il se trouve que les fautes les plus graves ne sont pas de cet ordre.

Personnellement le fait que plus un langage se veut souple, plus on se retrouve avec des comportements imprévus à l'exécution est un constat que je fais tous les jours.
Certes il n'est pas chiffrable facilement, mais je ne connais pas grand monde qui pratique divers langages régulièrement qui m'ait soutenu l'inverse.

Si les tests sont complets et conformes à la spécification, il permettent de détecter ce genre d'erreurs de manière tout aussi efficace. En outre, une batterie de tests unitaires bien faite favorise bien plus la maintenance et la documentation que la spécification de types, même si, je l'admets volontiers, cette dernière est un apport appréciable.

Qu'est ce qui vous fait croire que les tests unitaires seraient moins poussés dans un langage plus strict?
Au contraire, la rédaction des tests unitaires est bien plus facile et donc moins sujet aux oublis/erreurs quand les types en entrée et sortie sont clairement définis.

Si vous réimplémentez les vérifications sur le type qu'aurait fait un compilateur dans vos test, au final vous revenez au même point qu'avec un langage fortement typé, sauf que vous gérez ça manuellement ce qui deviens vite fastidieux et rajoute le risque de se tromper.

[yahiko]

Un langage est faiblement typé si et seulement si les casts non vérifiés au runtime sont autorisés. C++, par exemple, a des casts non vérifiés. Java, bien qu'ayant des casts, est fortement typé car tous les casts sont vérifiés valides au runtime.
JavaScript n'a pas du tout de cast (il n'a que des conversions), donc a fortiori tous ses casts sont vérifiés.

Certains points de ton post sont intéressants, ça me rappelle certains cours... ^^. J'aurais aimé savoir pour ma culture la source sur laquelle tu te bases pour ta définition de langage faiblement typé.

[Darktib]

La définition de sjrd me semble assez intéressante et claire.

JavaScript n'a pas du tout de cast (il n'a que des conversions), donc a fortiori tous ses casts sont vérifiés.

C'est inexact. S'il n'y a pas de cast, alors tous les casts sont à la fois vérifiés et non vérifiés (l'ensemble des casts étant l'ensemble vide). Ils sont aussi autorisés et non autorisés.

Il en ressort que Javascript est à la fois faiblement et fortement typé (ce qui risque de faire plaisir à tout le monde )


Plus sérieusement, avec cette définition:

Code :

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

faiblement typé <=> (pour tout cast X, X non vérifié au runtime => autorisé)

La deuxième partie étant toujours vraie pour Javascript, la première l'est aussi. Donc cette définition implique que Javascript est faiblement typé. CQFD

[ptah35]

Qu'est ce qui vous fait croire que les tests unitaires seraient moins poussés dans un langage plus strict?

Absolument rien et ce n'est certainement pas le cas dans les projets dont j'ai la charge. Ce que je veux dire c'est que les erreurs qui peuvent être détectées par le compilateur d'un langage statiquement typé sont des erreurs relativement mineures et que dans tous les cas une batterie de tests est nécessaire. De plus les tests sont sensiblement les mêmes que le langage soit dynamiquement ou statiquement typé et s'ils sont complets, dans tous les cas, la passation des tests impliquera l'absence d'erreur de type (puisque le domaine d'utilisation sera couvert). Il n'y a donc pas plus de vérifications manuelles à faire dans le cas d'un langage dynamiquement typé.

En outre, un certain nombre d'erreurs de type potentielles sont crées par les limites de la plupart des langages à typage statique (covariance/contravariance) et n'auraient aucune raison d'être.

Loin de moi l'idée de dire que le typage dynamique est meilleur que le typage statique, mais je ne peux pas non plus me résoudre à affirmer l'inverse du moins en ce qui concerne la qualité du code (un peu malgré moi d'ailleurs, puisque ma préférence va tout de même aux langages à typage statique). Une chose est certaine cependant, c'est que dans les deux cas un typage fort est souhaitable et pour en revenir au sujet de la discussion, JavaScript est loin d'être un langage fortement typé.

[TiranusKBX]

il ne doit pas y avoir d'identification du typage fort ou faible sur la base de la syntaxe du langage mais sur la spécificité à la compilation de ce fait si vous ne regardez pas comment fonctionne le compilateur javascript inutile de commenter et donc vous ne savez rien ! c'est trop facile de troller avec des fait non vérifié preuve à l'appuis

[guythom]

Le typage est l'essence de l'info pro
Soyons clair si l'ordi ne pouvait distingué
1 et 1.0 l'informatique ce du non sens et ne serait pas aussi efficace pour
les calculs scientifiques
Un langage script restera un langage script
Et JS à la base est un langage script
Ce n'est donc pas suprenant qu'il ait les défauts de tous les langages script:
"Impossible d'y developper une appli puissante et serieuse meme en compilation native avec optimisation
JavaScript n'est pas fortement typé
Que celui veut parler de typage aille voir Java , C/C++,Ada et Objective C

[sekaijin]

Personnellement je ne me prononcerais pas.
Pour moi, ce n'est pas une question.

Certains voient dans le mécanisme de typage de JS un problème.
Moi j'y vois une force.

D'ailleurs ce que fait naturellement JS est très péniblement reproduit avec des langages dits fortement typés. par exemple l'API réflexion de java ou le runtime Objective-C
Tous deux n'ont pour but que de passer outre les contraintes du modèle de programmation à base de classes.

Je ne me pose donc pas la question de savoir si, oui ou non, le langage est fortement typé. JS est un langage ou les définitions sont dynamiques et une fois qu'on a compris ça il suffit d'en tirer parti.

Tout comme lorsque j'utilise les langages à base de classe j'essaie de tirer, le meilleur partit du modèle de langage à base classes.
Lorsque j'utilise EcmaScript j'utilise au mieux la définition dynamique et la notion de prototype.

Pour moi, JS est un tas de références.
Une variable est une référence sur un objet comme en C++.
Lorsqu'on référence un autre objet (avec le même nom), il est logique que le type de l'objet ne soit pas nécessairement le même.

Est-il important qu'un nom de variable soit contraint à ne référencer qu'un seul type d'objet ?

Si cela peut être utile, il est tout aussi pertinent de ne pas avoir cette contrainte.
Car au final lorsque le langage impose ce genre de contrainte on en vient à la contourner.
Par exemple en java en utilisant la classe Object pour référencer tout et n'importe quoi.

Alors, tirez le meilleur de chaque langage et faites des caractéristiques de chacun une force.

A+JYT

[ptah35]

Je ne me pose donc pas la question de savoir si, oui ou non, le langage est fortement typé. JS est un langage ou les définitions sont dynamiques et une fois qu'on a compris ça il suffit d'en tirer parti.

Si je suis d'accord avec vous à propos des forces de JavaScript, je pense que vous passez à côté de la question. JavaScript est un langage dynamiquement typé et en ce qui me concerne ce n'est pas du tout une mauvaise chose. Cependant un langage à typage dynamique peut être également fortement typé en évitant les conversions implicites.

Par exemple, JavaScript accepte que l'on utilise des opérandes de types différents avec les opérateurs arithmétiques :

Code :

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

1
2
3
 
var p;
p = "2" * 2;

La chaîne "2" est implicitement convertie en numérique avant que la multiplication soit effectuée et le résultat affecté à p. Essayons maintenant une expression un peu plus complexe :

Code :

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

1
2
3
 
var res;
res = ("2" + 2) * 2;

on se trouve cette fois avec un comportement étrange puisque res ne contient pas 8 comme on serait en droit de l'attendre, mais 44. Ce comportement est bien sûr facilement explicable : l'opérateur + est utilisé à la fois comme opérateur arithmétique et comme opérateur de concaténation et cet c'est dernière opération qui a été effectuée. Mais pourquoi le "2" n'a-t-il pas été converti en numérique comme pour le produit ? La réponse se trouve dans l'arbitraire de la spécification du langage et c'est là tout le problème. Sans conversion implicite, ces instructions ne seraient pas valides. Ce serait alors au programmeur d'effectuer les conversions nécessaires, ce qui aurait pour effet de rendre le code moins ambigu.

Code :

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

1
2
3
 
var res;
res = (parseInt("2") + 2) * 2;

Je suis le premier à défendre JavaScript et à reconnaître ses qualités -- ne serait-ce que parce qu'il est incontournable et que par principe, lorsque je n'ai pas ce que j'aime, je m'applique à aimer ce que j'ai -- mais le choix qui a été fait de faire des conversions implicites, peut-être avec l'intention louable de simplifier la vie du programmeur, a finalement pour effet de la lui rendre plus difficile.

[drazikh]

Je ne vois pas en quoi le dernier exemple prouve quoi que ce soit. J'espère bien qu'appliquer une méthode à mon tableau ne va pas modifier son type... Pour moi c'est un comportement tout à fait normal.

[sekaijin]

ce dernier exemple montre que js est comme tout langage il possède quelques pièges

l'opérateur + existe pour les nombres et effectue une somme et pour les chaines où il effectue une concaténation.
alors que l'opérateur * n'existe que pour les nombres.

Cela associé au transtypage automatique peut amener le developpeur peu au fait du langage à des erreurs.

perso je préfèrerais que dans tous les langages il n'y ait pas de distinction entre les types primitifs et les autres.

il en va ainsi de tous les langages.

en C++ par exemple a + b est en fait l'appel de la methode operator + sur l'objet a pareil pour a == b une erreur fréquente est d'oublier qu'on ne peux pas appliquer une methode à l'objet null.

pour moi le fait de pouvoir écrire se genre de choses (tout comme l'exemple ci dessus) c'est du sucre syntaxique. et je serais tout aussi disposer à m'en passer.

mais avouons le, nous aimons en écrire le moins possible
A+JYT