Discussion :

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

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

[grim7reaper]

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

Tout à fait d‘accord.
C’est vrai que quand je développe en Java, ça me manque d‘avoir un interpréteur interactif genre bpython (pour Python) ou pry (pour Ruby) pour tester rapidement des petits bouts de code (la flemme de créer une classe & cie juste pour tester une méthode ou 3 lignes de code).
Heureusement, avec Jython et Jruby, bah je peux récupérer cette avantage de l‘interpréteur interactif pour tester rapidement des petits bouts de Java. Très pratique

[Schouss]

javascript a des classes , pas au sens java mais ce sont des classes quand même , smalltalk ( dont java s'inspire ) n'a pas non plus de classes à la java.

une "classe" en Javascript c'est une fonction qui a un prototype auquel on assigne des membres.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var MaClasse = function(){
  // constructeur
  this.prop = "ma propriété"
}
 
MaClasse.prototype.doSomething = function(){ // un membre } 
 
// héritage
 
var MaSousClass = function(){
   MaClass.apply(this); // "super"
}
 
MaSousClass.prototype = new MaClass;

J'adore ce post. Il résume à lui tout seul le sujet. Le particularisme de la notion objet de Javascript est-il risible ?

[sedryk]

J'adore ce post. Il résume à lui tout seul le sujet. Le particularisme de la notion objet de Javascript est-il risible ?

En l'occurence, il s'agit de classe et non d'objet. De plus comme dit précédemment, on ne peut pas parler de classe en javascript mais plutôt de prototype !

La notion d'objet comme répondant à un prototype ne me semble pas risible juste différente de la notion d'objet comme instance d'une classe. D'ailleurs un typeof sur un objet prototypé "MaClasse" ou "MaSousClasse" (comme défini ci-dessus) répondra "object" !

[anykeyh]

Parler de typage fort/faible ou de notion de classe est un faux débat, car ce n'est pas ce qui pose problème en javascript.

Par exemple, en LUA pas de classes non plus, la notion de prototypage existe sous la forme de metatables, et là aussi ça peut dérouter quand on a appris l'OO via Java/C++.

Mais c'est un faux problème, comme si un dev Java hurlais à l'héresie car Ruby n'implémente pas de notion d'interface (ou inversement un dev Ruby qui râle car y'a pas de notion de module en java ou que tout n'est pas objet...).

C'est une spécificité du langage, et pour le coup la notion de prototype est très puissante et très lisible une fois qu'on a fait l'effort de comprendre comment ça fonctionne.

Pour la notion de type faible ou fort, voir du coté d'actionscript, l'ECMA d'adobe qui permet de faire du typage fort.
Si le problème de javascript c'était son typage, alors tout le monde ferait de l'actionscript, non?
Pour avoir fait de l'actionscript et du javascript, je peux dire que le problème de javascript n'est pas son typage faible, mais véritablement:

- Des API destructurées (developpé par "acoup"), imbitables (pourquoi tout le monde utilise jQuery?); et notamment cette fameuse classe "Date" qui résume à elle seule tout ce qu'il ne faut pas faire!
- Un nom et une écriture proche de C/Java qui ne facilite pas l'impression dans la tete des gens que javascript != java
- Des notions fonctionnelles arrivée après coup. Je veux dire, les structures tels que for et while n'ont rien à faire en javascript!

Code :

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

1
2
3
4
 
//Exemple de for(var i = 0; i < x; i++) { }
// en pur fonctionnel si la notion de range avait été intégré au langage:
(0..x).by(1).each(function(i) {})

Du coup, le coté fonctionnel étant arrivé plus tard, on se retrouve avec des trucs aberrants en terme de syntaxe pour un langage fonctionnel; le plus remarquable étant le mot clé "function", bien trop long dés qu'on fait du pur fonctionnel (notamment inliné).

Personnelement, je préfére travailler d'ailleurs sous coffeescript. On gagne beaucoup en souplesse de syntaxe (mais les API reste les mêmes...)

Javascript n'est pas un mauvais langage en soit, il est comme tout le web en fait: un gros oignon avec des couches un peu incohérentes sur les bords...

Et puis il y a des trucs cool: tout est objet!:

Code :

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

1
2
3
4
5
6
 
  Number.prototype.times = function(callback) { for(var i = 0; i < this; i++) callback(i); }
 
  5..times(function(i) {
    console.log("hello developpez! x"+i);
  });

On peut définir des property sur les objets aussi, c'est sympa. Je pense que les prochaines version d'ECMA devrait améliorer largement le langage, comme pour PHP qui était mauvais jusqu'à la version 5.

Mais, comme trollé precedemment, à mes yeux, ça reste un HLM hein

[grim7reaper]

Si le problème de javascript c'était son typage, alors tout le monde ferait de l'actionscript, non?

Argument invalide.
C‘est rarement la meilleure technologie qui gagne…
Certaines techno’ sont devenues des standards de fait (car à l‘époque il n’y avait rien d‘autres ou pas mieux en face).
Le temps faisant son effet, maintenant il y a une inertie énorme pour changer les choses.

Donc non, l’argument « si c’est utilisé c‘est que c’est bien » n‘est pas valide.

Du coup, le coté fonctionnel étant arrivé plus tard, on se retrouve avec des trucs aberrants en terme de syntaxe pour un langage fonctionnel

Ça tombe bien, JS n‘est pas un langage fonctionnel.
Qu’il offre 2-3 fonctionnalités et/ou sucre syntaxique pour adopter un style fonctionnel ne suffisent pas à en faire un langage fonctionnel.
Un langage multi-paradigme permettant d‘écrire dans un style fonctionnel oui, un langage fonctionnel non.

[ZJP972]

Heu, c'est quoi un "WAT"?

[s4mk1ng]

Il faut avouer que c'est un langage étrange par rapport aux autres langages courremment utilisé, le fait qu'il ne fonctionne pas en objet mais en prototype est à lui seul déroutant(à moins qu'il y en ai qui utilisent Self ).

[Grimly]

Heu, c'est quoi un "WAT"?

Un WAT est une phénomène étrange d'un langage (pas forcément Javascript) où "wat" (pour "what" = "quoi" en anglais) serait la première expression qui sortirais de ta bouche en l'observant.

Il faut avouer que c'est un langage étrange

Il est possible de recréer la majorité des particularités du javascript avec tout autre langage même objet.

Un "objet" javascript est une Map de String vers d'autres objets
Une fonction est un "executable" isolé à qui il peux lui être donné un contexte. J'entends par "executable", quelquechose de similaire au Runnable de Java.
L'opérateur "new" est une copie simple du prototype donné avec l'application de la fonction à l'origine du prototype sur la copie.

[abrillant]

implicites, il faut pas s'attendre à quelque chose de logique. Ce type d'opération sont à éviter, il en est de même pour tout langage dans les priorités des opérateurs, si on utilise pas les parenthèses, on laisse le parseur faire l'évaluation lui même des groupes, * et / ayant une priorité plus grande sur - et +...

Par exemple par rapport à ce qui a été dit

"1" + "2" = "12"
car le plus est un opérateur de concaténation pour les chaînes

"1" - "2" = -1
car le moins est un opérateur pour les nombres, l'analyseur convertit "1" en 1 et "2" en 2. Ce qui est assez logique.

Par contre ce qui l'est moins, c'est d'avoir ce type de séquence dans son code, preuve qu'il y a surtout un problème dans la maîtrise du langage.

Bref, on peut faire dire n'importe quoi en zoomant sur des faux problèmes d'écriture qui ne concernent pas vraiment un développement "normal".

[bizulk]

Le problème des langages faiblement typé : souvent tu ne sais pas comment ta variable sera traitée, et tu passes ton temps à faire des conversions pour éviter les ambiguités.

[azias]

Je n'avais jamais entendu parler de ces "WAT" mais ce que la vidéo me donne à penser c'est que ceux qui en font sont apparemment encore plus débiles que ce qu'ils essaient de mettre en évidence! En tout cas, rien de constructif. Plus ça va et plus je me dit qu'il y a des gens qui s'ennuient vraiment dans la vie.

En voyant la vidéo et en entendant les rires des gens j'ai surtout l'impression qu'ils n'avaient rien compris à ce qu'est la programmation objet ou le typage fort. Alors on va éviter de leur parler en plus de la surcharge des opérateurs...

Bref, pour apporter ma petite pierre à l'édifice, je peux témoigner que dans un langage de preuve formelle (dont je tairai le nom parce qu'il ne mérite pas d'être conspué de la sorte), il m'a été possible il y a une dizaine d'année de prouver que 0=1 et par conséquence de prouver n'importe quoi. Cela dit, je l'ai fait exprès et en exploitant malicieusement un problème connu qui a sans doute été corrigé depuis.

[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 !

[notia]

Argument invalide.
C‘est rarement la meilleure technologie qui gagne…
Certaines techno’ sont devenues des standards de fait (car à l‘époque il n’y avait rien d‘autres ou pas mieux en face).
Le temps faisant son effet, maintenant il y a une inertie énorme pour changer les choses.
.....

<troll>
La preuve Android
</troll>

[TNT89]

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

Non, c'est pour cela que j'ai ecrit "Cela dit, ils (Les auteurs) ont aussi de bonnes lacunes en Mathématiques et en précision des formats flottants" parce que c'est effectivement commun a tous les langages basés sur le double IEEE-754 pour l'une et un gros problème de mathématiques de ne pas savoir que lim 1/x -> Inf quand x->0+.

[Invité]

Ce genre d'articles à trolls est lassant. On pourrait dire de n'importe langage qu'il est "la risée" à partir du moment où il ne plaît pas à au moins un programmeur qui l'expose ainsi publiquement sur le net. C'est bien simple pour moi : AUCUN langage n'est meilleur que l'autre car cela dépend de si nombreux facteurs, à commencer par la nature d'un projet par exemple.