Discussion :

[ptah35]

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 ?

J'ai fait mon exemple en utilisant des valeurs littérales, mais il aurait aussi pu s'agir de variables ou de n'importe quelle expression. J'ai souvent vu des erreurs de ce type arriver parce que l'une des valeur provenait de l'interface utilisateur et qu'il s'agissait de la valeur du contrôle (le plus souvent une chaîne). Avec la plupart des opérateurs arithmétiques, cela passe inaperçu mais avec un "+", des comportements étranges peuvent apparaître sans être immédiatement identifiés (la valeur finale n'est pas correcte mais tout de même un numérique si la chaîne contient un nombre). Si ces opérateurs n'acceptaient pas des opérandes de types différents (en levant une exception par exemple) de telles d'erreurs ne pourraient pas passer inaperçues.

Cela étant dit, je le répète encore une fois, quelque soit le langage de bons tests sont une nécessité et devraient permettre de détecter ce genre de problèmes si un compilateur ne l'a pas fait avant.

[sekaijin]

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.

Tous les jours je reçois des données issue de diverses sources qui au final se rapportent à des couples clefs valeurs. pas d'ordre dans les clefs pas de type strict dans le valeurs.
en java une seule solution une collection de type Map<Object, Object>

Tous les jours les nouvelles structures que je reçois m'amènent à soit réécrire toutes mes application parce-qu'elle ont une bonne conception comme tu l'entends. soit à concevoir des systèmes souples et donc capable de prendre en compte des données à la structure plus changeante et faiblement typée.

et ô chose étrange les espaces de stockage ces dernières années ont ouvert des voies vers des structures plus souple. le modèle fortement typé qu'est le relationnel ne permettant pas de répondre à tous les besoin.

Je maintiens dans mes développement c'est un problème quasi quotidien que de devoir en passer par la classe Object.

mais je pourrait tout aussi bien en passer par un typage bien plus fort comme par exemple parser de façon souple les données que je reçois en déduire la structure généré à la volé un ensemble de classe corrspondant à cette structure, les compiler à la volé et enfin les instancier pour manipuler mes données. mais je doute que cela soit beaucoup plus rapide et efficace que d'utiliser des Map.
ce n'est pas un hasard si les Standard Data Object existent etc.

A+JYT

[Kaamo]

Le typage typique à Javascript vient en partie du fait qu'il n'y avait pas de gestionnaire d'erreur dans la v1 du langage. (comprendre les blocs try {} catch() {} finally {} ). Du coup, plutôt que de jeter une exception (impossible à l'époque!) les variables sont implicitement converties et c'est aussi pourquoi JS échoue silencieusement. (Source : un tweet de Brendan Eich, le papa de JS).

Bien que ce typage ait ses inconvénients (conversion implicite en chaîne de caractère : '5' + 6 === '56') il a ses points forts, par exemple, quand il s'agit de traduire implicitement en booléen. A chaque fois que JS s'attend à un booléen (par exemple dans un if) toutes les valeurs peuvent être utilisées, elles sont automatiquement converties en true ou false (false si la valeur de la variable est égale à undefined, null, false, -0, +0, NaN, ''. true sinon). Il faut avouer que dans ce sens cela en arrange plus d'un.

Considérez-vous comme moi qu'au final, JavaScript est fortement typé ?

Je dirais que Javascript a un typage dynamique et plus particulièrement un "typage canard" (voir Duck Typing).
Cela veut dire que Javascript ne va pas vérifier le type de la variable avant de réaliser ce qu'on lui demande, mais va tout simplement vérifier si la variable peut réaliser ce qu'on lui demande.

Code :

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

1
2
3
4
5
6
7
var donald = {};
donald.bafouille(); // Object #<Object> has no method 'bafouille'
 
donald.bafouille = function bafouille() {
  console.log('Kshhshsh blblbl');
}
donald.bafouille(); // Kshhshsh blblbl

[gl]

Je dirais que Javascript a un typage dynamique et plus particulièrement un "typage canard" (voir Duck Typing).

Oui. Mais encore une fois, c'est orthogonal à la notion de typage fort/faible

[Uther]

Encore un fois la notion de typage fort-faible peut-être à la fois orthogonale à tout et rien. étant donné qu'elle n'a pas de définition claire.

[gl]

Encore un fois la notion de typage fort-faible peut-être à la fois orthogonale à tout et rien. étant donné qu'elle n'a pas de définition claire.

Je suis bien d'accord qu'elle n'a pas de définition claire et universellement admise (en même temps les concepts informatiques ayant une définition claire et universellement admise ne se comptent peut-être pas sur les doigts d'une main, mais ce n'est pas très loin). Mais ça tourne généralement autour de la détection des erreurs de typage, des conversions implicites (et souvent malvenus), de la perte d'information sur le type, etc.
Il n'y a pas de lien direct avec le typage statique/dynamique si ce n'est éventuellement un lien statistique (il semblerait selon certains auteurs qu'en moyenne les langages à typage statique soient plus fortement typés que les langages à typage dynamique. Personnellement je n'ai jamais vu d'étude statistique à ce sujet et, même si c'est vrai, je suis loin d'être convaincu que ce lien ait des causes techniques et non culturelles).

[Uther]

Mais ça tourne généralement autour de la détection des erreurs de typage, des conversions implicites (et souvent malvenus), de la perte d'information sur le type, etc.

Ca reste très vague. si on prend les deux définition à la fois claire et qui semblent avoir le plus plu dans le sujet:

On pourrait mesurer la faiblesse de typage d’un langage par rapport au possibilités de conversions implicites qu’il offre.

Un langage est faiblement typé si et seulement si les casts non vérifiés au runtime sont autorisés.

Auquel on peut ajouter la première définition historique(1974) du typage fort d'après wikipédia:

whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function.

Ça laisse des boulevards d'interprétation différentes. Pour faire une étude statistique, il faudrait déjà savoir sur quelle définition on se base. Suivant la définition que l'on choisi, le Javascript (comme le C et le C++) peut être alternativement fortement typé, faiblement typé, ou a cheval entre les deux.

[tomlev]

Ca reste très vague. si on prend les deux définition à la fois claire et qui semblent avoir le plus plu dans le sujet:

On pourrait mesurer la faiblesse de typage d’un langage par rapport au possibilités de conversions implicites qu’il offre.

Même cette définition n'est pas très satisfaisante ; C# est généralement considéré comme fortement typé, pourtant il autorise des conversions implicites :
- entre les types primitifs si ça peut se faire sans perte d'information (par exemple int vers double)
- quand une telle conversion a été définie par le développeur avec le mot-clé implicit

[fredoche]

Je regarde en ce moment les conférences de Douglas Crockford sur le javascript. Il parle de loose typing

Vu que vous n'avez pas évoqué le terme, et qu'il semble aller à l'encontre du typage fort évoqué dans le sujet, en tout cas dans son discours, je le livre à vos réflexions.

[Invité]

au lieux de dire typage fort faible on devrait plutôt dire typage fortement ou faiblement explicite ?

[grim7reaper]

On pourrait mesurer la faiblesse de typage d’un langage par rapport au possibilités de conversions implicites qu’il offre.

Même cette définition n'est pas très satisfaisante ; C# est généralement considéré comme fortement typé, pourtant il autorise des conversions implicites :
- entre les types primitifs si ça peut se faire sans perte d'information (par exemple int vers double)
- quand une telle conversion a été définie par le développeur avec le mot-clé implicit

Encore une fois, de mon point de vue, la force d’un typage est relative.
Ma définition est une façon, probablement parmi d’autres, de mesurer (de manière relative) la force/faiblesse du typage.
Je n‘ai pas posé un truc binaire du genre :
- possibilités de conversions implicites => typage faible
- aucune conversions implicites => typage fort
Pas du tout.
Encore une fois, ces histoires de typages faible/fort ce n’est pas absolu. Il y a plutôt tout un spectre de variations entre deux extrêmes.

Donc oui, de manière générale je le classerai plutôt C# en tant que langage fortement typé (mais par rapport à Haskell par exemple, il sera faiblement typé).

Bon après je ne connais que très peu C# donc mon jugement est à prendre avec des pincettes.

[stardeath]

Tous les jours je reçois des données issue de diverses sources qui au final se rapportent à des couples clefs valeurs. pas d'ordre dans les clefs pas de type strict dans le valeurs.
en java une seule solution une collection de type Map<Object, Object>

ce n'est pas un cas de programmation usuel.

Tous les jours les nouvelles structures que je reçois m'amènent à soit réécrire toutes mes application parce-qu'elle ont une bonne conception comme tu l'entends. soit à concevoir des systèmes souples et donc capable de prendre en compte des données à la structure plus changeante et faiblement typée.

prendre en compte des structures que tu ne connais pas implique que tu ne peux pas savoir non plus quel traitement tu peux effectuer dessus, java n'est pas magicien, même avec une bonne dose de réflexion, tu ne peux pas à l'avance faire un code qui sait traiter tous les objets possibles et imaginables.
ou alors tu as un point commun à tous les objets que tu reçois et donc utiliser Object devient une erreur de conception.

je ne peux cependant pas en dire plus, je n'ai pas plus d'info, je ne fais qu'apporter des suppositions sur les éléments que tu donnes.

et ô chose étrange les espaces de stockage ces dernières années ont ouvert des voies vers des structures plus souple. le modèle fortement typé qu'est le relationnel ne permettant pas de répondre à tous les besoin.

certes, pour des éléments ayant vraiment zéro point commun.

Je maintiens dans mes développement c'est un problème quasi quotidien que de devoir en passer par la classe Object.

parce que tu es dans un cas particulier, tout le monde ne traite pas des données strictement hétérogènes.

mais je pourrait tout aussi bien en passer par un typage bien plus fort comme par exemple parser de façon souple les données que je reçois en déduire la structure généré à la volé un ensemble de classe corrspondant à cette structure, les compiler à la volé et enfin les instancier pour manipuler mes données. mais je doute que cela soit beaucoup plus rapide et efficace que d'utiliser des Map.
ce n'est pas un hasard si les Standard Data Object existent etc.

utiliser une map pour des pairs d'objets dont aucun des 2 ne peut servir de clé me semble plutôt une mauvaise idée.
la map est une structure faite pour la recherche, tu dis que tes données ne peuvent être ordonnées, la map est donc un non sens.

avec les éléments que tu fournis, un vector<pair<object, object>> me semble déjà plus approprié.

[ascito]

pour vous dire...

en javascript comme en php et en java, la déclaration des constructeurs est quasi identique.

ce qui peu changer, et du coup ca revient au typage fort ou faible, c'est l’appartenance véritable d'une variable à un groupe, et donc à son constructeur.

Quand nous déclarons que la var A est dans le groupe de GROUPEDESA, celon certains langages et c'est ce qui en fait le typage fort, cette variable héritera tout au long de sa vie des propriétés du groupe dans lequel elle à été formé..

Le typage fort implique que si une variable change de groupe, elle ne doit pas poser de problème de fonctionnement.

admettons juste que une variable qui est un chiffre ne puisse pas rejoindre un groupe qui n'accepte pas les variables avec un chiffre.

[ptah35]

Tous les jours je reçois des données issue de diverses sources [...] en java une seule solution une collection de type Map<Object, Object>

Map<Objet, Objet> n'est pas nécessairement la seule solution. Même des données hétérogènes issues de sources diverses et variées peuvent être considérées comme autant d'objets appartenant à la classe des objets supportés par votre application. Même si cette classe n'avait pas plus de méthodes que la classe Objet, elle présenterait tout de même un intérêt ne serait-ce que du point de vue de la documentation du code et de la maintenance.

Quand nous déclarons que la var A est dans le groupe de GROUPEDESA, [...]

Il s'agit là bien plus de typage statique que de typage fort. Une variable de type void* en C ne changera jamais de type, mais peut-on pour autant parler de typage fort? En outre, les variables ne sont pas la seule chose à considérer lorsque l'on parle de typage, elles ne sont qu'un cas particulier d'expression; ce qui importe, ce sont les objets, c'est-à-dire les valeurs de ces expressions, mentionnés dans la citation de Liskov and Zilles citée par Uther.

[sekaijin]

Map<Objet, Objet> n'est pas nécessairement la seule solution. Même des données hétérogènes issues de sources diverses et variées peuvent être considérées comme autant d'objets appartenant à la classe des objets supportés par votre application. Même si cette classe n'avait pas plus de méthodes que la classe Objet, elle présenterait tout de même un intérêt ne serait-ce que du point de vue de la documentation du code et de la maintenance.

j'appelle ça chipoter une classe unique qui dérive de Object et qui n'a pour but que d'ajouter de la doc pour moi c'est sémantiquement la classe Object.
pire si je fais ça je vais perdre l'héritage existant entre Object, Interger, Float, String. du coup il me faudra reproduire toute la hiérarchie pour manipuler mes données pour au final produire un code complètement équivalent à celui que j'ai en utilisant Object, Character, Byte, Short, Long, Integer, Float, Double, Boolean.

Tu peux toujours essayer de convaincre, mais ce n'est pas par hasard si partout dans le monde les Lib qui traite du genre de problème auquel je suis confronté en sont toutes arrivées à un conteneur générique (Object ou un autre) et des type de base. le tout adossé à une sérieuse gestions de conversion dynamique de type. c'est l'oeuvre de centaine voire de millier d'ingénieurs, (dont je suis) sur des dizaines d'années d'expérience.

je maintiens la présence de l'API réflexion dans java, l'utilisation conjoint de Object/Cast, le runtime Objective-C , la gestion semi dynamique des types de C#, etc sont tous arrivé dans ces langages pour prendre en compte des cas très difficilement voire impossible à modéliser avec un langage de classe strict.
à la base de la théorie des langages à base de classe la notion d'interface n'existe pas. elle n'a aucune raison théorique d'exister. l'héritage est largement suffisant. mais écrie un compilateur pour un langage à héritage multiple n'est pas simple. le travail du développeur est compliqué. du coup la majorité des langage à base de classes ce sont cantonné à l'héritage simple mais c'était trop contraignant. on a percé un trou dans ces contraintes pour faciliter le travail. toujours dans la théorie de base l'accessibilité de membres est dans la ligne hiérarchique et il est impossible depuis une méthode d'un objet hors de cette ligne d'accéder à un membre privé ou protégé. mais il est des cas ou ça facilite tant la vie. ou pour le dire autrement il serait très compliqué de le respecter. qu'on a introduit par exemple en C++ les classes et méthodes amies.

des ajouts de ce type à des langage plus strict on en comptes par centaines.
Je dirais que Eifel est peut-être celui qui à le plus cherché à respecter la théorie. face à ces problématiques les solutions trouvé ont cherchées à respecter au mieux la théorie des langage à base de classe et au typage statique. pas d'ami, pas d'interface à la place de l'héritage multiple.

Certain langage à base de classe vont beaucoup plus loin et dans un certain sens se rapproche de Javascript. en javascript on peut ajouter une méthode à un prototype après avoir instancié des objets. en Objective-C on peut substituer une classe par une de ses héritières. dans les deux cas les objets instanciés ont accès aux méthode de la classe héritière.
C'est quasiment un retapage dynamique.
Là encore si on a ajouté ça aux langage ce n'est pas un hasard. cela répond à des besoins.

Javascript à des défauts et il évolue comme tous les autres.
Mais il réponds naturellement à ces besoins là. c'est donc une force.
mais tout comme pour les langage à héritage multiple comme Eifel qui demande de la part du développeur beaucoup d'attention. JS et plus souple plus puissant sur ces points là et la contre partie est qu'il demande au développeur d'être vigilant.

pour ma part je pense que c'est mon boulot et pas celui d'un quelconque outil que d'être vigilant.

A+JYT

[Invité]

Globalement j'apprécie tes arguments, sekaijin, mais je me permettrai une petite frivolité :

pour ma part je pense que c'est mon boulot et pas celui d'un quelconque outil que d'être vigilant.

Tout est dans les trois premiers mots. Le problème ne vient-il pas précisément du fait que cette vigilance n'est pas l'apanage d'un grand nombre d'adeptes du Javascript ? Il semble que les détracteurs de son système de types invoquent souvent la désinvolture présumée des javascripteurs. Finalement, comme l'a démontré Crockford, ce langage a souffert et continue de souffrir des mauvaises pratiques... auxquelles il prête flanc volontiers. Arf, on en revient au langage...

Un peu plus sérieusement, je trouve le message de sekaijin plutôt convainquant lorsqu'il mentionne les astuces implantées par les concepteurs de langages orientés objet pour donner du mou au typage. Sans rentrer dans le débat de savoir si cet amollissement va vers plus de dynamisme ou moins de sûreté ou plus d'inférence ou moins de force, je voudrais rappeler que, plus haut dans ce fil (je ne sais plus où exactement), quelqu'un a mentionné la pléthore de bibliothèques, de frameworks, de surcouches et de langages alternatifs qui, gravitant autour de JS, prétendent le rendre moins "fantaisiste" (J. Ashkenas, initiateur du projet CoffeeScript), en améliorer le modèle objet et apporter la dose de vigilance qui lui fait censément défaut. Entre autres prétentions. Donc le mouvement inverse existe, aussi. Et correspond à de réels besoins, qui manifestement diffèrent des besoins de sekaijin. Ce qui n'a rien d'anormal.

D'ailleurs, j'ai cité Ashkenas dans le précédent paragraphe, cela me fait penser que, selon lui, JS est un langage schizophrène qui souffre d'un décalage entre sa nature profonde (qui le rapprocherait de langages fonctionnels comme Lisp) et sa syntaxe maladroitement inspirée de Java. Cette syntaxe ne rendrait pas grâce à son essence. C'est un point de vue. Et c'est en tout cas ce qui l'a motivé à créer CoffeeScript, qui, rappelons-le, compile au final vers Javascript. Je ne connais malheureusement pas assez CoffeeScript pour dire si ce langage rend ou non le typage moins lâche. Si c'était le cas, ce serait un bon exemple, en plus de Dart, du mouvement inverse dont je parlais plus haut. Toutefois, anticipons la remarque : nous serons d'accord pour dire que CoffeeScript et Dart, niveau taux d'adoption par la communauté, ça reste encore marginal. Ce qui peut relativiser l'urgence des revendications pour un typage plus fort. Mais on doit pouvoir trouver d'autres exemples.

[Uther]

j'appelle ça chipoter une classe unique qui dérive de Object et qui n'a pour but que d'ajouter de la doc pour moi c'est sémantiquement la classe Object.
pire si je fais ça je vais perdre l'héritage existant entre Object, Interger, Float, String. du coup il me faudra reproduire toute la hiérarchie pour manipuler mes données pour au final produire un code complètement équivalent à celui que j'ai en utilisant Object, Character, Byte, Short, Long, Integer, Float, Double, Boolean.

Si tu peux vraiment avoir n'importe quel objet, tu as raison, il faut utiliser la classe Objet. Elle bien est faite pour ça.
Mais ça ne veux pas dire que tout le modèle de typage statique est pris en défaut, bien au contraire. Avoir un typage statique ne doit pas forcément interdire de pour pouvoir manipuler les objets indépendamment leur type quand c'est nécessaire.

Par contre, là ou j'ai plus de mal c'est quand tu dis que tu dois utiliser ça partout dans ton code. Si le programme a été conçu pour utiliser les types de manière normale, les cas ou on a a utiliser Object sont normalement exceptionnels, or tu sembles dire que ça arrive tout le temps, ce qui semble être symptomatique d'une mauvaise conception ou d'une application avec une problématique très particulière.

L'utilisation de la classe Object devrait être l'exception qui confirme la règle :
- Si un de tes programmes est obligé de l'utiliser partout parce que on ne peut jamais être sur d'aucun type, en effet, il faut peut-être mieux regarder du coté de Javascript pour celui-ci.
- Si tous tes programmes sont dans ce cas, on dirait qu'il y a un problème avec le typage dans la conception ou une mauvaise utilisation du langage.

Tu peux toujours essayer de convaincre, mais ce n'est pas par hasard si partout dans le monde les Lib qui traite du genre de problème auquel je suis confronté en sont toutes arrivées à un conteneur générique (Object ou un autre) et des type de base.

La plupart des libs java qui utilisent Object le font car elles ont été créées pour prendre en compte les versions de java antérieures à java 5 qui ne géraient pas les types génériques. Celles qui évoluent encore sont presque toutes passées aux génériques ou sont en train d'y passer.

je maintiens la présence de l'API réflexion dans java, l'utilisation conjoint de Object/Cast, le runtime Objective-C , la gestion semi dynamique des types de C#, etc sont tous arrivé dans ces langages pour prendre en compte des cas très difficilement voire impossible à modéliser avec un langage de classe strict.

Ne connaissant pas vraiment Objective-C, je ne parlerait pas de son cas.

Pour les types dynamique en C#, je vivais très bien sans et je n'ai encore jamais ressenti le besoin de les utiliser, ni vu aucun de mes collègues les utiliser. Ils ont l'avantage d’être purement optionnels.

En ce qui concerne Java, je n'ai jamais été confronté au genre de bibliothèque dont tu parles. Je ne vois pas quelles bibliothèque connue utiliserait l'introspection seulement pour passer au travers du typage lourd. En général c'est plutôt pour simuler d'autres fonctionnalités qui manquent au langage comme les closures ou piloter le code via des ressource externes (injection de dépendances, ORM, ...)
L'introspection n'a clairement pas été créée dans le but de contourner le typage, d'ailleurs si elle est si lourde à utiliser c'est bien en grande partie parce qu'elle s'occupe du typage.

à la base de la théorie des langages à base de classe la notion d'interface n'existe pas. elle n'a aucune raison théorique d'exister. l'héritage est largement suffisant. mais écrie un compilateur pour un langage à héritage multiple n'est pas simple. le travail du développeur est compliqué.

Sauf que si tu vas par là, à la base, l'héritage multiple n'existait pas non plus.
Chaque langage fait ces choix, mais si quasiment tous les langages modernes ont fait une croix sur l'héritage multiple façon C++ et se tournent plutôt vers des systèmes d'interfaces ou de traits, c'est bien parce qu'il apporte souvent bien plus de problèmes que de solutions. On peut le regretter, mais la encore tout est toujours une question de choix.

pour ma part je pense que c'est mon boulot et pas celui d'un quelconque outil que d'être vigilant.

Pour ma part, je pense que c'est le rôle des deux. Un outils ne fait pas tout mais il est fiable à presque 100%. Ce n'est clairement pas le cas des programmeurs, même des meilleurs.
Et les principaux conseils que j'ai pu lire venant des "meilleurs" programmeurs, c'est de rester autant que possible dans des choses simples, cadrées et avec un minimum d'effet de bord pour éviter les comportements imprévus, bref, plus ou moins ce que les langages strict essaient d'imposer.
Croire que, parce que le programmeur est bon, on évitera les erreurs, fini selon mon expérience toujours mal, parce que on maitrise rarement le niveau de compétence de toutes les personnes qui interviennent sur une applications et que même les meilleurs font des erreurs.

Donc quand on a un cadre permettant d'éviter toute une famille d'erreur, c'est toujours bon a prendre. Sans compter que dans le cas du typage statique, ça a aussi un impact positif sur les performances.

[pjassemat]

J'ai peu utilisé javascript mais d'après les exemples, il semble que Javascript fasse parti des langages où c'est le contenu qui défini le type de la variable ?
Un peu comme Lisp ?

var totoAsChaine = '123' => c'est une chaîne
var totoAsNombre = 123 => c'est un nombre

La donnée est donc typée par son contenu contrairement aux langages où la donnée est typée lors de sa définition (C, C++, Java ...).

String totoAsChaine = "123" ; => chaîne obligatoire...
int totoAsNombre = 123 ; => nombre entier obligatoire...

Ce qui n'empêche pas de faire des contrôles sur le type des variables et de lever des exceptions.

Mais bon dire que c'est fortement typé c'est juste pour faire du buz non ?
Dans un tel langage il faut contrôler en permanence le type des arguments non ? Dites moi que je me trompe...

[poringkiller]

totalement d'accord, je rajouterai même qu'un langage de script n'est pas fait pour faire des applications, comme son nom l'indique c'est pour faire du script.

Son nom indique aussi qu'il est apparenté au Java, et pourtant ce n'est pas du tout le cas. Depuis quand les caractéristiques d'un langage sont-elles définies par leur nom ?

Javascript est avant tout un langage de programmation, il est utilisé pour des moteurs 3D, des applications serveurs, des applications clients, et des et également pour des scripts.

Javascript est un langage incompris, car sa syntaxe ressemble pour beaucoup à celle du C et Java, mais ses paradigmes sont totalement différents, ce qui a tendance à frustrer les utilisateurs qui s'y attaquent sans l'avoir étudié avant (j'en faisais moi-même partie il y a peu). Mais réfléchissez-y avec vos yeux de développeur, est-il raisonnable de programmer dans un langage que vous n'avez pas étudié ? Et pourtant c'est l'approche que bon nombre de gens ont avec ce langage, car sa syntaxe peu verbeuse le rend facilement accessible.

Oui, en cours on nous apprend plus souvent l'héritage par classe, ce qui devient inutile (et source d'erreurs) quand on s'attaque à l'héritage par prototype, cependant, le fait que ce soit différent n'implique pas que ce soit erroné, il faut juste réfléchir d'une autre manière.

Aujourd'hui, je peux modifier mon code JS en temps réel et voir les implications directes de ces modifications sur mon application qui continue de tourner. Un langage compilé ne permet pas ce genre de choses.

Aujourd'hui, l'intelligence artificielle qui gère l'éclairage de mon appartement est codé en javascript, ce n'est pas du code "bricolo", c'est maintenable, clair et structuré en modules, un peu comme les langages compilés que vous semblez tant vénérer, alors renseignez vous avant de juger, vous pourriez comme moi y découvrir une beauté insoupçonnée.

[23JFK]

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

C'est un guerre de paroisse inutile, les deux concepts sont très proches et souvent indissociables.