Donc en fait "allez lire la norme si vous ne me croyez pas, moi je l'ai pas lu mais je sais quand même ce qu'il y a dedans". C'est bien ça ?
Oui, parce que je fais confiance au mec de mon labo qui bosser dessus depuis plusieurs semaines et qui nous fait un compte-rendu de ses travaux pendant une réunion de plus de quatre heures. Mais je conçois que, ne le connaissant pas, vous ne lui fassiez pas confiance ; donc allez lire la documentation.
Javascript souffre d'une très mauvaise image à cause de l'utilisation qui en est faite essentiellement.
En l'occurrence, j'évoque des fonctionnalités qui ne sont généralement (et heureusement ?) pas utilisées (notamment les prototypes). C'est intéressant dans l'idée, mais dans la pratique c'est mal fichu de partout, très tordu dans les coins... et foncièrement peu efficace.
Par contre, pourquoi à chaque fois qu'un langage est différent des classiques c/c++/java de base ("et découvrez les joies des choses qui ne fonctionnent pas comme vous vous y attendiez") c'est forcément un mauvais langage ?
Dans le labo en question, les gens codent en général en OCaml, alors tu sais, ce n'est pas parce que ce n'est pas classique qu'on crache dessus ;-)
Javascript est un langage intéressant, objet. Alors oui, c'est un langage à prototype et non un langage à classe. Et alors ? le fonctionnement n'est pas le même mais est assez intéressant.[...]
Ah mais on est d'accord, c'est hyper-rigolo comme bidule. La question est quand même : est-ce que, nom de nom, c'est vraiment adapté à l'usage auquel il est destiné.
M'enfin voilà, y'en a un peu marre des personnes qui jugent simplement parce que "la présentation détaillée qui m'en a été faite récemment m'a amplement suffit" mais sans être allé un peu plus loin, sans avoir testé.
Personnellement, moins il y a de typage, plus ça me choque ; là, j'avoue avoir été bouleversé. Et puis il y a plein de trucs qui ne sont pas possible, comme les fonctions récursives (terminales ou pas) qu'on est obligé de bidouiller avec des "trampolines" sinon elles sont bloquées par le navigateur au bout de x itérations (x=1000 avec Firefox je crois). La liaison retardée oblige aussi à se trimbaler tout l'environnement avec chaque variable, ce qui ralentit considérablement le truc, si j'ai bien compris - et en plus, ça donne des résultats parfois contre-intuitifs.
Javascript en lui même est un langage très intéressant, relativement facile
On ne doit pas parler du même langage ; on peut se restreindre à un sous-ensemble facile, je suis d'accord. Enfin cela dit, ça dépend ce qu'on entend par facile ; la syntaxe est limpide, par exemple. Mais bon, quand même, au vu de tous les exemples énoncés (et ceux que j'oublie), non, je ne dirais pas le langage (et je ne parle pas des implémentations) soit facile.
mais qui souffre d'une très mauvaise image, entretenue par des incompatibilité entre les différents navigateurs (ce qui en réalité ne montre en aucun cas que javascript est mauvais mais que leurs implémentations, ainsi que le support DOM - qui n'est pas javascript - sont pourraves)
J'insiste : je suis conscient de tous les problèmes d'implémentations incompatibles, mais là, ce n'est pas ça dont je parlais. Je pensais vraiment à la complexité du langage en lui-même (le bidule normalisé, sans le DOM).
note : oui il m'arrive de développer en javascript, y compris des scripts relativement gros mais j'ai également été longtemps contre javascript, jusqu'à ce que je me rende compte des qualités du langage et surtout qu'on pouvais faire de bonnes choses avec. Dire que javascript pue au vue de son support ou de ce qui est fait c'est comme dire que c++ pue simplement car MFC est une grosse merde.
Je conçois qu'on puisse coder proprement (avec assez de rigueur) en javascript. Et encore une fois, un sous-ensemble raisonnable (sans toucher à Function.prototype, en déclarant les variables avant leur utilisation, des bêtises comme ça) permet sûrement de faire des choses plus qu'acceptables.
Mais pour moi, il y a trop de choses baroques dans ce langage pour faire un ensemble dans lequel je me sente en confiance au moment de commencer à coder. Ça peut paraître bête, mais quand je regarde Caml (et encore plus Haskell), il y a une régularité et une sûreté inhérentes au langage qui sont tout à fait absentes de Javascript. Après, ce ne sont évidemment pas des langages de script. Mais quitte à faire un langage de script simple, pourquoi ajouter autant de possibilités de faire les choses salement dedans ? C'est un mystère pour moi...
[^] # Re: Sur javascript en général
Posté par MrLapinot (site web personnel) . En réponse au journal Web 2 mon cul !. Évalué à 5.
Oui, parce que je fais confiance au mec de mon labo qui bosser dessus depuis plusieurs semaines et qui nous fait un compte-rendu de ses travaux pendant une réunion de plus de quatre heures. Mais je conçois que, ne le connaissant pas, vous ne lui fassiez pas confiance ; donc allez lire la documentation.
En l'occurrence, j'évoque des fonctionnalités qui ne sont généralement (et heureusement ?) pas utilisées (notamment les prototypes). C'est intéressant dans l'idée, mais dans la pratique c'est mal fichu de partout, très tordu dans les coins... et foncièrement peu efficace.
Dans le labo en question, les gens codent en général en OCaml, alors tu sais, ce n'est pas parce que ce n'est pas classique qu'on crache dessus ;-)
Ah mais on est d'accord, c'est hyper-rigolo comme bidule. La question est quand même : est-ce que, nom de nom, c'est vraiment adapté à l'usage auquel il est destiné.
Personnellement, moins il y a de typage, plus ça me choque ; là, j'avoue avoir été bouleversé. Et puis il y a plein de trucs qui ne sont pas possible, comme les fonctions récursives (terminales ou pas) qu'on est obligé de bidouiller avec des "trampolines" sinon elles sont bloquées par le navigateur au bout de x itérations (x=1000 avec Firefox je crois). La liaison retardée oblige aussi à se trimbaler tout l'environnement avec chaque variable, ce qui ralentit considérablement le truc, si j'ai bien compris - et en plus, ça donne des résultats parfois contre-intuitifs.
On ne doit pas parler du même langage ; on peut se restreindre à un sous-ensemble facile, je suis d'accord. Enfin cela dit, ça dépend ce qu'on entend par facile ; la syntaxe est limpide, par exemple. Mais bon, quand même, au vu de tous les exemples énoncés (et ceux que j'oublie), non, je ne dirais pas le langage (et je ne parle pas des implémentations) soit facile.
J'insiste : je suis conscient de tous les problèmes d'implémentations incompatibles, mais là, ce n'est pas ça dont je parlais. Je pensais vraiment à la complexité du langage en lui-même (le bidule normalisé, sans le DOM).
Je conçois qu'on puisse coder proprement (avec assez de rigueur) en javascript. Et encore une fois, un sous-ensemble raisonnable (sans toucher à Function.prototype, en déclarant les variables avant leur utilisation, des bêtises comme ça) permet sûrement de faire des choses plus qu'acceptables.
Mais pour moi, il y a trop de choses baroques dans ce langage pour faire un ensemble dans lequel je me sente en confiance au moment de commencer à coder. Ça peut paraître bête, mais quand je regarde Caml (et encore plus Haskell), il y a une régularité et une sûreté inhérentes au langage qui sont tout à fait absentes de Javascript. Après, ce ne sont évidemment pas des langages de script. Mais quitte à faire un langage de script simple, pourquoi ajouter autant de possibilités de faire les choses salement dedans ? C'est un mystère pour moi...