Bovino 
Bah moi je m'en moque et je trouve que ce sujet ressemble un peu un troll.
Pour ma part, développer en javascript est très amusant et je pas n'ai du tout envie qu'il finisse un jour par ressembler à C# ou Java.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Bah moi je m'en moque
Bah moi je m'en moque et je trouve que ce sujet ressemble un peu un troll.
Pour ma part, développer en javascript est très amusant et je pas n'ai du tout envie qu'il finisse un jour par ressembler à C# ou Java.
Bonjour,
A la lecture de vos différents posts, il me vient une petite réflexion sur les problématiques de typages. Et j'avoue que cela me laisse assez perplexe.
Si je comprend bien, les typages forts sont principalement des contraintes que l'on retrouve dans les langages objet natif (Java, ...)
A contrario, les typages faibles se retrouvent plus dans les langages de script (Javascript, Perl, ...)
Ce que je ne comprend pas, c'est en quoi le typage fort/faible influe sur la qualité du code produit... Je m'explique. Pour moi, les contraintes sur les types se définissent dès la conception (dans un truc du genre modèle de données) et constituent des contraintes fonctionnelles.
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.
Si l'on choisit un langage faiblement typé, on va devoir implémenter les contrôles sur les types et la gestion des erreurs.
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...
Dans tout les cas, pour moi ce sont des erreurs de conception et de développement.
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 ?
Merci d'avance de vos réponses, ça m'aidera à y voir plus clair.
La question n'est pas est-ce que les langages a typages fort sont meilleurs que les langages a typages faibles, mais est-ce que JS est un langage a typage fort?
Pour t'as question, ça dépend surtout des développeurs et du genre d'appli que tu veux construire.
Certaines aiment quand tout est carré, tu déclare un int, tu met que des int dedans. D'autres aiment pouvoir mettre ce qu'ils veulent dans n'importe quelle variable.
Je vois quand même quelques avantages au typage fort. D'une part évidement côté développement pour éviter certains bugs à cause de conversions implicites hasardeuses ou d'absences (oubli) d'erreurs à l'exécution.Envoyé par jfchretien
D'autre part pour des raisons d'optimisation. Tu peux choisir un short plutôt qu'un int pour un petit nombre, et gagner en consommation mémoire. Tout type de données prend de la place en mémoire.
Enfin, pour certaines personnes pas à l'aise avec le langage, elles peuvent faire des gros bricolages pour contourner ces problèmes. Bricolages pas forcément performants ou fiables.
Juste pour ajouter mon petit grain de sel à ce sympathique "troll" ^^, n'oublions pas non plus que le typage fort et statique permet l'Ahead Of Time compilation, ce qui apporte de sensibles gains de performances (cf. asm.js)
De l'autre côté, l'avantage du typage faible et dynamique à la Javascript, c'est la rapidité et la concision pour le développeur de rédiger de petites fonctions, ce qui est tout à fait adapté au cas général des pages Web pour lequel il a été conçu. Pas besoin de déclarer ses variables à l'avance, pas besoin de typer ses variables, pas besoin de donner une signature à ses fonctions. Tant que le programme ne dépasse pas l'ordre de quelques milliers de lignes, le typage faible a tout à fait sa place.
Maintenant, à une plus grande échelle, on se retrouve face à un problème de confiance envers le code, et ce, malgré toutes les relectures attentives et les tests unitaires effectués. D'où l'utilité de solutions complémentaires comme CoffeeScript, TypeScript pour adresser le problème des erreurs de typages ou encore, emScriptem (C++ -> JS) et asm.js pour la problématique des performances.
Ça c‘est du typage dynamique, on peut faire la même chose en Python et Ruby.
Le typage faible n’a rien à voir avec les exemples que tu cites.
Et on peut même retrouver ça, dans une certaine mesure, avec du typage statique, pour peu qu’il y ai de l’inférence de type.
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).
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.
Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur technique du Scala Center à l'EPFL.
Découvrez Mes tutoriels.
La définition de sjrd me semble assez intéressante et claire.
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.JavaScript n'a pas du tout de cast (il n'a que des conversions), donc a fortiori tous ses casts sont vérifié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: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
Code : Sélectionner tout - Visualiser dans une fenêtre à part faiblement typé <=> (pour tout cast X, X non vérifié au runtime => autorisé)
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
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
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
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 :
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
2
3
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
2
3
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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
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.
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
Expliquer le typage fort par le fait que on peut "additionner des nombres et des chaines!" ne suffit pas à caractériser un typage fort ou faible dans la mesure où il y a utilisation d'un opérateur qui, surchargé, définit un type de retour indépendamment de la nature de la variable de stockage. Un typage fort veut dire qu'une fois que l'on a assigné un type à une variable, il n'est plus possible d'y mettre autre chose que des valeurs du type désigné lors de la définition. Mais les précédents commentaires expriment souvent bien mieux que je ne le pourrais ce qu'est la notion de typage. L'ultime indice qui exclut la javascript de la famille des langages fortement typés nous est fournit par google qui, en développant le dart, ambitionne de fournir aux développeurs de javascript un langage fortement typé chargé de s'assurer de la bonne utilisation les contraintes induites par un typage fort et de réduire ainsi la possibilité d'erreurs et d'attaques que l'on rencontre quand l'on peut à loisirs substituer un type par un autre.
google n'est pas le saint grall de la réponse ultime et universel sur la façon de concevoir la programmation.L'ultime indice qui exclut la javascript de la famille des langages fortement typés nous est fournit par google qui, en développant le dart, ambitionne de fournir aux développeurs de javascript un langage fortement typé chargé de s'assurer de la bonne utilisation les contraintes induites par un typage fort et de réduire ainsi la possibilité d'erreurs et d'attaques que l'on rencontre quand l'on peut à loisirs substituer un type par un autre.
qui peut pretendre que le typage fort doit être une obligation pour tous langages un peut comme une pensée unique a croire que le changement en cour de route du type est une aberation.
Google est quand même un gros nid d'ingénieurs, et ils ont dû réfléchir un minimum à l'utilité d'un outil de développement capable de générer du code javascript obéissant aux règles d'un typage fort, réflexion qui n'aurait eu aucun sens si javascript avait été d’emblée un langage typé.
Un typage n'est pas une obligation, mais cela rend le code plus sécuritaire, stable et cohérent, rien qu'en phase de débuggage, ne pas avoir à se demander ce que contient en réalité une variable peut simplifier grandement le travail.
Et tu crois que les gens qui ont conçu des langages à typage faible n'y ont pas aussi "réfléchi un minimum" ?
(je préfère de loin le typage fort, mais je me fais l'avocat du diable)
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
Répondre avec citation
Partager