Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Bonjour,
je me demande moi pourquoi à chaque fois que l'on parle de JavaScript les détracteurs arrivent de toutes parts alors que cela n'est même pas l'objet de la news ?Envoyé par Sodium
Perso quand même là où je me gausse c'est quand je lis de ta part
Les joies du CSS | Réponses sur forum | Simple comme JS | Essais libres autour de l'API G$$gle Maps
✂ ---------------------------------------------
developpez.net c'est aussi :
✔ Les meilleurs cours et tutoriels pour apprendre le CSS
✔ Les meilleurs cours et tutoriels pour apprendre le (X)HTML
✔ Les meilleurs cours et tutoriels pour apprendre le JavaScript
Pour la 100ème fois ... parce que JS est un langage de merde. Quand une techno a autant de détracteurs, l'hypothèse la plus raisonnable est généralement qu'il y a de bonnes raisons de ne pas aimer cette techno.je me demande moi pourquoi à chaque fois que l'on parle de JavaScript les détracteurs arrivent de toutes parts alors que cela n'est même pas l'objet de la news ?
Il est difficile d'être développeur web sans avoir du à un moment où l'autre acquérir une certaine expérience de JS. Partir du principe que tous ses détracteurs le critiquent à cause d'une méconnaissance est donc une très lourde erreur.
Quand on critique les propos d'une personne, le minimum est d'amener un minimum d'arguments ou d'expliquer au moins ce que l'on critique.Perso quand même là où je me gausse c'est quand je lis de ta part
Est-ce que tu te "gausses" parce que du code TypeScript est forcément retranscrit en JavaScript (bien dégueulasse) ? Si tu pars par là, tout code finit par être transformé en binaire, donc peut-être que l'on devrait tous coder en binaire (ou au moins en assembleur) ?
De mon côté, je travaille depuis une bonne dizaine d'années avec ExtJS, de la version 2 à la version 6 aujourd'hui. Je développe notament un ERP interne pour mon groupe... franchement ça fait bien le job...
ExtJS 6 est beaucoup moins permissif, surtout quand tu es en MVC ou MVVM.
Tiens, un autre truc rigolo avec JavaScript c'est que quand on le critique il y a systématiquement une armée d'acharnés sectaires qui viennent hurler que l'on n'a pas compris le langage, que l'on est débile et/ou incompétent, mais jamais le moindre intervenant pour poster un lien vers un exemple de code source bien écrit pour apporter une démonstration illustrant ses propos.
Une recherche Google sur "well written JavaScript code" ne renvoie rien de concluant, juste des bonnes pratiques de programmation de base (nommage de variables et fonctions...).
Du bon code PHP ? Déjà nettement moins compliqué : https://github.com/laravel/framework...Filesystem.php
Tout est limpide, une fonction fait rarement plus de 3 lignes et surtout n'est pas pollué à 80% par du bullshit spécifique au langage qu'il faut arriver à filtrer visuellement pour comprendre la logique de ce qui s'exécute derrière du genre MachinChose.prototype.maFonction = function() {...};
Par le passé, j'avais le même rapport avec Javascript. Mais la dernière évolution, particulièrement du coté de la POO, c'est révélé un très net progrès. Pour un programme comme l'éditeur Atom, je comprend l'utilité d'un typage strict. Mais pour les trucs qui tiennent sur deux pages, cette obsession me fais penser aux types qui porte des bretelles avec une ceinture.
Yay, JavaScript a progressé, il en arrive peu à peu au niveau du PHP d'il y a 10 ans ... à condition de le retransformer derrière pour qu'il soit compatible avec les navigateurs.Par le passé, j'avais le même rapport avec Javascript. Mais la dernière évolution, particulièrement du coté de la POO, c'est révélé un très net progrès.
La question n'est pas pourquoi utiliser un typage strict mais pourquoi s'en passer.Pour un programme comme l'éditeur Atom, je comprend l'utilité d'un typage strict. Mais pour les trucs qui tiennent sur deux pages, cette obsession me fais penser aux types qui porte des bretelles avec une ceinture.
Avec un typage strict :
- tu sais ce qu'attend une classe ou fonction et ce qu'elle renvoie juste en lisant sa déclaration, la doc devient dans la majorité des cas superflue.
- l'IDE affiche les erreurs et éventuellement bloque à la compilation si une fonction reçoit une mauvaise valeur ou ne renvoie pas ce qu'elle devrait, évitant des tests inutiles et d'éventuels plantages de l'application en production
- l'iDE permet peut afficher directement les fonctions et variables d'une classe ainsi que ce qu'elle attend et renvoie
Le typage strict force également à de bonnes pratiques de programmation, ce qui donne au final un code plus simple et plus clair et d'éviter des trucs illisibles et inmaintables du genre "var data = unNombre; data = data.toString(); data = faisDiversesOpératiionsSurMaVariable(data); ...".
Et sérieusement, c'est tant de boulot que ça que de déclarer le type d'une variable ? Ca justifie d'obliger celui qui relira le code dans 6 mois (souvent soi-même) à relire le contenu d'une fonction pour comprendre ce qu'elle attend, fait et renvoie ?
Il en va de même pour l'encapsulation : on ne déclare pas une variable comme privée juste pour le fun, se taper du travail en plus ou faire plus "pro" mais pour s'assurer qu'elle ne pourra pas être modifiée ailleurs, compromettant le fonctionnement de l'application.
J'aimerais bien savoir pourquoi il serait impossible de faire un code de qualité avec du JS alors que ce serait possible avec du TypeScript (puisqu'au final on produit du JS à partir de ce dernier) ? Si c'est parce que JS est trop permissif alors qu'est-ce qui empêche de s'imposer quelques "contraintes" ou plutôt "règles" ?
Par exemple pour le typage il y a quand même quelques moyens/outils dont on peut se servir, je pense à la JSDoc qui peut être prise en compte par certains outils d'assistance et il y a même un linter qui signale les erreurs liées à cela...
Mais peut-être que j'ai mal compris le problème ?
Il est impossible de faire du code de qualité parce que la syntaxe est dégueulasse dans tous les cas.J'aimerais bien savoir pourquoi il serait impossible de faire un code de qualité avec du JS alors que ce serait possible avec du TypeScript (puisqu'au final on produit du JS à partir de ce dernier) ? Si c'est parce que JS est trop permissif alors qu'est-ce qui empêche se s'imposer quelques "contraires" ou plutôt "règles"...
Pour ce qui est du code JS qui résulte du TypeScript, on en revient à ce que l'on disait : au final, on fait toujours du binaire, le langage de programmation n'est là que pour l'organiser.
S'imposer des contraintes ne sert à rien si le langage n'apporte aucune aide derrière. Exemple là en une ligne je sais ce que ma fonction fait :
Pas besoin de commentaires ni de tests à l'intérieur de la fonction pour vérifier que la qu'elle ne reçoit pas des données de type incorrect.
Code : Sélectionner tout - Visualiser dans une fenêtre à part public function doSomething(string variable): void { ... };
Comme le disait l'oncle Bob, les commentaires sont en général de la pollution : un code clair n'a besoin que de très peu de documentation et encore faut-il penser à mettre à jour la doc lorsque l'on met à jour le code, ce qui est loin d'être évident même en étant attentif...Par exemple pour le typage il y a quand même quelques moyens/outils dont on peut se servir, je pense à la JSDoc qui peut être prise en compte par certains outils d'assistance et il y a même un linter qui signale les erreurs liées à cela...
http://www.kyleblaney.com/software-b...a-failure.html
Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation.
Comments are not like Schindler's List. They are not "pure good." Indeed, comments are, at best, a necessary evil. If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much -- perhaps not at all.
Quand je tape "Sodium" et "cerveau", le premier résultat qu'on obtient c'est "Le Sodium : une solution efficace contre le cerveau ...".
Coïncidence ?
Trêve de plaisanteries, on a compris ton message : Tu n'aimes pas le JavaScript parce qu'il n'y a pas de typage statique natif.
Pour le moment c'est toi l'acharné sectaire qui vient hurler que JavaScript c'est "de la merde" pour reprendre ton argumentaire.
Si ça te saoule tant que ça qu'est ce que tu fais sur cette partie du forum et sur ce fil de discussion ? Ça fait du bien quand ça fait mal c'est ça ton truc ?
Bricolages...
Pour info, le créateur de JS, Brendan Eich, avait voulu prendre Scheme, un des deux LISP de l'époque, pour langage de script pour navigateur... Sa hiérarchie lui a demandé de prendre/pondre au contraire un langage de script proche de la syntaxe ultra habituelle de C/C++/Java, choix marketing mais pas des plus heureux, et lui a même imposé de le nommer JavaScript pour coller à Java... Le monde en eut été totalement autrement, si le choix de Eich, Scheme, avait été réalisé, avec un langage solide, extensible (macros) par nature, et surtout fonctionnel! On aurait pas perdu 20 ans et plus (les FP revenant enfin)..., autant de trous de sécurité, le parallélisme (CPU ARM multicores sur nos smartphones), etc. Sic!
"JavaScript est une merde": j'acquiesce non parce que ça l'est (et ça l'est...) mais parce que ça a détourné le monde des dev de vrais langages beaucoup, beaucoup mieux pensés, académiques, propres, puissants, lisibles, etc. Que SmallTalk et Lisp aient eu si peu de succès est triste... Mais le monde est rempli de succès de bricolages (de génies), à commencer par le PC et DOS/Windows... Et que même Linux, initié par un jeune étudiant et non pas une vraie organisation solide, ai tué les Unix et NT me laisse pantois sur cette industrie: bordel ou génie, ou les deux...
Pour revenir au sujet, après avoir tâté divers frameworks avec mes collègues, la messe est dite: chacun a ses forces et faiblesses, et mieux vaut fouiner la faiblesse que la force, et trouver là où le bat blessera: pour le mobile, je ne parie plus que sur React Native tant nous nous sommes cassé les dents sur les autres frameworks sur une fonctionnalité ou une autre, telle que les badges de notification pour une app iOS par exemple, ce que d'autres FW faisaient mal ou pas. Sans parler des motifs interactives, etc.: là, seul un FW vraiment mature ayant essuyé TOUS les plâtres récents (upgrade d'iOS, pour ne pas le nommer, Apple se foutant vraiment bien des dev hors de ceux qui ont mangé leur pomme...) est fiable. Et je connais nombre d'agences web, en France ou ailleurs, qui me l'ont aussi dit, après avoir testé d'autres FW pour le mobile...
(Cela dit, si j'avais le choix, sur seulement mobile, je prendrais Dart/Flutter... plus de JS ou TS ou... ni d'API native à binder, tout se fait dans Flutter même les composants graphiques, et c'est compilé, bref, c'est propre, loin de ces bricolages aussi géniaux soient-ils... mais ce n'est pas le sujet ici, pardon.)
Hors mobile, juste sur Web desktop, React vs Angular, c'est "le bazar vs la cathédrale" (voir ce que ça signifie sur wikipédia, instructif) , c'est "petite équipe stable" (agence web, start-up) versus "grande entreprise et équipe mouvante", de l'avis d'experts et formateurs sur les deux: Angular, en imposant ses choix et en étant très complet, permet à des nouveaux venus d'autres entreprises où ils l'utilisaient d'arriver en terrain connu et très balisé, d'être opérationnel rapidement. React permet trop de choix d'outils de son écosystème à la demande, mais inversement permet aussi de choisir ce qu'on veut selon le besoin.
Tout ça me fait penser aux OS, les distros GNU/Linux (comparables à la demande pour coller au plus près du besoin, optimales) vs Windows ("je fais tout pareil, partout, je suis gros mais facile, c'est pareil partout"...), non?
Vive WASM, j'attends que Python y passe... enfin quelque chose de lisible... (oups, ok, troll inside, je sors...)
ps:regardez ReactXP de Microsoft avec lequel ils ont fait leur Skype, et les initiatives équivalentes React Native for Web et React DOM (et https://platform.uno), ça serait cocasse que ce soient les langages mobile natifs qui aillent sur le Web grâce à WASM, et tuent JS, in fine, plutôt que le contraire comme avec React Native, non?
Je ne suis pas sûr de te suivre parce que je ne connais pas TypeScript alors : tu veux dire que la vérification comme quoi on passe bien une string en argument est faite automatiquement, c'est ça ? Si oui ben apparemment il faut quand même ajouter le mot "string", non ? Bon je t'accorde que c'est plus concis que de mettre une ligne de JSDoc (oui parce que comme déjà dit il y a des outils qui prennent en compte la JSDoc, c'est-à-dire tu peux préciser le type des paramètres et c'est pris en compte par le linter par exemple) mais en fait il y a même des outils qui sont capables de deviner le type du/des paramètre(s) de la fonction (et même celui de la valeur retournée) et ils peuvent même écrire la JSDoc automatiquement...
Après la JSDoc (qui indique le type des paramètres et celui de l'éventuel valeur retournée, une description,...) on aime ou on n'aime pas, mais cela peut être très utile et elle est très utilisée en Java malgré que Java soit un langage typé et moins permissif d'ailleurs j'ai l'impression que TypeScript ressemble à Java...
Qu'on soit d'accord ou pas de toute façon il me semble que ce qu'il dit ne vise pas spécifiquement JS, non ? A moins que tu penses qu'un code écrit en JS ne peut en aucun cas être clair et nécessiterait donc forcément beaucoup de documentation pour être clarifié ???
Franchement parfois le code aura beau être clair il n’empêche qu'il peut être difficile (sans documentation) de comprendre ce que font certains algorithmes...
Je te répondrais: Est-ce si difficile de lire la documentation ?
Je ce n'est pas parce qu'un langage n'est pas typé qu'il n'y a pas de contrôle des valeurs pour autant. Autrement comment voudrais-tu faire des tests ? Beaucoup de programmeurs ont du mal à comprendre que Ruby soit un langage strictement typé malgré le fait qu'il n'y a de déclaration de type. Une assignation de variable avec une valeur est une méthode efficace de remplacer les déclarations de type. Que ce sois Ruby ou JavaScript. Après une première assignation de valeur une variable devient typée d'une façon définitive. Il en va de même pour les paramètres de fonction et de méthode.
Tu as peut-être entendu l'expression garbage-in garbage-out. Qui se traduirait par merde à l'entrée, merde la sortie. C'est vrai, mais ce que le concept doit rappeler au programmeur, est que seulement les entrées nécessité une vérification. SI tu as des tomates à l'entrée, les chances d'avoir du jus de pommes à la sortie sont nulles. Et c'est un point important, car un programmeur peut limiter les contrôles de types au strict minimum, alors que la majorité de compilateur n'y arrive pas. Donc avec le typage, tu as également une réduction de performance. Et pour un langage interprété, l'impact est encore plus prononcé. Parce qu'un langage interprété ne fait pas de multiple passe pour trouvé des façons d'optimiser.
JavaScript n'a pas été bricolé. Il a été fabriqué à une époque ou les ordinateurs n'étaient pas très performants.
Ce n'est pas une syntaxe spécifique à TypeScript mais plutôt commune à la majorité des langages orientés objet dérivés du C. Par ton ignorance, tu prouves assez bien mon propos : les défenseurs de JavaScript sont en majorité des développeurs peu expérimentés qui n'ont pas acquis de bonnes pratiques de programmation.Je ne suis pas sûr de te suivre parce que je ne connais pas TypeScript alors : tu veux dire que la vérification comme quoi on passe bien une string en argument est faite automatiquement, c'est ça ? Si oui ben apparemment il faut quand même ajouter le mot "string", non ?
De un oui, c'est ce que je pense, de deux en plus de ça la syntaxe de JavaScript est merdique, bourrée de mots-clés qui polluent la lecture du code.Qu'on soit d'accord ou pas de toute façon il me semble que ce qu'il dit ne vise pas spécifiquement JS, non ? A moins que tu penses qu'un code écrit en JS ne peut en aucun cas être clair et nécessiterait donc forcément beaucoup de documentation pour être clarifié ???
Si je dois lire la documentation, c'est dans la majorité des cas que le programmeur n'a pas fait son boulot correctement.Je te répondrais: Est-ce si difficile de lire la documentation ?
Tu ne connais visiblement pas bien l'histoire de JavaScript, et la fin de ton message est juste stupide : C++ ou Java existaient déjà depuis longtemps lorsque JavaScript a débarqué.JavaScript n'a pas été bricolé. Il a été fabriqué à une époque ou les ordinateurs n'étaient pas très performants.
tu n'aime pas la poo ? voir la programmation tout court ?
peut pas mieux faire(Cela dit, si j'avais le choix, sur seulement mobile, je prendrais Dart/Flutter... plus de JS ou TS ou... ni d'API native à binder, tout se fait dans Flutter même les composants graphiques, et c'est compilé, bref, c'est propre, loin de ces bricolages aussi géniaux soient-ils... mais ce n'est pas le sujet ici, pardon.)
Javascript est un excellent langage. Il suffit de s'y intéresser un peu, de ne pas être bloqué comme beaucoup sur le langage actuel qu'on vénère (Java, C#, Php, Python, C/C++ ou autre).
Chaque langage a ses avantages et ses inconvénients.
Mais on ne peut pas laisser dire que JS est un mauvais langage parce que :
- il n'est pas multithread : on voit bien NodeJS monothread qui a éclaté en perf (surtout en montée en charge...!!) d'autres serveurs web très connus et utilisés. Le créateur de NodeJS l'explique très bien d'ailleurs ici :
- il n'y a pas de typage fort : ici on est dans le cadre des capacités des développeurs à définir des contrats et à les respecter sans qu'on leur tienne la main, rien d'autre
- il n'y a pas de POO : JS est en POP, qui, une fois qu'on l'a compris, est tout aussi intéressant (voir plus pour moi) que la POO
Les exemples d'applications grands publics ayant un succès phénoménale existent bien :
- Discord : 50 MILLIONS de users toute plateforme confondue, 90% de code identique sur toutes les platesformes : Web, PC, Linux, Mobiles
- Visual Studio Code : un excellent éditeur
- Beaucoup des sites webs les plus utilisés
Bref, comme souvent, les détracteurs d'un langage communément utilisé n'ont tout simplement pas compris l'intérêt du langage et encore moins ses principes et son fonctionnement. Ils s'arrêtent à la comparaison de leur langage ou concepts favoris, sans chercher à sortir de leur zone de confort. Triste.
Ouais mais là on ne parle pas des autres langages, dans ce contexte tu critiques JS et tu défends TypeScript alors si maintenant tu compares JS aux autres langages, on ne vas pas s'en sortir, tu aimes bien te disperser apparemment...
Tu me fait rire des fois, tu as pleins de préjugés... D'abord je ne défends pas spécialement JS (j'ai moi aussi trouvé certains codes déroutants à cause de ce que permet la syntaxe du JS) ensuite je suis passé par le C/C++/Java avant JS et c'est vrai qu'une des choses qui m'avait troublé c'est qu'au début je m'attendais à retrouver avec JS toute l'assistance à laquelle j'étais habitué avec Java, j'ai mis du temps à trouver des outils qui s'en approchaient mais ils existent...
J'ai vraiment du mal à te suivre, je crois que tu vas me pousser à jeter un œil à TypeScript car quelques choses me dit que ce que tu reproches là à JS se retrouve aussi avec TypeScript. Par exemple les mots-clés du JS qui polluent la lecture du code comme tu dis ne se retrouvent-ils pas dans TypeScript ? Quelque chose me dit qu'il y en a même plus dans TypeScript...
Enfin bref...
Non, encore une fois le typage fort n'est pas qu'une question de fiabilité du code, c'est aussi une question de lisibilité...il n'y a pas de typage fort : ici on est dans le cadre des capacités des développeurs à définir des contrats et à les respecter sans qu'on leur tienne la main, rien d'autre
Tu te trompes toi-même... JS est totalement orienté objet, il n'est pas orienté classes... bref même les afficionados du langage ne le comprennent pas visiblement.il n'y a pas de POO : JS est en POP, qui, une fois qu'on l'a compris, est tout aussi intéressant (voir plus pour moi) que la POO
Et non, la programmation que ce soit par prototype ou par fonctions qui contiennent d'autres fonctions (qui est probablement l'un des concepts les plus stupides que j'ai jamais connus) n'est ni intéressante, ni lisible, c'est juste de la pollution inutile.
Je n'ai pas dit qu'on ne pouvait pas faire des applications à succès, j'ai dit qu'on ne pouvais pas faire du code propre, maintenable et lisible.Les exemples d'applications grands publics ayant un succès phénoménale existent bien :
Discord : 50 MILLIONS de users toute plateforme confondue, 90% de code identique sur toutes les platesformes : Web, PC, Linux, Mobiles
Visual Studio Code : un excellent éditeur
Beaucoup des sites webs les plus utilisés
Et Visual Studio Code est codé en TypeScript...
Je critique JS en tant que langage de programmation et je lui oppose son "concurrent" principal sur son terrain de chasse, je ne vois pas bien la contradiction.Ouais mais là on ne parle pas des autres langages, dans ce contexte tu critiques JS et tu défends TypeScript alors si maintenant tu compares JS aux autres langages, on ne vas pas s'en sortir, tu aimes bien te disperser apparemment...
Moi faire du TypeScript, du Java, du PHP ou du C++ je m'en fous, je veux juste avoir du code propre.
Oui tu soulèves bien le problème ... JavaScript est tellement un mauvais langage que tout le monde en fait parce qu'il est populaire mais presque personne ne l'utilise sans un ou plusieurs frameworks / librairies / pseudos-langages par dessus ...D'abord je ne défends pas spécialement JS (j'ai moi aussi trouvé certains codes déroutants à cause de ce que permet la syntaxe du JS) ensuite je suis passé par le C/C++/Java avant JS et c'est vrai qu'une des choses qui m'avait troublé c'est qu'au début je m'attendais à retrouver avec JS toute l'assistance à laquelle j'étais habitué avec Java, j'ai mis du temps à trouver des outils qui s'en approchaient mais ils existent...
Eh bien penches-toi sur TypeScript.J'ai vraiment du mal à te suivre, je crois que tu vas me pousser à jeter un œil à TypeScript car quelques choses me dit que ce que tu reproches là à JS se retrouve aussi avec TypeScript. Par exemple les mots-clés du JS qui polluent la lecture du code comme tu dis ne se retrouvent-ils pas dans TypeScript ? Quelque chose me dit qu'il y en a même plus dans TypeScript...
Par mots-clés je parle de la manière de déclarer les prototypes, fonctions dans des fonctions, variables dans des fonctions, etc.
Dans l'exemple "var machin.prototype.maFonction = function() => { .. }" tu as 3 bons quarts du code qui ne servent à rien par rapport à "function maFonction() { };" ou même "maFonction() { };" dans les langages "normaux".
TypeScript c'est un superset du JavaScript. 95% de ce que tu utilises quand tu écris ton appli Angular c'est pas les fonctionnalités ajoutées par TypeScript c'est du js vanilla.
Et c'est faux. Si tu étais honnête avec toi-même tu dirais que tu as des difficultés à lire un programme écrit avec un paradigme fonctionnel sans typage statique.
Le fait de rendre un code lisibile ou non a peu à voir avec le langage lui-même, mais avec le développeur : à condition d'avoir compris le langage, condition première évidemment, ce qui n'est clairement pas ton cas. Il est tout à fait possible de produire du code intelligible dans n'importe quel langage. La notion de contrats ainsi que la documentation associée sont là exactement pour ca.
Déjà, se tromper soi-même : drôle d'expression qui ne veut rien dire. En fait, t'es juste un petit troll qui pense être meilleur que les autres, mais qui n'a juste rien compris aux concepts dont tu parles. Et en plus tu montres continuellement ton incompétence en agressant les autres, ainsi que le langage que tu cibles par ton ignorance. Allez une petite aide sur la différence et l'intérêt, pourtant d'une évidence crasse, de la composition sur l'héritage :
Tiens donc. Et explique-moi comment on peut faire des applications aussi importantes par exemple que Discord, avec 90% de code commun sur toutes les plateformes, utilisé par 50 millions de personnes à travers le monde, avec un langage avec lequel on ne pourrait soit-disant par faire de code propre, maintenable et lisible? Rigolo va.
Comme tout les langages dès que tu veux faire du code découplé, maintenable, et en plus forcément lisible, des frameworks structurants voient le jour. Rien d'étonnant, à part si on ne sait pas de quoi on parle...
Tu n'as effectivement rien compris au prototypage objet. Ca te semble illisible parce que tu es mauvais, alors tu décides de traiter le langage de mauvais pour excuser ton incompétence. Rigolo #2.
Pas besoin de répondre, tu passes en ignore list directe.
Ce genre de troll déconsidère fortement le forum, tout en empêchant de discuter du sujet. Il ne discute pas, il affiche son incompétence et aggresse les autres qui eux, ont pour la plupart pris la peine de comprendre. C'est dommage, sur un forum orienté entre-aide.
C'est exactement ca!
Pour la centième fois cet argument n'a aucune pertinence. On s'en fout de en quoi le code est transformé au final, ce qui importe au programmeur c'est le langage dans lequel il code. Après ça peut bien être transformé en JavaScript, en ActionScript, en C ou en ook je n'en ai absolument rien à foutre, c'est le job du transcompilateur, pas le miens, et personne (à moins d'être masochiste) n'ira jamais lire le code final en JavaScript.TypeScript c'est un superset du JavaScript. 95% de ce que tu utilises quand tu écris ton appli Angular c'est pas les fonctionnalités ajoutées par TypeScript c'est du js vanilla.
Euh je n'ai commencé à utiliser le typage statique qu'il y a 2-3 ans... L'absence de typage statique n'est qu'un problème parmi d'autres.Et c'est faux. Si tu étais honnête avec toi-même tu dirais que tu as des difficultés à lire un programme écrit avec un paradigme fonctionnel sans typage statique.
I'm rubber you're glue...En fait, t'es juste un petit troll qui pense être meilleur que les autres, mais qui n'a juste rien compris aux concepts dont tu parles
Je ne vois pas bien le rapport, on peut très bien faire de la composition en PHP ...Allez une petite aide sur la différence et l'intérêt, pourtant d'une évidence crasse, de la composition sur l'héritage
https://r.je/you-do-not-need-inheritance-oop.html
Bref, encore une preuve d'ignorance.
De la même manière que des mecs ont érigé des temples et des pyramides majestueux il y a 5000 ans avec des rondins.Tiens donc. Et explique-moi comment on peut faire des applications aussi importantes par exemple que Discord, avec 90% de code commun sur toutes les plateformes, utilisé par 50 millions de personnes à travers le monde, avec un langage avec lequel on ne pourrait soit-disant par faire de code propre, maintenable et lisible? Rigolo va.
On peut faire n'importe quoi avec n'importe quoi à condition d'y consacrer suffisamment d'efforts. On le fera juste moins vite et bien. Si tu aimes travailler avec des rondins tant mieux pour toi, perso je préfère utiliser une grue...
C'est illisible parce que c'est illisible. Quand je lis du code, je ne devrais pas avoir à filtrer visuellement près de 3/4 d'éléments inutiles pour comprendre la logique.Ca te semble illisible parce que tu es mauvais, alors tu décides de traiter le langage de mauvais pour excuser ton incompétence.
Répondre avec citation
Partager