Discussion :

[landry161]

Pour moi, c'est Javascript, car Javascript est un faux langage.

Même Google déteste le Javascript qu'ils ont essayé de tuer 2 fois (avec GWT puis avec DART).

D'ailleurs, heureusement que Google a rendu le Javascript supportable et industrialisable avec Angular (et en utilisant une surcouche comme TypeScript).

Le problème, c'est que ce faux langage est incontournable.

En fait, Javascript n'a aucune qualité, il est là car il était partout et qu'il était le seul dans tous les navigateurs.

Il est là car il était là par hasard.

http://sametmax.com/la-communaute-js...tte-technique/

Sauf que ce langage apporte beaucoup aux développeurs.
Il y a quelques de cela sur Developpez.com, certains avaient prédit la mort du JavaSript. Quel est le bilan aujourd'hui? Et beh...
Moi je pense que que tout les langages sont utiles. Après il faut juste tenir compte de plusieurs critères dans le cadre des projets sur lesquels nous travaillons.

[Artemus24]

Salut SimonDecoline.

Oui, je suis d'accord avec vous, mais le problème n'est pas là.
Il arrive souvent que quelqu'un pose une question et tout ce qu'il a comme réponse un '-1' sans aucune explication.

L'explication de Marco46 me convient parfaitement :

Oui c'est une plateforme, pas un langage. Non seulement le JavaScript côté serveur avec Node ou dans un browser est le même, mais c'est souvent le même moteur d'exécution (V8), donc à 100% identique modulo l'API de la plateforme.

Sauf que Marco46 se focalise que sur le moteur V8 pour dire que c'est la même chose.
Et bien non, node.js et javascript peuvent évoluer différemment.
Si c'était exactement la même chose, tout ce qui fonctionne sous node.js devrait aussi fonctionner en javascript et vice-versa. On nomme cela le portage !
On ne peut pas parler de portage puisque le javascript st coté client tandis que node.js est coté serveur.
Et de ce fait, les finalités ne sont pas les mêmes.

De plus vous créditez mon opinion, à savoir "c'est souvent le même moteur d'exécution".
Donc vous reconnaissez qu'il peut exister une différence de version, voire même une différence dans l'évolution du produit.

La grosse différence vient que la V8 est développé par Google et est utilisé par les navigateurs Chromium, Google Chrome. Or Mozilla Firefox utilise la version SpiderMonkey, .
Déjà là, il y a une différence de version entre Google Chrome et Mozilla Firefox.

Si pour vous tous, c'est du javascript, je trouve que c'est très réducteur votre façon de voir les choses.
Nous n'avons pas la même version de javascript (ECMAScript, SpiderMonkey, Rhino, KJS, JavaScriptCore, V8), nous n'avons pas la même finalité (coté client, serveur, électronique, ...) et je peux aussi supposer que nous n'avons pas les mêmes bibliothèques donc sûrement des incompatibilités, et je ne cherche pas plus loin les différences.

Je prends comme exemple MySql et MariaDB. A la base c'est le même produit, mais à un instant donnée, il y a eu scission.
MySql a été racheté par Oracle et Michael Widenius, son fondateur a par la suite créé MariaDB.
On nomme cela un fork communautaire, et même si en apparence c'est pareil et bien non, c'est différent.

@+

[Sodium]

En même temps on ne t'a pas mis moins un sans explication, on l'a mis après t'avoir dit plusieurs fois que tu disais n'importe quoi. Et le pire c'est que tu récidives et que tes exemples sont de moins en moins pertinents. JavaScript est un LANGAGE. L'api utilisée, le contexte dans lequel il est exécuté, le fait d'avoir accès à certain ou non à certaines fonctionnalités en fonction du contexte n'a rien à voir avec la définition du langage. De même, MariaDb, MySQL, Postgres... ça reste du SQL, avec des différences en fonction du SGBD mais ça reste le même langage. C'est comme si tu disais que les québecois ne parlent pas français parce qu'ils ont des expressions et mots à eux...

[PhilippeGibault]

Je déteste le Javascript car:

Pas Objet.

Pas compilé, enfin c'est faux depuis que Google l'a compilé avec Chrome. Node JS a d'ailleurs permis de l'industrialiser.
Mais ça ne c'est pas fait automatiquement.

Pas typé.

Difficilement debbugable.

Comme le dit Dijkstra, coder, c'est ajouter des bugs.

Javascript est un langage qui permet d'en ajouter facilement, contrairement à des langage plus cadré comme Java, ou C#.

[Mister Nono]

Je déteste le Javascript car:

Pas Objet.

Pas compilé, enfin c'est faux depuis que Google l'a compilé avec Chrome. Node JS a d'ailleurs permis de l'industrialiser.
Mais ça ne c'est pas fait automatiquement.

Pas typé.

Difficilement debbugable.

Comme le dit Dijkstra, coder, c'est ajouter des bugs.

Javascript est un langage qui permet d'en ajouter facilement, contrairement à des langage plus cadré comme Java, ou C#.

+1

[Sodium]

JavaScript bien évidemment, what else

JavaScript est bien orienté objet par contre, il a juste sa façon très personnelle de le faire, et par très personnelle je veux dire stupide.

Il y a des classes en JavaScript depuis récemment. Par contre toujours pas de typage strict... peut-être pour 2025 ?

[PhilippeGibault]

Attention, ceci a réellement existé dans un vrai langage , et peut-être que ça existe encore

Code :

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

1
2
3
4
5
6
7
8
9
10
''        ==   '0'           // false
0         ==   ''            // true
0         ==   '0'           // true
false     ==   'false'       // false
false     ==   '0'           // true
false     ==   undefined     // false
false     ==   null          // false
null      ==   undefined     // true
" \t\r\n" ==   0

Code :

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

1
2
3
4
5
6
7
8
9
10
11
> parseInt('06')
6
> parseInt('07')
7
> parseInt('08')
0
> parseInt('09')
0
> parseInt('10')
10

Code :

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

1
2
3
4
5
6
7
> {} + {} // Ceci n'est effectivement PAS un nombre
NaN
> {} + [] // logique IMPARABLE
0
> [] + {} // fuck la commutativité
"[object Object]"

Code :

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

1
2
3
4
5
6
7
8
9
> '5' + 3
'53'
> '5' - 3
2
> "Vous en étiez à... peau de couilles je crois ?" + 1
'Vous en étiez à... peau de couilles je crois ?1'
> "Vous en étiez à... peau de couilles je crois ?" - 1
NaN

Code :

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

1
2
3
4
5
6
7
> Math.min(null, 1234)
0
> Math.min('null', 1234)
NaN
> Math.min('1', 1234)
1

[Lcf.vs]

Attention, ceci a réellement existé dans un vrai langage , et peut-être que ça existe encore

Code :

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

1
2
3
4
5
6
7
8
9
10
''        ==   '0'           // false
0         ==   ''            // true
0         ==   '0'           // true
false     ==   'false'       // false
false     ==   '0'           // true
false     ==   undefined     // false
false     ==   null          // false
null      ==   undefined     // true
" \t\r\n" ==   0

Code :

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

1
2
3
4
5
6
7
8
9
10
11
> parseInt('06')
6
> parseInt('07')
7
> parseInt('08')
0
> parseInt('09')
0
> parseInt('10')
10

Code :

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

1
2
3
4
5
6
7
> {} + {} // Ceci n'est effectivement PAS un nombre
NaN
> {} + [] // logique IMPARABLE
0
> [] + {} // fuck la commutativité
"[object Object]"

Code :

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

1
2
3
4
5
6
7
8
9
> '5' + 3
'53'
> '5' - 3
2
> "Vous en étiez à... peau de couilles je crois ?" + 1
'Vous en étiez à... peau de couilles je crois ?1'
> "Vous en étiez à... peau de couilles je crois ?" - 1
NaN

Code :

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

1
2
3
4
5
6
7
> Math.min(null, 1234)
0
> Math.min('null', 1234)
NaN
> Math.min('1', 1234)
1

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

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

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 ^^'

[L33tige]

Attention, ceci a réellement existé dans un vrai langage , et peut-être que ça existe encore

Code :

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

1
2
3
4
5
6
7
8
9
10
''        ==   '0'           // false
0         ==   ''            // true
0         ==   '0'           // true
false     ==   'false'       // false
false     ==   '0'           // true
false     ==   undefined     // false
false     ==   null          // false
null      ==   undefined     // true
" \t\r\n" ==   0

C'est pour ça qu'on appel les "==" les evil twins et que l'on est censé utiliser les triples égales.

Code :

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

1
2
3
> {} + {} // Ceci n'est effectivement PAS un nombre
NaN

Oui, et c'est normal, puisque l'opération qui à échouée à la base était une addition.

Code :

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

1
2
3
4
5
6
7
8
9
> '5' + 3
'53'
> '5' - 3
2
> "Vous en étiez à... peau de couilles je crois ?" + 1
'Vous en étiez à... peau de couilles je crois ?1'
> "Vous en étiez à... peau de couilles je crois ?" - 1
NaN

Bah c'est logique à tous les niveaux là, et dans pas mal de langages on se retrouve avec des résultats similaire, comme le python...

Et puis bon, ça c'est juste du copié/collé d'articles tout pétés qui ont 5 ans et dont le but était de troller...

Si vraiment on veut etre de mauvaise foi en JAVA on à :

Code :

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

1
2
3
4
5
6
7
8
public class Testing { 
    public static void main(String[] args) 
     { 
         // the line below this gives an output 
         // \u000d System.out.println("comment executed"); 
     } 
}

WOW mais si c'est vl'a pas les conséquences de mes propres actions ? Je déteste donc JAVA maintenant

[nouknouk]

JavaScript est bien orienté objet par contre, il a juste sa façon très personnelle de le faire, et par très personnelle je veux dire stupide.

C'est l'histoire d'un charpentier qui rencontre un électricien qui se sert d'un tournevis ; le charpentier obtus ne peut s'empêcher de se moquer de l'électricien et de son tournevis, car cet outil est absolument nul pour enfoncer des clous de façon efficace.

Même chose ici: les 'haters' du JS sont avant tout des développeurs obtus qui ne connaissent que l'OO basé sur le principe de classes ; en se moquant du JS, il ne font que trahir leur méconaissance profonde de l'OO prototypal, et montrent leur incapacité manifeste à enlever les oeillères qu'ils se sont forgées avec le temps.

La répartie préférée des fanatiques de JS c'est qu'on ne l'aime pas parce qu'on ne le comprend pas. Très bien, mais pourquoi n'a-t-on pas la même relations avec tous les autres langages alors ?

Tu as maintenant ta réponse: l'immense majorité des développeurs ont été biberonnés aux langage OO basés sur des classes, des interfaces, de l'héritage. Ils sont incapables de penser autrement, faute de pouvoir prendre du recul sur leurs propres outils.

Et puis il y en a quelques autres, souvent ceux qui sont tombés dans la marmite de l'informatique à ses prémices, et avant l'hégémonie des langages style Java, C++). Ceux-là sont capables de prendre plus de recul, de comprendre que les classes c'est pas la seule façon d'aborder le sujet de l'OO (ou du dev. en général), et sont aptes à comprendre un approche différente, qui a elle aussi ses atouts.

[blbird]

Même chose ici: les 'haters' du JS sont avant tout des développeurs obtus qui ne connaissent que l'OO basé sur le principe de classes ; en se moquant du JS, il ne font que trahir leur méconaissance profonde de l'OO prototypal, et montrent leur incapacité manifeste à enlever les oeillères qu'ils se sont forgées avec le temps.

Tu as maintenant ta réponse: l'immense majorité des développeurs ont été biberonnés aux langage OO basés sur des classes, des interfaces, de l'héritage. Ils sont incapables de penser autrement, faute de pouvoir prendre du recul sur leurs propres outils.

Et puis il y en a quelques autres, souvent ceux qui sont tombés dans la marmite de l'informatique à ses prémices, et avant l'hégémonie des langages style Java, C++). Ceux-là sont capables de prendre plus de recul, de comprendre que les classes c'est pas la seule façon d'aborder le sujet de l'OO (ou du dev. en général), et sont aptes à comprendre un approche différente, qui a elle aussi ses atouts.

Je n'aurais pas dit mieux, bravo. Il y a beaucoup de manières différentes d'approcher la POO dans un langage, avec ses avantages et ses inconvénients.

Seulement de nos jours, beaucoup de développeurs n'ont appris qu'une seule (POO mono-héritage), et ne jure que par cela sans vouloir réfléchir plus loin.

[Invité]

Si on omet la guéguerre JS/anti-JS, les réponses suivantes sont assez intéressantes pour le monde du web en comparaison avec le dernier sondage il y a 2 ans.

Dans les flops, Python passe de 6% à 14%, TypeScript de 1.9% à 8.5%.
Dans les tops, Java passe de 25% à 16%, PHP de 21% à 14%.

A noter l'apparition de Windev dans la liste qui polarise 20% des votes, même dans le cadre d'un vote à choix multiple avoir une mauvaise techno (selon l'avis des votants contre Windev) dans la liste valorise positivement les autres technos. Difficile de savoir quel est l'impact réel de ce nouveau choix, mais il me semble que c'est facile de se dire "Java/PHP bof mais à côté de Windev c'est ok" et donc ne pas voter contre, ce qui explique une partie des gaps non-négligeables entre les 2 sondages.

Il y a une montée du typage fort ces dernières années et c'est à priori globalement apprécié. PHP est désormais presque fortement typé (PHP7.4 devrait achever cette transition), c'est optionnel mais ça fait parti du langage contrairement a Python (un script Python fortement typé n'est pas exécutable par Python alors que l'équivalent PHP l'est). Plusieurs personnes dans mon entourage se sont même remotivées à aller voir du côté de Java pour du backend web, et de mon petit cercle non-représentatif l'avis est unanime : c'est ok mais le système de licence et d'update est vomitif, puis ils vont voir vers Go et même Rust.

Python pour le web semble en déclin (ma constatation personnelle + des lectures sur la toile). Il y a encore 3-4 ans (pré-PHP7) il y avait une véritable fuite des dev. PHP vers Python pour plusieurs raisons : langage plus propre et plus respecté et PHP n'avait aucun argument pour lui hormis le monde du travail en France. Aujourd'hui les gens qui quittent PHP se dirigent plutôt vers JavaScript et même certains reviennent à PHP.

Du coup je ne comprend pas trop la montée négative de TypeScript, qui est dans cette veine du typage fort pour les langages interprétés. Peut être que la mouvance JavaScript n'est pas encore atteinte par ce phénomène.


EDIT : TypeScript était peut être très peu utilisé il y à 2 ans, ce qui pourrait expliquer cette différence.

[Pyramidev]

Il n'y a pas que les fans de la POO version Java (ou C++) qui n'aiment pas la programmation orientée prototype version JavaScript.
Par exemple, en ce qui me concerne, je n'aime pas l'héritage, même si je l'utilise quand un langage ne me propose rien de mieux. Et pourtant, je trouve que, la programmation orientée prototype version JavaScript, c'est globalement de la merde.
Je vais détailler un peu.

L'héritage de la POO version Java a les inconvénients suivants :

• On mélange deux concepts qui auraient dû être séparés : les mixins et le polymorphisme. Pour rappel, conceptuellement, un mixin, c'est une sorte d'héritage sans sous-typage : si une classe A utilise un mixin B, alors A récupère automatiquement tout le contenu de B, mais l'utilisateur de A ne sait pas que ce contenu vient de B. B ne sert qu'à factoriser du code. Les mixins sont moins verbeux que l'encapsulation. On peut les utiliser avec parcimonie. Il ne faut pas en abuser, sinon, on se retrouve avec des classes qui ont une longue liste de méthodes éparpillées dans plein de fichiers différents, dont des méthodes qu'elles n'auraient pas dû avoir. Les mixins risquent de rigidifier le code, donc ce concept n'aurait pas dû être mélangé à du sous-typage qui rigidifie le code encore plus.
• La POO version Java impose que, dans le code d'une classe ou d'une interface, il faut connaître la liste exhaustive des types parents. L'une des conséquences est que cela empêche de combiner deux types abstraits a posteriori : il faut soit éditer le code de ces deux types abstraits pour qu'ils dérivent d'un même nouveau type, soit passer par des wrappers.
• La POO version Java a un polymorphisme qui repose sur le sous-typage, ce qui affaiblit le typage et limite les possibilités d'effectuer des contrôles rigoureux lors de l'analyse statique du code.
  Par exemple, si une fonction prend deux paramètres et retourne une valeur, en pure POO, on ne peut pas restreindre à la compilation le type du deuxième paramètre en fonction du premier et on ne peut pas restreindre le type de retour en fonction des deux autres types. On peut en programmation générique, mais pas en pure POO.
  Autre exemple : si un langage contrôle à la compilation quels types d'erreurs une fonction peut retourner et si une fonction est pure, alors, quand on écrit du code réutilisable avec des callbacks, on a rapidement besoin de pouvoir faire ce genre de chose : soit f une fonction qui prend en paramètre une callback et qui ne peut pas avoir d'effets de bord autres que ceux de la callback. Quand on sait que la callback est pure alors on sait que l'appel de f pour cette callback-là est pur. Et quand on sait que la callback peut lancer des erreurs X et Y, alors on sait que l'appel de f pour cette callback-là pourra lancer des erreurs X et Y. Java n'a pas été conçu pour que le compilateur sache propager ce genre de contrôle dans un contexte de polymorphisme. C'est pourquoi les checked exceptions sont un échec en Java et qu'il n'y aura probablement jamais de contrôles sur les fonctions pures dans les futures versions du langage.

La POO version Java a au moins un avantage : il n'y a pas de polymorphisme accidentel. Quand on veut modifier le code, on sait différencier assez facilement les fonctions spécifiques à une classe des fonctions liées à d'autres classes par un type parent commun. Ce n'est pas comme le duck typing avec lequel il est parfois périlleux de renommer une méthode.

Mais il n'y a pas besoin de la POO pour avoir cet avantage. Avec les typeclasses de Haskell et les traits du Rust, on évite aussi le polymorphisme accidentel et on n'a aucun des 3 inconvénients cités ci-dessus.

Concernant la programmation orientée prototype version JavaScript, ça revient à combiner des mixins avec une sorte de polymorphisme non typé (ce qui est un oxymore) et sans restrictions sur les redéfinitions. On a très peu de garanties sur le code, ce qui entrave les possibilités de raisonner localement sur le code : si on fait tel changement dans tel bout de code, quelles seront les conséquences ? Est-ce que ça va péter ailleurs ?

Hélas, mon message manque d'exemples. Mais il est déjà long.

[Invité]

Même chose ici: les 'haters' du JS sont avant tout des développeurs obtus qui ne connaissent que l'OO basé sur le principe de classes ; en se moquant du JS, il ne font que trahir leur méconaissance profonde de l'OO prototypal, et montrent leur incapacité manifeste à enlever les oeillères qu'ils se sont forgées avec le temps.

Tandis que les 'lovers' du JS sont avant tout des développeurs ouverts qui s'intéressent aussi aux langages fonctionnels fortement typés comme PureScript...

[Sodium]

C'est l'histoire d'un charpentier qui rencontre un électricien qui se sert d'un tournevis ; le charpentier obtus ne peut s'empêcher de se moquer de l'électricien et de son tournevis, car cet outil est absolument nul pour enfoncer des clous de façon efficace.

Même chose ici: les 'haters' du JS sont avant tout des développeurs obtus qui ne connaissent que l'OO basé sur le principe de classes ; en se moquant du JS, il ne font que trahir leur méconaissance profonde de l'OO prototypal, et montrent leur incapacité manifeste à enlever les oeillères qu'ils se sont forgées avec le temps.

Tu as maintenant ta réponse: l'immense majorité des développeurs ont été biberonnés aux langage OO basés sur des classes, des interfaces, de l'héritage. Ils sont incapables de penser autrement, faute de pouvoir prendre du recul sur leurs propres outils.

Et puis il y en a quelques autres, souvent ceux qui sont tombés dans la marmite de l'informatique à ses prémices, et avant l'hégémonie des langages style Java, C++). Ceux-là sont capables de prendre plus de recul, de comprendre que les classes c'est pas la seule façon d'aborder le sujet de l'OO (ou du dev. en général), et sont aptes à comprendre un approche différente, qui a elle aussi ses atouts.

L'oeuf et la poule encore une fois, le modèle basés sur les classes est dominant parce que c'est celui qui fonctionne le mieux.... un peu comme la roue ronde s'est imposée contre la roue carrée.

C'est assez incroyable ce manque d'humilité, cet élitisme, ce manque de recul : "NOUS on a compris, NOUS on sait, les AUTRES sont des ignares !"

[hotcryx]

JavaScript bien évidemment, what else

JavaScript est bien orienté objet par contre, il a juste sa façon très personnelle de le faire, et par très personnelle je veux dire stupide.

Il y a des classes en JavaScript depuis récemment. Par contre toujours pas de typage strict... peut-être pour 2025 ?

C'est un autre type de langage, va falloir l'accepter au lieu de râler...

Si vous n'aimez pas javascript, faites autre chose.

Est-ce que les programmeurs en assembleur ou en C, pinallaient autant?!

[Doksuri]

Je déteste le Javascript car:

Pas Objet.

JavaScript est bien orienté objet par contre, il a juste sa façon très personnelle de le faire

tout est dit
quand aux scripts de troll que tu as copier/colle du site... comme je l'ai dis, tout a une explication logique.

[Sodium]

tout est dit
quand aux scripts de troll que tu as copier/colle du site... comme je l'ai dis, tout a une explication logique.

Ce n'est pas parce qu'une chose a une explication qu'elle n'est pas stupide

[Sophia N]

Je ne veux pas commencer une guerre, mais pour moi il faut distinguer langages de développements pour "développeurs"
C, C++, Swift, Objective-C, Pascal, etc
et les langages de scripting pour "webmasters"
Java, Javascript, etc...

Les langages qui compilent en standalone et les langages interprétés, recompilés (managed) qui donnent un produit final qui n'est pas vraiment votre code (Java, C#, etc...)

Developpeurs et webmaster sont tous deux informaticiens, mais spécialisés différemment.
Comme un dermatologue est un ophtalmologue, deux médecins, deux spécialités.

Personnellement j'utilise des langages de programmation. Compilés jusqu'au processeur.
Mais c'est un choix personnel.

[Invité]

Va savoir pourquoi moi j'aime bien faire du JQuery mais pas du Javascript. Mais étant PHPaddict', j'accepte de faire du JQuery couplé avec du PHP Symfony.