+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 7 PremièrePremière 123456 ... DernièreDernière
  1. #21
    Membre émérite Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2007
    Messages
    829
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : avril 2007
    Messages : 829
    Points : 2 896
    Points
    2 896

    Par défaut

    Citation Envoyé par Lcf.vs Voir le message
    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...
    Mon blog de développeur web.

    Projet : BakuJS

  2. #22
    Membre expert

    Homme Profil pro
    Ingénieur Etudes et Développements Junior
    Inscrit en
    juillet 2009
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Etudes et Développements Junior
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 918
    Points : 3 672
    Points
    3 672

    Par défaut

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

  3. #23
    Membre éclairé
    Homme Profil pro
    Enseignant
    Inscrit en
    décembre 2007
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Suisse

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2007
    Messages : 205
    Points : 827
    Points
    827

    Par défaut

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

  4. #24
    Invité
    Invité(e)

    Par défaut

    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.
    Dernière modification par Invité ; 11/08/2013 à 23h56.

  5. #25
    Membre éclairé
    Profil pro
    Inscrit en
    juillet 2007
    Messages
    802
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2007
    Messages : 802
    Points : 650
    Points
    650

    Par défaut

    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.

  6. #26
    Membre expert

    Profil pro
    Inscrit en
    février 2006
    Messages
    2 003
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 003
    Points : 3 107
    Points
    3 107

    Par défaut

    Citation Envoyé par mekal Voir le message
    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.

  7. #27
    Invité
    Invité(e)

    Par défaut

    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

  8. #28
    Membre expert

    Homme Profil pro
    Ingénieur Etudes et Développements Junior
    Inscrit en
    juillet 2009
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Etudes et Développements Junior
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 918
    Points : 3 672
    Points
    3 672

    Par défaut

    Citation Envoyé par mekal Voir le message
    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.

  9. #29
    Membre confirmé
    Profil pro
    Inscrit en
    mai 2011
    Messages
    276
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2011
    Messages : 276
    Points : 585
    Points
    585

    Par défaut

    Citation Envoyé par LSMetag Voir le message
    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 ...).

    Citation Envoyé par LSMetag Voir le message
    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.

    Citation Envoyé par LSMetag Voir le message
    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.

  10. #30
    Membre à l'essai
    Profil pro
    Développeur informatique
    Inscrit en
    février 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2003
    Messages : 12
    Points : 16
    Points
    16

    Par défaut Bah moi je m'en moque

    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.

  11. #31
    Nouveau membre du Club
    Homme Profil pro
    Analyste technique
    Inscrit en
    septembre 2011
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Analyste technique

    Informations forums :
    Inscription : septembre 2011
    Messages : 9
    Points : 38
    Points
    38

    Par défaut

    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.

  12. #32
    Membre expérimenté
    Homme Profil pro
    Inscrit en
    janvier 2008
    Messages
    619
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : janvier 2008
    Messages : 619
    Points : 1 349
    Points
    1 349

    Par défaut

    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.

  13. #33
    Membre expert

    Homme Profil pro
    Ingénieur Etudes et Développements Junior
    Inscrit en
    juillet 2009
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Etudes et Développements Junior
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 918
    Points : 3 672
    Points
    3 672

    Par défaut

    Citation Envoyé par koyosama Voir le message
    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.

    Citation Envoyé par koyosama Voir le message

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

  14. #34
    Membre expert

    Homme Profil pro
    Ingénieur Etudes et Développements Junior
    Inscrit en
    juillet 2009
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Etudes et Développements Junior
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 918
    Points : 3 672
    Points
    3 672

    Par défaut

    Citation Envoyé par jfchretien Voir le message
    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.

  15. #35
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 139
    Points : 6 450
    Points
    6 450
    Billets dans le blog
    43

    Par défaut

    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.
    Tutoriels et FAQ TypeScript

  16. #36
    Membre éclairé
    Inscrit en
    juillet 2012
    Messages
    228
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 228
    Points : 855
    Points
    855

    Par défaut

    Citation Envoyé par yahiko Voir le message
    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.

  17. #37
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 139
    Points : 6 450
    Points
    6 450
    Billets dans le blog
    43

    Par défaut

    C'est pour cela que j'avais ajouté le terme "dynamique" :
    Citation Envoyé par yahiko
    De l'autre côté, l'avantage du typage faible et dynamique à la Javascript [...]
    Tutoriels et FAQ TypeScript

  18. #38
    Membre éclairé
    Inscrit en
    juillet 2012
    Messages
    228
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 228
    Points : 855
    Points
    855

    Par défaut

    Citation Envoyé par yahiko Voir le message
    C'est pour cela que j'avais ajouté le terme "dynamique" :
    Citation Envoyé par yahiko Voir le message
    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.

  19. #39
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 139
    Points : 6 450
    Points
    6 450
    Billets dans le blog
    43

    Par défaut

    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.
    Tutoriels et FAQ TypeScript

  20. #40
    Membre éclairé
    Inscrit en
    juillet 2012
    Messages
    228
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 228
    Points : 855
    Points
    855

    Par défaut

    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.

Discussions similaires

  1. Réponses: 30
    Dernier message: 20/09/2012, 14h25
  2. Réponses: 9
    Dernier message: 27/02/2010, 21h15
  3. Réponses: 2
    Dernier message: 15/01/2010, 17h52
  4. Réponses: 2
    Dernier message: 15/01/2010, 17h52
  5. Réponses: 1
    Dernier message: 05/10/2007, 17h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo