Discussion :

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

[darklinux]

Ah python le truc qui bouffe 225000 instructions pour faire 1+1 ? Le bidule avec un méga verrou globale de gogole ?

Python est juste une bouse mais à la mode.

Il faut considérer python comme un BASIC 2.0 avec des morceaux de Perl , sinon cela fait plus de vingt ans qu ' il est à la mode , c 'est donc un classique , comme " les variations Goldberg " par Glenn Gould un incontournable et oui , la rédaction est foutraque , mais permet de faire plein de choses intérréssantes .

[Engiwip]

Arrête j'ai appris Perl au collège j'adore ce truc 😱. J'avais même codé tout un moteur de recherche avec lol, robot, indexeur, indexeur etc.

Et oui on s y est tous intéressé. ( enfin je parle pour les séniors)
Et tu as du au moins écrire plus de documentation que de code.
Avec un web crawler qui tient sur une ligne...

Perl c est le spring break a cancun, l auberge espagnole qui ferait passer l inventeur de JS pour un nobel.( si si...)
Absolument tout est permis. Il y a des fans.
Des mongueurs qui disent. Des fous.

[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 !"

[foetus]

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 bidon ce que tu dis

Parce que la POO avec l'héritage est une forme de polymorphisme : elle s'est imposée rien du tout.
Pour le cas du JavaScript le but est de s'approprier et de modifier des objets (du contexte, ajout et suppression de méthodes) facilement et à l'exécution.

[Sodium]

C'est bidon ce que tu dis

Parce que la POO avec l'héritage est une forme de polymorphisme : elle s'est imposée rien du tout.
Pour le cas du JavaScript le but est de s'approprier et de modifier des objets (du contexte, ajout et suppression de méthodes) facilement et à l'exécution.

Ah ben oui, ajouter des méthodes à un objet à l'exécution ça sent bon la programmation robuste et maintenable

[nouknouk]

le modèle basés sur les classes est dominant parce que c'est celui qui fonctionne le mieux

Tu fais deux erreurs fondamentales dans ta réflexion:

1- tu a une vue dichotomique des choses: il n'y a pas une solution qui serait 'le bien', l'autre 'le mal'.

Les technos sont complémentaires et addressent des problématiques et des besoins différents. Un marteau en ferraille est super pour planter des clous mais n'égalera jamais un maillet quand on pose du carrelage. De la même fçaon, le JS n'est pas adapté pour écrire le driver d'un GPU, pas plus que l'assembleur n'est adpaté pour coder une page web.

2- d'autre part tu occultes complètement le fait que l'informatique n'est en rien un monde figé ; il évolue énormément, très vite, et les outils (dont les langages) avec lui.

Les lambda, la généralisation des appels asynchrones avec des callbacks, les promises (parmi d'autres choses) sont des exemples de concepts qui existaient depuis 40 ans (tu ne devais pas être né), mais que le JS a mis sur le devant de la scène parce que ça répond à un besoin de plus en plus courant, alors qu'il était marginal il y a quelques temps. Parce que l'informatique et les besoins évoluent, tout simplement. Et donc les outils avec.

Il y a 20 ou 30 ans, un programme était un monolithe qui vivait en relative autarcie ; l'overhead d'un code managé consommait en proportion une très large partie de la puissance de calcul disponible ; la mémoire disponible était une ressource relativement rare et limitée et on devait en optimiser sont usage, etc...

De nos jours, la plupart des logiciels sont pensés pour interagir avec l'extérieur , ils ont des besoins forts en traitements asynchrones, doivent être souple quant à la forme des données en input qui peut provenir de différentes sources, les développeurs veulent des outils qui résolvent les dépendances en allant les chercher eux-même sur des repositories sur le net, etc...
A contrario, l'évolution exponentielle de la puissance de calcul disponible rend l'overhead d'un code managé quasi négligeable pour la plupart des besoins, la RAM est disponible en quantité, etc...


Bref, tes réflexions manquent cruellement de mise en perspective et de pondération (peut-être as-tu une relative jeunesse comme excuse ?). Je te conseille vivement de ré-évaluer tes "certitudes". Pars du principe que s'il n'y avait qu'une seule solution parfaite à tous les problèmes et en tous temps, il n'y aurait qu'un seul langage qui conviendrait à tout le monde, ce qui n'est évidemment pas le cas.

La diversité des langages et autres outils n'est que le reflet d'une diversité des besoins, des projets, et qui évolue par ailleurs au cours du temps.

[Paleo]

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.

Deux commentaires :
- En JavaScript, un objet hérite toujours d'un autre objet, ce dernier lui servant de classe ;
- Au sujet de l'héritage entre classes que vous évoquez ici, en JavaScript il est justement aisé de s'en passer.

TypeScript de 1.9% à 8.5%.

Ce sont des développeurs JavaScript plus ou moins contraints de l'utiliser, notamment ceux d'Angular.

Ah ben oui, ajouter des méthodes à un objet à l'exécution ça sent bon la programmation robuste et maintenable

En JavaScript on peut fabriquer un objet de multiples manières, y compris en plusieurs étapes dans une fonction servant de factory. Cela ne veut pas dire que changer ensuite le type d'un objet serait une bonne pratique. Mais durant l'étape de création, pourquoi pas ? Les constructeurs des classes ne sont pas la seule manière de créer des objets.

[Pyramidev]

La diversité des langages et autres outils n'est que le reflet d'une diversité des besoins, des projets, et qui évolue par ailleurs au cours du temps.

Pas seulement. C'est aussi le reflet du fait que la conception des langages et des outils progresse par essais et erreurs.
Par exemple, en langage C, stocker un code d'erreur dans une variable globale (errno), ce n'était pas adapté aux besoins de l'époque. C'était une erreur de conception.
Il y a plusieurs solutions pour répondre à un même besoin dans un même contexte, et ce n'est pas toujours la meilleure qui est choisie.

[Sodium]

Les technos sont complémentaires et addressent des problématiques et des besoins différents. Un marteau en ferraille est super pour planter des clous mais n'égalera jamais un maillet quand on pose du carrelage. De la même fçaon, le JS n'est pas adapté pour écrire le driver d'un GPU, pas plus que l'assembleur n'est adpaté pour coder une page web.

Il faut arrêter le n'importe quoi, on plante les mêmes clous avec JavaScript qu'avec les autres langages, c'est juste le que le marteau de JavaScript est cabossé et mal foutu. La manière dont JavaScript fonctionne n'est pas là pour répondre à un besoin particulier (qui a l'époque était de faire clignoter un texte sur une page web) mais un effet de bord du temps ridiculement court consacré à sa création. Ben oui, même un génie quand on lui demande de créer un nouveau langage en dix jours il aura forcément des tares à la sortie.

[ragnarokr]

JavaScript fonctionne n'est pas là pour répondre à un besoin particulier (qui a l'époque était de faire clignoter un texte sur une page web)

On avait déjà la balise <blink> pour ça

[Engiwip]

Pas seulement. C'est aussi le reflet du fait que la conception des langages et des outils progresse par essais et erreurs.
Par exemple, en langage C, stocker un code d'erreur dans une variable globale (errno), ce n'était pas adapté aux besoins de l'époque. C'était une erreur de conception.
Il y a plusieurs solutions pour répondre à un même besoin dans un même contexte, et ce n'est pas toujours la meilleure qui est choisie.

ahah , tu n' as pas essayé le langage Go alors
mais bon c'est une erreur de conception google....çà passe crême.
comme dirais le fameux philosophe F.Ribery "la roue tourne va vite tourner "

[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?!

[hotcryx]

Il faut arrêter le n'importe quoi, on plante les mêmes clous avec JavaScript qu'avec les autres langages, c'est juste le que le marteau de JavaScript est cabossé et mal foutu.

Non, tu as différentes tailles de clous...

Si tu trouves que le JS est un marteau cabossé, peut-être n'es-tu tout simplement pas habile avec ce type de marteau.

[Sodium]

Code JavaScript :

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

1
2
3
4
5
6
7
8
9
10
11
const reasonsToHateJavascript = [
    'Object model is stupid',
    'No strict typing',
    'Absurd opperation results',
    'You need 200mo of dependencies to do any work',
    // ...
];
 
for (const reason of reasonsToHateJavascript) {
    console.log('YOU ONLY SAY THAT BECAUSE YOU\'RE TO DUMB TO GET IT!!!!'); 
}

[nouknouk]

...

je pense qu'on a atteint le niveau zéro de l'argumentation.

Manifestement les chances qu'il en ressorte quelque chose de constructif sont à peu près nulles ; bon vent à toi et toutes tes certitudes.