Navigation

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

  1. #61
    Expert confirmé
    Citation Envoyé par StringBuilder Voir le message
    A mon sens, le débat est le même ici (quoi que c'est pire, car on tente une espèce de fuite en arrière)
    Je ne pense pas que ce soit une fuite en arrière. La POO à la java/c++ est issue de recherche des années 70/80. Les langages fonctionnels modernes comme elm/ocaml/haskell sont issus de travaux des années 90 et plus.

    Citation Envoyé par StringBuilder Voir le message
    Le Fortran est mort principalement parce qu'il a arrêté d'évoluer, et que "politiquement" il a été décidé qu'il fallait le mettre au placard.
    Fortran est encore souvent utilisé dans certains domaines et il continue d'évoluer (POO, concurrence, etc). La dernière norme date de 2018.

    Citation Envoyé par StringBuilder Voir le message
    Microsoft a inventé le Basic à peu près à la même époque, et pourtant VB.NET est toujours très utilisé.
    Basic a été inventé par 2 profs du Dartmouth College et non par Microsoft.

    Citation Envoyé par StringBuilder Voir le message
    Et quand on y regarde bien, C++ 11 n'a plus rien à voir sur bien des points avec la première mouture, et un programme en C des années 80 ne compilera pas sur un gcc flambant neuf (alors que le *.exe généré à l'époque peut parfaitement encore tourner sous certaines conditions).
    Justement si. La POO de C++ n'a quasiment pas évolué depuis les années 90. Quant aux nouvelles fonctionnalités, il y a justement compatibilité ascendante. Un code en C++98 a de grande chance de compiler sur un GCC de 2020.

    Je ne dis pas tout ça pour faire une leçon d'histoire des langages mais pour illustrer qu'on pense tous connaitre des faits alors que ce sont souvent des légendes ou des impressions personnelles. Et c'est ce que relêve l'article par rapport à la POO et au fonctionnel, et donc que ça vaudrait peut-être le coup d'essayer vraiment le fonctionnel.

  2. #62
    Expert éminent sénior
    Citation Envoyé par StringBuilder Voir le message
    Je ne parlais pas de ce débat, mais celui de décider d'abandonner un langage (et toute une méthodologie) au profit d'un autre sous prétexte que pour faire ça ou ça, parfois c'est plus adapté.

    Si tu as des équipes de 200 personnes, tu peux te permettre d'en former 10, 15, 20% sur une dizaine de langages/technos différentes, puis "faire tes courses" en fonction d'un besoin précis (à condition que toi-même ait suffisamment de recul sur chaque langage/techno pour faire un choix qui tienne la route).
    Mais la réalité est généralement autre, les équipes sont souvent bien plus réduites, et le chef de projet est mono ou bi-techno maxi. Donc habitude ou non, il n'a pas vraiment d'autre choix que d'utiliser les outils qu'il a à disposition et que son équipe sait utiliser.
    Il me semble pourtant que les projets web sont assez courants ... Je parle de JavaScript là !
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  3. #63
    Membre averti
    Il y a des discussions qui font sourire quand on regarde dans le rétroviseur.

    En licence info, on n'avait toujours pas accès à l'internet, à l'époque, à moins d'avoir une connaissance qui était au moins parmi les thésards. C'était le grand développement du minitel (mais là, je commence à m'égarer). On faisait du Pascal, et la POO n'en était qu'au début de son développement (pour ceux qui avaient accès à l'internet).
    Avec le binôme, ou avec l'équipe projet (on avait 1 long projet sur un semestre), on avait commencé à exploiter certaines particularité de la portée des données en Pascal, en particulier quand on utilise différents fichiers. Ce qui revient à dire que l'on s'était organisé comme si (ce qui s'appellerait plus tard) les classes étaient chacune dans son fichier. Ainsi, on contrôlait bien l'interface. Bref, on avait commencer à s'organiser façon (une vision de la) POO, avec un langage qui n'en parlait à l'époque pas.
    À la fin de la licence, je (heu, "on") pestais car il manquait vraiment un truc au Pascal : pouvoir passer une fonction/procédure en paramètre, "voir" l'assigner comme une variable. (re-)Bref, on commençait à avoir une approche utilisant du fonctionnel.

    Plus tard, le vocabulaire est venu : POO, classes, fonctionnel, etc. Les guerres de religion afférentes aussi : j'ai eu un méchant échange avec un responsable, en DEA, qui me disait que "la POO, c'est bon, tout le monde c'est ce que c'est, c'est pas la peine de définir les contours". Ben justement, c'est comme en modélisation : on commence par définir les contours et le vocabulaire, parce que des avis, il y en a une pelletée.

    Conclusion du laïus : certaines notions sur lesquelles on peut poser des mots aujourd'hui, existent depuis bien longtemps, et beaucoup y sont venus. Ces notions sont utiles quelque part ou par moments ? => On finit par les retrouver dans les langages, même ceux qui n'y faisaient pas référence au départ, parce qu'on s'aperçoit que finalement c'est bien utile.

    Alors inutile de taper sur le côté "pur" de certaines approches, comme objet (avec Smalltalk) ou fonctionnel (avec Haskell), car elles servent de champs d'investigations.

    Elles peuvent même servir de manière très pratique.
    Vers 1994, parler de POO était un peu "dépassé" et "tout le monde savait" que Java allait tomber à l'eau comme toutes les modes (dixit les directeurs de recherche du cnrs que je croisais). Il ne fallait surtout pas dire que l'on faisait de l'objet "poussé", et encore moins du Smalltalk. Au boulot, j'ai été le seul à faire planter une appli très utile sur les serveurs Sun : je me suis retrouvé sur la console Smalltalk. Mais le vendeur n'en avait jamais parlé à quiconque… Smalltalk a été à l'époque le seul environnement qui permettait de proposer à l'utilisateur, sur le Sun, un look & feel unix / windows / mac à la demande, en 3 mots à la console. C'était aussi l'époque d'apparition de NeXTSTEP, coulé par la concurrence.
    Côté fonctionnel, Microsoft est un contributeur pour Haskell. Première conséquence : l'existence de F#, une mise en œuvre dans l'environnement Microsoft. C'est un premier pas, car ce qui est jugé intéressant ou utile, va se retrouver dans les autres langages de Microsoft. Donc pas la peine de taper sur Haskell ni sur F#.

    Il y a des manières de penser et de s'organiser qui sont utiles, mais qui ont leurs champs d'applications privilégiés. Les noms viennent après, les modes aussi. Mais si c'est utile, cela va se répandre.

    Bon, tout cela est bien joli, mais l'entreprise va généralement chercher un codeur pas cher pour faire du bénéf' en le plaçant. À partir de la, les belles idées…

  4. #64
    Expert confirmé
    Citation Envoyé par Stellar7 Voir le message
    Conclusion du laïus : certaines notions sur lesquelles on peut poser des mots aujourd'hui, existent depuis bien longtemps, et beaucoup y sont venus. Ces notions sont utiles quelque part ou par moments ? => On finit par les retrouver dans les langages, même ceux qui n'y faisaient pas référence au départ, parce qu'on s'aperçoit que finalement c'est bien utile.
    Je suis assez d'accord. Par contre, les "mots" du fonctionnel viennent du lambda-calcul des années 30 donc on peut dire qu'ils ont toujours exister.

    Citation Envoyé par Stellar7 Voir le message
    Côté fonctionnel, Microsoft est un contributeur pour Haskell. Première conséquence : l'existence de F#, une mise en œuvre dans l'environnement Microsoft. C'est un premier pas, car ce qui est jugé intéressant ou utile, va se retrouver dans les autres langages de Microsoft. Donc pas la peine de taper sur Haskell ni sur F#.
    F# c'est la version Microsoft du langage ocaml, pas haskell. Par contre, c'est vrai que certains gros contributeurs de haskell étaient des chercheurs employés par Microsoft. C'est même un peu étonnant car Microsoft n'a pas vraiment fait de promotion autour de ces 2 langages.

  5. #65
    Expert éminent
    Citation Envoyé par Marco46 Voir le message
    Il me semble pourtant que les projets web sont assez courants ... Je parle de JavaScript là !
    Bon, je commence à raccrocher les wagons...

    J'avais pas fait attention à la ligne en tout petit mentionnant "d'après mon expérience avec Typescript".

    Si je comprends bien, on parle donc en effet, en Typescript (donc JavaScript en effet) de savoir si on doit travailler avec des classes d'objet, ou avec du fonctionnel.

    Et là d'un coup, au risque de troller un peu, je comprends bien mieux...

    Il ne s'agit pas de jeter à la poubelle les langages objets que sont Java ou C# et les remplacer par F# ou LISP, mais de changer la façon de coder en JavaScript.

    Si c'est ça, ok, je comprends mieux (ouf ! me direz-vous).

    JavaScript est à la base un langage pour ainsi dire non typé, et son support du modèle objet plus que limité.
    Il a évolué ces dernières années avec TypeScript, mais ça reste à la fois :
    - un langage peu typé
    - très limité en terme de POO
    => Bref, tout sauf un langage réellement orienté objet.

    Enfin, TypeScript est utilisé plutôt en frontend, donc gère la couche présentation, et très partiellement la couche métier.
    => La couche présentation n'a pour ainsi dire pas besoin d'objet (on se contente de contrôles utilisateurs et des objets déjà présents dans Angular par exemple, sans devoir en créer de nouveaux ni de les enrichir)
    => La couche métier côté front-end va se contenter de faire quelques contrôles et calculs sans pour autant implémenter les règles métiers (trop complexes et trop proches des données pour être embarquée côté utilisateur). A nouveau, pour faire quelques calculs simples sur un nombre limité de données, la POO ne sert rigoureusement à rien.

    Par conséquent, ne pas faire de POO en JS, pour faire autre chose, à la limite n'importe quoi d'autre se tient, puisque de toute façon JS n'est pas fait à la base pour faire de la POO.

    Voilà, désolé si certains prendront ce message pour un troll. C'est pas tout à fait vrai ni tout à fait faux cependant
    On ne jouit bien que de ce qu’on partage.

  6. #66
    Expert éminent
    Citation Envoyé par StringBuilder Voir le message
    très limité en terme de POO [...] JS n'est pas fait à la base pour faire de la POO.
    tu te trompes - pour simplifier (*), il a 2 programmations objet : la programmation objet (pure (Python, Smalltalk, ...) et les autres (C++, Java, ...)) et la programmation orientée prototype (Self, JavaScript) (<- lien wiki en français)


    * : Plus de détails sur le wiki en anglais, "Object-oriented programming"

  7. #67
    Expert confirmé
    Citation Envoyé par StringBuilder Voir le message
    Si je comprends bien, on parle donc en effet, en Typescript (donc JavaScript en effet) de savoir si on doit travailler avec des classes d'objet, ou avec du fonctionnel.
    ...
    Il ne s'agit pas de jeter à la poubelle les langages objets que sont Java ou C# et les remplacer par F# ou LISP, mais de changer la façon de coder en JavaScript.
    Pas uniquement. L'article parle aussi de elm, qui est un langage inspiré de haskell, pour le front.

    Citation Envoyé par StringBuilder Voir le message
    Par conséquent, ne pas faire de POO en JS, pour faire autre chose, à la limite n'importe quoi d'autre se tient, puisque de toute façon JS n'est pas fait à la base pour faire de la POO.
    Je ne suis pas expert en JS mais je pense que ta vision de JS et du front n'est pas du tout à jour. La POO JS est différente de la POO java/c++ mais largement aussi puissante. Quant à la complexité des applications front, je pense que ça a bien augmenté depuis quelques années, avec les SPA PWA et tous les frameworks qui vont avec (ou pas d'ailleurs).

  8. #68
    Expert éminent sénior
    Citation Envoyé par StringBuilder Voir le message

    Il ne s'agit pas de jeter à la poubelle les langages objets que sont Java ou C# et les remplacer par F# ou LISP, mais de changer la façon de coder en JavaScript.
    Ben si justement. Sais-tu que le plus clair du Fortune 500 a migré de stacks J2EE vers node ces dernières années ? Twitter, paypal, netflix, Uber, LinkedIn, Walmart, Groupon, etc ... etc ... La liste est longue !

    Et même pour les clients lourds il y a de plus en plus d'applications complexes, par exemple Visual Studio Code.

    Citation Envoyé par StringBuilder Voir le message

    Il a évolué ces dernières années avec TypeScript
    TypeScript est une excellente extension mais c'est surtout le langage vanilla lui-même qui a énormément évolué en 5 ans.

    Citation Envoyé par StringBuilder Voir le message

    Enfin, TypeScript est utilisé plutôt en frontend, donc gère la couche présentation, et très partiellement la couche métier.
    Je n'en rajouterais pas sur la POO les autres ont répondu mais tu sembles totalement ignorer que JavaScript est énormément utilisé côté backend et sur des SI de très grande complexité. Après Node n'est pas conçu pour effectuer des traitements CPU lourds mais pour traiter un très grand nombre de requêtes, c'est aussi de la complexité dans un contexte asynchrone et stateless tel que le web et JS se comporte à merveille dans le contexte du web, bien mieux que Java y compris côté backend.

    Bref pour traiter des I/O à la pelle, et le fonctionnel pour ça c'est bien plus efficace que la POO à classe traditionnelle.

    Ce n'est pas un hasard si le FaaS (Function as a Service) c'est autant développé ces dernières années. Ça répond à un besoin concret.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  9. #69
    Membre expert
    Bonjour.

    Citation Envoyé par SimonDecoline Voir le message
    Justement : l'article essaie de voir s'il ne vaudrait pas mieux faire du fonctionnel plutôt que de faire tout le temps de l'objet.
    Citation Envoyé par Patrick Ruiz Voir le message

    Dans une publication parue il y a peu, Andy Peterson de l'entreprise Atomic Object explique pourquoi il ne fait pas un usage systématique des classes et s’appuie autant que possible sur une approche fonctionnelle.
    Je vois 2 choses ici :

    - pas un usage systématique des classes
    - approche fonctionnelle

    C'est clair ici, il fait de l'objet, même si ce n'est pas systématique. Pour le fonctionnel, il parle d'approche, mais ajouté à de l'objet ou pas... J'avoue, j'extrapole ici, mais sans exemple de la part de cet auteur, je peux extrapoler. JackIsJack résume le tout selon moi :

    Citation Envoyé par JackIsJack Voir le message
    Un exemple vaudrait mieux qu'un long discours.

    Désolé l'argument des balles de jonglages ne me séduit pas : du concret !
    J'attends aussi du concret.

    Citation Envoyé par Patrick Ruiz Voir le message

    on note que de plus en plus de livres orientés programmation fonctionnelle paraissent
    Donc c'est l'avenir... Peut-être, qui sait. A l'heure actuelle, le fonctionnel répond à des problématiques, mais pas à toutes.

    Citation Envoyé par SimonDecoline Voir le message

    Que vient faire le javascript ici ? Il apparait dans quelques commentaires mais il n'est mentionné nul part dans l'article dvp. L'article parle plutôt de elm ou des fonctionnalités de fonctionnel qui apparaissent dans beaucoup de langages.
    Que vient faire javascript, je me le demande ;

    Citation Envoyé par Patrick Ruiz Voir le message

    Basé sur son expérience en entreprise avec Typescript
    Typescript, javascript, c'est vrai aucun lien...

    Citation Envoyé par Patrick Ruiz Voir le message

    En fait, il s’agit d’une posture globale de l’équipe de développeurs de l’entreprise spécialisée en développement web
    C'est vrai, ils sont spécialisés en développement web, mais aucun lien avec javascript...

    Je ne vais pas répondre à cette question, je suis blasé là.

    Sinon, vous en pensez quoi de l'évolution javascript -> typescript -> fonctionnel, vous pensez que cela va résoudre le problème de la gestion des états des objets ?

  10. #70
    Membre expert
    Bonjour.

    Citation Envoyé par StringBuilder Voir le message
    ...
    J'aime beaucoup toutes tes questions qui font réfléchir. Et aussi l'armada de réponses qui ne se remettra jamais en question, et qui a réponse à tout.

  11. #71
    Membre expert
    Bonjour.

    Citation Envoyé par Marco46 Voir le message
    JavaScript est typé. Il n'a pas de typage statique ni la possibilité de définir ses propres types complexes mais il est typé.
    Oui. Nous ne serons jamais d'accord.

    Un langage typé qui peut ajouter des choux avec des carottes, ne sera jamais typé dans ma compréhension des choses de l'informatique.

    Et quand tu as un bug, parce que tu as ajouté un chou et une carotte, dans 100000 lignes de code, oui tu t'arraches les cheveux. Un compilo C/C++ t'aurait prévenu...


    Citation Envoyé par Marco46 Voir le message

    Quand à l'asynchrone c'est le contexte par défaut que tu sois en browser ou en backend, le web est asynchrone et stateless. Et JS est extrêmement bien équipé pour gérer l'asynchrone du coup je ne comprends pas.
    JS gère-t-il aussi l'asynchronicité de tes variables globales, ou l'état de tes objets membre ? Ils sont forts chez javascript. Je comprends le problème de l'auteur, et je ne dis pas que JS est bien équipé.

    Citation Envoyé par Marco46 Voir le message

    Les bugs et la maintenabilité d'un code n'ont pas de rapport avec le langage (ya plus de liens avec le paradigme du langage en revanche). Ça dépend d'abord et avant tout de l'auteur du code source.
    Cela mérite un débat.

    Citation Envoyé par Marco46 Voir le message

    Il y a une multitude d'outils pour écrire des tests de tout type donc pas de raison de s'arracher les cheveux comme tu dis.
    Outils payants ou gratuits, c'est important de savoir pour des langages tout public ?

    Citation Envoyé par Marco46 Voir le message

    La situation que tu décris n'existe plus depuis pratiquement 10 ans. Node a tout changé.
    Oui Node a tout changé. Les développeurs Front-End font des doubles appels à la même ressource statique, et ils ne savent même pas pourquoi. Ils comprennent rien à tous ces frameworks, tellement c'est simple et tout public.

    Citation Envoyé par Marco46 Voir le message

    Il faut simplement apprendre le langage et les outils les plus courants. Rien de surnaturel là dedans Cela dit l'évolution de son écosystème a été tellement rapide ces dernières années qu'il est possible de l'avoir manqué complètement si on est habitué aux rythmes des langages historiques (Java, C# et pire C++).
    "et pire C++"... C'est-à-dire ?

  12. #72
    Membre expert
    Bonjour.

    Citation Envoyé par Marco46 Voir le message
    mais tu sembles totalement ignorer que JavaScript est énormément utilisé côté backend et sur des SI de très grande complexité.
    Vous croyez vraiment à ce que vous racontez ? Quelques sont ces statistiques sur ces fameux SI d'une très grande complexité...

    Les SI utilisent ce truc par phénomène de mode, par lobbying et par facilité, pas par efficacité.

    Cela me rappelle des discussions en 2003 avec les soit-disant puristes Linux. Ils ont d'ailleurs disparu au fur et à mesure que les subventions Google ont disparu.

    Aujourd'hui nous avons les puristes javascript, enfin les vendeurs de Framework javascript.

    Bientôt, ils vont vous faire croire que l'on peut faire des jeux vidéos en node.js...

    L'histoire se répète.

  13. #73
    Expert éminent sénior
    Citation Envoyé par moldavi Voir le message
    Les SI utilisent ce truc par phénomène de mode, par lobbying et par facilité, pas par efficacité.
    Personnellement, j'utilise JS en backend parce que cela m'évite de passer constamment du JS au PHP, et que cela me permet de transférer facilement du code du front-end au back-end, et inversement. De plus, JS est pas mal pour manipuler du DOM.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  14. #74
    Expert éminent
    J'ai quand même une question par rapport à ce que vous appelez le "backend".

    Qu'est-ce donc ?

    Chez moi, le backend, c'est ce qui est exécuté côté serveur. A l'heure des applications web riches et des clients légers, la partie backend se résume, pour grande partie, à de la manipulation de données (CRUD en base, quelques calculs et vérification ce règles, point).
    C'est d'autant plus vrai que la grande mode du backend c'est d'être stateless (monte mieux la charge, notamment permet de faire de l'asynchrone sans devoir synchroniser le contexte).

    Je n'ai pas trouvé avec TypeScript comment se connecter à une base de données, écrire dans un fichier, etc. Du coup je m'interroge clairement sur l'intérêt de coder un backend en TS :
    - le code exécuté en TS sur le serveur aurait à priori parfaitement pu être exécuté sur le client
    - le code TS exécuté sur le serveur va reposer sur des "API" au même titre que le code exécuté sur le client

    Si de toute façon je dois reposer sur des API en PHP, C# ou Java, je ne vois pas pourquoi mettre en place deux programmes, avec un échange REST au milieu, pas plus que je ne vois comment on peut se vanter d'avoir de meilleures performances avec une telle architecture !

    J'ai raté un truc je pense...
    On ne jouit bien que de ce qu’on partage.

  15. #75
    Expert éminent sénior
    Citation Envoyé par StringBuilder Voir le message
    Chez moi, le backend, c'est ce qui est exécuté côté serveur. A l'heure des applications web riches et des clients légers, la partie backend se résume, pour grande partie, à de la manipulation de données (CRUD en base, quelques calculs et vérification ce règles, point).
    C'est d'autant plus vrai que la grande mode du backend c'est d'être stateless (monte mieux la charge, notamment permet de faire de l'asynchrone sans devoir synchroniser le contexte).
    Cela dépend de ce que tu développes.

    Si c'est un site bête et méchant, tu vas utiliser p-e un CMS bête et méchant.
    Si c'est une application, tu peux te retrouver avec beaucoup de choses en backend avec éventuellement un serveur socket.io.

    Citation Envoyé par StringBuilder Voir le message
    Je n'ai pas trouvé avec TypeScript comment se connecter à une base de données, écrire dans un fichier, etc.
    T'as pas bien cherché alors :
    https://typescript.developpez.com/ac...pt-par-Yahiko/

    Citation Envoyé par StringBuilder Voir le message
    - le code exécuté en TS sur le serveur aurait à priori parfaitement pu être exécuté sur le client
    Sauf dans les cas où tu veux protéger ta propriété intellectuelle, ou si tu veux que l'utilisateur n'interfère pas avec les calculs, ou si c'est des calculs intensif et/ou que tu veux conserver un cache des choses déjà calculée pour tous les clients.

    Citation Envoyé par StringBuilder Voir le message
    pas plus que je ne vois comment on peut se vanter d'avoir de meilleures performances avec une telle architecture !
    Ce n'est pas uniquement une question de performances d'exécution, mais tout simplement de vitesse/confort de développement.

    Pour la vitesse d'exécution, tu as tellement de choses qui viennent avant le langage, et au pire, tu peux toujours te démerder pour réimplémenter les goulots d'étranglements.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  16. #76
    Expert éminent
    Citation Envoyé par Neckara Voir le message
    Cela dépend de ce que tu développes.

    Si c'est un site bête et méchant, tu vas utiliser p-e un CMS bête et méchant.
    Si c'est une application, tu peux te retrouver avec beaucoup de choses en backend avec éventuellement un serveur socket.io.
    Là tu me parles d'outils, pas de ce que fait le site si comment l'implémenter.

    Citation Envoyé par Neckara Voir le message
    Je dois vraiment avoir de la merde dans les yeux...
    Tout ce que fait ton exemple, c'est de lire un fichier index.html et renvoyer le résultat à l'appelant.
    Je ne vois pas d'accès à des données...

    Citation Envoyé par Neckara Voir le message

    Sauf dans les cas où tu veux protéger ta propriété intellectuelle,
    Pipo, plage, ski, toussa...

    Citation Envoyé par Neckara Voir le message

    ou si tu veux que l'utilisateur n'interfère pas avec les calculs, ou si c'est des calculs intensif et/ou que tu veux conserver un cache des choses déjà calculée pour tous les clients.
    Intèrférer : ok pourun site bancaire public. Pour une application d'entreprise, OSEF. Et pour choisir de surcharger un serveur de calculs pour pouvoir garder les résultats en cache, ou plutôt déporter les calculs au client... perso mon choix est vite fait !

    Citation Envoyé par Neckara Voir le message

    Ce n'est pas uniquement une question de performances d'exécution, mais tout simplement de vitesse/confort de développement.
    Belle façon de voir les choses. La RATP va acheter des Ferrari, et les passagers s'entasserons dans l'emplacement de la roue de secours, car les conducteurs préfèrent conduire une Ferrari plutôt que leurs bus pourraves.
    Le confort du développeur doit venir dans les dernières positions quand il s'agit de choisir une techno, clairement pas l'inverse !

    Citation Envoyé par Neckara Voir le message

    Pour la vitesse d'exécution, tu as tellement de choses qui viennent avant le langage, et au pire, tu peux toujours te démerder pour réimplémenter les goulots d'étranglements.
    Hmmmm...
    Temps d'accès en mémoire, on est de l'ordre de la µs.
    Temps d'accès disque, on est de l'ordre de la ms.
    Temps d'accès REST (serveur socket + encapsulation HTTP + ...) on est de l'ordre du centième ou dixième de seconde à condition d'être sur un réseau local fibré.

    Bref, le goulot d'étranglement, il commence déjà par choisir la techno qui correspond au besoin : si j'ai pas besoin de faire du REST entre mon backend et ma couche d'accès aux données, je fait pas de REST en me disant que je verrai plus tard si ça rame !
    On ne jouit bien que de ce qu’on partage.

  17. #77
    Expert éminent sénior
    Citation Envoyé par moldavi Voir le message

    Et quand tu as un bug, parce que tu as ajouté un chou et une carotte, dans 100000 lignes de code, oui tu t'arraches les cheveux. Un compilo C/C++ t'aurait prévenu...
    Je n'ai plus rencontré ce type de bug en JavaScript, ni même en Java d'ailleurs, depuis que j'ai pris l'habitude d'écrire systématiquement des TU.

    En fait je peux éventuellement le rencontrer mais au moment de l'exécution du test, c'est à dire quelques secondes après avoir écrit mon code.

    En revanche résoudre un ticket de bug dont la cause est d'avoir ajouté un chou à une carotte ça je n'ai plus rencontré depuis que j'écris des TU parce que je les détecte en amont, en fait immédiatement.

    Citation Envoyé par moldavi Voir le message

    JS gère-t-il aussi l'asynchronicité de tes variables globales, ou l'état de tes objets membre ? Ils sont forts chez javascript. Je comprends le problème de l'auteur, et je ne dis pas que JS est bien équipé.
    Tu confondrais pas asynchrone et mutation par hasard ?

    Citation Envoyé par moldavi Voir le message

    Outils payants ou gratuits, c'est important de savoir pour des langages tout public ?
    99,99999% des outils JS sont opensource et gratuits.

    Citation Envoyé par moldavi Voir le message

    Oui Node a tout changé. Les développeurs Front-End font des doubles appels à la même ressource statique, et ils ne savent même pas pourquoi. Ils comprennent rien à tous ces frameworks, tellement c'est simple et tout public.
    La population de dev JS est surtout très jeune et manque d'expérience, mais c'était pareil avec Java il y a 10 ans. Il ne faut pas oublier que la croissance de la population de dev est énorme, ça double tous les 5 ans donc l'expérience moyenne du dev lambda que tu rencontres dans le monde pro est mécaniquement faible sauf politique RH bien particulière.

    Citation Envoyé par moldavi Voir le message

    "et pire C++"... C'est-à-dire ?
    Que l'évolution de JS en 5 ans a été extrêmement rapide. "Pire" n'était pas le bon mot à employer ce n'est pas péjoratif d'avoir un écosystème stable.

    Citation Envoyé par moldavi

    Vous croyez vraiment à ce que vous racontez ? Quelques sont ces statistiques sur ces fameux SI d'une très grande complexité...

    Les SI utilisent ce truc par phénomène de mode, par lobbying et par facilité, pas par efficacité.
    Non c'est juste plus efficace et moins cher à exploiter pour les besoins de ces grands groupes. Ça ne veut pas dire que c'est pertinent pour tous les SI ça dépend du contexte.



    Citation Envoyé par moldavi

    Bientôt, ils vont vous faire croire que l'on peut faire des jeux vidéos en node.js...
    Pour écrire un moteur graphique c'est peu probable. En revanche pour gérer la couche réseau d'un jeu en ligne c'est très probable !

    Citation Envoyé par StringBuilder
    Je n'ai pas trouvé avec TypeScript comment se connecter à une base de données, écrire dans un fichier, etc.
    Si tu ne sais pas comment faire des I/O avec node, que ce soit en JS ou en TS ça n'a juste rien à voir TS étant une extension de JS apportant du typage statique et seulement du typage statique, c'est simplement que tu ne t'es pas formé dessus.

    Les API d'I/O dépendent de la plateforme (node ou browser), pas du tout du langage.

    Citation Envoyé par StringBuilder

    pas plus que je ne vois comment on peut se vanter d'avoir de meilleures performances avec une telle architecture !
    On a de meilleures performances si l'outil correspond au besoin.

    Si le besoin est d'effectuer du calcul alors Node sera horrible en terme de performances.

    Si le besoin est de traiter un grand nombre de requêtes réseau (http ou autre d'ailleurs) avec peu de traitement et d'aboutir à des I/O (fichiers, réseau, bases de données, ...) alors node est conçu pour être performant. Et il l'est vraiment beaucoup ! (débat event loop vs multi-threading)

    Citation Envoyé par StringBuilder

    J'ai raté un truc je pense...
    Oui tu as oublié de te former c'est gênant xD

    Commence donc par le point de départ :

    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  18. #78
    Expert éminent sénior
    Citation Envoyé par StringBuilder Voir le message
    Tout ce que fait ton exemple, c'est de lire un fichier index.html et renvoyer le résultat à l'appelant.
    Je ne vois pas d'accès à des données...
    Si tu peux lire un fichier, tu peux aussi écrire. Et si tu recherche fs, tu trouveras toute une API de manipulation de données. Je t'ai juste donné le premier lien.

    Tiens pour un accès à une base de donnée (idem premier lien) : https://www.w3schools.com/nodejs/nodejs_mysql.asp


    Citation Envoyé par StringBuilder Voir le message
    Pipo, plage, ski, toussa...
    Heu… ???

    Citation Envoyé par StringBuilder Voir le message
    Intèrférer : ok pourun site bancaire public. Pour une application d'entreprise, OSEF.
    Heu… tu es sérieux ?

    Citation Envoyé par StringBuilder Voir le message
    Et pour choisir de surcharger un serveur de calculs pour pouvoir garder les résultats en cache, ou plutôt déporter les calculs au client... perso mon choix est vite fait !
    Cela dépend encore une fois des calculs… j'en ai qui demandent ~64 cœurs, et quelques To de ram. Non, je ne vais pas les faire côté client.

    Citation Envoyé par StringBuilder Voir le message
    Le confort du développeur doit venir dans les dernières positions quand il s'agit de choisir une techno, clairement pas l'inverse !
    L'optimisation prématurée est diabolique.

    Déjà un code qui fonctionne, développé dans des temps raisonnables, c'est suffisant dans 99% des cas. Et pour les 1% restant, tu peux faire évoluer ton code en réimplémentant certaines sections critiques.


    Citation Envoyé par StringBuilder Voir le message
    Hmmmm...
    Temps d'accès en mémoire, on est de l'ordre de la µs.
    Temps d'accès disque, on est de l'ordre de la ms.
    Temps d'accès REST (serveur socket + encapsulation HTTP + ...) on est de l'ordre du centième ou dixième de seconde à condition d'être sur un réseau local fibré.

    Bref, le goulot d'étranglement, il commence déjà par choisir la techno qui correspond au besoin : si j'ai pas besoin de faire du REST entre mon backend et ma couche d'accès aux données, je fait pas de REST en me disant que je verrai plus tard si ça rame !
    Pourquoi tu veux faire du REST aussi…
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  19. #79
    Expert confirmé
    Marco46 et StringBuilder, vous ne parlez pas de la même chose.

    StringBuilder pense à des exemples d'applications internes en entreprise où il n'y a pas besoin de séparer le client et le serveur et où on peut directement coder des applications Desktop.
    Alors, les performances des applications Desktop sont meilleures, car on ne s'encombre pas des échanges HTTP entre la partie graphique et la partie métier/calculs. EDIT après lecture du message de Neckara : mais il y a toujours des cas particuliers, comme l'exemple de Neckara où le PC du client n'est pas assez puissant.

    Marco46 parle du cas où on sépare le client et le serveur. Dans le cas où le serveur reçoit un très grand nombre de requêtes, mais que chaque requête est rapide à traiter, Node se débrouille bien par rapport à la concurrence.

    Mais, là, on est partis dans le hors-sujet.

  20. #80
    Expert éminent
    Pour rappel : je demande en quoi TS peut remplacer Java ou C# côté backend (donc pour coder les API qui fournissent et traitent les données pour le compte de la partie client).
    Car autant je suis convaincu pour faire du web riche, bah de toute façon c'est JS et rien d'autre (donc TS ou alternatives), autant côté serveur, j'ai toujours pas pigé ce que TS peut apporter, et comment il peut être plus performant.

    Citation Envoyé par Marco46 Voir le message
    Je n'ai plus rencontré ce type de bug en JavaScript, ni même en Java d'ailleurs, depuis que j'ai pris l'habitude d'écrire systématiquement des TU.
    Moralité, JS oblige a écrire 10 fois plus de TU pour compenser les lacunes (laxitudes ?) du compilateur.

    Citation Envoyé par Marco46 Voir le message
    En fait je peux éventuellement le rencontrer mais au moment de l'exécution du test, c'est à dire quelques secondes après avoir écrit mon code.
    Ok, donc t'as une interface ITruc.
    Tu as un objet Machin qui n'hérite pas de ITruc, puisque ça sert à rien d'indiquer explicitement l'héritage quand on souhaite implémenter une interface : le faire d'implémenter les méthodes suffit (en gros, du moment que mon objet implémente certaines méthodes il hérite automatiquement de toutes les interfaces qui déclarent ces interfaces).
    TU ou pas, le jour où tu passes dans ton code et que tu dégages une méthode car tu penses qu'elle ne sert à rien, ce n'est qu'en rejouant tous tes TU (si tu as bien pensé à tous les écrire) que tu te rendra compte que t'as fait pété un module qui appelle ton objet dans un coin totalement hors de ton contexte.

    Citation Envoyé par Marco46 Voir le message
    99,99999% des outils JS sont opensource et gratuits.
    Je prend le premier tuto sur DVP et bam ! Premier IDE proposé est un truc payant :
    https://tarh.developpez.com/articles...er-typescript/


    Citation Envoyé par Marco46 Voir le message

    Si tu ne sais pas comment faire des I/O avec node, que ce soit en JS ou en TS ça n'a juste rien à voir TS étant une extension de JS apportant du typage statique et seulement du typage statique, c'est simplement que tu ne t'es pas formé dessus.

    Les API d'I/O dépendent de la plateforme (node ou browser), pas du tout du langage.
    Ok, donc un backend, j'ai pas de navigateur. Je suis libre, je souhaite écrire un ERP en TS, j'ai une base de données Oracle (histoire d'avoir un truc aussi bien présent sur Linux que Microsoft), je souhaite donc exécuter des requêtes SQL dedans.
    File-moi des liens, car jusqu'à présent, j'ai toujours pas vu la moindre doc me parler de connexion ODBC ou autre à une base de données depuis JavaScript !

    Ensuite, si les I/O sont dépendants de l'OS, de l'environement d'exécution (browser, serveur web, script, je ne sais quoi) alors :
    - Vas-y la merde pour se former
    - Vas-y la pérennité des outils

    Citation Envoyé par Marco46 Voir le message

    Si le besoin est de traiter un grand nombre de requêtes réseau (http ou autre d'ailleurs) avec peu de traitement et d'aboutir à des I/O (fichiers, réseau, bases de données, ...) alors node est conçu pour être performant. Et il l'est vraiment beaucoup ! (débat event loop vs multi-threading)
    Non, ça c'est pas un besoin, c'est une conséquence de l'architecture web riche : quand t'as un écran qui fait 200 appels à des API serveur par seconde afin d'avoir un chargement asynchrone, c'est la conséquence des choix effectués (application web, asynchrone, etc.)


    Citation Envoyé par Marco46 Voir le message

    Oui tu as oublié de te former c'est gênant xD

    Commence donc par le point de départ :

    Je suis de la vieille école, j'ai pas sous la main un casque pour regarder des vidéos.
    Si tu as des liens avec de la LECTURE et des exemples (si possible complets) alors je suis preneur, je veux bien me former pour aller plus loin dans ce débat.
    On ne jouit bien que de ce qu’on partage.