Comme déjà dit environ 2700 fois ce qui m'importe en tant que développeur, c'est la qualité du code sur lequel je travaille. Ce qu'il advient ensuite n'est absolument pas mon problème. Tant que cela fonctionne, le transpilateur peut bien le convertir en Brainfuck si ça lui chante.Du coup, selon ta logique, Angular et TypeScript ne sont faits que pour te ramener dans le rang, en te faisant quand même utiliser le JS, de façon détournée. T'as pas honte d'être tombé dans le piège ?
Euh non, c'est juste un des éléments qui démontrent que je me suis donné du mal pour appréhender le langage et que je connais probablement beaucoup mieux ses bases que beaucoup de monde ici.Et le sommet c'est quand un type te dit qu'il a lu un livre de sept-cents pages, et même que c'était écrit en tout petit, parce qu'il n'y a que les hommes, les vrais, qui ont le courage de lire des livres qui sont écrits en petit. Même que ça compte comme deux pages quand c'est écrit petit.
Quand je critique une chose, j'aime pouvoir le faire de manière éduquée.
Ce n'est absolument pas ce que j'ai dit. J'ai dit que l'héritage ne devait être utilisé que lorsqu'il se justifie et que les débutants en POO font souvent l'erreur de l'utiliser à la place de la composition/injection de dépendances.De même que l'affirmation selon laquelle l'héritage donne forcément du code de mauvaise qualité. On voit que les fondements théoriques qui se cachent derrière la pensée sont très solides...
Je n'hésiterai pas à me remettre en question dès que j'aurai vu un argument pertinent en faveur de JavaScript.Et, même si je chambre un peu, je trouve surtout dommage de camper infiniment sur ses positions et de refuser de se remettre en question. C'est pas grave de ne pas avoir la bonne réponse tout de suite, mais l'attitude constructive c'est d'accepter qu'on n'ait pas complètement raison, et pas forcément complètement tort.
Pour le moment, le seul argument qui ressort de ce débat, c'est que le JavaScript c'est bien parce que tout le monde l'utilise, et ce n'est pas bien convainquant...
Perso, je n'ai fait que lui démontrer qu'il ne sait pas de quoi il parle, que ses arguments ne tiennent pas... ce sont des faits, contrairement à son impression concernant ce langage.
Il n'a pas été capable de l'apprendre suffisamment pour en maîtriser les constructeurs d'objets globaux, comment aurait-il pu connaître suffisamment le langage pour savoir comment faire les choses proprement ?
Si j'ai donc une position, ce n'est que celle de quelqu'un qui a étudié et expérimenté ce langage en profondeur, qui en connait les capacités et limites, les best practices, ...
Désolé que mes réponses sur la POO ne te plaisent pas pour le moment.Quand tu vois les réponses sur la POO, par exemple, cela songeur sur le fait qu'il sache de quoi il parle, tu ne crois pas ?
Je te conseille de lire quelques bouquins sur le sujet de visionner des conférences, notamment sur le refactoring.
Je te conseille notamment cet article, même si je ne suis pas tout à fait d'accord, l'auteur prétendant que l'on n'a jamais besoin de l'héritage : https://r.je/you-do-not-need-inheritance-oop.html
Quand tu seras monté en compétences, on pourra peut-être rediscuter du fond.
Il n'y a pas de position. Essaye de relire si tu as besoin de comprendre le débat. C'est lui que donne un avis tranché basé sur des postulats erronés. Alors les personnes qui ont réagi se sont simplement contenté de reprendre ses arguments erronés pour lui expliquer pourquoi il se trompait. L'agressivité est venue ensuite, principalement parce qu'il répond à côté des arguments qui lui sont donnés, ou ne répond qu'à ceux qui lui plaisent (ajouté au fait qu'il traite les gens de neuneu, ce qui n'aide pas à lancer une discussion intéressante).
Ensuite, je ne crois vraiment pas qu'il faille sortir de Harvard pour comprendre que ce qu'il dit est une OPINION et non une réalité du Monde du développement. Se contenter de dire que JS est nul parce qu'on ne l'aime pas, c'est super intéressant.
Et, relis de nouveau si la première relecture n'a pas suffi, mais j'ai dit que je pouvais comprendre son opinion si elle aboutissait à une conclusion plus intelligente. S'il disait: "certains aspects me gênent, comme la façon de gérer les objets qui n'existe dans aucun autre langage, etc., et tout ceci fait que je n'aime pas JS", j'aurais dit que j'étais pleinement d'accord. Le langage est spécial et on a la droit de ne pas l'aimer.
Mais là, il se sert du fait qu'il ne l'aime pas pour dire que c'est une grosse bouse qui n'a rien à faire là. Super.
Si je disais que je n'aimais pas les poivrons verts parce qu'ils sont plus amers et moins sucrés que les rouges et les jaunes, tu me dirais que tu peux comprendre.
Mais si je disais que les poivrons verts sont moins sucrés donc ils ne devraient pas exister parce que ce sont vraiment les trucs les plus stupides du Monde (et qu'au passage je disais que les gens qui en mangent sont neuneu), tu penserais certainement que j'ai de sérieux problèmes dans ma tête.
Je termine en donnant un lien vers un article pas très vieux (et pas très récent non plus) qui donne des infos sur JS. J'avais trouvé les infos intéressantes, notamment celles proposées par certains liens dans l'article. On y comprend un peu mieux comment est conçu JS et, personnellement, ça m'a aidé à m'y adapter, parce que c'est un langage que je n'ai jamais apprécié (surtout au début) mais dont je comprends certains intérêts en étudiant les raisons pour lesquelles il est ainsi conçu:
https://medium.com/javascript-scene/...w-6fa6bdf5ad95
En PHP, je bosse aussi pas composition/injection de dépendances mais, en JS (même de façon détournée), donc, si je comprends bien, tu utilises un langage qui te propose un modèle objet alternatif, pour faire des classes qui ne bénéficieront pas de l'héritage ? Est-ce que tu te rends compte du non-sens ?
Je ne comprends rien à ta phrase, commence donc par te relire.
Je n'utilise plus JavaScript pour faire des choses complexes. Je l'ai utilisé par le passé pour faire quelques jeux vidéo, mais maintenant que je suis formé à Angular et TypeScript ça n'aurait tout simplement plus de sens.
J'utilise encore JavaScript pour faire ce pourquoi il a été prévu : ajouter des interactions simples sur une page.
Non, le problème vient de ta phrase. Déjà ça manque sérieusement de ponctuations. Ensuite la dernière partie ne veut tout simplement rien dire :
tu utilises un langage qui te propose un modèle objet alternatif, pour faire des classes qui ne bénéficieront pas de l'héritage ? Est-ce que tu te rends compte du non-sens ?
Qui utilise ? Moi ? Quel modèle alternatif ? Le prototypage ? Mais tu parles de classes ensuite. Si j'utilise des classes, je n'utilise donc pas le modèle alternatif.
"Qui ne bénéficieront donc pas de l'héritage" : quelle différence avec PHP ?
De fait, je n'ai de mémoire encore jamais écrit de classe héritant d'une autre classe en JavaScript. Cela ne veut pas dire que je ne le ferais pas si je me retrouvais face à un cas de figure où cela ferait sens.
Bref, je ne vois tout simplement pas où tu veux en venir.
Tout cela mérite des discussions conceptuelles qui vont bien au delà de la question du sujet.
Le concept de classe est discutable en soi et son intuitivité tout autant
Ouep et moi j'attends toujours le lien qui sous-tend tes propos concernant le typage fort et classes vs prototypes dans les urgences de Eich
non tu ne te trompes pas.
Le langage n'est pas responsable quand on sait à quel point il est optimisé aujourd'hui selon les moteurs d'exécution des différents navigateurs, mais plutôt ce que l'on cherche à en faire ou ce que l'on en fait.
Au hasard HTML (Hyper Text Markup Language)
Ma ponctuation est tout à fait correcte... Tu ne dois pas être davantage au fait de la grammaire, que du JS.
Que tu préfères le TypeScript, pour rédiger ton code, ok, si t'es plus à l'aise avec, pourquoi pas.
Mais ça n'explique pas pourquoi utiliser des classes, alors que tu n'en utilises pas le seul avantage potentiel de ce modèle et qu'un autre modèle objet existe et est suffisant. (D'autant plus qu'en TS, il est tout de même possible de combiner objets et interfaces, sans classes.)
Je ne sais pas où tu as lu ou entendu que le seul "avantage potentiel" des classes était l'héritage mais c'est un non sens total.Que tu préfères le TypeScript, pour rédiger ton code, ok, si t'es plus à l'aise avec, pourquoi pas.
Mais ça n'explique pas pourquoi utiliser des classes, alors que tu n'en utilises pas le seul avantage potentiel de ce modèle et qu'un autre modèle objet existe et est suffisant. (D'autant plus qu'en TS, il est tout de même possible de combiner objets et interfaces, sans classes.
L'intérêt principal des classes (ou des autres formes d'objet) est de séparer un code complexe en petits composants très simples et idéalement réutilisables.
Quant à pourquoi utiliser des classes plutôt que de prototypes, c'est tout simplement afin d'avoir un code plus concis et donc à la fois plus clair et moins générateur de bugs potentiels. Tout en étant bien entendu plus facile à appréhender pour mes collègues qui font plutôt du Java et ne sont donc pas forcément au fait des excentricités de JavaScript.
On parle de langages de programmations là, pas de structuration... mais si tu veux un autre exemple de langage ayant le monopole dans son domaine et possédant de sérieuses lacunes qui sont comblées en partie par des librairies tierces, CSS est un autre bon exemple.Au hasard HTML (Hyper Text Markup Language)
Let me fix it for you:
En PHP, je bosse aussi par composition/injection de dépendances. Mais tu veux donc dire qu'en JS, tu préfères utiliser des classes alors que le modèle par prototype te permettrait d'arriver au même résultat puisque tu n'utilises pas l'héritage ?
Pour comprendre ta phrase, il fallait déjà être dans ta tête et savoir que pour toi, le seul intérêt des classes par rapport aux Prototypes est l'héritage, ce qui est bien entendu doublement faux puisque 1) ce n'est pas le seul avantage des classes et 2) on peut tout à fait faire de l'héritage avec les prototypes.
je partage évidemment cet avis à 200% tout est dit et cette argumentaton je ne cesse de la tenir sur ce forum.
Bref plus on utilise des frameworks de manière abusive plus le risque est de construire des usines à gaz qui évidemment risquent de tourner au ralenti.
Logiquement un projet informatique ne devrait pas être dépendant de plus de 2-3 technos
c'est exact mais encore faut-il concevoir ces petits composants de manière efficiente c'est là la difficulté du design des objets.
Autrement on risque de produire du code "lasagne"
voui c'est bien pour ça que chacun a sa propre vision et conception des choses.
Si je te parle d'un objet en particulier tu ne le vois pas de la même manière que je le vois.
Et pour conceptualiser cet objet sous forme de code informatique et donc de données qui le décrivent il y aura quasiment autant d'appréciations de cet objet qu'il n'existe d'individus, histoire de compliquer les choses
C'est super intéressant dis-moi ça, tu tiens ça d'où, la grande Bible des 100 chiffres à retenir en informatique ?je partage évidemment cet avis à 200% tout est dit et cette argumentaton je ne cesse de la tenir sur ce forum.
Bref plus on utilise des frameworks de manière abusive plus le risque est de construire des usines à gaz qui évidemment risquent de tourner au ralenti.
Logiquement un projet informatique ne devrait pas être dépendant de plus de 2-3 technos
Quand on fait du web, on se retrouve à faire systématiquement face aux mêmes problématiques. Si on est un peu organisé, on va commencer à développer des librairies. Et si l'on est réellement organisé, on finira par regrouper ces librairies en un framework.
Alors, faire son propre framework, c'est très bien pour monter en compétence, mais on finira forcément par rencontrer l'un ou plusieurs des problèmes suivant :
- Mieux vaut avoir sacrément bien bossé la doc et la tenir à jour en permanence si l'on ne veut pas devenir la personne du bureau qui ne peut jamais prendre un congé parce qu'au moindre pépin, elle devra intervenir
- C'est beaucoup plus compliqué de recruter de nouveau collaborateurs et de les évaluer s'ils ne sont pas déjà formés à la techno utilisée dans l'entreprise
- Beaucoup de clients sont réticents à acheter du développement 100% maison car ils veulent pouvoir changer de prestataire si le besoin se fait sentir
- Et surtout, probablement le point le plus important, même une équipe de quelques génies ne pourra jamais faire un travail du niveau d'un projet open-source avec des milliers de contributeurs et quelques fois des gens de Google ou Facebook dessus
À la limite, la seule "bonne" raison de s'acharner a maintenir son propre truc, c'est que pour les employés de la boîte ne montent pas en compétence sur une techno qui améliorerait leur employabilité ailleurs
N'est-ce pas là tout simplement le nœud du problème et quelque part l'opposition de fait qui existe depuis le départ ?
Peut-on ajouter "est-ce que les développeurs Java n'acceptent que de faire du Java" ? Est-ce que leur cerveau est contraint aux paradigmes de programmation qui accompagne ce langage ? Le Java serait-il exclusif ?
Que tu le veuilles ou non, HTML est un langage, et réponds à ta question qui ne précisait pas le besoin de programmation.
Fut un temps ou VBscript a eu cours sur IE, il t'aurait pas plu celui-là non plus
N'est-ce pas là tout simplement le nœud du problème et quelque part l'opposition de fait qui existe depuis le départ ?
Peut-on ajouter "est-ce que les développeurs Java n'acceptent que de faire du Java" ? Est-ce que leur cerveau est contraint aux paradigmes de programmation qui accompagne ce langage ? Le Java serait-il exclusif ?
Si tu veux ...Que tu le veuilles ou non, HTML est un langage, et réponds à ta question qui ne précisait pas le besoin de programmation.
Alors allons-y, Morse VS araméen, vous avez 10 minutes.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager