Discussion :

[Zefling]

Pour moi, la seule différence entre un langage fortement typé et un faiblement typé, c'est la possibilité, pour le développeur, de faire n'importe quoi ou pas et de devoir assumer (ou pas) ses erreurs.

Je dirais donc qu'il y a des développeurs fortement/faiblement typés.

Le pire code que j'ai vu jusque là, c'est pas en JS ou PHP, mais en Java. Le typage fort n’empêche pas de faire n'importe quoi. Si le dév est mauvais, quelque soit le langage, ça peut vite tourner à la catastrophe...

[LSMetag]

Je rejoins totalement les posts de grim7reaper et Farid63.

Il n'est pas compliqué de sortir l'exemple:

var i = 2 + '2'.

Pas d'erreur. Ca ne donnera ni 4, ni 22. Il faudra d'abord comprendre que c'est vers cet endroit du code qu'il y a un soucis et faire un alert dessus. Pas très pratique pour débugguer.

Javascript est bien un langage faiblement typé à mes yeux. On ne spécifie aucun type à chaque variable. C'est les valeurs qu'on lui insère qui définissent son type, dynamiquement, et qui ne sera pas forcément celui qu'on souhaite. Et Javascript fait implicitement beaucoup de conversions, parfois étranges (comme ci-dessus).

[ptah35]

Le fait de ne pas déclarer le type des variables en JavaScript n'est pas ce qui fait que JavaScript a un typage faible. Un langage peut avoir à la fois un typage dynamique et fort, c'est le cas du LISP ou de Python par exemple.

Ce qui rend le typage de JavaScript "faible", ce sont essentiellement les conversions de type implicites. Par exemple, les conversions qui sont effectuées lors de l'utilisation de l'opérateur + qui, selon le type des opérandes, représente une addition ou une concaténation. Ce sont ce genre de conversions de types qui rendent difficile la compréhension du code.

Je suis toujours prêt à me faire l'avocat de JavaScript, mais il n'a définitivement pas un typage fort et ce n'est définitivement pas une qualité.

[Invité]

je me demande pas si la vision de variable en javascript ne serait pas plutot differente des autres languages elle me semble plus généraliste et simplifier grandement le langage tout en le plaçant dans un langage puissant, les variable en javascript ne se limite pas a des int float et string

elles peuvent contenir des fonctions (fonction anonymes)

Code :

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

var ma_fonction=function(){le code}

elles peuvent contenir un lien vers un element d'une page(sorte de pointeur)

Code :

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

var mon_element=document.getElementById('mon_element');

elles peuvent contenir des portions de code html pouvant subir des traitements comme un element deja intégré dans la page

Code :

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

1
2
3
4
5
6
7
8
var elem=document.createElement('div');
elem.setAttribute('class','une_class')
 
var t=document.createTextNode('un_texte');
elem.appendChild(t);
 
var mon_element=document.getElementById('mon_element');
mon_element.appendChild(elem);

de cette façon on peut faire des traitements dans un canvas avant affichage et ca c'est cool.

elles servent aussi d'espace de nom pouvant contenir des variable et des fonctions tres utile car il faut bien se mettre en tete que dans une page html se cotoys plusieurs programmes ecrit pas divers personnes.

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
var mon_espace={
 
element1:'vide',
element2:null,
element3:0,
tableau:['coucou','allo','hop'],
 
ma_fonction:function(e){
 
du code du code
	},
 
ma_fonction2:function(){
 
du code du code
	}
}

ces mêmes espaces de nom pouvant aussi servir de tableau associatives
[code]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
var mon_espace={
 
element1:'vide',
element2:null,
element3:0,
tableau:['coucou','allo','hop']
}
 
fonction ma_fonction(){
alert(mon_espace.tableau[2]) //allo
}

etcétéra etcétéra

un coté plutot generaliste que j'aime car il rend le language simple mais efficace.

[verbose]

Personnellement, j'ai un point de vue assez catégorique sur la question.

Il convient de préciser qu'on parle de "langage", c'est-à-dire ce qui est inscrit dans le code source uniquement. A partir de là, tout est dit. JavaScript, en tant que langage, est faiblement typé. Par contre, JavaScript est fortement typé au runtime.

[stardeath]

un coté plutot generaliste et que j'aime dans le javascript car efficace.

efficace en quoi?

en général, on pratique la programmation fourre-tout surtout quand on a soit un problème de conception, soit un cas très particulier ; en tout cas pas de manière générale ni sans avoir un minimum de contrôle sur le principe en question.

l'avoir exposé en principe premier d'un langage, c'est surtout un moyen de se dédouaner et faire du code illisible et inmaintenable.
c'est pour ça qu'on voit un peu partout soit des surcouches qui restreignent cette possibilité, soit des bonnes pratiques qui s'inspirent des langages plus "classiques".

je doute en tout cas très fortement de la qualité d'un code qui s'appuierait sur ce principe.

[Invité]

l'utilisation du javascript a ces debut c'etait du n importe quoi personne ne dira le contraire mais depuis des convention orales (pas normalisé) sont apparu c'est sur çà n’empêchera pas de coder comme un pied si on ne cherche pas a respecte ces convention.

en tout cas ce probleme de typage ne m'a jamais dérangé car quand j'ecrit

Code :

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

var la_variable = 'coucou'

le fait de mettre des guillemets me fonts dire que c'est une string

en ce qui concerne les int et float ce son tous deux des chiffres

[LSMetag]

je me demande pas si la vision de variable en javascript ne serait pas plutot differente des autres languages elle me semble plus généraliste et simplifier grandement le langage tout en le plaçant dans un langage puissant, les variable en javascript ne se limite pas a des int float et string

elles peuvent contenir des fonctions (fonction anonymes)

Code :

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

var ma_fonction=function(){le code}

elles peuvent contenir un lien vers un element d'une page(sorte de pointeur)

Code :

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

var mon_element=document.getElementById('mon_element');

elles peuvent contenir des portions de code html pouvant subir des traitements comme un element deja intégré dans la page

Code :

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

1
2
3
4
5
6
7
8
var elem=document.createElement('div');
elem.setAttribute('class','une_class')
 
var t=document.createTextNode('un_texte');
elem.appendChild(t);
 
var mon_element=document.getElementById('mon_element');
mon_element.appendChild(elem);

de cette façon on peut faire des traitements dans un canvas avant affichage et ca c'est cool.

elles servent aussi d'espace de nom pouvant contenir des variable et des fonctions tres utile car il faut bien se mettre en tete que dans une page html se cotoys plusieurs programmes ecrit pas divers personnes.

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
var mon_espace={
 
element1:'vide',
element2:null,
element3:0,
tableau:['coucou','allo','hop'],
 
ma_fonction:function(e){
 
du code du code
	},
 
ma_fonction2:function(){
 
du code du code
	}
}

ces mêmes espaces de nom pouvant aussi servir de tableau associatives
[code]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
var mon_espace={
 
element1:'vide',
element2:null,
element3:0,
tableau:['coucou','allo','hop']
}
 
fonction ma_fonction(){
alert(mon_espace.tableau[2]) //allo
}

etcétéra etcétéra

un coté plutot generaliste que j'aime car il rend le language simple mais efficace.

Tout ça est déja fait en langage C# par exemple, le typage fort en plus. Ou alors on peut y utiliser le polymorphisme ou même le mot clé "var" quand on ne connaît pas exactement les types de retour. Le problème justement avec le Javascript, c'est qu'on ne connaît pas les types des variables et qu'il est alors difficile de prévoir leur comportement dans les diverses opérations (surtout que Javascript est très permissif et ne sort pas d'erreurs explicites).

Ok si tu déclare en dur un truc avec des quotes, tu sauras que c'est une string. Mais quand tu récupères le résultat d'une requête en Ajax, le résultat d'une opération complexe,... tu sais vraiment ce que c'est ?

Tu dois te demander en permanence ce qu'est ou est devenue ta variable avant de faire la moindre opération. Et même quand tu te trompes, soit ça passe (!!!) et va planter plus tard avec un message hors contexte, soit ça planta tout de suite. Et quand ça plante, il n'y a pas d'affichage d'une erreur en gros, juste un script qui ne fait rien ou fait en partie. Il faut aller dans la console chercher un message peu clair.

Si encore on avait une IDE digne de ce nom permettant de débugguer ou d'inspecter les variables, on s'en sortirait déja mieux. Même avec Firebug, c'est loin d'être l'idéal.

[koyosama]

Tout ça est déja fait en langage C# par exemple, le typage fort en plus. Ou alors on peut y utiliser le polymorphisme ou même le mot clé "var" quand on ne connaît pas exactement les types de retour. Le problème justement avec le Javascript, c'est qu'on ne connaît pas les types des variables et qu'il est alors difficile de prévoir leur comportement dans les diverses opérations (surtout que Javascript est très permissif et ne sort pas d'erreurs explicites).

Personnellement quand je parle à des développeur web de POO alors catastrophe (trop compliqué, KISS my app ... ). Quand je parle de Design Pattern j'ai l'air d'un extra-terrestre . Quand je parle d'héritage, c'est l'apocalyse complet . Alors le polymorphisme Kezako ... .

Il y a la théorie, la pratique de la théorie et la réalité. Je pense que 90% des gens qui touchent à du Javascript à part Jquery connaissent rien d'autre, le javascript natif n'en parlons même pas. (Je sens que je vais me faire ...).

Ok si tu déclare en dur un truc avec des quotes, tu sauras que c'est une string. Mais quand tu récupères le résultat d'une requête en Ajax, le résultat d'une opération complexe,... tu sais vraiment ce que c'est ?

Alors là, je suis complètement furax. J'en ai marre de voir des gens faire des requêtes AJAX comme des bourrin. Une requête bien faite, c'est une requête qui contrôle chaque erreur. de l'erreur 404 à l'erreur 599.
C'est pour ça que le serveur doit toujours envoyé un bon format. Combien de glandu je vois envoyé des réponse de type 'OK' en plain/text car il bite rien au flux de données. Même du Json il envoie m'importe quoi. J'ai même des scripts quand ils renvoyaient rien, c'est faux ...

Après si tu utilise des requête sur un flux de données que tu ne contrôle pas. Il est préférable de faire côté serveur en asynchrone. Et de contrôler le flux de ton serveur. Personnellement je suis pas partisan du cross-domain. Et je fais toujours des interface côté serveur pour avoir certaine variable toujours pour dire si le webservice a les bonne données. Bien sûr, je modifie le code erreur qui va avec.

Tu dois te demander en permanence ce qu'est ou est devenue ta variable avant de faire la moindre opération. Et même quand tu te trompes, soit ça passe (!!!) et va planter plus tard avec un message hors contexte, soit ça planta tout de suite. Et quand ça plante, il n'y a pas d'affichage d'une erreur en gros, juste un script qui ne fait rien ou fait en partie. Il faut aller dans la console chercher un message peu clair.

Si encore on avait une IDE digne de ce nom permettant de débugguer ou d'inspecter les variables, on s'en sortirait déja mieux. Même avec Firebug, c'est loin d'être l'idéal.

Oui je suis d'accord avec toi. Les langage de script sont comme ça. Quand ça plante, tu le vois pas. C'est pour ça aussi que je préfère le compilé.

Par contre il y a des outils comme coffeescript, Dart et typescript qui permet de compilé ton programme et te dira tout de suite ou ça plante. Avant c'était galère à mettre en place. Maintenant avec des outils comme npm ou webmatrix. c'est très facile à mettre en place.

[BugBlaster]

Bah moi je m'en moque et je trouve que ce sujet ressemble un peu un troll.
Pour ma part, développer en javascript est très amusant et je pas n'ai du tout envie qu'il finisse un jour par ressembler à C# ou Java.

[jfchretien]

Bonjour,

A la lecture de vos différents posts, il me vient une petite réflexion sur les problématiques de typages. Et j'avoue que cela me laisse assez perplexe.

Si je comprend bien, les typages forts sont principalement des contraintes que l'on retrouve dans les langages objet natif (Java, ...)
A contrario, les typages faibles se retrouvent plus dans les langages de script (Javascript, Perl, ...)

Ce que je ne comprend pas, c'est en quoi le typage fort/faible influe sur la qualité du code produit... Je m'explique. Pour moi, les contraintes sur les types se définissent dès la conception (dans un truc du genre modèle de données) et constituent des contraintes fonctionnelles.

Si l'on choisit un langage fortement typé, on va contraindre chaque variable sur un type. Le contrôle du typage sera donc implicite. Mais il sera quand même nécessaire de catcher les erreurs de type et de les traiter.

Si l'on choisit un langage faiblement typé, on va devoir implémenter les contrôles sur les types et la gestion des erreurs.

Jusqu'à présent, la seule différence notable que j'ai vu, c'est dans l'art et la manière de ne pas gérer erreurs de type. Dans un langage comme Perl, on ne fait rien et on voit ce qui se passe. Dans un langage comme Java, on catche les erreurs et on les masque pour que le programme ne plante surtout pas à l'exécution...

Dans tout les cas, pour moi ce sont des erreurs de conception et de développement.

Tout ça pour poser cette simple question : en quoi le typage (fort, faible, statique, dynamique) est-il un critère pour définir si un langage est bon ou mauvais, sachant qu'un bon concepteur/développeur sera toujours capable de produire un code propre et fonctionnel quelque soit le langage ?

Merci d'avance de vos réponses, ça m'aidera à y voir plus clair.

[FaridM]

La question n'est pas est-ce que les langages a typages fort sont meilleurs que les langages a typages faibles, mais est-ce que JS est un langage a typage fort?

Pour t'as question, ça dépend surtout des développeurs et du genre d'appli que tu veux construire.

Certaines aiment quand tout est carré, tu déclare un int, tu met que des int dedans. D'autres aiment pouvoir mettre ce qu'ils veulent dans n'importe quelle variable.

[LSMetag]

Personnellement quand je parle à des développeur web de POO alors catastrophe (trop compliqué, KISS my app ... ). Quand je parle de Design Pattern j'ai l'air d'un extra-terrestre . Quand je parle d'héritage, c'est l'apocalyse complet . Alors le polymorphisme Kezako ... .

Haha ! J'ai déja constaté que j'avais l'air d'un érudit parce que je connaissais MVC, les ORM, le polymorphisme,... Mais je pense qu'ici il y a des gens assez compétents pour comprendre ça ^^. Personnellement je n'ai travaillé que sur du JS natif (et un peu de Dojo). Je me suis documenté sur JQuery et je suis finalement passé à Dart.

Alors là, je suis complètement furax. J'en ai marre de voir des gens faire des requêtes AJAX comme des bourrin. Une requête bien faite, c'est une requête qui contrôle chaque erreur. de l'erreur 404 à l'erreur 599.
C'est pour ça que le serveur doit toujours envoyé un bon format. Combien de glandu je vois envoyé des réponse de type 'OK' en plain/text car il bite rien au flux de données. Même du Json il envoie m'importe quoi. J'ai même des scripts quand ils renvoyaient rien, c'est faux ...

Après si tu utilise des requête sur un flux de données que tu ne contrôle pas. Il est préférable de faire côté serveur en asynchrone. Et de contrôler le flux de ton serveur. Personnellement je suis pas partisan du cross-domain. Et je fais toujours des interface côté serveur pour avoir certaine variable toujours pour dire si le webservice a les bonne données. Bien sûr, je modifie le code erreur qui va avec.

Je ne parlais pas du traitement de la réponse du serveur. Je ne pensais pas d'ailleurs qu'on pouvait envoyer des réponses OK quand ça foirait.
Je parle par exemple si au lieu de renvoyer du simple texte ou XML, on envoie des tableaux ou des listes.

J'ai effectivement préféré migrer vers du Dart car compilé, correspondant plus à mes habitudes objet, et surtout plus performant (au moins sur Chrome/Chromium).

[LSMetag]

Bonjour,

A la lecture de vos différents posts, il me vient une petite réflexion sur les problématiques de typages. Et j'avoue que cela me laisse assez perplexe.

Si je comprend bien, les typages forts sont principalement des contraintes que l'on retrouve dans les langages objet natif (Java, ...)
A contrario, les typages faibles se retrouvent plus dans les langages de script (Javascript, Perl, ...)

Ce que je ne comprend pas, c'est en quoi le typage fort/faible influe sur la qualité du code produit... Je m'explique. Pour moi, les contraintes sur les types se définissent dès la conception (dans un truc du genre modèle de données) et constituent des contraintes fonctionnelles.

Si l'on choisit un langage fortement typé, on va contraindre chaque variable sur un type. Le contrôle du typage sera donc implicite. Mais il sera quand même nécessaire de catcher les erreurs de type et de les traiter.

Si l'on choisit un langage faiblement typé, on va devoir implémenter les contrôles sur les types et la gestion des erreurs.

Jusqu'à présent, la seule différence notable que j'ai vu, c'est dans l'art et la manière de ne pas gérer erreurs de type. Dans un langage comme Perl, on ne fait rien et on voit ce qui se passe. Dans un langage comme Java, on catche les erreurs et on les masque pour que le programme ne plante surtout pas à l'exécution...

Dans tout les cas, pour moi ce sont des erreurs de conception et de développement.

Tout ça pour poser cette simple question : en quoi le typage (fort, faible, statique, dynamique) est-il un critère pour définir si un langage est bon ou mauvais, sachant qu'un bon concepteur/développeur sera toujours capable de produire un code propre et fonctionnel quelque soit le langage ?

Merci d'avance de vos réponses, ça m'aidera à y voir plus clair.

Je vois quand même quelques avantages au typage fort. D'une part évidement côté développement pour éviter certains bugs à cause de conversions implicites hasardeuses ou d'absences (oubli) d'erreurs à l'exécution.
D'autre part pour des raisons d'optimisation. Tu peux choisir un short plutôt qu'un int pour un petit nombre, et gagner en consommation mémoire. Tout type de données prend de la place en mémoire.
Enfin, pour certaines personnes pas à l'aise avec le langage, elles peuvent faire des gros bricolages pour contourner ces problèmes. Bricolages pas forcément performants ou fiables.

[yahiko]

Juste pour ajouter mon petit grain de sel à ce sympathique "troll" ^^, n'oublions pas non plus que le typage fort et statique permet l'Ahead Of Time compilation, ce qui apporte de sensibles gains de performances (cf. asm.js)

De l'autre côté, l'avantage du typage faible et dynamique à la Javascript, c'est la rapidité et la concision pour le développeur de rédiger de petites fonctions, ce qui est tout à fait adapté au cas général des pages Web pour lequel il a été conçu. Pas besoin de déclarer ses variables à l'avance, pas besoin de typer ses variables, pas besoin de donner une signature à ses fonctions. Tant que le programme ne dépasse pas l'ordre de quelques milliers de lignes, le typage faible a tout à fait sa place.

Maintenant, à une plus grande échelle, on se retrouve face à un problème de confiance envers le code, et ce, malgré toutes les relectures attentives et les tests unitaires effectués. D'où l'utilité de solutions complémentaires comme CoffeeScript, TypeScript pour adresser le problème des erreurs de typages ou encore, emScriptem (C++ -> JS) et asm.js pour la problématique des performances.

[grim7reaper]

Pas besoin de déclarer ses variables à l'avance, pas besoin de typer ses variables, pas besoin de donner une signature à ses fonctions.

Ça c‘est du typage dynamique, on peut faire la même chose en Python et Ruby.
Le typage faible n’a rien à voir avec les exemples que tu cites.

Et on peut même retrouver ça, dans une certaine mesure, avec du typage statique, pour peu qu’il y ai de l’inférence de type.

[yahiko]

C'est pour cela que j'avais ajouté le terme "dynamique" :

De l'autre côté, l'avantage du typage faible et dynamique à la Javascript [...]

[grim7reaper]

C'est pour cela que j'avais ajouté le terme "dynamique" :

De l'autre côté, l'avantage du typage faible et dynamique à la Javascript [...]

Alors pourquoi mentionner faible ?
C’est juste l’avantage du typage dynamique tout court, rien de propre au Javascript ou au typage faible.

[yahiko]

Pourquoi pas ?

De l'autre côté, l'avantage du typage faible et dynamique à la Javascript, c'est la rapidité et la concision pour le développeur de rédiger de petites fonctions, ce qui est tout à fait adapté au cas général des pages Web pour lequel il a été conçu.

[grim7reaper]

Mouais, mais je ne vois pas ce que le typage faible vient faire ici
Si tu le retires de la phrase, elle est tout aussi vraie pour ce qui concerne la rapidité et la concision.