Discussion :

[Sodium]

C'est du serveur dans tous les cas
Le code est interprété directement par la machine et pas par un client.
PHP aussi peut-être utilisé en ligne de commande.

[Marco46]

C'est du serveur dans tous les cas

Ton utilisation du mot "serveur" est abusive. Le JS avec Node c'est une plateforme d'exécution de JavaScript qui permet de faire plus que du serveur. Tu peux faire des outils CLI, du client lourd, du serveur, de la lib, etc ...

Serveur signifie réseau, tu n'es absolument pas obligé de faire du réseau avec Node, même si c'est tout à fait vrai qu'il a été conçu d'abord pour faire du réseau.

En fait tu dis la même chose que Paleo, simplement tu ne devrais pas employer le mot "serveur" qui est limité à un usage réseau.

[Sodium]

Je voulais dire que le script s'exécute au même endroit, que l'on réponde à des requêtes http ou pas. Effectivement mon utilisation du mot serveur était sans doute abusive

La frontière est tout de même ténue. Pour PHP on parle de langage serveur alors que l'on peut tout à fait ne l'utiliser que pour lancer des scripts en invite de commande.

[air-dex]

Je voulais dire que le script s'exécute au même endroit, que l'on réponde à des requêtes http ou pas. Effectivement mon utilisation du mot serveur était sans doute abusive

La frontière est tout de même ténue. Pour PHP on parle de langage serveur alors que l'on peut tout à fait ne l'utiliser que pour lancer des scripts en invite de commande.

Il ne faut pas confondre la technologie et son usage principal. Il ne faut pas non plus confondre PHP et son plugin pour serveurs Apache. C'est pour ça que je parlais de Python et de Django.

[Sve@r]

Ce que j'adore toujours, avec ce genre d'arguments, c'est qu'il faut quand même sacrément être de mauvaise foi, pour se servir d'exemples pareils...

Ce que j'adore moi, c'est qu'il faut quand-même sacrément être de mauvaise foi pour nier les exemples qui ne te conviennent pas...

On additionne pas des pommes et des poires, les opérations décrites ci-dessus n'ont juste aucune raison d'être.

Je suis d'accord. On n'additionne généralement pas les pommes et les poires. Mais si quelqu'un pond un langage qui accepte de les additionner, alors je m'attends à ce qu'il respecte au-moins la commutativité de l'addition. C'est un minimum.

Dans un langage à typage strict, t'aurais simplement une exception ou un plantage de compilation... le JS n'en soulève pas, ok... mais osef, un dev un minimum pas trop crétin ne fait pas ce genre de choses ^^'

Python permet de multiplier des stings par des entiers (et respecte dans ce cas la commutativité de la multiplication). Je suis dev, je pense ne pas être trop crétin et il m'est arrivé d'écrire des trucs comme "0123456789" * n parce que je voulais générer n plages de chiffres...

[Sodium]

Ca c'est parce que tu fais du JavaScript. Tu ferais du NodeJS tu te rendrais compte que ce n'est pas du tout le même langage !

[Sve@r]

Ca c'est parce que tu fais du JavaScript. Tu ferais du NodeJS tu te rendrais compte que ce n'est pas du tout le même langage !

Je ne sais pas trop à qui tu réponds vu que tu ne l'as pas cité... mais si c'est à moi alors tu as mal lu mon post. Je ne fais pas de javascript (ni bien évidemment de NodeJS). Et mon post était une réponse à Lcf.vs qui, lui, défend javascript avec des arguments qui me semblent bien faibles (il nie tout exemple qui montre que js est totalement à chier en disant "oui mais de toute façon ça on ne l'écrira jamais").

[Sodium]

C'était une vanne adressée aux individus de la page précédente

[Marco46]

Je ne fais pas de javascript (ni bien évidemment de NodeJS).

Oui ça se voit

Et mon post était une réponse à Lcf.vs qui, lui, défend javascript avec des arguments qui me semblent bien faibles (il nie tout exemple qui montre que js est totalement à chier en disant "oui mais de toute façon ça on ne l'écrira jamais").

JS n'est pas à chier, il n'a pas de typage statique (et pas "typage strict" qui ne veut rien dire) et a des règles de conversion de type au runtime (JS est un langage à typage dynamique) peut-être un peu trop souples qui sont forcément déroutantes quand on ne les connaît pas.

Les exemples listés sont en partie obsolètes et pour le reste démontrent simplement l'ignorance de l'auteur sur le langage.

Après tu peux trouver à chier les langages à typage exclusivement dynamique avec des règles de conversion un peu loose, c'est plutôt ça le vrai sujet à ce niveau.

[Invité]

Après tu peux trouver à chier les langages à typage exclusivement dynamique avec des règles de conversion un peu loose, c'est plutôt ça le vrai sujet à ce niveau.

Le problème, c'est surtout que le typage "un peu loose" mène facliement à une grosse lose.

[Paleo]

alors je m'attends à ce qu'il respecte au-moins la commutativité de l'addition.

Il y a méprise car il s'agit de l'opérateur de concaténation.

Les exemples listés sont en partie obsolètes et pour le reste démontrent simplement l'ignorance de l'auteur sur le langage.

Les exemples avec les nombres en base 8 sont obsolètes.

Les opérateurs "==" et "!=" posent un réel problème si on les utilise, et certains programmeurs le font. Cela dit la solution est simple et au sein d'une équipe les linters aident bien à les bannir. Personne ne le relève mais il existe un problème avec les autres opérateurs de comparaison : ">", "<", ">=", "<=" ne disposent pas d'équivalent strict.

[Sve@r]

Il y a méprise car il s'agit de l'opérateur de concaténation.

Non non, je ne parlais pas de "x" + 1 qui donne "x1" mais de {} + [] qui donne 0 et où [] + {} donne [Object, Object]. Ca ce ne ressemble pas à de la concaténation...

[Paleo]

Non non, je ne parlais pas de "x" + 1 qui donne "x1" mais de {} + [] qui donne 0 et où [] + {} donne [Object, Object]. Ca ce ne ressemble pas à de la concaténation...

Les explications sont ici.

En bref :

- {} + [] la première paire d'accolades n'est pas interprétée comme un objet mais comme un bloc d'instructions vide, il est ignoré. Il reste + []. L'opérateur + force la conversion de l'opérande [] en number. Par défaut une array vide est convertie en chaîne de caractères vide, puis en zéro.
- [] + {} la array vide est convertie en chaîne de caractères vide, et l'objet vide est converti (via sa méthode "toString") lui aussi en chaine de caractères "[Object, Object]". Il s'agit d'une concaténation.

Malgré les apparences, aucun de ces deux cas n'est à comprendre comme une addition.

Par exemple en Java il est possible de concaténer des objets et c'est alors le résultat de la méthode "toString()" qui est en fait concaténé. En JavaScript un principe similaire de conversion automatique existe et il est en outre étendu aux traitements numériques via les membres "valueOf()" et "toString()" de l'objet. Ce qui permet de créer ce genre d'exemples troublants. Mais ces exemples ne vont pas loin. Remplissez les arrays et vous verrez plus facilement la concaténation : ["a", "b"] + [1, 2] est converti en "a,b" + "1,2" ce qui donne "a,b1,2".

[Sodium]

Non non, je ne parlais pas de "x" + 1 qui donne "x1" mais de {} + [] qui donne 0 et où [] + {} donne [Object, Object]. Ca ce ne ressemble pas à de la concaténation...

Les fanatiques de JavaScript te diront que tu n'as qu'à apprendre la quarantaine (à une vache près hein, j'ai la flemme de rechercher la liste) de règles expliquant les particularités dans la façon dont il traite les opérations sur les variables. Moi je suis plutôt de l'école "si ça paraît illogique à tant de développeurs, le problème ne vient probablement pas des développeurs", mais c'est juste moi hein

[Dave Hiock]

Les fanatiques utilisateurs sérieux de JavaScript te diront que tu n'as qu'à apprendre la quarantaine ...

Quel que soit le langage, je dis bien quelque soit le langage, on ne peut pas leur donner tord, en présence de telles situations cela reste quand même un bon réflexe même si cela peut paraître abscons.

Moi je suis plutôt de l'école "si ça paraît illogique à tant de développeurs,

C'est peut être ce qui fait la différence entre un développeur et un apprenti développeur car écrire quelque chose comme {} + [] dans le code ne m'apparaît comme des plus « logique ».

Tu ferais du NodeJS tu te rendrais compte que ce n'est pas du tout le même langage !

As tu au moins testé sur nodeJS {} + [], j'en doute !

[Sodium]

Quel que soit le langage, je dis bien quelque soit le langage, on ne peut pas leur donner tord, en présence de telles situations cela reste quand même un bon réflexe même si cela peut paraître abscons.

Non. PHP est beaucoup plus simple d'accès par exemple. La plupart des fonctions ont un nom qui explique de manière claire ce qu'elle font, et le langage adopte de plus en plus un modèle objet bien plus logique pour les transformations. Il y a peu de mots-clés ou symboles magiques comme c'est le cas en JavaScript. Si je cherche comment faire quelque chose en PHP, en 10 secondes je vais tomber sur le manuel de PHP où ça sera indiqué de manière lisible. Si je cherche à faire un truc en JavaScript, je vais tomber (si j'ai du bol) sur un post Stack overflow avec un code bourré de bizarreries.

C'est peut être ce qui fait la différence entre un développeur et un apprenti développeur car écrire quelque chose comme {} + [] dans le code ne m'apparaît comme des plus « logique ».

La différence entre un bon intervenant et un intervenant pas bien malin sur un forum est que le bon intervenant aurait compris que le but n'est d'utiliser ce bout de code en situation réelle mais de mettre en évidence l'un des nombreux comportements "exotiques" de JavaScript.

Par ailleurs, je parlais de JavaScript dans son ensemble, pas de cet exemple précis. Là aussi ça me semblait assez clair, mais visiblement pas pour tout le monde

As tu au moins testé sur nodeJS {} + [], j'en doute !

Euh, oui, mais je ne vois pas bien le rapport

[Sve@r]

Attention, je ne crache absolument pas sur les dev javascript. Parce qu'ils n'ont que ça à leur disposition ils doivent faire avec et c'est tout à leur honneur. javascript est vraiment a chierdifficile et leur challenge est donc en proportion vraiment méritoire. Et ils peuvent même aimer ça en plus, personne n'a le droit de le leur reprocher. Et certains arrivent même à produire des codes vraiment magnifiques en javascript.
Mais qu'ils ne viennent pas dire "javascript best of" parce que je rejoins Sodium sur ce point. S'il y en a tant qui ne l'aiment pas, probable alors qu'il y a quand-même un souci concret avec ce langage. Le code que je cite est super esthétique et montre un art consommé mais il reste illisible et inmaintenable.

[Paleo]

S'il y en a tant qui ne l'aiment pas, probable alors qu'il y a quand-même un souci concret avec ce langage...

He he il y a certes les "bad parts", ce n'est pas pour rien que Douglas Crockford a écrit "JavaScript: The Good Parts" à l'époque de ES3 et de IE6. C'est ce livre, plus TypeScript, qui m'ont convaincu d'adopter cette technologie il y a quelques années. J'avais auparavant un background de POO classique en Java et en PHP.

[Sodium]

Attention, je ne crache absolument pas sur les dev javascript. Parce qu'ils n'ont que ça à leur disposition ils doivent faire avec et c'est tout à leur honneur. javascript est vraiment a chierdifficile et leur challenge est donc en proportion vraiment méritoire. Et ils peuvent même aimer ça en plus, personne n'a le droit de le leur reprocher.

On est pour moi très clairement dans le syndrome de Stockholm : les devs JavaScript ont passé tellement de temps à apprendre à faire avec les faiblesse et bizarreries du JavaScript que psychologiquement, ils sont obligés de valoriser ce temps perdu et d'en tirer une certaine fierté. Et donc également de dénigrer ceux qui préfèrent utiliser leur temps à des choses plus productives.

[Dave Hiock]

Tout d'abord je vais donner quelques précisions qui me semblent importantes.

Je ne suis pas plus développeur JavaScript que développeur de photos argentique mais ce langage, comme bien d’autres m’intéresse, je n’en « déteste » aucun il y en a simplement que j’apprécie plus ou moins bien que d’autres. .

Lorsque j’ai entrepris la lecture de cette discussion, malgré un titre plutôt mal choisi à mon avis, je ne pensais pas lire tout ce que j’ai lu et peut être n’ai je retenu que quelques remarques dans les derniers posts.
Ceci dit un bon nombre d’arguments est tout à fait pertinent.

Non. PHP est beaucoup plus simple d'accès par exemple. …. Si je cherche comment faire quelque chose en PHP, en 10 secondes je vais tomber sur le manuel de PHP où ça sera indiqué de manière lisible.

Je suis d’accord sur le point concernant l’accessibilité du langage, quant à la documentation c’est pour moi un autre sujet, visiblement de la document bien faite existe également pour JavaScript, qui concerne surtout les API, mais moins sur le « noyau JavaScript » hors de la documentation ECMAScript.

La différence entre un bon intervenant et un intervenant pas bien malin sur un forum est que le bon intervenant aurait compris que le but n'est d'utiliser ce bout de code en situation réelle mais de mettre en évidence l'un des nombreux comportements "exotiques" de JavaScript.

Concernant la qualité des intervenants je te laisse juge au vu de ce que j’ai pu lire de tes interventions.

Par ailleurs, je parlais de JavaScript dans son ensemble, pas de cet exemple précis.

Cela je l’avais compris, mais cet exemple précis est caractéristique du reste me semble t-il.

Euh, oui, mais je ne vois pas bien le rapport

Et bien si nodeJS c’est juste du JavaScript(attention porte ouverte aux courants d’air).

S'il y en a tant qui ne l'aiment pas, probable alors qu'il y a quand-même un souci concret avec ce langage.

C’est exactement ce que j’ai essayé d’analyser mais je dois admettre que les argumentations me laissent un peu sur ma faim. J’en retiens quand même quelques choses.