Discussion :

[Niark13]

Moi je suis plus dans l’idée que typage statique ou dynamique je m’en fiche, par contre je préfère carrément un typage fort (ça élimine quand même pas mal d’erreurs à la con, sournoises et qui peuvent être difficile à trouver).

+10000

J'ai beaucoup de plaisir à travailler en Python, qui bien que dynamique, a un typage fort qui interdit pas mal de ce que l'on voit dans les WAT*de JS.

Quand je vois les sommes faramineuses qui sont investies à la fois pour rendre JS plus rapide et pour développer des alternatives qui compilent vers JS (coffeescript, dart, typescript…), je me dis que l'avenir de JS est plus comme environnement d'exécution que comme langage de programmation.

[Orwel]

Le C est un bon exemple : selon le point de vue que l’on adopte il est soit faiblement typé, soir fortement. Par contre, il est indubitablement statiquement typé.

Quelque explication, s'il vous plaît. Pour moi, le C est un langage fortement typé (1 variable / 1 type) avec la possibilité d'interprété les données avec un typage dynamique (1 donnée / plein de variable avec des types différents).

La variable indique l'interprétation de la donnée, mais avec la magie du C on peut attribuer moult variable sur une même donnée.

Le typage faible c'est une variable qui peut bouffer n'importe quoi et faire n'importe quoi sans se plaindre. Ce qui est parfait pour des scripts.

Les WAT sont une forme de critique du langage, mais tournée avec humour. Si on accepte la critique, elle peut aider à progresser; mais il ne fait jamais la dénigrer purement comme cela est présenté dans l'article.

[Niark13]

Quelque explication, s'il vous plaît. Pour moi, le C est un langage fortement typé (1 variable / 1 type) avec la possibilité d'interprété les données avec un typage dynamique (1 donnée / plein de variable avec des types différents).

La variable indique l'interprétation de la donnée, mais avec la magie du C on peut attribuer moult variable sur une même donnée.

Le typage faible c'est une variable qui peut bouffer n'importe quoi et faire n'importe quoi sans se plaindre. Ce qui est parfait pour des scripts.

Les WAT sont une forme de critique du langage, mais tournée avec humour. Si on accepte la critique, elle peut aider à progresser; mais il ne fait jamais la dénigrer purement comme cela est présenté dans l'article.

« 1 variable / 1 type », ça n'est pas du typage fort, c'est du typage statique. La « force » d'un typage consiste à définir si les conversions types sont implicites ou pas.

C pour moi, est un langage statique à typage faible, parce qu'il autorise les conversion implicites (sans cast) de void* vers n'importe quel type de pointeur, et les entiers vers les enums. Ça n'est pas un défaut, mais un choix de conception.

Python est un langage à typage fort, parce que

Code :

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

"1" + 2

lancera une exception parce que le langage se refuse à trancher si le résultat doit être 3 ou "12". Le programmeur devra explicitement convertir vers l'un ou l'autre des types avant d'appeler l'opérateur +. Python a, en outre, un typage dynamique, parce qu'une variable peut se voir affecter des valeurs de types différents pendant sa durée de vie.

Je te rejoins sur l'interêt du typage dynamique pour les langages de scripts. Là où j'ai du mal, c'est quand on a à la fois du typage dynamique avec du typage faible (Javascript et ses conversions silencieuses).

[grim7reaper]

Quelque explication, s'il vous plaît. Pour moi, le C est un langage fortement typé (1 variable / 1 type) avec la possibilité d'interprété les données avec un typage dynamique (1 donnée / plein de variable avec des types différents).

Non, non et non.
Le typage est statique.
Le type est défini et vérifié à la compilation.

Si ensuite le langage fourni des opérateurs de coercition et défini des règles de conversions implicite ça ne change rien au fait que le type est statique. Tu n’auras pas une erreur à l’exécution si tu veux multiplier un entier par une structure, ça va claquer lors de la compilation. En cela, le typage est statique.

Pour l’histoire du typage fort/faible, comme je l’ai dit dans mon précédent message c’est sujet à interprétation. Pas de définition très claire, pas de séparation binaire.
Mais pour le côté faiblement typé je peux citer :
- tu peux mélanger les entiers et les flottants dans une expression arithmétique (impossible en Haskell, qui est très fortement typé, sans conversion explicite).
- ce genre de code est valide (les compilo‘ gentil émettent un avertissement, mais ça reste du C valide) :

Code C :

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

1
2
3
4
5
6
int main(void)
{
    double d = 0.0;
    int* p = &d;
    return 0;
}

Mais d‘un point de vue global, je suis d’accord que l‘on considère généralement que le C est fortement typé.
Après, comme fort/faible sont des notions relative tout dépend avec qui tu compares. C a un typage faible comparé à Haskell, mais fort comparé à Javascript.

[Yo Eight]

- tu peux mélanger les entiers et les flottants dans une expression arithmétique (impossible en Haskell, qui est très fortement typé, sans conversion explicite).

Si on peut, comme le montre cette session GHCi

Code :

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

1
2
3
4
5
6
7
 
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> 2 * 3.0 - 1 / 2
5.5

Le système d'inférence d'Haskell est suffisament intelligent pour correctement déterminer le type de l'expression:

Code :

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

1
2
3
 
Prelude> :t 2 * 3.0 - 1 / 2 -- affiche le type d'une expression
2 * 3.0 - 1 / 2 :: Fractional a => a

Cette expression pourra être 'convertie' selon le context d'utilisation en Float ou en Double par exemple

[Golgotha]

Je me suis toujours trouvé plus à l'aise à faire du JavaScript ou du python qu'a travailler avec un langage fortement typé comme java. Pour faire un parallèle (à la con) j'ai l'impression de faire une peinture au numéro avec Java, quand avec du JavaScript t'a une feuille blanche avec une grande liberté : Avec la peinture au numéro tu risque pas de faire une grosse merde mais c'est limité, avec la feuille blanche tu peux faire une grosse merde mais t'as plus de liberté.

Pour revenir au sujet, je pense qu'on peux se moquer de tout les langages et que ça ne sert à rien du tout... Chaque langage à ces particularités, ces qualités et ces défauts, la pluralité est toujours une bonne chose.

[grim7reaper]

Je me suis toujours trouvé plus à l'aise à faire du JavaScript ou du python qu'a travailler avec un langage fortement typé comme java.

Python est fortement typé, pas de différence avec Java à ce niveau là.
La différence est que Python (et Javascript) a un typage dynamique et que Java a un typage statique.
Elle est là la différence qui te rends plus à l’aise avec l’un qu‘avec l‘autre.
Par sur la différence typage faible/fort, sinon tu aurais aussi l‘impression de faire de la peinture au numéro avec Python, ce qui ne semble pas être le cas.

J’ai l’impression que beaucoup de gens mélange les notions de typage statique/dynamique avec les notions de typage faible/fort…

[Golgotha]

Python est fortement typé, pas de différence avec Java à ce niveau là.
La différence est que Python (et Javascript) a un typage dynamique et que Java a un typage statique.
Elle est là la différence qui te rends plus à l’aise avec l’un qu‘avec l‘autre.
Par sur la différence typage faible/fort, sinon tu aurais aussi l‘impression de faire de la peinture au numéro avec Python, ce qui ne semble pas être le cas.

J’ai l’impression que beaucoup de gens mélange les notions de typage statique/dynamique avec les notions de typage faible/fort…

Mélange ou n'ont pas le courage de faire un cours sur le typage ^^

Globalement c'est le coté langage de script qui me plait. Java (ou un autre langage comme java) avec un typage static et une compilation (de toute façon ça va ensemble...) ça rends le développement chiant, mais plus cadré ça je suis d'accord.

[Washmid]

A propos des applications lourdes, il y a depuis quelque temps des commerciaux développeurs qui semblent essayer de faire croire que oui, on peut faire des supers applications client lourd en javascript/HTML comme avec java/c#.

Petit exemple avec un commercial développeur de "15 ans d'expérience" :

http://blogs.msdn.com/b/dorischen/ar...-amp-tips.aspx

Conséquence, un de mes responsable a récemment sorti qu'on devait envisager de porter une de nos appli (500 000 lignes de code) en full javascript pour windows 8

Tout ça pour dire que certains ne font vraiment pas la différence entre grosse appli et petit script, dont on peut comprendre qu'ils reprochent à javascript ce genre de choses

[Paul TOTH]

A propos des applications lourdes, il y a depuis quelque temps des commerciaux développeurs qui semblent essayer de faire croire que oui, on peut faire des supers applications client lourd en javascript/HTML comme avec java/c#.

Petit exemple avec un commercial développeur de "15 ans d'expérience" :

http://blogs.msdn.com/b/dorischen/ar...-amp-tips.aspx

Conséquence, un de mes responsable a récemment sorti qu'on devait envisager de porter une de nos appli (500 000 lignes de code) en full javascript pour windows 8

Tout ça pour dire que certains ne font vraiment pas la différence entre grosse appli et petit script, dont on peut comprendre qu'ils reprochent à javascript ce genre de choses

mais bien sur qu'on peut faire des applications lourdes en HTML5/JS, très lourdes même

fut une époque ou Java/C# étaient critiqués de la même façon en disant qu'il n'était pas possible de porter une application de 500 000 lignes de C ou C++ dans ces langages.

en fait il y a deux points de vue, celui du technicien/développeur qui considère l'outil et son fonctionnement face au but à atteindre, et le dirigeant/commercial qui regarde la portée du produit: si Microsoft me dit que l'avenir c'est JS/HTML5, qu'est-ce que je vais m'enquiquiner avec l'avis d'un développeur qui ne veux manifestement pas se mettre à la page et garder son environnement de travail obsolète ?

Heureusement, j'ai des fois des clients qui veulent des solutions, et non des technologies, dès lors je peux librement choisir mon environnement de travail avec pour seule contrainte d'offrir au client un produit qui répond à ses attentes...et là ce n'est pas souvent du HTML/JS (ni même du C# ou Java d'ailleurs )

[Andromed]

Est-il normal qu'il trouve absurde le fait que Java différencie 1.0 et 1? Un troll que je n'ai pas capté peut être? J'espère.

En industrie, le typage est indispensable, c'est pour ça que les langage non typé (PHP, JS...) sont là que pour faire joujoue!

[wirenth]

Il y a encore des gens pour se lancer dans des flame war à propos de "leur" langage... ça me fait toujours marrer les types qui disent "je suis developpeur JS" ou "je suis développeur C++", etc... Parce que tu connais qu'un langage et tu l'utilises pour tout et n'importe quoi ? Mon menuisier ne m'a jamais dit "je suis menuisier marteau, parce que je peux tout faire avec, même si c'est pas idéal".

Quant au JavaScript, oui il contient de très nombreux pièges. Mais c'est pas grave parce que JavaScript is Web Assembly Language and that's OK

[xelab]

Quant au JavaScript, oui il contient de très nombreux pièges. Mais c'est pas grave parce que JavaScript is Web Assembly Language and that's OK

Je trouve cette comparaison assez facile et rapide. Quand je code en Java ou C++, je n'ai absolument pas besoin de connaître l'assembleur. Par contre si je code dans un langage qui compile du javascript, j'ai intérêt à connaître un minimum le fonctionnement du javascript (qui est quand même un langage de haut niveau) sous peine de ne parfois rien comprendre au résultat et aux éventuels bugs.

[getz85]

Pour ceux qui ne connaissent pas: http://wtfjs.com/

Il y a de sacrés pépites quand même, je doute qu'on puisse trouver des exemples aussi aberrants dans d'autres langages (parce que son exemple sur Java est complètement idiot )

[Bovino]

getz85, malheureusement, les exemples que je vois sur la première page ne démontrent qu'une chose : ceux qui les postent ne connaissent pas JavaScript...

Si je prends l'exemple

Code :

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

"Why am I a " + typeof + ""; // "Why am I a number"

typeof étant un opérateur, ce qui suit doit être l'opérande et + "" est un opérande valide puisque le + en préfixe est un opérateur de transtypage en nombre, donc une chaine vide transtypée en nombre (console.log(+"")) donne 0 et typeof 0 est bien un number. Il n'y a rien là de spectaculaire et tout cela est parfaitement décrit par ECMA262.

Bref, qu'on aime ou qu'on aime pas le typage dynamique, c'est un fait que JavaScript est un langage à typage dynamique et il faut le prendre en compte. Le corollaire, c'est que toute opération doit retourner un résultat et que si les paramètres de l'opération sont incompatibles, il faut les transtyper selon des règles. Or ces règles existent et il n'y a pas de surprise avec JavaScript si l'on connait ces règles.

[TNT89]

ceux qui les postent ne connaissent pas JavaScript...

Ca en reste néanmoins un problème : je ne connais pas (que très peu) JS, et je suis incapable par un quelconque raisonnement logique "naturel" de formuler le résultat sans le tester...

Je conçois que la plupart ne sont pas des morceaux de codes sains et courants. Par contre, l'interprétation des strings en int ou la comparaison des arrays semblent extrêmement scabreuses. Je suis persuadé que j'en ferai les frais très rapidement.

(Cela dit, ils ont aussi de bonnes lacunes en Mathématiques et en précision des formats flottants... cf "negative zero equal but not equal" et "magic increasing number"...)

[Bovino]

(Cela dit, ils ont aussi de bonnes lacunes en Mathématiques et en précision des formats flottants... cf "negative zero equal but not equal" et "magic increasing number"...)

Petit retour là-dessus parce que là encore, on charge JavaScript peut-être à tort...

Déjà, concernant le magic increasing number, ça n'a rien de spécifique à JavaScript, voir : The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic.

Concernant les zéros signés, je ne crois pas (sauf erreur de ma part, je suis prudent désormais) que ce soit non plus spécifique, mais que -0 soit égal à +0 ne me semble pas choquant, en rechanche que 1/0 et 1/-0 ne soient pas égaux, est logique vu que 1/0 vaut Infinity et 1/-0 vaut -Infinity donc à moins de considérer que les nombres forment une structure circulaire, heureusement que deux valeurs diamétralement opposées ne soient pas égales !

[Kaamo]

Le typage faible/dynamique vient du fait que Javascript n'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).

Bien que le typage faible ait ses inconvénients (conversion implicite en chaine de caractère : '5' + 6 === '56') il a ses points forts 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. Il faut avouer que le typage faible/dynamique dans ce sens nous arrange pas mal.
Ces valeurs sont interprétées à false : undefined, null, false, -0, +0, NaN, ''. Toutes les autres à true. Tout le monde en abuse de ce typage faible, et ne s'en plaint pas pour autant.

Une bonne pratique serait d'utiliser Boolean(), Number() et String() pour convertir une donnée vers le type attendu. Ainsi, les variables auront bien le type que l'on souhaite ! Exemple très simple, loin d'être complet, mais c'est pour montrer les possibilités de maitriser le typage de JS. Il faut aller plus loin que dans certains langages mais cette souplesse, si elle est maitrisée, n'est plus une contrainte mais une force.

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
function gestionVariables(mesInfos){
  var prenom = String(mesInfos.monPrenom);
  var age = Number(mesInfos.monAge);
  var loveJS = Boolean(mesInfos.loveJS);
 
  if (isNaN(age))
    throw "Type non valide pour l'âge !";
 
  console.log("Je m'appelle " + prenom + ", j'ai " + age + " ans et " + (loveJS ? "j'aime =)" : "j'aime pas =(") + " le Javascript !");
}
 
// Exemple 1 : Type non valide pour l'âge !
try {
  gestionVariables({ monPrenom: 'Toto', monAge:'blabla', loveJS: false});
} catch(e) {
  console.log(e);
}
 
// Exemple 2 : Je m'appelle Toto, j'ai 25 ans et j'aime =) le Javascript !
try {
  gestionVariables({ monPrenom: 'Toto', monAge: '25', loveJS: true});
} catch(e) {
  console.log(e);
}

[anykeyh]

Non mais le vrai "wat" dans javascript, c'est l'objet date :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
var dayInWeek = new  Date().getDay(); // Why?! x_x
var dayInMonth = new Date().getDate(); //Wat? 
var year = new Date().getYear(); //113? WAT?
 
var month = new Date().getMonth() + 1; // +1?! WAT?!
 
var now = new Date();
var now2 = new Date(now.getTime());
 
if (now != now2) { alert('WAT... ;_;?') }
 
if (now >= now2) { alert('WAT WAT WAT?!'); }

Je vous évite la gestion des fuseaux horaire avec "ce truc"
ça pourrait être risible ça ne coutait pas des millions d'euros chaque années en baisse de productivité...

Quand une personne me dit "mais non javascript c'est pas mal", je le questionne sur l'objet date, ça calme d'un coup.

[Bovino]

Code :

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

if (now != now2) { alert('WAT... ;_;?') }

Euh... fail...

Dans quel langage une instance d'un objet est égale à une autre instance ???