+ Répondre à la discussion Actualité déjà publiée
  1. #41
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 095
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 095
    Points : 5 930
    Points
    5 930
    Billets dans le blog
    39

    Par défaut

    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.
    Tutoriels et FAQ TypeScript

  2. #42
    Expert confirmé
    Avatar de Loceka
    Profil pro
    Inscrit en
    mars 2004
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2004
    Messages : 2 096
    Points : 4 223
    Points
    4 223

    Par défaut

    Citation Envoyé par jfchretien Voir le message
    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).

  3. #43
    Membre éclairé
    Inscrit en
    juillet 2012
    Messages
    228
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 228
    Points : 857
    Points
    857

    Par défaut

    Citation Envoyé par yahiko Voir le message
    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).

    Citation Envoyé par yahiko Voir le message
    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.

    Citation Envoyé par yahiko Voir le message
    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

  4. #44
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 095
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 095
    Points : 5 930
    Points
    5 930
    Billets dans le blog
    39

    Par défaut

    Citation Envoyé par grim7reaper Voir le message
    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
    puis plus loin (même scope)
    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.
    Tutoriels et FAQ TypeScript

  5. #45
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 467
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 467
    Points : 7 992
    Points
    7 992

    Par défaut

    Citation Envoyé par Zefling Voir le message
    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.

    Citation Envoyé par koyosama Voir le message
    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.

    Citation Envoyé par jfchretien Voir le message
    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.

    Citation Envoyé par jfchretien Voir le message
    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.

    Citation Envoyé par jfchretien Voir le message
    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.

    Citation Envoyé par jfchretien Voir le message
    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.

  6. #46
    Membre régulier
    Homme Profil pro
    Directeur technique
    Inscrit en
    novembre 2004
    Messages
    56
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2004
    Messages : 56
    Points : 113
    Points
    113

    Par défaut

    "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é.

  7. #47
    Membre éclairé
    Homme Profil pro
    Enseignant
    Inscrit en
    décembre 2007
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Suisse

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2007
    Messages : 205
    Points : 825
    Points
    825

    Par défaut

    Citation Envoyé par Uther Voir le message
    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.

  8. #48
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 467
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 467
    Points : 7 992
    Points
    7 992

    Par défaut

    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.

  9. #49
    Membre éclairé
    Homme Profil pro
    Enseignant
    Inscrit en
    décembre 2007
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Suisse

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2007
    Messages : 205
    Points : 825
    Points
    825

    Par défaut

    Citation Envoyé par Uther Voir le message
    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.

    Citation Envoyé par Uther Voir le message
    [...] 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.

  10. #50
    Expert éminent

    Avatar de sjrd
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    juin 2004
    Messages
    4 514
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Suisse

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 4 514
    Points : 9 989
    Points
    9 989

    Par défaut

    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.
    sjrd, ancien rédacteur/modérateur Delphi, désormais membre de l'équipe Scala à l'EPFL en tant que doctorant.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript.
    Découvrez Mes tutoriels, ou mon logiciel phare FunLabyrinthe v5.3 : un jeu de labyrinthe gratuit et personnalisable à l'infini avec des scripts Delphi-like.

  11. #51
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 467
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 467
    Points : 7 992
    Points
    7 992

    Par défaut

    Citation Envoyé par ptah35 Voir le message
    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.

    Citation Envoyé par ptah35 Voir le message
    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.

  12. #52
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 095
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 095
    Points : 5 930
    Points
    5 930
    Billets dans le blog
    39

    Par défaut

    Citation Envoyé par sjrd Voir le message
    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é.
    Tutoriels et FAQ TypeScript

  13. #53
    Membre averti Avatar de Darktib
    Profil pro
    Inscrit en
    mai 2009
    Messages
    45
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2009
    Messages : 45
    Points : 377
    Points
    377

    Par défaut

    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

  14. #54
    Membre éclairé
    Homme Profil pro
    Enseignant
    Inscrit en
    décembre 2007
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Suisse

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2007
    Messages : 205
    Points : 825
    Points
    825

    Par défaut

    Citation Envoyé par Uther Voir le message
    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é.

  15. #55
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS
    Inscrit en
    avril 2013
    Messages
    1 304
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2013
    Messages : 1 304
    Points : 4 303
    Points
    4 303
    Billets dans le blog
    6

    Par défaut

    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

  16. #56
    Candidat au Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    octobre 2012
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2012
    Messages : 7
    Points : 2
    Points
    2

    Par défaut

    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

  17. #57
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 931
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 931
    Points : 8 226
    Points
    8 226

    Par défaut

    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

  18. #58
    Membre éclairé
    Homme Profil pro
    Enseignant
    Inscrit en
    décembre 2007
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Suisse

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2007
    Messages : 205
    Points : 825
    Points
    825

    Par défaut

    Citation Envoyé par sekaijin Voir le message
    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.

  19. #59
    Candidat au Club
    Profil pro
    Inscrit en
    août 2013
    Messages
    1
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2013
    Messages : 1
    Points : 4
    Points
    4

    Par défaut

    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.

  20. #60
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 931
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 931
    Points : 8 226
    Points
    8 226

    Par défaut

    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

Discussions similaires

  1. Réponses: 30
    Dernier message: 20/09/2012, 15h25
  2. Réponses: 9
    Dernier message: 27/02/2010, 22h15
  3. Réponses: 2
    Dernier message: 15/01/2010, 18h52
  4. Réponses: 2
    Dernier message: 15/01/2010, 18h52
  5. Réponses: 1
    Dernier message: 05/10/2007, 18h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo