Discussion :

[23JFK]

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.

[Invité]

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.

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.

[23JFK]

google n'est pas le saint grall de la réponse ultime et universel sur la façon de concevoir la programmation.

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 aberration.

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.

[tomlev]

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

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 )

[stardeath]

Et tu crois que les gens qui ont conçu des langages à typage faible n'y ont pas aussi "réfléchi un minimum" ?

c'est peut être que justement ils n'ont pas suffisamment réfléchi

quand tu as affecté un entier à une variable, et que d'une manière inattendu tu te retrouves avec une string, je doute que la surprise soit de bon gout.
je pense que tous ici, avons déjà passé quelques minutes voir heures à chercher pourquoi une variable n'avait pas la bonne valeur, et maintenant on va nous dire que c'est une bonne idée d'en plus checker si le type est bon?

je dirai que c'est surement une blague.

[gl]

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

Au vu du reste de ton message, il me semble qu'ici tu parles plus de la distinction objet à prototype / objet à classe.
C'est encore une notion différente du typage fort/faible ou statique/dynamique (même si dans l'esprit je trouve que ça se marie très bien avec un typage dynamique).

Sinon +1 sur l'intérêt des prototypes et sur le fait d'utiliser les caractéristiques du langage plutôt que de se battre contre.

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.

Non, ça c'est la différence entre typage statique et dynamique.


Sinon une remarque plus globale sur la catégorisation des langages entre "faiblement typé" et "fortement typé", je n'adhère pas du tout à une telle catégorisation.
Ce n'est pas juste deux catégories clairement distinctes (tout n'est pas blanc ou noir) mais bien un axe, une mesure relative entre langages.
Et encore ! J'aurais même tendance à penser qu'un langage n'est pas simplement un point sur un axe typage faible-typage fort mais bien un segment sur un ensemble de critères assez distincts.

[tomlev]

Pour ceux qui ne l'auraient pas encore lu, je vous conseille l'article Strong typing de Wikipedia, qui reprend la plupart des idées exprimées dans ce débat...

[sevyc64]

Et tu crois que les gens qui ont conçu des langages à typage faible n'y ont pas aussi "réfléchi un minimum" ?

c'est peut être que justement ils n'ont pas suffisamment réfléchi

Avant de juger ceux qui ont conçu les langages, posez-vous la question dans quel contexte ou été créés ces langages.

Javascript est à la base un langage interprété, et non pas compilé. De plus interprété coté client dans des logiciels, principalement les navigateurs, dont leur vocation première n'est une quelconque compilation et vérification du code. De plus encore que c'est, c'était tout au moins au début, de l'interprétation de code à la volée, ce qui fait que, à l’exécution d'une instruction, l'environnement complet du code n'est pas forcément connu en totalité. Difficile dans ce cas de vérifier quoique ce soit sur la qualité du code.

Bref, dans ces conditions là, le typage fort n'apporte pas forcément beaucoup d'avantages. Quant au typage faible, il se révèle plus souple et certainement moins contraignant pour les interpréteurs.

Pour ce qui est du typage dynamique de Javascript, je n'en connais pas la raison, mais il doit bien y en avoir une, qui doit surement aussi pouvoir l'objet de débat.

Pour ce qui est des conversion/transtypages implicites, quasiment tous les langages en font, y compris les langages à typages fort. Mais suivant la force du typage, la conversion aura plus ou moins de succès.
Dans un code de ce type (peu importe le langage) :

Code :

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

1
2
3
4
5
 i : byte =12
j : double =12600
k : double
 
k = i + j

on peut s'attendre à ce que k =12612.
Beaucoup de langages accepterons cette opération à la compilation, y compris les langages à typage fort, malgré le fait qu'il y ait une conversion de type implicite (voire 2 suivant les langages). Certains émettrons un warning, mais rien de plus.
A l’exécution par contre, certains feront n'importe quoi, d'autres donnerons le bon résultat. Les langages à typage fort (et surtout à typage statique) devraient, eux, et encore pas tous, renvoyer une exception pour dépassement de capacité.
(A noter que k = j + i ne devrait poser aucun problème, quelque soit le langage, malgré, là aussi la conversion implicite)

Tout ça pour dire que la conversion implicite n'est pas l'apanage des langages à typage faible, et tout le monde en fait tous les jours sans même s'en rendre compte.

[Invité]

je pense que tous ici, avons déjà passé quelques minutes voir heures à chercher pourquoi une variable n'avait pas la bonne valeur,

on peut aussi se dire pourquoi une tel erreur

peut etre parce que la personne qui a codé avant c'est dit c'est pas grave si je fait une erreur de type elle sera détecte grâce au typage fort

[grim7reaper]

Les langages à typage fort (et surtout à typage statique) devraient, eux, et encore pas tous, renvoyer une exception pour dépassement de capacité.
(A noter que k = j + i ne devrait poser aucun problème, quelque soit le langage, malgré, là aussi la conversion implicite)

Et certains, qui ont un typage vraiment fort, ne compilerons même pas (que ça soit j+i ou i+j).

[stardeath]

Avant de juger ceux qui ont conçu les langages, posez-vous la question dans quel contexte ou été créés ces langages.

Javascript est à la base un langage interprété, et non pas compilé. De plus interprété coté client dans des logiciels, principalement les navigateurs, dont leur vocation première n'est une quelconque compilation et vérification du code. De plus encore que c'est, c'était tout au moins au début, de l'interprétation de code à la volée, ce qui fait que, à l’exécution d'une instruction, l'environnement complet du code n'est pas forcément connu en totalité. Difficile dans ce cas de vérifier quoique ce soit sur la qualité du code.

donc grosso modo, tu dis à demi mot que javascript, on ne l'utilise pas ou plus dans l'optique dans laquelle il a été créé. moi ça me va.

par contre maintenant qu'on fait des softs un poil plus compliqués en javascript, il serait peut être temps de bazarder ces mauvaises pratiques de conceptions de langage.

mais bon, je ne me fais pas d'illusion.

[Invité]

petit rappel JavaScript était a la base un langage serveur. et sa standardisation qui se situe après son adaptation dans un navigateur aurait durée 1 ans et 7 mois. on peut ainsi considéré que JavaScript n'a pas été crée a l’arrache.

[ptah35]

Au risque de répéter ce qui a déjà été dit mainte fois dans ce fil, il convient de distinguer typage statique/dynamique de typage fort/faible.

Si l'on peut, le plus souvent, facilement classer un langage dans la catégories des langage à typage statique ou celle des langage à typage dynamique, il n'en va pas de même pour les catégories typage fort et typage faible. Ces deux dernières notions ne sont pas clairement définies et comme l'a très bien dit gl, il convient sans doute de les considérer ensemble comme formant un axe. Un langage a donc un typage plus ou moins fort et ce, qu'il s'agisse d'un langage à typage statique ou à typage dynamique.

Parmi les indicateurs qui permettent de détecter un typage faible, on trouve les conversions de types implicites qui ne sont pas sûres. En JavaScript, c'est le cas, par exemple, des opérateurs arithmétiques qui acceptent comme opérandes des expressions de n'importe type alors qu'elles n'ont de sens que si les opérandes sont de type numérique. Il y a bien sûr des raisons historiques à cela, et il est tout à fait possible de vivre avec (si les tests sont corrects et complets, leur passation implique l'absence d'erreur de type, que celles-ci soient détectées par des exceptions ou une valeur particulière comme NaN). Néanmoins, de ce point de vue, le typage de JavaScript est plutôt faible et que l'on soit partisan des langages à typage statique ou de ceux à typage dynamique, on ne peut qu'être favorable à un typage aussi fort que possible.

Il se trouve cependant, que JavaScript est très souvent décrié à cause de son typage dynamique et trouve cela très dommage car en soit, je ne pense pas que cela soit une mauvaise chose. Le typage statique a de nombreux avantage, mais peut également rendre certaines choses fort complexes et auxquelles il n'y a pas de réponse unique (problème de la covariance et de la contravariance dans l'héritage et les types génériques par exemple). Personnellement, je refuse de me ranger dans un camps ou dans l'autre, je pense que les deux approches présentent un intérêt.

Question : Même si je n'accorde pas vraiment d'importance aux pousses verts et rouges, je me demande quels sont les arguments de celui qui a mis un pousse rouge à ce post.

[sekaijin]

Il se trouve cependant, que JavaScript est très souvent décrié à cause de son typage dynamique et trouve cela très dommage car en soit, je ne pense pas que cela soit une mauvaise chose.

je suis entièrement d'accord. quand je vois le nombre de cast que l'ont trouve dans les programmes je me dit que finalement c'est bien plus simple lorsque le langage est typé dynamiquement.

je ne vois pas de différences entre

Code java :

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

1
2
3
4
5
Object obj = myMap.get("truc");
if (obj instenceof Machin) {
  Machin truc = (Machin)obj;
  truc.myMethod();
}

et

Code javascript :

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

1
2
3
4
var truc = myMap.get("truc");
if (truc instanceof Machin) {
  truc.myMethod();
}

mis a part qu'avec le typage dynamique javascript ne nécessite qu'une variable. pour moi dans les deux cas il faut vérifier le type de l'objet.

j'entends déjà les réponses qui me diront qu'avec Java si on a bien définit myMap le compilateur nous avertira avant l'exécution.

Si on l'a bien defini. et c'est bien la le problème SI et seulsement SI.
malheureusement de nombreux cas aboutissent à utiliser la classe Object. et la la différence entre une String ou un Integer...

C'est si vrai que le compilateur aura tout vérifié que nous n'avons jamais de cast exception. et cela n'est pour moi pas fondamentalement différent que d'être surpris parce qu'une variable js contient un string à la place d'un entier.

quant à la vérification par le compilateur, il ne permet pas de tout vérifier et il faut tout comme en js en passer par des test uniraires et vérifier la couverture des tests.

ok le compilateur aura interdit de référencer une string avec un variable définie comme entier. mais cela n'empêchera jamais de se retrouver obliger d'en passer par la classe objet et du coup de se retrouver à la merci d'erreurs toutes aussi grossières. qui sans les tests approprié ne seront pas détecté.

oui un compilateur c'est très utile. Oui Contraindre le type de variable c'est très utile. et Oui pouvoir changer de type dynamiquement c'est aussi très utile.

lorsque je développe en java j'use et j'abuse des capacité du compilateur des contraintes sur mes variables.
mais je peste aussi contre ces contraintes qui me force à faire des choses compliqué pour résoudre des problèmes simples.

Lorsque je développe en javascript j'use du typage dynamique qui me permet simplement de répondre à des problèmes complexes. et je râle contre le manque de garde fou qui m'éviteraient de faire des c@ne#ies.

Alors dans les deux cas je testes je reteste et je teste encore.
A+JYT

[stardeath]

...

selon toi, de nombreux cas mèneraient à du code comme le tien, je serai curieux de savoir lesquels.
un cast n'est pas une opération triviale, ça indique qu'une partie de code va avoir besoin de quelque chose dont on a aucun exemplaire direct sous la main.

utiliser le typage dynamique ou le super-objet java pour cacher ça, ça se range du coté de l'exception qui confirme la règle ou de la mauvaise conception ; certainement pas en tout cas de la programmation de tous les jours.

[Invité]

Google [...] 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 des contraintes induites par un typage fort [...]

Après la lecture de ce sujet et des articles de Wikipédia portant sur les types en programmation, je ne suis plus sûr de grand chose à propos de ce qu'on appelle typage fort et typage faible*. Mais j'aimerais bien connaitre ta source pour l'affirmation citée ci-dessus. Que penser de cet article, d'ailleurs ? Sinon, pour aller dans ton sens, l'un des objectifs des initiateurs du projet Dart (Bak et Lund) est de réduire drastiquement le nombre de conversions implicites effectuées par JavaScript et qui mènent parfois à des aberrations du genre 1 est égal à 2 (voir la vidéo en lien ci-avant). C'est peut-être ce à quoi tu pensais.

* En tout cas, ce qui ressort de Wikipédia et des débats dans ce fil, c'est qu'il n'y a malheureusement pas de consensus pour définir la force d'un typage (cela a été dit dès la première page). D'ailleurs, l'article de Wikipédia sur ce sujet laisse penser (ce n'est que mon avis) que la force d'un système de types est la résultante assez subjective d'un ensemble de critères bien mieux définis, comme l'aspect statique/dynamique, l'inférence ou la sûreté. Cela dit, en général, il semble que le typage faible soit plus négativement connoté que le typage fort. En tout cas beaucoup plus, dans l'esprit des développeurs, que le typage statique ne l'est en regard du typage dynamique. En bref, ce serait carrément mieux vu d'adopter un typage fort.

Je voulais revenir sur des définitions intéressantes données dans ce fil. En effet, l'article de Bovino passe bien trop vite sur les définitions (à dessein ?) et entretient certaines confusions. Mais ce reproche a déjà été formulé, principalement par grim7reaper. Grim7reaper, justement, qui évoquait les conversions implicites parmi les critères permettant selon lui de comparer les forces de typage de différents langages :

Plus il y a de conversions implicites, plus le typage est faible (car il est plus facile de faire des conversions entre les types et de mélanger des types différents dans une même opération), à contrario moins de conversion [im]plicite => typage plus fort.

Vu le nombre de votes positifs et les réactions qui ont suivi, il semble que ce critère ait emporté l'adhésion d'une large majorité. (Au passage cela fait écho à l'argument sur Dart)

Et pouf, deux pages plus loin, une autre définition, donnée par sjrd et contre laquelle personne n'a vraiment bataillé non plus :

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.

(Au passage, comme yahiko, j'aurais aimé connaitre la source, parce que résumé comme ça c'est un peu obscur : un cast, n'est-ce pas une forme de conversion ?)

Darktib a répondu, sur un ton semi humoristique :

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é

Bien qu'un brin trollesque, je me serais arrêté à cette première partie du message. Pourquoi, dans la logique de sjrd, appliquer une définition faisant clairement mention des casts alors que sjrd lui-même considère qu'il n'y a pas de casts en Javascript ? La définition semble clairement inadaptée au cas de Javascript, dans ce cas, non ?

Et que penser du fait que cette deuxième définition balaye complètement le critère donné par grim7reaper ? Moi qui ne suis pas un spécialiste de la théorie des types en programmation, j'avoue m'y perdre un peu...

[fredoche]

salut

bon je vous le dis d'emblée, je n'y connais rien aux "types", autodidacte, mes connaissances se bâtissent sur mes besoins en général. Donc j'ai des grosses lacunes théoriques, et jouer sur les mots, c'est pas mon fort sur ce sujet.

Je m'intéresse au javascript, beaucoup à vrai dire. Ca fait bien 15 ans que j'en fais... mal comme la plupart, mais je travaille à me corriger et à comprendre les clés de ce langage.

Donc votre débat m'intéresse, mais j'ai beaucoup de mal à le suivre et à voir quels sont les problèmes évoqués, basés sur des exemples qui me paraissent extra-terrestres.

J'aurai bien envie de poser quelques questions candides, histoire de satisfaire un peu mon ignorance :
Ca sert (encore) à quelque chose les types ? Notamment certains comme "int", "float" ou autres nombres à espaces mémoires réduits ? Quand des procs savent traiter des mots de 32 ou 64 bits et que la RAM même sur les plus petites "machines" dépassent bien souvent le million d'octets

J'ai le sentiment, et c'est là où je suis vraiment mauvais à comprendre, que le typage pour certains sert surtout à faire du contrôle de valeurs basique, du contrôle de saisie voir ? je vais me faire assassiner mais ce n'est pas un troll.
Entre intercepter une erreur et la gérer, et faire un contrôle explicite de valeur (et de type probablement, ce que permet tout à fait javascript), il y a de grosses différences ?

Quand je vois des exemples avec

Code :

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

"2"+2*2

. Là ça me dépasse... Mais parce que je suis un esprit pratique.
Donc toujours avec cette esprit pratique comment peut on arriver à ce genre de situation dans la vie réelle ? quelle est la valeur d'exemple de cet exemple ? on peut mélanger choux et carottes et obtenir un résultat ? Ce ne sera ni des choux, ni des carottes, quel intérêt ?

C'est pas un peu contre-productif de jouer tout le temps avec des types : genre je veux diviser un int par un int, faut que je convertisse tout en double avant ? C'est ça ?

Bon je suis candide et ignorant mais on me paie pour faire du dev entre autres, et ça fait des années que je le fais, notamment avec des BDD. Avec les BDD, les types on en a à foison (avec MS SQL Server en tout cas).
De toute façon, même si je type dans mon langage, je vais devoir gérer probablement d'autres types sur ces BDD. Ce qui veut dire contrôle, gestions de cas ou d'exception, et conversions de type.
Parce que des types, c'est pas une norme, à chaque langage, univers ou système ses spécificités. Et on fait tous du multi-tiers, avec des IHM d'un coté (l'utilisateur le type il s'en fiche), plusieurs langages, plusieurs couches, plusieurs systèmes et du stockage. Le typage... fort et statique surtout, je suis pas sur que ce soit toujours un avantage

En fait je m'interroge sur le réel intérêt de ces types à l'heure de l'informatique actuelle, Ghz CPU, Go de RAM, To de stockage...
Parce que les types c'est quoi sinon de la pré-réservation d'espace ? dans une optique économe et efficace qui s'explique par l'histoire de l'info... mais désormais, avec des environnements en briques de partout, des machines plus puissantes que les Cray des années 80 ?


je suis hors-sujet hein

[yahiko]

Bonjour,

Compte-tenu de certains arguments, il peut être utile de se référer aux spécifications de Javascript avant d'affirmer des contres-vérités.
Norme ECMAScript-262 5.1 : http://www.ecma-international.org/ecma-262/5.1/

Par exemple, le chapitre 9 (Type Conversion and Testing) indique clairement que Javascript est conçu pour réaliser des conversions (cast) implicites.

The ECMAScript runtime system performs automatic type conversion as needed.

Sinon, voici ce qu'on peut lire dans la définition Wikipédia (http://en.wikipedia.org/wiki/Strong_and_weak_typing) mentionnée plus haut :

En programmation, les langages sont souvent communément qualifiés de fortement ou faiblement typés. En général, ces termes n'ont pas de définition précise.

[danielhagnoul]

En plaisantant, j'ai dit au début de cet échange de points de vue que pour JS on pouvait parler de "typage solide" (je pensais dynamique, mais résistant). Tous les points de vue exprimés ne m'ont pas fait changer d'avis : bien qu'il soit déroutant pour les débutants venant d'un autre langage on peut se fier au système de type de JS.

@fredoche : hors sujet théorique oui, pratique je ne trouve pas.

Les attributs HTML contiennent toujours du texte, il en résulte que l'addition d'un texte avec un nombre n'est pas aussi rare qu'on l'imagine.

Les ordinateurs sont plus rapides, mais les scripts sont de plus en plus lourds. Pour les variables, il faut penser au stockage, mais aussi au temps d'exécution.

[Uther]

google n'est pas le saint grall de la réponse ultime et universel sur la façon de concevoir la programmation.

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.

Personne pas même Google ne prétend que le typage fort est absolument nécessaire dans tous les cas. Mais il est indiscutable que le typage faible a des inconvénients qui ont poussé Google a créer Dart, même s'ils continuent en parallèle d'améliorer leur moteur Javascript. Même Mozilla qui est un ardent défenseur du Javascript (et qui compte son créateur dans ses chefs) a conçu asm.js, pour outrepasser entre autre les problèmes de performances induit par le typage de Javascript.

Ca sert (encore) à quelque chose les types ? Notamment certains comme "int", "float" ou autres nombres à espaces mémoires réduits ? Quand des procs savent traiter des mots de 32 ou 64 bits et que la RAM même sur les plus petites "machines" dépassent bien souvent le million d'octets

Les machines ont beau être toujours plus rapides, elles iront toujours plus vite pour faire des calculs sur 32 bit que 64 bit et pour travailler sur les entiers que sur les nombres à virgule flottantes.
De plus le compilateur saura mieux optimiser un code si la structure des objets qu'il manipule est connue d'avance que s'il doit la vérifier a chaque utilisation.

J'ai le sentiment, et c'est là où je suis vraiment mauvais à comprendre, que le typage pour certains sert surtout à faire du contrôle de valeurs basique, du contrôle de saisie voir ?

Non le typage ne sert clairement pas a faire du contrôle se saisie, loin de là. Seuls quelque rares langages permettent d'avoir des types assez finement définis pour envisager de faire cela et encore, ils ne recomendent pas de s'en passer.
Le typage permet surtout de s'assurer qu'on ne mélange pas les torchons et les serviettes, cf notamment l'exemple si dessous ou on mélange chaines et chiffres.

Quand je vois des exemples avec

Code :

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

"2"+2*2

. Là ça me dépasse... Mais parce que je suis un esprit pratique.
Donc toujours avec cette esprit pratique comment peut on arriver à ce genre de situation dans la vie réelle ? quelle est la valeur d'exemple de cet exemple ? on peut mélanger choux et carottes et obtenir un résultat ? Ce ne sera ni des choux, ni des carottes, quel intérêt ?

Ce code est présenté avec des littéraux pour mettre en évidence un des problèmes que peut entrainer le typage faible, mais dans la pratique il peut se présenter sous des formes bien plus sournoises à détecter.
Supposons qu'on ait x + y * z. Comme le type des variables n'est pas déclaré en javascript, on se sait pas si on a en réalité à faire à "2"+2*2 ou 2+2*"2" qui ont pourtant des résultats différents. Le problème se complique encore plus si ces variables sont manipulées par des fonctions que l'on n'as pas écrit soi même.

En fait je m'interroge sur le réel intérêt de ces types à l'heure de l'informatique actuelle, Ghz CPU, Go de RAM, To de stockage...
Parce que les types c'est quoi sinon de la pré-réservation d'espace ? dans une optique économe et efficace qui s'explique par l'histoire de l'info... mais désormais, avec des environnements en briques de partout, des machines plus puissantes que les Cray des années 80 ?

Nos capacités sont il est vrai toujours plus importantes mais on essaye généralement d'en profiter pour traiter plus de données. Donc garder des technologies optimisées a encore un sens.
De plus le typage fort n'est pas qu'une question de performance mais aussi de structuration pour éviter de mélanger les torchon et serviètes comme expliqué plus haut.