Discussion :

[sekaijin]

C'est effectivement une définition que l'on peut choisir.
une des définitions donnée est celle-ci

les conversions implicites de types sont formellement interdites. Si de telles conversions sont possibles, le langage est faiblement typé.

dans ce cas Java est faiblement typé car

Code :

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

1
2
         Integer i = 5;
         String a = "test : " + i;

Le puriste de Java me dirons que dans ce cas c'est la méthode Integer.toString(); je réponds tout comme en javascript et dans ne nombreux langage.

une autre définition parfois combiné avec la précédente parfois non est

la compilation ou l'exécution peuvent détecter des erreurs de typage. Si ces erreurs ne sont jamais reconnues, le langage est faiblement typé

Lorque je fais

Code :

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

a= Math.sin("t");

si cela me retourne NaN (Not a Number)
Ais-je détecté que le type est incorrect ?
Math.sin étant une méthode don la signature prends tout objet y a-t-il eu une erreur non détecté ?
JS serait-il fortement typé si tout d'un coup aulieu d'utiliser la LIB standard j'en utilisait une qui vérifie le type de Math.sin ?
Que dire des fonction qui retourne une code 0 1 -1 et ne lève aucune exception ?

Je trouve que tous cela est bien plus ambigüe qu'il n'y parait.
Si je réuni ces deux définitions j'aurais tendence à dire que JS est faiblement typé.

Mais je peux choisir d'autre définition. par exemple

Un langage est faiblement Typé s'il autorise un objet à changer de type au cours de sa vie.

de tels langages existes. je pourais faire

Code :

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

1
2
3
4
5
6
7
8
9
Object a = new Integer(5);
Integer b = a;
typeof a; // Integer
log(b); //5
a.toString();
String c = a;
typeof a; // String
log(b); //null
log(c); //"5"

dans un tel exemple les référence a b et c ne change jamais de nature. un copilateur type Java pourait donc vérifier les type et ne trouverait aucune erreur de type.
pourtant l'objet à changé de nature en cours de route.
si je prends les deux première définition ce langage est fortement typé. si je prends la dernière JS est fortement typé.
qui croire ?

Benjamin C. Pierce American professor of computer science at the University of Pennsylvania.
author of one book on type systems, Types and Programming Languages ISBN 0-262-16209-1. has also edited a collection of articles to create a second volume Advanced Topics in Types and Programming Languages ISBN 0-262-16228-8. à dit

J'ai passé quelques semaines à essayer de clarifier les terminologies « fortement typé », « statiquement typé », « sûr », etc., et j'ai trouvé cela extraordinairement difficile… L'utilisation de ces termes est si diverse qu'elle les rend presque inutiles.

Je suis du même avis. Sur la grosse centaine de langage que je connais (plus ou moins bien) la diversité est telle que je suis incapable de choisir une définition de fortement typé ou faiblement typé.
Je préfère comprends le typage du langage que de savoir s'il est fortement ou faiblement typé.
pour moi le typage le plus faible est

Un langage est faiblement Typé s'il autorise un objet à changer de type au cours de sa vie.

à l'opposé le plus fort typage est celui qui interdit toute utilisation d'un type à la place d'un autre. et qui donc impose à chaque objet le nécéssitant la présence d'une méthode explicite (comme toString() en Java) appellée explicitement.

Code :

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

String a = "test : " + i.toString();

entre les deux existe une multitude de définition qui donne une palette de couleur au choix.
A+JYT

[sosolal]

Disons qu'on s'en fiche un peu, de la force du typage .

[la.lune]

C++ qui est communément admi comme fortement typé permet d'écrire

Code :

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

a=new Array()+new Number(4)-new String("2")+new Boolean(true)

. cela ne fait pas de C++ un langage faiblement typé.

Impossible de faire un truc pareil en C++, les opérateurs surchargés s'appliquent tout simplement sur les références des vers les objets, mais pas sur les objets elles même ou non plus sur des pointeurs comme ça, l'opérateur new en C++ fait une instanciation dynamique et retourne un pointeur sur l'objet.

Et l'instanciation normale ne se fait même pas comme en Java et JavaScript. Mais comme MaClass objet(pramsduconstructeur); du coup impossible d'appliquer directement un opérateur directement sur l'objet qu'on vient de créer. On peut à la rigueur accéder en faisant faire appel aux références des objets comme ça:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class A {int a;
public:
 A(int b){
this->a=b;
};
A operator +(A a){
this->a=this->a+a.a;
return *this;
}
int getVal(){
return a;}
 
 
void affiche(ostream &flux) const{
flux<<a<<"\n";
};
 
 
};
std::ostream &operator<<(std::ostream &flux, A const& a)
{
    a.affiche(flux) ;
    return flux;
}

Ainsi dans Main je pourrais faire appel au références sur les objets

Code :

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

1
2
3
A a(2);A b(3);
a=(*new A(3))+(*new A(3));
cout<<"a="<<a;

a=6

Le plus important ici, c'est qu'il doit exister une définition préalable de l’opérateur + ce qui n'a rien n'avoir avec la définition standard du lagunage, donc un contrat qu'on définit entre les références, et l'opérateur joue juste le rôle d'un simple nom de méthode qu'on va appeler.

Mais pourquoi JavaScript se donne le droit d'appeler des opérateurs sur d'autres objets sémantiquement aucun sens, pas de contrat défini, sans se soucier des dangers qui peuvent exister alors que ça donne des codes dépourvus de toute sens, à quoi ça sert vraiment de définir des types pour nos objets s'ils peuvent être placés n'importe où.
Quand je définis l'opérateur moi même les gens saurons que j'ai changé ce qui se passe dans le normale. En JS on ne comprend rien du tout. Des appels statiques des opérateur sur toute chose.

En javaScript tout comme en Java lorsque tu crée un Objet il a un certain type et celui-ci ne changera jamais jusqu'à sa destruction

Mais il faut bien dire l'objet indépendamment de là où il est stocké, car déjà l'objet en soi je ne peux pas le modifier c'est comme vouloir faire:
new Array()=12 ou faire même si je veux écraser l'ancien new Array(1,2,3)=new Array(0,1);, il va refuser
Ici il sait dire "Ah cette assignation n'est pas autorisée", et ben tout simplement par ce que ce sont des objet et c'est le moment de la création des objets eux même et pourtant il permet de faire le bordel en manipulation.

Par contre en C++ vu que l'exemple précédant je travaillais comme avec des variables, je peux faire facilement comme ça:

Code :

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

cout<<"a="<<(*new A(3)=*new A(5));

a=5

En 2e lieu je crois qu'on mélange dans le débat, mais qui vous a dis que typage dynamique est synonyme de faiblement typé c'est juste les variables qui ne sont pas typés statiquement, mais le problème en JavaScript se pose sur les contenus des variables et des objets, comment les moteurs JavaScript sont aussi con de ne pas pourvoir dire que tout ceci n'a pas de sens:

Code :

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

a=new Array()+new Number(4)-new String("2")+new Boolean(true)

JavaScript est assez intelligent pour que tu n'ai pas à écrire le cast

Je n'appel pas ça de l’intelligence mais l'inexistence de typage lui oblige, et gare à nous au contenu, JavaScript n'est pas responsable.

Moi je vois là, une faiblesse car au préalable JavaScript, nous dit la règle suivante: "Moi JavaScript: je ne m'intéresse pas aux types des données que vous me fournissez, moi j'évalue tout juste les contenus que je trouve dans les variables ou placés explicitement dans les instructions et puis je regarde l'opérateur, alors si j'arrive à vous retourner quelque chose tant mieux pour vous, sinon je vais vous insérer ou retourner un bon NaN dans vos résultats et tant pis pour vous, débrouillez vous je ne suis pas là pour faire du social".

Alors là je dois suivre le jeu en tant que développeur aussi JavaScript et je dis ok ok JS ne se soucie pas alors je vais pouvoir faire tout ce que je veux, mais si je me trompe un jour j'aurais un bon et je ne saurais jamais où est tel.

Moi si on me dit d'écrire un compilateur de JavaScript je serais très content car le jeu est très simple je ne suis pas obligé de dire que quoi que se soit ni lever une exception.

Ce me casse la tête c'est qu'en JavsScript je ne peux même pas tester si ce foutu NaN existe ou pas avant de décider que si l'instruction a pu en sa totalité la retourner, car en toute malhonnêteté intellectuelle JS a l’audace de considérer NaN comme "A" ou 2. Ce qui fait que entre le debut de l'instruction et le point virgule il peut y avoir un NaN quelque part c'est simple il va l'insérer dans le résultat.

Un petite exemple si l'utilisateur aura à insérer des nombres à virgule ou moi même j'ai oublié dans une variable de type string contenant le nombre venant du serveur ou en entrée, donc si je me trompe je fais b="2,5" au lieu de b="2.5" et puis je fais

Code :

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

1
2
b="2,5";
var result="VAL"+12/b+2*2+"FINAL";

result="VALNaN4FINAL"

C'est ça ce que vous appelez détecter une erreur de type, au lieu de me déclencher une erreur, mon utilisateur a devant lui un bon NaN inséré dans le résultat.

dans ce cas Java est faiblement typé carCode :
Sélectionner tout - Visualiser dans une fenêtre à part

1 2	Integer i = 5; String a = "test : " + i;

Il n y a pas de conversion implicite ici, il y a de la concaténation combien de fois on va vous répéter la même chose, si je fais:

Code :

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

String a = "test : " + 1;

où est la conversion implicite, Java permet de faire

Code :

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

int i=Integer(5)

pour les types primitifs et ça s’arrête là.
Une conversion implicite c'est qu'on pusse faire des calculs sur des chaines, ÇA N'EXISTE PAS EN JAVA
Je ne peux pas faire

Code :

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

Integer i=5-"3"

Mais quand tu dis ceci:

a= Math.sin("t");si cela me retourne NaN (Not a Number)
Ais-je détecté que le type est incorrect ?

Mais que ce que tu veux qu'il fasse le "t"? Dis moi? La première règle en programmation "TOUTE INSTRUCTION DOIT RETOURNER QUELQUE CHOSE" ou moins rompre le programme. NaN est une valeur, je peux faire NaN.toString()=="NaN", contrairement à undefinned que je ne peux pas faire undefined.toString(). Et JavaScript ne renvoi quelque chose de type undefinded, sauf une pour variable non initialisés ou qui sont vides si là ils pointaient est détruit. POINT BARRE
On n'appelle pas ça détecter une erreur, il ne sait rien faire avec le "t" donc il se débrouille pour renvoyer une valeur moche et polluer mon programme

Détecter une erreur c'est le signaler, rompre le programme pour ces irrégularités de type ou au moins un warning, quelque chose comme ça mais pas le silence. Une raison de plus que je serais le premier candidat pour l’écriture d'un moteur de JavaScript, comme le jeu est aussi simple que ça.

dans un tel exemple les référence a b et c ne change jamais de nature. un copilateur type Java pourait donc vérifier les type et ne trouverait aucune erreur de type.
pourtant l'objet à changé de nature en cours de route.

Je m'excuse mais là à présent vous commencez à dire des chose que je ne comprend pas du tout.
Tu reviens sur la même discussion qu'une VARIABLE DE TYPE OBJET PEUT CHANGER DE RÉFÉRENCE VERS UN AUTRE OBJET EN COURS ROUTE, et non pas l'objet avec un type déjà défini ou avec lequel on a assigné une valeur. Est ce que ça à changer de type en cours de route, il est resté et restera toujours de type Object jusqu'a la fin du programme. Mais essaye de Changer c ou b pour voir

Déjà je me demande quelque langage que si je fais a.toString(); alors a devient de type String? C'est quel langage ça, c'est complètement ABSURDE et IMPOSSIBLE à moins que toString() ne soit pas une méthode d'instance, une sorte de méthode static surchargé syntaxiquement comme les méthodes d’extension de C#. Comment une méthode d'instance appeler sur un objet, va détruire l'instance elle même et faire appel à une autre instance d'un autre type et l'affecter à cette variable elle même. C'est de la magie ça.

Une instruction comme ça this=new MaClass() c'est peut être chez les extra-terrestres. Si tu me dit qu'on fait a=a.toString(), on écrase l'ancien pour la nouvelle valeur j'aurais comprendre, ce qui fait que b pointe sur NULL car l'ancien objet est complètement détruit, donc b devient comme une variable non instancié.
Dans toutes les circonstances les deux points ne sont pas respectés par JavaScript. Et comme j'ai dis que l'opérateur de concaténation en Java par exemple à été bien défini pour prendre les en 2e opérandes les objet de type primitifs, qu'il soit définis avec les type primitif en soi ou les class représentant les types primitifs et ça s’arrête là. PAS DE CONVERSION IMPLICITE

Benjamin C. Pierce n'est pas un envoyé de Dieu, c'est son avis et ça s’arrête là, il y a pas un illuminé en programmation pour orienter les avis du monde.

Dans tout ça si le langage dont les concepteurs n'ont pas su fortifier le concept de type pour me m'aider moi développeur a éviter les bug d'ordre type sans que je sois obligé à faire des logs partout dans mon code mais il ne m'assure pas que les erreurs de types seront signalés que ça soit en compilation ou interprétation, alors il est faiblement typé. Même si vous criez mille fois qu'il ne l'est pas.

Je continuerais à codé pour JavaScript mais dans ma conscience c'est un mal nécessaire.

[sekaijin]

Salut la lune
les expressions que je donnais à propos de C++, Java et autres sont à prendre sur le FOND pas sur la forme.
je ne parlais pas de code je donnais un principe :
en C++ on peu définir un opérateur + qui prends un String et un Integer pour retourner une String.
et on peut faire cela quelque soit le type des objets. passé en paramètres.

Javascript ne se donne aucun droit sur l'interprétation sémantique des paramètres. l'opérateur + à une signature définie en C++ et il l'utilise. que cette signature soit celle que vous attendez ou pas ne change rien. il n'y a aucune magie aucune transformation il y a juste l'application d'une méthode simple.
la définition de cette méthode prête à discussion. pourquoi pas mais ça reste tout comme en C++ l'application d'une méthode conformément à sa signature.

quant au NaN si je fais une méthode C++ sinus qui prends en paramètre une référence à tout type d'objet
et qui retourne NULL si le paramètre ne peut être utilisé pour faire un sinus
C++ n'est pas pour autant faiblement typé.
Pourquoi la définition de la même fonction en JS ferais de JS un langage faiblement typé ?
Je ne dis pas que c'est une bonne chose. je dis que c'argument ne peu pas pour java impliqué qu'il est fortement type et impliquer pour javascript le contraire. ce n'est pas un argument valable.

si je remplace la lib standard de JS par la mienne qui comme en C++ vérifie le Type et produit une exception
JS sera-t-il pour autant fortement typé ?
pour moi non dans les deux cas. ce n'est pas la signature des opérateurs ni des méthodes qui permettent de dire qu'un langage est faiblement type.

Tu dis détecter un erreur c'est lever un exception une erreur un warning. crois tu qu'avant l'introduction des exception dans les langage on ne gérait pas les erreurs ?
on trouve encore des fonctions dans des langage pourtant strict qui retourne un int indiquant comment s'est déroulé l'exécution.
la encore je ne dis pas que c'est la meilleurs façon de faire. mais elle existe et elle permet de détecter les erreurs.

Code :

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

1
2
3
4
5
if (0 < read(fs, buff) {
  ...
} else {
  ...
}

ce n'est donc qu'un choix dans la façon de programmer. et je comprends qu'on préfère gérer des exceptions plutôt que de tester des valeurs de codes retournés.

détrompe toi écrire un compilateur JS est autrement plus complexe que d'écrire un compilateur C++. car justement c'est l'analyse syntaxique et sémantique qui permets d'inférer les types. alors qu'un C++ c'est le développeur qui le fait. et justement non JS ne se moque pas des types. il les respectes.
quand à ce que tout le monde prends pour de la conversion de type il ne s'agit que d'appel de méthodes.

enfin dans mon exemple

Code :

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

1
2
3
4
5
6
7
8
9
Object a = new Integer(5);
Integer b = a;
typeof a; // Integer
log(b); //5
a.toString(); // Modifie la zone mémoire alloué par new Integer(5); pour en faire une string
String c = a;
typeof a; // String
log(b); //null
log(c); //"5"

je parle de langage capable de changer le type d'un Objet. je ne parle pas de a b ou c dans ce code je parle de la zone mémoire créé par new Integer(5); dans certain langage l'appel a.toString(); converti la zone mémoire référencé par a et b en une String. mais comme b est de type Integer, le runtime casse la référence b vers cette zone. ni a ni be ni C n'ont changé de type pourtant la zone mémoire référencé par a est devenue une string

Code :

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

1
2
3
4
5
6
7
8
Object a = new Integer(5);
//on vérifie le type de l'objet référencé par a c'est un Integer
typeof a; // Integer
log(b); //5
a.toString(); // Modifie la zone mémoire alloué par new Integer(5); pour en faire une string
//on vérifie le type de l'objet référencé par a c'est une String
typeof a; // String
log(c); //"5"

l'objet à changé de type.
Je ne discute pas de l'utilité de tel langages (s'ils existe c'est pour répondre à des besoins)
Je dis juste que de mon point de vu personnel il ne fait aucun doute que de tel langages sont faiblement typés
Alors qu'un compilateur à la Java ne trouverait rien à redire.
de mon point de vu la vérification syntaxique n'est donc pas suffisante pour conclure sur le fait que le langage est fortement typé ou pas car j'ai deux langage qui respecte cette règle de lever une exception ou une erreur sur l'analyse syntaxique du code alors que l'un est fortement typé et l'autre non.

je suis entièrement d'accord pour dire que
Benjamin C. Pierce n'est pas un envoyé de Dieu
mais ce n'est pas parce que tu as choisi 1 définition parmi des centaines pour dire ce qu'un langage faiblement typé que c'est une vérité absolue. B. C. Pierce n'est qu'un parmi d'autre qui c'est penché sur ce problème. et il a trouvé beaucoup trop de définitions pour conclure.

cela n'empêche pas de faire un choix. il suffit d'être conscient que c'est un choix.

Je tiens à rappeler ici que je ne conteste pas que JS soit faiblement typé. de mon point de vu perso c'est le cas.
ce que je conteste ce sont les arguments avancés.
Non JS ne fais pas n'importe quoi. Non Js ne converti pas les objets au petit bonheur la chance, non JS ne ne moque pas des type.

Je conteste les arguments qui veulent prouver que JS est faiblement typé en se basant sur des assertions qui en C++ Java ou autre donne le contraire.
Pour moi une telle expression ne prouve rien. c'est le B.A.BA de la logique
si assertion A alors faiblement type
assertion A et JS alors faiblement typé
assertion A et Java alors fortement typé

A+JYT

[phildepantin]

Quitte à faire de la sémantique terminologique, autant le faire correctement.

1. Javascript n'est pas un langage orienté objet.

2. Tout n'est pas objet dans Javascript, contrairement à Ruby, par exemple, ou même les valeurs nil, true et false sont des objets.

[pterrat]

JavaScript natif est un langage un peu méconnu au niveau du typage. Il est très compliqué de gérer un typage en JS qui se gère automatiquement d'ailleurs, ça va vite de faire du code dégueulasse.

L'avenir est dans le TypeScript maintenant, qui permet de gérer tout un tas de types de manière beaucoup plus efficace. Et surtout TypeScript est beaucoup plus lisible à ce niveau là et demande moins de connaissances pour des débutants.

Pareil en JavaScript, les classes n'existent pas, on parle d'un langage orienté prototype. Mais encore une fois, c'est tellement une galère à gérer correctement que honnêtement, autant pas s’embêter avec ça.

Exemple de classe en TypeScript :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class Lion extends Animal {
  sex: string;
 
  constructor(name: string, sex: string) {
    super(name);
 
    this.sex = sex;
  }
 
  shout(): string {
    return "Rooooaarrr!"
  }
}

La même en VanillaJs (Javascript natif)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
var __extends = (this && this.__extends) || (function () {
    var extendStatics = Object.setPrototypeOf ||
        ({ __proto__: [] } instanceof Array && function (d, b) { d.__proto__ = b; }) ||
        function (d, b) { for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p]; };
    return function (d, b) {
        extendStatics(d, b);
        function __() { this.constructor = d; }
        d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());
    };
})();
var Lion = /** @class */ (function (_super) {
    __extends(Lion, _super);
    function Lion(name, sex) {
        var _this = _super.call(this, name) || this;
        _this.sex = sex;
        return _this;
    }
    Lion.prototype.shout = function () {
        return "Rooooaarrr!";
    };
    return Lion;
}(Animal));

Si vous voulez en savoir plus sur les différents types en TypeScript, vous pouvez aller voir cet article

Si vous voulez continuer à vous embêter avec du JS natif, je vous souhaite bon courage
(Si vous avez une TMA à faire sur du Js natif, je vous souhait encore plus de courage )

[SylvainPV]

@pterrat: le code ci-dessous est du JS standard (norme ES2015), qui fonctionne sans transpilation nécessaire sur 90% des navigateurs. Et babel-preset-env s'occupe des 10% restants sans problèmes.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class Animal {
	constructor(name){
		this.name = name;
    }
}
 
 
class Lion extends Animal {
  constructor(name, sex) {
    super(name);
 
    this.sex = sex;
  }
 
  shout() {
    return "Rooooaarrr!"
  }
}
 
 
const simba = new Lion()
simba.shout()

Typescript se calque volontairement sur les évolutions du langage JavaScript pour maintenir son interopérabilité (on peut renommer un *.js en *.ts et ça doit compiler). On peut vanter les syntaxes spécifiques TypeScript comme les enums ou le JSX, mais pour ce qui est des classes, ça fait partie du standard

[pterrat]

Tu as raison. Il me semble de mémoire que les classes de la norme ES2015 ne sont pas prises en compte par IE.

[Gabbby]

Pour moi, cet article est proche du grand n'importe quoi. Des règles générales :

- un langage fortement typé n'admet pas le typage dynamique. Point !
- un langage fortement typé refuse de s'éxécuter s'il y a une erreur de type : il faut d'abord rendre les types (paramètre, affectations) compatibles pour exécuter le code. C'est une règle générale, pas absolue.
- un langage fortement typé peut être statiquement analysé : dès qu'un langage n'est pas statiquement analysable, il n'est pas fortement typé. C'est ce qui permet les assistants profonds et la détection d'erreur lors de la frappe du code.
- un langage fortement typé objet respecte la hiérarchie des classes : il applique le principe de Liskov (principe de la programmation objet)
- non JS n'est pas un langage objet : il permet seulement de simuler des classes, mais n'a aucunes des qualités requises pour pouvoir être considéré comme fortement typé : ni encapsulation, ni héritage, ni polymorphisme, ni généricité, ni interface (contrat), ni contraites de types, ni abstractions, rien... C'est un langage de script qui permet seulement de singer les vrais langages objets !

[psychadelic]

@Gabbby Titrer que JavaScript est un langage fortement était juste un titre provocateur, ainsi que l'argumentation qui en a suivi.

Et tu n'es pas le seul à avoir pris la mouche pour réagir sur le sujet proposé.

En fait, je suis relativement d'accord avec ce qu tu a écrit, jusqu'a

- non JS n'est pas un langage objet :...

je te renvois à l'article de sylvainpv Onze idées fausses sur l'héritage en JavaScript
mais il doit y avoir d'autres, car que tu le veuilles ou non JavaScrit est un langage Objet, mais qui n'utilise pas un mécanisme par classes mais par prototypes.
Ce qui est presque normal puisque c'est un langage interprété.

C'est un langage de script qui permet seulement de singer les vrais langages objets !

C'est un peu violent non ?
Voir même un peu méprisant envers la communauté de développeurs travaillant sous JavaScript sous l'une ou l'autre de ses multiples faces : NodeJS, Angular, Electron..
et de ses incroyables réalisations, comme Visual Studio Code de Microsoft, NetFlix (ils ont laissé tomber Java en 2015) ...

D'ailleurs, cela ne t'étonne pas que le Langage JavaScript soit l'un des plus utilisé sous GitHub, stackOverflow ?
Ne vas pas me faire croire que tous ces contributeurs sont des écervelés !

https://madnight.github.io/githut/#/...equests/2017/4
https://insights.stackoverflow.com/s...017#technology

[tomlev]

- un langage fortement typé objet respecte la hiérarchie des classes : il applique le principe de Liskov (principe de la programmation objet)

Mais un langage fortement typé n'est pas forcément un langage orienté objet (par exemple Haskell est un langage purement fonctionnel, sans aucune notion de POO, et il est très fortement typé). Et de toute façon, le respect du principe de Liskov ne dépend pas du langage, mais du programmeur... Tu peux violer ce principe en Java, en C#, en C++ ou n'importe quel autre langage objet.

Bref... De toute façon je pense qu'avec l'arrivée de WebAssembly, les jours de Javascript sont comptés. Il va survivre encore un bon moment, et il aura sans doute toujours ses fans, mais je pense qu'à terme les gens utiliseront d'autres langages plus robustes, compilés en WebAssembly, pour le développement front. Voir démo de Blazor (prototype de framework SPA basé sur C# et WebAssembly) ici (à 31m45)

[SylvainPV]

@tomlev: pour arriver à utiliser des langages haut niveau qui compilent en WASM, il faudra encore du temps. Il n'a pas vraiment été pensé en ce sens, et beaucoup de fonctionnalités manquent encore. A court terme, transpiler directement en JS me paraît plus judicieux, comme le font déjà de nombreux langages: TypeScript, Kotlin, Haxe etc... Et on peut toujours utiliser WASM pour des tâches bien spécifiques, comme certains algorithmes ou des moteurs graphiques.

Si les ingénieurs derrière WASM n'arrêtent pas de répéter qu'il ne va pas remplacer JS, c'est parce qu'en taille de bundle JS aura toujours l'avantage (la js1k le prouve chaque année), et que pour un usage web classique, c'est ce qui compte le plus. WASM ne va pas remplacer JS, mais JS va probablement rejoindre WASM dans le rang des langages cible de compilation. Dans tous les cas, les développeurs auront plus de choix dans les langages à disposition, c'est ce qu'il faut retenir.

[Uther]

@tomlev: pour arriver à utiliser des langages haut niveau qui compilent en WASM, il faudra encore du temps. Il n'a pas vraiment été pensé en ce sens, et beaucoup de fonctionnalités manquent encore. A court terme, transpiler directement en JS me paraît plus judicieux, comme le font déjà de nombreux langages: TypeScript, Kotlin, Haxe etc... Et on peut toujours utiliser WASM pour des tâches bien spécifiques, comme certains algorithmes ou des moteurs graphiques.

Utiliser un langage de haut niveau est tout a fait possible, ça marche déjà plutôt bien par exemple avec C++ et Rust. Le principe de base, c'est que si on peut faire du bas niveau, on peut en principe faire du haut niveau vu que le haut niveau repose sur l'utilisation cadrée de concepts de bas niveau. L'inverse est plus difficile, même si ça n'est pas complètement impossible comme l'a montré asm.js.
Actuellement, le seul souci est pour les langages avec leur propre garbage collector qui ne peuvent pas partager directement leur objets avec JavaScript car les deux Garbage collector pourraient entrer en conflit. Mais il est prévu à l'avenir de permettre a WASM d'interagir directement avec le Garbage Collector du moteur JavaScript pour résoudre ce problème.

Si les ingénieurs derrière WASM n'arrêtent pas de répéter qu'il ne va pas remplacer JS, c'est parce qu'en taille de bundle JS aura toujours l'avantage (la js1k le prouve chaque année), et que pour un usage web classique, c'est ce qui compte le plus. WASM ne va pas remplacer JS, mais JS va probablement rejoindre WASM dans le rang des langages cible de compilation. Dans tous les cas, les développeurs auront plus de choix dans les langages à disposition, c'est ce qu'il faut retenir.

Des concours du genre de la js1k ne sont pas l’apanage du JavaScript, il y en a avec tout type de technologie.
De plus on ne peut pas comparer du code géré automatiquement et écrit à la main. Le code compilé a partir qu'autres langages est rarement optimal en taille.
Enfin, le WASM a été pensé pour être efficace en terme de taille et de performance. Son avenir en tant que cible de compilation me semble clair.

Si les promoteur de WASM annoncent qu'il ne va pas remplacer le JS partout, c'est surtout que le JS reste le seul langage utilisable directement dans le navigateur sans compilation, ce qui fait qu'il restera un choix pour son domaine original : le script d'interface simple.

[SylvainPV]

Si tu considères que C++ est un langage haut niveau, oui évidemment c'est possible, vu que C/C++ sont justement les langages choisis pour le MVP de WebAssembly. Je pensais plus à des langages comme Java, Scala, Kotlin... Comme tu le mentionnes, le garbage collector est un problème, parmi d'autres. Il y a tout un tas de compilateurs expérimentaux mais le code produit est trop lourd et soumis à plein de contraintes diverses. C'est pour ça que je dis qu'il faudra encore du temps.

On est d'accord qu'on ne peut pas comparer du code généré automatiquement et écrit à la main, il n'empêche que JS reste très optimal même en cible de compilation. Sa syntaxe permissive permet d'avoir des minifiers très efficaces. Dans des concours comme le js1k, le plus gros des gains en taille est fait automatiquement par des packers spécialisés, même si les golfers doivent comprendre comment ils fonctionnent et retravailler leur code pour en tirer le maximum.

Je dis que JS va devenir un langage cible de compilation, mais en vérité il l'est déjà. Des centaines de langages compilent vers JS et même quand on code en JS vanilla, aujourd'hui on passe par tout un process de build babel/uglify/prepack/trucbidule et le code en sortie ne ressemble plus vraiment à celui d'origine. Tous ces compilos et outils ne vont pas migrer vers WASM, même quand le support et les fonctionnalités seront là, simplement parce que le code en sortie sera plus lourd que la version JS minifié, et que le gain de perf ne vaudra pas le coup par rapport à l'augmentation de taille. Pour un usage web classique, je reprécise encore. On verra si le futur me donne raison ou pas.

[Uther]

Si tu considères que C++ est un langage haut niveau, oui évidemment c'est possible, vu que C/C++ sont justement les langages choisis pour le MVP de WebAssembly. Je pensais plus à des langages comme Java, Scala, Kotlin... Comme tu le mentionnes, le garbage collector est un problème, parmi d'autres.

Ok tu veux plutôt parler des langages avec un gros Runtime que des langages de haut niveau en général.
Dans ce cas là, c'est vrai qu'il faut inclure le Runtime dans le WebAssembly si on veut les faire marcher avec l'infrastructure existante. Donc effet, c'est plus lourd, il n'y a pas de miracle. Mais s'il veulent faire un backend WASM officiel, il y a fort a parier qu'il arriveront à produire un Runtime allégé.

Je dis que JS va devenir un langage cible de compilation, mais en vérité il l'est déjà. Des centaines de langages compilent vers JS et même quand on code en JS vanilla, aujourd'hui on passe par tout un process de build babel/uglify/prepack/trucbidule et le code en sortie ne ressemble plus vraiment à celui d'origine.

En effet, le JavaScript est actuellement la cible de compilation de toutes les technologies web qui ciblent le client. Et le but de WebAssembly est justement de remplacer JavaScript dans cet cet usage précis. Il faut voir que WASM a été étudié spécialement pour cela. C'est un format binaire qui il vise particulièrement à être rapide à télécharger et compiler.

Tous ces compilos et outils ne vont pas migrer vers WASM, même quand le support et les fonctionnalités seront là, simplement parce que le code en sortie sera plus lourd que la version JS minifié, et que le gain de perf ne vaudra pas le coup par rapport à l'augmentation de taille. Pour un usage web classique, je reprécise encore. On verra si le futur me donne raison ou pas.

Je ne doute pas que certains outils ne migreront pas, mais ça sera surtout par ce que c'est trop complexe de revoir toute leur infrastructure pour le WASM.

Par contre rien ne semble indiquer que JavaScript sera forcément plus léger que WASM. C'est vrai que JavaScript se minimise très bien, mais WASM est un format binaire conçu spécifiquement pour être léger. Les tests réalisé sur emscriptem, indiquent que WASM est 10 à 20% plus léger que du JavaScript (les deux étant minimisés et compressés).

Il faut aussi voir que la taille n'est pas le seul élément a rentrer en compte. WebAssembly se compile également bien plus vite avec des performances potentiellement meilleures.

[SylvainPV]

le but de WebAssembly est justement de remplacer JavaScript dans cet cet usage précis. Il faut voir que WASM a été étudié spécialement pour cela.

La FAQ du site officiel affirme pourtant tout le contraire: http://webassembly.org/docs/faq/#is-...ace-javascript

C'est également ce que j'entends de la bouche de tous les gens qui travaillent sur WASM depuis des années, Brendan Eich en tête. WASM ne remplacera pas JavaScript, il sera complémentaire dans son usage.

Je veux bien voir à quels tests Emscripten tu fais référence pour le gain de 10 à 20%, pour voir si ça correspond vraiment à un usage web classique ou si c'est juste une démo technique genre suite de Fibonacci.

[headmax]

J'ai testé cette technologie WebAssembly, elle semble être adapté a une personne venu du software vers du web sans connaissance réel en javascript, elle ne remplacera pas javascript d'ailleurs cette techno est limité a ça dans une "VM" mais en utilisant l'existant de javascript donc on est dans le même contexte et les risques sont les mêmes que le langage natif. Les nouvelles implémentations html5 ne sont pas toutes gérés en totalité, impossibilités d'utiliser les sockets..., une ressource externe type DLL's (...unsafe), ce limite a des appels web services/api ...
J'y ai cru un petit moment, on est loin d'égalé JS ... l’intérêt peut être du fait qu'il fait partie du monde du .NET sa portabilité j'ai pas tout exploré, il ne s'impose pas si on a un minimum de connaissance JS l'intérêt peut être son côté POO et plus facile a maintenir et à gérer pour C#*JAVA C++...

[Uther]

La FAQ du site officiel affirme pourtant tout le contraire: http://webassembly.org/docs/faq/#is-...ace-javascript

C'est également ce que j'entends de la bouche de tous les gens qui travaillent sur WASM depuis des années, Brendan Eich en tête. WASM ne remplacera pas JavaScript, il sera complémentaire dans son usage.

Ça n'a absolument rien de contradictoire avec ce que j'ai dit. Je n'ai jamais prétendu que WebAssembly vise à remplacer JavaScript en tant que langage de programmation. JavaScript restera le seul langage de script directement intégré à tous les navigateurs et donc un choix privilégié pour les développements client légers.

Par contre, WebAssembly a spécifiquement été conçu pour être une technologie plus adaptée que JavaScript dans le rôle de cible de compilation pour les langages tiers.

Je veux bien voir à quels tests Emscripten tu fais référence pour le gain de 10 à 20%, pour voir si ça correspond vraiment à un usage web classique ou si c'est juste une démo technique genre suite de Fibonacci.

J'avais vu cette estimation là : https://hacks.mozilla.org/2017/03/wh...r-than-asm-js/
Ce n'est pas des simples démos techniques, mais pas non plus un usage web classique à base de manipulation du DOM, vu que WebAssembly n'est pas encore capable de faire ça directement. Il n'est pas impossible que Javacript puisse être légèrement plus léger en fonction des cas, mais il faut voir que l'écart ne sera probablement pas colossal, dans un sens comme dans l'autre.
Quand la technologie sera bien stabilisée, il sera généralement préférable d'utiliser une technologie de bytecode prévue pour ça avec de meilleures performances générales et des outils adaptés qu'un hack à base de transpilation.

elle ne remplacera pas javascript d'ailleurs cette techno est limité a ça dans une "VM" mais en utilisant l'existant de javascript donc on est dans le même contexte et les risques sont les mêmes que le langage natif.

Je suis pas sur d'avoir bien compris ce que vous voulez dire : cette phrase ne semble plutôt contradictoire.

Pour ce qui est des interactions avec le navigateur et la machine, WebAssembly sera en effet limité au API Web de JavaScript, accéder directement aux ressources de la machines (socket, bibliothèques systèmes,...) serait une terrible faille de sécurité pour un navigateur.
Donc au final, les risques de sécurité seront exactement les mêmes que pour le JavaScript.

Les nouvelles implémentations html5 ne sont pas toutes gérés en totalité

Le WebAssembly est loin d'être terminé. En effet, dans les implémentations actuelles, il lui manque encore l'accès à pas mal des API Web de JavaScript (notamment DOM). Mais à terme, WebAssembly devrait avoir accès à toutes.

[headmax]

Je suis pas sur d'avoir bien compris ce que vous voulez dire : cette phrase ne semble plutôt contradictoire.

En effet le terme "VM" que j'ai m'y entre me semble pas approprié, n'ayant pas assez de recule sur cette techno voici un lien bien plus explicite concernant ce sujet https://floooh.github.io/2017/06/09/...mystified.html

[SylvainPV]

Les configurations évoquées dans la FAQ stipulent que JS sera toujours utilisé en complément de WASM. Je pense notamment que la configuration 3 ("Mostly HTML/CSS/JavaScript app with a few high-performance WebAssembly modules") sera le cas le plus courant pour l'usage web classique. Le canvas de la config 2 sera bien joli pour les démos techniques, mais snobber le DOM n'est pas envisageable pour toutes les contraintes SEO/accessibilité/amélioration progressive...

Alors si JS reste incontournable, pourquoi ça ne serait pas une cible de compilation ? Ça l'est déjà actuellement comme expliqué précédemment, et si en plus le WASM rend obligatoire l'usage d'un compilateur, alors il n'y a aucune raison de s'en priver. Parions-même que dans les langages alternatifs, des frameworks viendront gérer à la place du développeur ce mélange de JS/WASM en sortie. Je ne m'avance pas à grand chose en disant cela, puisque c'est déjà ce que font les premiers frameworks expérimentaux là-dessus : https://github.com/aspnet/blazor ; https://github.com/DenisKolodin/yew