Discussion :

[Pongten]

Si tu veux représenter une url valide tu te fais une classe ValidUrl. Tu pourrais très bien vouloir manipuler une url invalide pour x raisons. En proposant implicitement que l'url doit être valide tu masques le comportement réel de ton constructeur et tu fais des suppositions.

Heu.. là, tu joues sur les mots.. le type int représente un nombre entier, on ne l'a pas nommé validInt pour dire que c'est vraiment le cas..

Deuxième problème comment tu définis valide ? Sur quels critères ? Pour moi tout ça nécessite un mécanisme à part, séparé et explicite.

Maintenant, je m'entends sur la notion de "validité". Je veux dire ici que l'objet garantira que son contenu peut effectivement être considéré comme une URL, mais pas nécessairement que l'URL mènera effectivement à une ressource valide, etc..

C'est pas aussi clair que tu le prétends. Il y a beaucoup de développeurs qui recommandent de se limiter à l'assignation de valeurs. Le plus connu ça doit être l'article de Misko Hevery (l'auteur initial d'AngularJS) mais il y en a beaucoup d'autres.

Je ne trouve pas que son article contredise mes propos. Pour moi le constructeur s'assure que l'objet qu'on lui demande de créer est valide. C'est une des bases de la POO, l'encapsulation. Par contre, il va de soi que si l'objet à des dépendances, ce n'est pas sa responsabilité de les construire et donc intervient l'injection (mais on s'écarte là…)

[Pongten]

Un chantier a beau être une "anticipation" de building de standing, je ne voudrais pas vivre sur un chantier.

Puisqu'on est dans la formule.. on peut mener un cheval à la rivière, mais pas le forcer à boire.

Pour la programmation c'est pareil, je n'ai pas envie de m'acharner sur un langage qui peut-être dans 15 ans sera au niveau de la concurrence, je préfère passer directement à autre chose de réellement abouti, et à ce niveau TypeScript fait toujours bien le job, même s'il manque encore des choses comme de véritables tableaux associatifs par exemple.

Tu peux me dire sur quel langage tu travailles qui n'a connu aucune évolution depuis sa création ?
On peut regarder entre PHP 1 et PHP 7 ? C#1 et C#8 ??? etc ?

Pourquoi JS n'aurait pas le droit d'évoluer ?

[Pongten]

Pour ma part je n'arrive pas à penser en objet, de la manière classique telle qu'elle est souvent évoquée ici.
Pour moi qui n'a pas eu droit au bourrage de crane scolaire, l'approche fonctionnelle ou bien procédurale est bien plus intuitive.
Elle n'exclut pas l'objet, mais ces objets sont l'objet justement de traitements qui correspondent à des fonctions. On peut chainer ces traitements sans que ceux-ci dussent répondre forcément d'appartenir à une classe et tout le bataclan bien lourdingue de la POO.
C'est juste comme la réalité de la plupart des productions humaines, on prend des matières, on les transforme, on les combine, on les assemble, et on en sort des objets finis. Aucun de ces objets dans la vraie vie, pas plus que les matières ou les objets intermédiaires qui vont composer l'objet final ne portent les fonctions qui permettent ces transformations, combinaisons, compositions...

On peut faire l'exercice, décrire une voiture en POO et en Procédural.. challenge ?

[Sodium]

Pourquoi JS n'aurait pas le droit d'évoluer ?

1) C'est beaucoup trop lent. PHP est devenu fréquentable depuis sa version 5.4 sortie en 2012 et n'a plus grand-chose à envier à ses concurrents depuis la version 7 sortie fin 2016. JavaScript est encore loin d'être au niveau de PHP 5.4
2) Le langage ne doit pas évoluer mais se transformer. Il faut que son paradigme parte aux oubliettes. Quand il sera enfin à la hauteur de ses concurrents, il ne s'agira plus du tout du même langage et acquérir une expérience dans le JavaScript actuel est donc une perte de temps
3) JavaScript est exécuté côté client et le programmeur est donc dépendant de l'interpréteur. Lorsque qu'il sera devenu un langage réellement intéressant, il faudra au minimum 10 ans pour qu'on puisse l'utiliser tel sans craindre de se couper d'une masse importante d'utilisateurs (et quand tu travailles en entreprise, tu as beau n'avoir que 2 ou 3% d'utilisateurs avec des machines et/ou navigateurs obsolètes, souvent ce sont 2 ou 3% d'utilisateur dont on ne peut pas se permettre de perdre le chiffre d'affaire)

[ijk-ref]

En gros, TypeScript est (excepté par rapport à la possibilité du typage) juste une anticipation de JS..

Woué "en gros" à part le petit truc de rien du tout qui est le typage statique

La vitalité du web, du WWW est indéniable, alors comment prétendre qu'il y a un problème avec le langage.

Le gros avantage du JS est qu'il est universel…le seul standard... contrairement à toutes les autres solutions comme les applets Java, Flash/actionscript ou Silverlight qui restaient propriétaires et ne fonctionnaient pas sur toutes les platforms. La grande force de JS est aussi de permettre d'écrire rapidement de petits codes sans grande connaissance en programmation.

Donc oui JS est incontournable à l'heure actuelle où tout se passe sur le web. Sauf qu'un petit détail semble t'échapper : aucuns gros projets ne sont codés directement en JS. Google utilise Dart et Microsoft utilise TypeScript. JS n'est qu'ici le langage cible. Ta remarque est donc comparable à ne pas voir de problème à coder directement en langage machine. Si tu n'y vois pas de problèmes…

[goldbergg]

@goldbergg : ...

Ok je comprend mieux, merci pour ce details.

Le c# m'a l'air en effet beaucoup plus strict que le D niveaux déclaration.

On peut faire l'exercice, décrire une voiture en POO et en Procédural.. challenge ?

C'est l'un des premiers truc que j'ai appris a faire en C avec les structure.

[Invité]

J'imagine que l'on peut le faire via les WebAssembly, non ? Enfin ça, c'est pour le côté client.

Merci pour l'info. J'ai regardé et effectivement l'interfaçage JS/C++ est relativement propre en WebAssembly. Par contre, il faut vraiment faire le tri dans les docs pour trouver des infos exploitables et je n'ai pas trouvé comment réutiliser facilement le code wasm généré par emscripten dans nodejs. Enfin, WebAssembly nécessite de compiler toutes les dépendances, et honnétement j'ai autre chose à faire que d'aller récupérer le code source de toutes les libs que j'utilise.

Pour résumer, si j'ai un code C++ qui utilise quelques libs et que je veux l'appeler dans un code JS, en pratique c'est juste pas possible : avec les interfaces de nodejs il faut se taper des wrappers dégueulasses comme il y a 20 ans et avec WebAssembly il faut quasiment que je recompile mon OS en wasm. En python, ça me prend 2 min café compris.

Franchement, je suis de plus en plus déçu par JS. L'ES6 est sympa mais les fameux avantages "langage universel front-back", "interfaçage performant" etc, c'est du total bullshit. Au moins, j'ai compris pourquoi JS est populaire : il est tellement pauvre que n'importe qui peut devenir "expert" en quelques mois.

Et par pitié, ne me ressortez pas les arguments "tu n'as pas compris l'expressivité des prototypes" ou "JS est utilisé par Google/Facebook...". Pour l'expressivité allez voir les traits et les types algébriques en Rust et vous pourrez mettre les prototypes JS bien profond dans la poubelle. Quant à l'utilisation de JS par Google/Facebook... oui... sauf que c'est généralement pour coder des micro-services pas trop compliqués; leurs systèmes d'IA et de big data, ils ne sont pas codés en JS; à un moment il faut arrêter le délire.

[Marco46]

Heu.. là, tu joues sur les mots.. le type int représente un nombre entier, on ne l'a pas nommé validInt pour dire que c'est vraiment le cas..

Non c'est un problème de nommage et c'est fondamental, en plus tu prends un type primitif c'est assez limite comme comparaison.

Maintenant, je m'entends sur la notion de "validité".

Mais c'est exactement ce que je reproche à ta démarche, je ne suis pas dans ta tête et donc je ne t'entends pas. C'est pour ça qu'il faut être explicite et là clairement ce n'est pas le cas.

Je ne trouve pas que son article contredise mes propos.

Bah je sais pas ce qu'il te faut :

Warning Signs:
- ...
- Static method calls in a constructor or at field declaration
- Anything more than field assignment in constructors
- Control flow (conditional or looping logic) in a constructor
- ...

Ça fait 3 warning sur 7 de cochés au minimum.

Autres points :

- Comment tu écris le test de ta logique de validation ?
- Comment tu réutilises ailleurs cette logique de validation ?

Pour moi le constructeur s'assure que l'objet qu'on lui demande de créer est valide.

Sauf que la définition du terme "valide" est sujette à interprétation. C'est beaucoup trop tendancieux.

2) Le langage ne doit pas évoluer mais se transformer. Il faut que son paradigme parte aux oubliettes. Quand il sera enfin à la hauteur de ses concurrents, il ne s'agira plus du tout du même langage et acquérir une expérience dans le JavaScript actuel est donc une perte de temps

Le paradigme principal de JavaScript c'est le fonctionnel et presque tous les frameworks js modernes utilisent à fond ce paradigme. Et c'est parfaitement adapté au front parce qu'en définitive un frontend c'est une grosse fonction qui prend en entrée les données qu'il tire sur le réseau pour les sortir dans sa page html.

Le one way binding, l'immutabilité, et Redux ça vient tout droit du fonctionnel ça n'a aucun rapport avec la POO.

Tu as un blanc dans ta veille techno de fin 2015 à aujourd'hui. Mais sinon ça doit être moi qui suis vieux et obsolète hein

il faudra au minimum 10 ans pour qu'on puisse l'utiliser tel sans craindre de se couper d'une masse importante d'utilisateurs (et quand tu travailles en entreprise, tu as beau n'avoir que 2 ou 3% d'utilisateurs avec des machines et/ou navigateurs obsolètes, souvent ce sont 2 ou 3% d'utilisateur dont on ne peut pas se permettre de perdre le chiffre d'affaire)

A partir du moment où ton browser est capable d'exécuter de l'ES5 tu as accès à tout. Je t'invite à te renseigner sur Babel et sur qui a salarié les auteurs de cet outil. C'est une petite appli front pour qui 2 ou 3 % de users représentent environ la population française.

Sauf qu'un petit détail semble t'échapper : aucuns gros projets ne sont codés directement en JS.

Ah bon ? Paypal, Twitter ou Netflix c'est des petits projets ?

Google utilise Dart et Microsoft utilise TypeScript.

Dart est un échec, il n'est quasiment pas utilisé quand à TypeScript c'est un superset de JavaScript qui ne rajoute que les types. Dans un projet TypeScript, 90% de ce que tu utilises c'est du js vanilla. C'est ouf de pas comprendre ça, n'importe quel codejs vanilla est du TypeScript valide. Pour passer du js en ts il te suffit de changer l'extension du fichier.

leurs systèmes d'IA et de big data, ils ne sont pas codés en JS; à un moment il faut arrêter le délire.

By design on sait que Node est pas fait pour le calcul ça bloquerait l'event loop. Le but de node c'est d'avaler un grand nombre de requêtes en tirant parti le mieux possible des ressources disponibles. Ça a un temps de boot inégalé par rapport aux autres stacks donc ça scale mieux et c'est beaucoup moins cher à exploiter.

C'est pour ça que tous les gros qui le peuvent migrent sur node, parce que 95% de ton code source ne nécessite pas d'utiliser l'artillerie lourde. On a besoin que ça soit propre, pas cher, rapide, souple et que ça scale. Et quand tu as un besoin de calcul spécifique, là tu fais un micro-service dans un langage adapté.

[fredoche]

Tiens d'ailleurs les gens de Microsoft sont eux aussi tellement nuls et incapables de changer de paradigme qu'ils ont développé TypeScript par dessus pour avoir des classes, du typage strict et tout le tralala, bref, des trucs totalement inutiles réclamés uniquement par des ignorants.

Ah, et les gens de chez Google sont eux aussi tellement nuls qu'ils ont décidé de faire de TypeScript le langage officiel d'Angular dès la version 2 au lieu de JavaScript, renommant par la même occasion AngularJs en Angular.

Bref, pauvre monde rempli d'ignares qui ne comprennent rien à rien.

Il faut arrêter de croire qu'on est automatiquement un visionnaire parce qu'on ne fait rien comme tout le monde. Comme le disait Jerry Seinfeld, "Sometimes the road less traveled is less traveled for a reason".

T'as bien lu parce que je ne crois pas dire autre chose. Microsoft supporte des tas de langages, des tas d’environnement de développement différents, des tas d'outils différents. Les paradigmes ils les supportent tous. Ils supportent Javascript via Jscript depuis plus de 20 ans. Et ils t'apportent un outil te permettant d'utiliser tout ce que tu peux réclamer avec TypeScript.

t'as l'impression que Javascript est "less traveled", t'as des peaux de sauc devant les yeux là, tu parles de quoi ? de toi ? parce que tout le monde entier fait du JS.

On peut faire l'exercice, décrire une voiture en POO et en Procédural.. challenge ?

Tu sais la voiture je risque de la décrire dans un SGBD, et manipuler les données qui m'intéresse en fonction du contexte. Bah oui je fais du web, sorry.

1) C'est beaucoup trop lent. PHP est devenu fréquentable depuis sa version 5.4 sortie en 2012 et n'a plus grand-chose à envier à ses concurrents depuis la version 7 sortie fin 2016. JavaScript est encore loin d'être au niveau de PHP 5.4
2) Le langage ne doit pas évoluer mais se transformer. Il faut que son paradigme parte aux oubliettes. Quand il sera enfin à la hauteur de ses concurrents, il ne s'agira plus du tout du même langage et acquérir une expérience dans le JavaScript actuel est donc une perte de temps
3) JavaScript est exécuté côté client et le programmeur est donc dépendant de l'interpréteur. Lorsque qu'il sera devenu un langage réellement intéressant, il faudra au minimum 10 ans pour qu'on puisse l'utiliser tel sans craindre de se couper d'une masse importante d'utilisateurs (et quand tu travailles en entreprise, tu as beau n'avoir que 2 ou 3% d'utilisateurs avec des machines et/ou navigateurs obsolètes, souvent ce sont 2 ou 3% d'utilisateur dont on ne peut pas se permettre de perdre le chiffre d'affaire)

Le point 2), plus simplement, tu veux quel langage à la place ? le ... ?

Woué "en gros" à part le petit truc de rien du tout qui est le typage statique

Le gros avantage du JS est qu'il est universel…le seul standard... contrairement à toutes les autres solutions comme les applets Java, Flash/actionscript ou Silverlight qui restaient propriétaires et ne fonctionnaient pas sur toutes les platforms. La grande force de JS est aussi de permettre d'écrire rapidement de petits codes sans grande connaissance en programmation.

Etant donné que c'est u n des buts listés par Brendan Eich, but atteint. Tellement rare dans les projets informatiques, les buts atteints

The big debate inside Netscape therefore became “why two languages? why not just Java?” The answer was that two languages were required to serve the two mostly-disjoint audiences in the programming ziggurat who most deserved dedicated programming languages: the component authors, who wrote in C++ or (we hoped) Java; and the “scripters”, amateur or pro, who would write code directly embedded in HTML.

Donc oui JS est incontournable à l'heure actuelle où tout se passe sur le web. Sauf qu'un petit détail semble t'échapper : aucuns gros projets ne sont codés directement en JS. Google utilise Dart et Microsoft utilise TypeScript. JS n'est qu'ici le langage cible. Ta remarque est donc comparable à ne pas voir de problème à coder directement en langage machine. Si tu n'y vois pas de problèmes…

Pourquoi celui-ci est-il devenu un standard ? dans le contexte du web ? Parce c'est bien la réalité... mais pourquoi ? Ce n'est pas la politique commerciale de Microsoft qui a imposé JS, et pourtant windows est un quasi standard.
Ils avaient aussi leur concurrent: VBscript s'exécutait sur le navigateur IE, peut-eêtre même toujours. et les activeX de surcroit... dès 95-96 si je ne m'abuse. Javascript était un code propriétaire, propriété de Netscape.

Un chantier a beau être une "anticipation" de building de standing, je ne voudrais pas vivre sur un chantier.

Pour la programmation c'est pareil, je n'ai pas envie de m'acharner sur un langage qui peut-être dans 15 ans sera au niveau de la concurrence, je préfère passer directement à autre chose de réellement abouti, et à ce niveau TypeScript fait toujours bien le job, même s'il manque encore des choses comme de véritables tableaux associatifs par exemple.

C'est quoi pour toi un "véritable" tableau associatif ?
C'est une blague ou quoi ?

Franchement, je suis de plus en plus déçu par JS. L'ES6 est sympa mais les fameux avantages "langage universel front-back", "interfaçage performant" etc, c'est du total bullshit. Au moins, j'ai compris pourquoi JS est populaire : il est tellement pauvre que n'importe qui peut devenir "expert" en quelques mois.

Je crois que c'est bien loin d'être la réalité, les experts sont assez peu dans ce langage, surtout en regard du nombre de pratiquants. Et peut-être même que peu ont la prétention de l'être. Et pourtant j'en lis sur ce forum qui ont une sacré compréhension du langage.
Mais bon c'est assez drôle tout le monde se plaint de tous les cotés dégueulasses du langage, et en même temps c'est juste facile d'être un expert. Cherchez l'erreur...

Les gars faites-vous plaisir, parce que "expert" en quelques mois, bah non seulement ça paie, mais ça claque sur le CV.

[Invité]

Le paradigme principal de JavaScript c'est le fonctionnel et presque tous les frameworks js modernes utilisent à fond ce paradigme. Et c'est parfaitement adapté au front parce qu'en définitive un frontend c'est une grosse fonction qui prend en entrée les données qu'il tire sur le réseau pour les sortir dans sa page html.

Le one way binding, l'immutabilité, et Redux ça vient tout droit du fonctionnel ça n'a aucun rapport avec la POO.

N'importe quoi. Dire que JS est principalement fonctionnel c'est comme dire que C est principalement objet parce qu'il y a des struct. JS a les closures, map/reduce/filter et de l'immutable (et encore, pas en natif) ? Super. Et le currying, les m-expr, les types algébriques, les traits, les modules paramétriques, la terminal-recursion native, le pattern-matching, les fonctor/monad... ? Les vrais langages fonctionnels ont ce genre de fonctionnalités depuis 20 ans au moins.

By design on sait que Node est pas fait pour le calcul ça bloquerait l'event loop. Le but de node c'est d'avaler un grand nombre de requêtes en tirant parti le mieux possible des ressources disponibles. Ça a un temps de boot inégalé par rapport aux autres stacks donc ça scale mieux et c'est beaucoup moins cher à exploiter.
...

Oui merci, je suis au courant que node scale mieux que tout le monde mais là mon problème c'est juste d'interfacer du C++ sans y passer des heures, vu que l'article a l'air de dire que JS fait ça super bien...

[Invité]

Cette guerre de chapelle est un peu triste à lire, surtout que hormis quelques attaques ad hominem tout le monde à a peu près raison sur ce topic. A peu près car beaucoup de ce qui est dit peut être valide ou non selon le contexte, par exemple valider l'url dans le constructeur de la classe peut être un choix valide ou très nul selon l'architecture du système.


La POO c'est vraiment génial pour réaliser tout ce qui à des specs de base bien définies. Évidemment aucune application n'a des specs parfaites en amont (imaginez, le rêve !), mais il faut au moins que le cœur de l'application soit stable. C'est du au fait que la POO nécessite pas mal de code boilerplate, rien d'horrible surtout grâce aux IDE, mais ça fait que changer de stratégie en milieu de parcours est vraiment pénible.

Un exemple réel pour illustrer : je bosse pour une boite qui, en très gros, gère des documents légaux et permet à nos clients de s'assurer de la conformité de leurs documents. L'entreprise est historiquement centrée sur tout ce qui est législation environnementale et ce depuis 15 ans, avec aucun signe de changement, on peut donc vraisemblablement lors du design de la nouvelle appli se dire que c'est acquis. Or, 3-4 mois dans le développement, on nous annonce un chamboulement, conquête de nouveaux marchés etc. On passe donc d'une boite environnementale à une boite supportant tous types de documents, qui va implémenter de la gestion opérationnelle, et autres joyeusetés absolument pas au rendez vous initial. Il a fallu réécrire quasiment l'intégralité du code, notre système de base étant devenu un espèce de sous-système du nouveau logiciel.

On aurait très facilement pu ajouter les nouvelles briques (gestion opérationnelle, etc) sur l'existant, mais comme le coeur même du système est chamboulé il a fallu repenser toute l'architecture. Après coup, je suis certain que si on avait eu initialement un code en fonctionnel au lieu de orienté objet on aurait pu réutiliser beaucoup plus de composants.

On pourrait se dire que après cette "mésaventure", on soit passé sur du fonctionnel, un backend type NodeJS, mais non. A mon sens la très grande force de l'OO c'est sa lisibilité, sa facilité à maintenir et la simplicité à construire par dessus SI on comprend bien les concepts. Je ne veux pas parler pour tous les devs mais l'OO chez moi c'est quelque chose qui a fait clic un jour, la veille tu es dubitatif sur la nécessité d'une telle complexité, tu n'es jamais vraiment sur de comment interfacer tes classes ensembles, tu sais qu'il ne faut pas trop coupler ton code mais ça semble tellement pénible, ... et le lendemain tout est clair. Tout ce qui semblait complexe est soudainement clair, simple et compréhensible, c'est même beau. En lisant 2-3 classes d'un projet tu comprends tout de suite comment c'est architecturé, comment construire la suite, etc. A chaque fois que je termine un module, je suis super content car je sais que ce code est capable de survivre facilement à mon départ un jour et que mon successeur sera capable de prendre la suite facilement.


Pour Javascript, je pense que faire de la programmation basé sur les prototypes c'est vraiment passer à côté de la force du langage qui est le paradigme fonctionnel. Si la POO demande pas mal de boilerplate pour fonctionner, les prototypes en JS c'est de loin la taille au dessus. L'exemple en page 2 ou 3 avec Object.defineProperty c'est juste horrible, je n'ose même pas imaginer devoir décrire mes objets par ce biais. A mon avis JavaScript devrait pousser du côté fonctionnel, cette façon de coder compense le manque de typage niveau stabilité et rend les tests unitaires très simples.

Si JS est largement utilisé de nos jours c'est entre autres pour cette grande flexibilité. Le souci c'est que le langage "souffre" de sa simplicité de la même manière que PHP à souffert de la sienne. Comme c'est très simple de faire un truc qui marche dans ces langages, il y a beaucoup de novices, ce qui n'est en soit pas un mal sauf quand ces novices sont propulsés à des postes qui demandent des compétences plus grandes (coucou les SSII) ou pire qu'ils pensent avoir tout compris à l'informatique. On vient de virer un collègue qui après 5 ans d'expérience en front-end ne savait pas sélectionner une div ou utiliser les constructions de base du JS (genre map, filter, for..in), il faisait son taf en abusant des libs type lodash et de stack overflow, et forcément un jour ça se voit.


Bref peace les gars, vous savez tous que chaque langage est mieux adapté à certains cas que d'autres. Cette conversation pourrait être super intéressante comme comparaison de paradigmes basé sur des expériences vécues et tout le monde pourrait en sortir grandi, il suffit de mettre un peu d'eau dans son vin (ne faites pas ca en vrai, c'est dégeu )

[ijk-ref]

(…) TypeScript c'est un superset de JavaScript qui ne rajoute que les types. Dans un projet TypeScript, 90% de ce que tu utilises c'est du js vanilla. C'est ouf de pas comprendre ça, n'importe quel codejs vanilla est du TypeScript valide. Pour passer du js en ts il te suffit de changer l'extension du fichier.

Tout cela je le sais très bien.

Ne pas comprendre que l'insignifiant typage statique apporte de grandes améliorations que n'a pas JS seul. "C'est ouf de ne pas comprendre ça".

La laitue est une salade mais la salade n'est pas une laitue. Le JavaScript est du TypeScript mais le TypeScript n'est pas du JavaScript.

(…)Pourquoi celui-ci est-il devenu un standard ? dans le contexte du web ? Parce c'est bien la réalité... mais pourquoi ? Ce n'est pas la politique commerciale de Microsoft qui a imposé JS, et pourtant windows est un quasi standard.
Ils avaient aussi leur concurrent: VBscript s'exécutait sur le navigateur IE, peut-eêtre même toujours. et les activeX de surcroit... dès 95-96 si je ne m'abuse. Javascript était un code propriétaire, propriété de Netscape.

Fausse dissertation d'essayer de faire croire que VBScript ou activeX avait une chance de devenir un standard tout ça pour mettre en valeur VS.

Tu poses uniquement des questions rhétoriques comme pour conforter une croyance sur un topic religion JavaScript est l'élu. Il en est ainsi car il est le seul et unique bon et juste langage parfait, les autres sont des faux prophètes, amen. JavaScript était le 1er, tous l'ont cloné, tous ont essayé de proposer d'autres choses en vain… qu'on ait (quasiment) réussi à standardiser HTML/CSS/JS est comme tu le dis déjà assez remarquable. Pas besoin de lui prêter en plus des pouvoirs magiques.

Sinon Ajax (dont JS) c'est tellement bien que la plupart s'amusent à perdre leur temps à écrire une application de leur site

[alves1993]

Dart est un échec, il n'est quasiment pas utilisé quand à TypeScript c'est un superset de JavaScript qui ne rajoute que les types.

heuu sur quelle base tu t'appuies pour énoncer que Dart est un échec ?
Franchement tu es vraiment un fanboy de JavaScript.
Bien que Dart ne soit pas aussi populaire que TypeScript, ce n'est pas pour autant un échec.
Tu as l'habitude de lister les grosses plateformes qui ont été conçues avec Javascript et bien je vais aussi te lister des plateformes qui ont été conçus avec Dart ou qui ont utilisé Dart pour concevoir certaines parties de leurs plateformes :

• Google AdWords
• AdSense performance reports
• Security Monkey from Netflix
• Google Fiber

Si Google à décider de construit Google AdWords avec Dart ce n'est pas vraiment anodin, ils auraient pu choisir JavaScript, mais ils ont opté pour Dart. Sans oublier Flutter qui commencent à avoir le vent en poupe en ce moment.

Perso je n'ai aucun problème avec JavaScript (ES6 ), je l'utilise au boulot.

[fredoche]

Fausse dissertation d'essayer de faire croire que VBScript ou activeX avait une chance de devenir un standard tout ça pour mettre en valeur VS.

Tu poses uniquement des questions rhétoriques comme pour conforter une croyance sur un topic religion JavaScript est l'élu. Il en est ainsi car il est le seul et unique bon et juste langage parfait, les autres sont des faux prophètes, amen. JavaScript était le 1er, tous l'ont cloné, tous ont essayé de proposer d'autres choses en vain… qu'on ait (quasiment) réussi à standardiser HTML/CSS/JS est comme tu le dis déjà assez remarquable. Pas besoin de lui prêter en plus des pouvoirs magiques.

Sinon Ajax (dont JS) c'est tellement bien que la plupart s'amusent à perdre leur temps à écrire une application de leur site

Je m'en fiche que Javascript soit l'élu, je serais vulgaire que je te dirais que je m'en bat les cou...lles avec une pelle à gâteau.

Je te demande de t'interroger sur le pourquoi de ce standard de facto... Mais ça doit échapper à beaucoup que de regarder la réalité de façon honnête.

Pour ta gouverne, j'ai toujours fait des applis web depuis ma formation... bien avant Ajax.
Les web store et compagnie existent depuis plus de 20 ans. Dell a bâti son succès sur le modèle de la vente directe, et il y a 20 ans, on configurait sa machine en ligne avant la commande... en ligne.
Comment faire si ce n'est en utilisant des applications interactives en ligne qui interfaçaient des bases de données et des systèmes de supply-chain ? Tu crois qu'un acheteur envoyait les commandes par email ?

Mon 1er job dans ce métier, ça a été entre autres de faire le support technique pour la gestion du contenu des boutiques en ligne de HP Europe. Je faisais partie de l'équipe E-business. "E-business", l'eldorado des années 2000.

HP qui a l'époque pédalait dur pour adapter son modèle de production et de commercialisation afin de pouvoir concurrencer Dell qui lui taillait des croupières dans les parts de marché. IBM pédalait autant. Le système de boutique HP était une horreur.
Pour cette même boite j'ai repris le développement d'une application de gestion de workflows pour la localisation des contenus, un service essentiel à HP qui vendait des produits partout dans le monde, et se davit d'adapter et les produits et tous les contenus (manuels, pub, documentation, sites web...) aux marchés locaux. J'ai fait une application de devis en ligne pour ces mêmes services de loc.

J'ai fait pour l'e-business une application de recherche de contenus par référence qui interfaçait 4 systèmes différents : un système de doc produit style datasheet, un système de GED basé sur Documentum pour la mise à disposition de l'information produit, l'information pricing pour l’Europe, et toute l'info supply-chain lié aux sous-références. Un truc qui aurait certainement été perçu comme une horreur par tous ces tenants des langages nobles, j'interfaçais ces différents services (applications néanmoins) avec un petit script JS qui générait 4 frames dans le document du navigateur et sourçait ces frames avec en paramètre la référence produit saisie par l'utilisateur. Un bricolage quoi... mais qui eut un grand succès.

Quand j'ai été embauché par ma pme il y a 15 ans, elle se définissait comme ASP : Application Service Provider. Ensuite on a parlé de SaaS : Software as a Service. Je fais des applis de GED depuis 15 ans.

Des applications qui utilisent moult langages, systèmes et services ça fait des décennies qu'on en fait. Que j'en fais en tout cas.
Le monde des applications web est par essence hétérogène. Tu es obligé d'utiliser plein de briques, et Javascript ou ECMAScript n'est jamais que l'une de ces briques. Il y avait pas grand monde à s’embarrasser avec des paradigmes de conceptualisation qui concernent essentiellement des langages intégrés.
Les problématiques de performance, de testing, de charge, de typage si ça vous chante, on se les cogne depuis plus de 20 ans, et avec ce que l'on nous donne pour le faire.
Quand j'ai commencé mes premières applis tournaient sur des netserver E40, du pentium pro avec 128 Mo de ram max. Les navigateurs tournaient sur des machines avec des pentium cadencés max à 200 MHz. Maintenant on a des processeurs octocore cadencés à plusieurs Ghz et plusieurs Gos de RAM dans un smartphone qui tient dans la main.

Vos histoires de performance c'est du blabla pour couper les cheveux en 4. Dans la vie réelle, les choix sont toujours des compromis

Et j'ai pas vu beaucoup de monde à l'époque faire des CGI ou des DLL C++ pour le backoffice. PERL, PHP, ASP, Coldfusion ... ça oui

Le Java oui... bah les applets mais coté serveur Tomcat démarrait et n'était jamais recommandé en production. Un truc comme Jboss ou Websphere coutait 200 000 balles, 30000 € au moins. Peut-être toujours ? PHP ou ASP à coté: rien ou la licence windows pour faire la même chose en moins buggué.

A l'époque je côtoyais déjà plein de programmeurs classiques, de ces fameux langages à paradigme. Ils me regardaient bosser avec des yeux étranges, pas d'IDE, pas de trace, pas de débogage sinon du http 500.
J'ai l'impression de lire les mêmes, qui pleurent de la médiocrité de ce qu'on leur offre pour bosser, alors que aujourd'hui c'est juste Byzance avec la qualité des outils de débogage qu'intègre les navigateurs.
Le job reste le même

Franchement le principe de réalité vous connaissez ou bien vous vivez dans un monde parallèle ?
Moi j'ai plutôt l'impression qu'on a beaucoup de contributeurs ici qui sont les tenants d'un et d'un seul langage, et qui sont de plus en plus confrontés au fait que le monde informatique a basculé en réseau il y a plus de 20 ans, et que l'interface utilisateur privilégiée sur ce réseau, c'est le navigateur web. Et que la demande professionnelle répond à ça.

Et qu'il faut faire avec

[Invité]

Je m'en fiche que Javascript soit l'élu

Oui, c'est pour ça que tu rédiges des posts de 3 km sur JS.

Je te demande de t'interroger sur le pourquoi de ce standard de facto... Mais ça doit échapper à beaucoup que de regarder la réalité de façon honnête.

La réalité c'est que JS a profité de l'expansion du web et qu'il est relativement simple. N'importe quel ado qui fait voler un papillon dans une page web peut se prétendre" programmeur" donc oui JS est largement dominant chez les "programmeurs".

aujourd'hui c'est juste Byzance avec la qualité des outils de débogage qu'intègre les navigateurs.

Donc, on est bien d'accord que JS a 15 ans de retard. Aujourd'hui on ne corrige plus les bugs à la main au runtime. Dans les vrais langages modernes, on a des tests automatiques, des compilateurs, des analyseurs statiques, voire même une grammaire qui empêche tout simplement d'écrire du code bugé (types algébriques, dependent-types...).

Moi j'ai plutôt l'impression qu'on a beaucoup de contributeurs ici qui sont les tenants d'un et d'un seul langage

C'est clair. Alors qu'ils pourraient tous utiliser JS.

[Pyramidev]

JS a les closures, map/reduce/filter et de l'immutable (et encore, pas en natif) ? Super. Et le currying, les m-expr, les types algébriques, les traits, les modules paramétriques, la terminal-recursion native, le pattern-matching, les fonctor/monad... ? Les vrais langages fonctionnels ont ce genre de fonctionnalités depuis 20 ans au moins.

Qu'appelles-tu m-expr ? Les M-expression ?
Pour les autres points, parmi les langages qui ont 20 ans ou plus, existe-t-il un autre langage que Haskell qui répond à tous ces critères ?

Aujourd'hui, il n'existe pas une définition officielle qui sépare les langages fonctionnels des autres. Cela pose un gros problème car, sur beaucoup de pages Wikipédia dont Comparison of multi-paradigm programming languages, dès qu'un langage supporte les lambdas, on considère abusivement qu'il supporte le paradigme fonctionnel, ce qui empêche de distinguer les vrais langages fonctionnels des autres.

Mais, d'un autre côté, la définition d'un langage fonctionnel ne devrait pas être trop stricte non plus.

La page Wikipédia Functional programming est plus sérieuse que Comparison of multi-paradigm programming languages. Elle met en avant les points suivants : fonctions de première classe, fonctions d'ordre supérieur, curryfication, fonctions pures, transparence référentielle et récursion (avec l'optimisation de la tail recursion). L'évaluation peut être stricte ou paresseuse. Le typage peut être statique ou dynamique.

[Invité]

Qu'appelles-tu m-expr ? Les M-expression ?

Oui, c'est bien à ça que je pensais.

Pour les autres points, parmi les langages qui ont 20 ans ou plus, existe-t-il un autre langage que Haskell qui répond à tous ces critères ?

Les langages fonctionnels ont tous au moins quelques unes de ces fonctionnalités mais je ne crois pas qu'un langage les ait toutes. Par exemple, les m-expr c'est plus en lisp, les modules paramétriques en ocaml... Par contre, la tail-recursion, le pattern-matching, les functors, etc c'est assez commun.

Désolé si mon propos était un peu confus. Je suis un peu énervé car je viens de passer des heures à tester les "merveilleuses fonctionnalités d'interfaçage de JS" pour me rendre compte qu'en fait c'est du pipeau complet.

Aujourd'hui, il n'existe pas une définition officielle qui sépare les langages fonctionnels des autres. Cela pose un gros problème car, sur beaucoup de pages Wikipédia dont Comparison of multi-paradigm programming languages, dès qu'un langage supporte les lambdas, on considère abusivement qu'il supporte le paradigme fonctionnel, ce qui empêche de distinguer les vrais langages fonctionnels des autres.
...

Complètement d'accord.

[fredoche]

Au fait Simondecoline, tu sais faire voler un papillon sur une page web ?

pour vous les gars : https://hackernoon.com/do-not-be-thi...r-480072581f1b
Levez le doigt ceux qui se reconnaissent

Tout frais de ce matin proposée par mon 'appli' medium

quelques passages tellement vrais :

The hater

The biggest problem is: there are people that live complaining about programming languages.

some developers just don't want to see programming languages as business tools, instead, they see as a weapon to harm other programmers.

Being this kind of developer can harm a whole workplace, because of their negativity. Sorry, but it isn’t because someone hates JavaScript that the whole web is going to give up on it. So, instead of complaining, let’s deal with it and start studying.

[blbird]

Oui, c'est pour ça que tu rédiges des posts de 3 km sur JS.

Lui au moins, il sait de quoi il parle.

La réalité c'est que JS a profité de l'expansion du web et qu'il est relativement simple. N'importe quel ado qui fait voler un papillon dans une page web peut se prétendre" programmeur" donc oui JS est largement dominant chez les "programmeurs".

Si tu penses que le JS est simple, c'est que ce n'est pas le JS qui est simple, mais ta connaissance et/ou ta compréhension du JS.

Donc, on est bien d'accord que JS a 15 ans de retard. Aujourd'hui on ne corrige plus les bugs à la main au runtime. Dans les vrais langages modernes, on a des tests automatiques, des compilateurs, des analyseurs statiques, voire même une grammaire qui empêche tout simplement d'écrire du code bugé (types algébriques, dependent-types...).

Tu te rend compte des énormités que tu écris? JS est langage de SCRIPT. Et de fait, il ne peut pas avoir de compilateur, comme n'importe quel autre langage de script. Et comme tu as l'air de le sous-entendre, une compilation réussie ne fait pas un programme sans bug, très loin de là.
JS n'empêche pas d'avoir des analyseurs syntaxiques, ni d'avoir des tests automatiques. Comme dans tous les autres langages, il existe même des librairies JS dédiés aux tests automatiques et à l'intégration (Mocha, Jasmine, Jest, Unexpected, Chai, ...). Dingue non?

Bref, si tu pouvais arrêter ta croisade contre un langage que tu n'aimes pas, envers lequel tu ne sembles pas t'intéresser, mais surtout que tu sembles haïr suffisament pour raconter n'importe quoi à son sujet à longueur de posts. Tu te décridibilises juste tout seul comme un grand.

Being this kind of developer can harm a whole workplace, because of their negativity. Sorry, but it isn’t because someone hates JavaScript that the whole web is going to give up on it. So, instead of complaining, let’s deal with it and start studying.

Que dire de plus.

[Invité]

Oui, oui, bravo. JS est formidable, un compilateur n'a rien à voir avec un interpréteur, les types algébriques et les dependent-types n'existent pas et quiconque se plaint des JS fanboys est un crétin qui ne comprend pas JS.

Et sinon, vous ne voulez pas répondre à ce que raconte l'article sur comment interfacer facilement du C++ en JS sans tomber dans les problèmes que j'ai évoqués ?