Journal Toileharicot 12 est dehors

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
14
19
août
2020

Ah Nal,

Je t'écris pour t'informer que la version 12 de Netbeans, le meilleur IDE Java/PHP/Node.js, est en sorti.

Cette version LTS apporte les nouveautés suivantes:

  • la gestion des dernières nouveautés de Java (le meilleur langage pour les projets d'entreprise): records, pattern matching, bloc de textes) ;
  • la même chose pour PHP (le pire langage pour les projets d'entreprise): typage, nouveaux opérateurs ;
  • de nouveaux thèmes.

Oracle, une généreuse PME qui éditait Netbeans avant, a aussi fait don de code concernant C++. Ce langage devrait revenir dans les prochaines versions, ce qui comblera de joie les pauvres développeurs C++ qui doivent en attendant se contenter d'Eclipse ou pire de VSCode.

netbeans

  • # Net != Toile

    Posté par  . Évalué à 10.

    Même si je ne suis pas avare de jeux de mots, "net" ne veut pas dire "toile" mais plutôt "filet". C'est plutôt à "web" qu'est attribué "toile".

    Ce serait donc plus juste d'écrire "Filetharicot 12 est dehors" :).

    La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

  • # TinuxFR

    Posté par  . Évalué à 10.

    Ah Nal,

    une envie particulière?

    Je trolle dès quand ça parle business, sécurité et sciences sociales

  • # No comment

    Posté par  (site web personnel) . Évalué à -4.

    Trop commenter le code nuit à sa lisibilité. En plus le bleu sur nos écrans c'est mauvais pour les yeux.

    C'est vraiment important de commenter 1 pauvre ligne de code aussi triviale ? Alors oui, javadoc et tout, mais avec d'autres IDE, on accède au code très rapidement et on préfère le lire directement plutôt que de se coltiner la doc de chaque méthode.

    • [^] # Re: No comment

      Posté par  . Évalué à 9.

      Ce n'est pas du commentaire de code, mais de la documentation d'API.

      Un commentaire de code est là pour aider à celui qui lis le code. Il lui indique pourquoi les choses sont faites de cette façon (quand le code ne peux pas l'indiquer de lui même).

      La documentation d'une API décris ce que fait l'API sans avoir besoin d'aller en lire le code. Pas mal d'éditeurs ter permettent d'y accéder sans aller voir le code. Très pratique quand tu veux entrer les paramètres d'une méthode en gardant la doc sous les yeux (ça évite les sauts qui, aussi rapides et efficaces qu'ils soient, obliger à repositionner ton regard.

      Donc moi ça me choc pas.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: No comment

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 19 août 2020 à 20:40.

        Je suis bien au courant. Quasiment tous les projets java utilisent ce principe. Cela dit, avec asciidoctor par exemple, on devrait pouvoir externaliser cette documentation. Ça fait sens si on veut la traduire et même documenter à partir des tests, des exemples de code tiré du git, présent dans d'autres fichiers.

        Je veux bien documenter une classe, au dessus du code de celle-ci, car ça ne gêne pas la lecture du code. Par contre documenter toutes les méthodes est une perte de temps, surtout lorsque ça paraît triviale. La doc inline qui explique un passage complexe est bien sûr primordial.

        • [^] # Re: No comment

          Posté par  . Évalué à 6.

          Quasiment tous les projets java utilisent ce principe.

          Et python et les projets qui utilisent doxygen et julia et ocaml et golang…

          Cela dit, avec asciidoctor par exemple, on devrait pouvoir externaliser cette documentation.

          Ça ne fais pas la même chose. Tu ne peux associer cette documentation à ton code. Donc aucun éditeur ne pourra t'aider. C'est pas inutile pour autant, mais ce n'est pas la même chose.

          Ça fait sens si on veut la traduire et même documenter à partir des tests, des exemples de code tiré du git, présent dans d'autres fichiers.

          Tout à fait beaucoup font vraiment leur tambouille pour ça que ce soit avec de la doc inline ou des trucs comme asciidoctor. Il y a même un langage dont la doc inline peut contenir une portion de code qui sera exécutable, mais j'ai pas pu retrouver où j'avais vu ça.

          Je veux bien documenter une classe, au dessus du code de celle-ci, car ça ne gêne pas la lecture du code.

          La plupart des éditeurs permettent de la cacher et les linters te fournissent un minimum de vérification de la correspondance.

          Par contre documenter toutes les méthodes est une perte de temps, surtout lorsque ça paraît triviale.

          Je n'ai pas dû être claire. Il s'agit de documenter l'API. La complexité du code sous-jacent n'a rien à voir. Si ça peut être plus clair, imagine le cas d'une bibliothèque C ou C++ qui décrit ça avec doxygen dans ses entêtes. L'écriture de cette documentation peut être antérieure à l'écriture du code qui l'implémente. Par exemple tu peut aller jusqu'à indiquer la complexité de l'implémentation et c'est alors judicieux de documenter aussi ce qui te paraît trivial. C'est un contrat de l'API.

          Ah et ça ça concerne l'API et non tout le code (à moins que tout ton code soit une API). Généralement une faible portion du code d'une bibliothèque fait partie de l'API, sinon ça devient complexe à maintenir. On peut voir un exemple avec rxjava pour une classe qui fait partie de l'API et une qui n'en fait pas parti.

          La doc inline qui explique un passage complexe est bien sûr primordial.

          Encore une fois ça n'a rien à voir. Documenter une API et commenter un code sont 2 choses qui n'ont rien à voir et sont régulièrement faites par des personnes différentes (c'est celui qui implémente qui documente son code alors que rien ne l'oblige pour la documentation d'une API).

          Je trouve important de la doc non associée à l'API qui décrit plus les concepts et qui ne soit pas organisée par rapport au code, mais l'un empêche pas l'autre et ils ont des objectifs bien différents.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: No comment

            Posté par  (site web personnel) . Évalué à -1.

            Je connais bien Javadoc, et je sais bien qu'il s'agit de la documentation d'une API.. c'est même ce que je dis dans mon 1er message. Normalement si il s'agit d'une API, c'est vrai que le code est trivial par nature. De plus les IDE proposent d'afficher le Javadoc au survole de la méthode…

            Asciidoctor permet déjà de mettre des extraits de code à partir d'un numéro de commit et un numéro de ligne. On pourrait appliquer ce principe pour commenter une API.

            Avantages : i18n, documentation API composite, enrichie aux extraits de code des tests venant des sources pour montrer l'usage de l'API, documentation structurée.

            Si on a pas besoin de tout ça, juste d'une documentation de l'API, c'est difficile de faire mieux que les Javadoc like, je te l'accorde.

          • [^] # Re: No comment

            Posté par  . Évalué à 9.

            Il y a même un langage dont la doc inline peut contenir une portion de code qui sera exécutable, mais j'ai pas pu retrouver où j'avais vu ça.

            C'est peut-être Python et ses doctests.
            Et c'est trop trop trop badass.
            Ça remplace pas les frameworks de test mais ça permet d'avoir des exemples dans ta doc qui s'exécutent comme des TU.

            Par exemple :

                def combi1(n):
        """
            n : (int) un entier qui ne sert à rien
            retour : (int) la valeur de 1.

        Exemples :

        >>> combi1(42)
        1
        >>> combi1(33)
        1
        >>> combi1(666)
        1
        """
        return 1

            Avec doctest, les exemples de ta documentation sont toujours bon car ils sont utilisés comme des TU (très simple).
            python -m doctest
            pour les lancer

            https://en.wikipedia.org/wiki/Doctest

            https://docs.pytest.org/en/stable/doctest.html

            https://docs.python.org/fr/3.10/library/doctest.html

    • [^] # Re: No comment

      Posté par  (site web personnel) . Évalué à 4.

      Après vérification la couleur est RGB(17,29,48), ça envoie quand même beaucoup moins de bleu qu'un fond blanc (5 fois moins), et c'est peut être un peu plus agréable qu'un fond noir.

      Un LUG en Lorraine : https://enunclic-cappel.fr

      • [^] # Re: No comment

        Posté par  (site web personnel) . Évalué à -9.

        tes pupilles se protègent p-e plus en voyant un écran blanc qu'un écran tout bleu. Mais bon, le wifi c'est pas bon, la 5G, n'en parlons pas, et il parait que se droguer c'est mal.

        C'est vrai que c'est moins flashy que l'écran bleu d'un PDP-1 OS.

  • # le meilleur langage pour les projets d'entreprise

    Posté par  . Évalué à 3. Dernière modification le 19 août 2020 à 23:27.

    S il y a bien une chose a savoir c est qu une phrase comme "le meilleur langage pour les projets d'entreprise" est forcément fausse. De manière général quand qqun dis "c est le meilleur" il faut se mefier. Et la c est comme si toutes les entreprises avaient les mêmes besoins. Java est truffé de défaut et PHP plein de qualité. Pour des script ou le web PHP ferra très bien l affaire et permettra de developper rapidement quelque chose de souple. Java est verbeux et très complexe a géré côté mémoire. Il conviens donc plus pour des système a plus grande échelle. Mais aujourd'hui a cause du côté procedurié d Oracle une grosse entreprise préférera du Go ou si elle a des ressources (pas trop de pb de perfs) du node.js…

    Eh oui en informatique il n existe pas de language universel. Beaucoup de langage peuvent se justifier selon les contextes. Moi j ai une préférence pour Rust et Julia en ce moment. Mais ils ne conviennent pas pour tout après j irais vers du Go…

    • [^] # Re: le meilleur langage pour les projets d'entreprise

      Posté par  (site web personnel) . Évalué à 4.

      Eh oui en informatique il n existe pas de langage universel.

      Java en est proche, des sites web aux applis mobiles en passant par les traitements de masse ou le calcul distribué. Il est moins à l'aise sur le bureau (bien que Swing soit un vrai bonheur par rapport à Gtk ou Qt), mais dans la plupart des domaines, Java est un bon choix.

      Il parait que certains font même des jeux avec !

      Beaucoup de langage peuvent se justifier selon les contextes.

      Le contexte d'une entreprise, ce sont des projets qui vont durer des années avec des équipes qui tournent.

      Java a deux qualités majeures pour ce contexte:

      • il est facile à lire et à comprendre (la verbosité devient une qualité) ;
      • son runtime, ses API et la plupart des bibliothèques sont stables.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: le meilleur langage pour les projets d'entreprise

        Posté par  . Évalué à 0. Dernière modification le 20 août 2020 à 14:43.

        Tu peux faire des site web aux scripts et traitements de masse ou jeux dans n'importe quel langage. (Le mobile est un peu a part tu dépends souvent du choix de l'OS). Dans mon entreprise on développe en PHP du web comme des scripts de traitements massif de manière très efficace et performantes (du moins comparé à Java) et surtout de manière beaucoup plus réactive que s'ils étaient en Java.

        Java fais facilement une consommation de mémoire importante, il demande donc d'y passer du temps ce qui a un coût qui n'est pas toujours justifié par de petits projets en entreprises. De ces défaut découle un autre problème, le coût des développeurs.

        Java n'est pas plus fais pour durer qu'un autre, il est régulièrement incompatible ce qui fais que quand tu reprends un projet tu dois réécrire une partie. Et je ne parle pas des libs (notamment graphique ou web). Connais tu l'histoire de JSF, JSP…
        Le langage le plus stable à ma connaissance c'est C/C++. Le code même écris il y a 30 ans compile avec une option.

        La lisibilité du code dépends essentiellement de la manière dont il est écris et structuré, des pratique de l’entreprise.

        • [^] # Re: le meilleur langage pour les projets d'entreprise

          Posté par  . Évalué à -1.

          C'est aussi a cause de sa consommation mémoire qu'il est peu apprécié sur le bureau. J'utilise Netbeans et DBeaver, ils ont de grosses qualité, mais pas la stabilité sur le long terme (il faut killer quand on en demande de trop et surtout s'il est ouvert depuis longtemps). J'ai le cas de DBeaver qui frise quand une ligne d'une requête est trop longue. Tu peux critiquer l'implémentation de DBeaver mais c'est plus probablement la lourdeur naturelle de Java.

        • [^] # Re: le meilleur langage pour les projets d'entreprise

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Java fais facilement une consommation de mémoire importante, il demande donc d'y passer du temps ce qui a un coût qui n'est pas toujours justifié par de petits projets en entreprises. De ces défaut découle un autre problème, le coût des développeurs.

          Et une immense partie du cout en mémoire, sur les machines récentes, vient de l’incompréhension des développeurs du modèle mémoire de Java et des réglages par défaut de la JVM.

          La connaissance libre : https://zestedesavoir.com

        • [^] # Re: le meilleur langage pour les projets d'entreprise

          Posté par  . Évalué à 3.

          Java n'est pas plus fais pour durer qu'un autre, il est régulièrement incompatible ce qui fais que quand tu reprends un projet tu dois réécrire une partie.

          C'est factuellement faux. Au niveau langage la comptabilité source et binaire sur les 15+ dernières années est limite irréprochable. Tu prends un JAR compilé il y a 15 ans en Java 1.3 ou 1.4, il tourne toujours avec un JRE 15. Tu recompiles, il compile et tourne. Et au passage il tourne plus vite grâce aux amélioration du JIT.

          Il existe quelque cas marginaux qui posent des problèmes (coucou bridge method, changement de comportement de substring & cie) et quelques rares nettoyages qui ont été fait en Java 9 sur des API peu utilisées, coûteuses à maintenir ou dangereuses. Ce sont de rares exceptions. Ce sont de rares exceptions. Beaucoup d'évolutions niveau JVM ont été coûteuses pour préserver cet attribut.

          Si tu as des problèmes, c'est que les libs que tu utilises elles ne sont pas aussi disciplinées et que les nouvelles versions que tu choisies d'utiliser ont cassées la compatibilité source ou binaire. Ou que tu as choisi de changer de libs car tes besoins ont changés. C'est autre chose que la question d'origine car tu peux toujours utiliser les JAR d'avant, ça tournera.

          Donc oui maintenir un projet dans le temps demande de l'effort de maintenance. Il est juste grandement facilité par le fait qu'un binaire qui tourne continuera à tourner. Ça permet de ne pas avoir d'écosystème qui éclate à cause de chaîne de dépendance brisé (ie. pas besoin de recompiler la veille lib stable dont tout le monde dépend sans le savoir et qui n'a pas eu de release depuis 8 ans). Ca permet de continuer à faire tourner le binaire d'un projet arrêté il y 6 ans sans avoir à géler le hard & soft d'un serveur etc. D'autres langages n'ont pas cette culture et le coût à terme n'est vraiment pas le même. Dans la vraie vie, c'est plutôt pratique.

          • [^] # Re: le meilleur langage pour les projets d'entreprise

            Posté par  . Évalué à 2.

            C'est factuellement faux.

            Pas tout à fait, ça l'était jusqu'à l'arrivée de java 9, mais depuis ils se sont mis à vraiment retirer certaines des API qu'ils déprécient.

            Et au passage il tourne plus vite grâce aux amélioration du JIT.

            C'est d'ailleurs amusant de voir que d'anciennes bonnes pratiques d'optimisation (par exemple le cas du toArray) sont devenues des contre-optimisations avec les JVM modernes.

            • [^] # Re: le meilleur langage pour les projets d'entreprise

              Posté par  (site web personnel) . Évalué à 2.

              Pas tout à fait, ça l'était jusqu'à l'arrivée de java 9, mais depuis ils se sont mis à vraiment retirer certaines des API qu'ils déprécient.

              Ces changements mineurs prévus de longue date et les frayeurs qu'ils provoquent en entreprise montrent bien que la stabilité est un critère de choix majeur.

              Mais rien avoir avec les drames des migrations de versions de Python ou PHP…

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: le meilleur langage pour les projets d'entreprise

            Posté par  . Évalué à 0.

            euh… Non.

            La nécessité de hascode et equals en cohérence à rendu bon nombre de code non fonctionnel.

            Par ailleurs Oracle ayant un passif sur la segmentation/fermeture de trucs ouvert (coucou MySql), java est désormais un langage appartenant au passé.

            Il faut maintenant lui préférer c++ qui depuis 2011 botte vraiment des culs.

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: le meilleur langage pour les projets d'entreprise

              Posté par  . Évalué à 3.

              Je ne sais pas si j'aurais pris le C++ qui est une norme ISO pour laquelle il faut payer pour y avoir accès comme modèle d'ouverture par rapport à Java dont la documentation du langage est gratuite et librement distribuable.

              (je sais qu'il y a moyen d'avoir une préversion de la norme ISO gratuitement mais ça reste un contournement)

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: le meilleur langage pour les projets d'entreprise

              Posté par  (site web personnel) . Évalué à 3.

              J'espère que le futur de Java sera plutôt du côté d'Adopt Openjdk que d'Oracle.

              J'aimais bien C++, mais il est trop laborieux. Je mise plus sur Go et peut être Rust quand ils auront atteint la maturité.

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: le meilleur langage pour les projets d'entreprise

              Posté par  . Évalué à 3.

              La nécessité de hascode et equals en cohérence à rendu bon nombre de code non fonctionnel.

              Peux-tu expliciter ? Quelle évolution à cassé quel code ?

              • [^] # Re: le meilleur langage pour les projets d'entreprise

                Posté par  . Évalué à 1.

                lors du passage de java 5 ou 6 vers java 7

                Les Collections se sont mise à vérifier que les hashcode et equals étaient cohérent, mais le projet n'avait pas codé un seul hashcode.

                Le problème c'est que c'est au runtime que la blague se produit… Personne n'avait anticipé le problème.

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: le meilleur langage pour les projets d'entreprise

                  Posté par  . Évalué à 3.

                  Je ne trouve pas trace et la javadoc de 1.5 expliquait déjà qu'il fallait que ce soit cohérent. Je serait intéressé de trouver plus de détail si quelqu'un a.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: le meilleur langage pour les projets d'entreprise

                    Posté par  . Évalué à -1.

                    j'ai pas dit que le code était bon avant, il marchait (comprendre aucun bug n'avait été remonté); le changement de jre a mis en évidence ce soucis dans le code en jetant des exceptions.

                    String en java 1.2 (java 5 == java 1.5) ) changé sa version de hashcode pour des raison de performances; j'imagine que dès l'origine c'était nécessaire; mais lorsque ce n'était pas fait les collection ne te jetaient pas d'exception.

                    J'ajouterai que les génériques en java ça n'a vraiment pas la puissance des templates…

                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                    • [^] # Re: le meilleur langage pour les projets d'entreprise

                      Posté par  . Évalué à 3.

                      J'ai du mal à voir comment les HashMap et les HashSet pouvaient être implémenter pour ne pas s'appuyer sur la correspondance. J'imagine qu'ils refaisait un equals systématiquement.

                      Pour la fonction de hash des string peut-être que java a changé en 1.2, mais il n'a pas changé ensuite pour passer à murmur3 contrairement à tout les autres langages.

                      Si tu as un code qui s'appuyer massivement sur substring ton code a pu avoir un problème quand ils ont changé son comportement.

                      Oui il y a eu des changements, mais le fais que sur 25 ans, on puisse les lister et qu'une partie étaient des bugs sous-jacent, montre que c'est plutôt stable.

                      J'ai pas compris ta remarque sur template ? Ça n'a rien à voir avec la stabilité et ce ne sont pas vraiment des outils comparables.

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: le meilleur langage pour les projets d'entreprise

              Posté par  . Évalué à 4.

              Par ailleurs Oracle ayant un passif sur la segmentation/fermeture de trucs ouvert (coucou MySql), java est désormais un langage appartenant au passé.

              Ils ont passé la main au projet OpenJDK ce qui met le JDK Oracle sur un pied d'égalité (organisationnel en tout cas) avec tout ceux qui veulent fournir un JDK que ce soit ta distribution, adopt openjdk, amzon ou autre.

              Même l'une des partie les plus fermées, JavaEE s'est organisé au sein d'Apache et est aujourd'hui émancipé d'Oracle.

              Oracle reste un très gros acteur de Java (il fourni de l'infra, de la main d'œuvre, ils ont sorti des projets comme graal,…), mais il le fait au même titre que RedHat, Google ou IBM pour parler de très grosses boites.

              Je ne vois pas comment on peut sous-entendre que Java prend le même chemin que MySQL si on s'est un peu intéressé au sujet.

              Bien sûr on peut parler du procès Oracle/Google, c'est pas le premier et ce ne sera pas le dernier procès du genre, on a eu AT&T, on à celui-ci, on en aura d'autres.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: le meilleur langage pour les projets d'entreprise

                Posté par  . Évalué à 2.

                Même l'une des partie les plus fermées, JavaEE s'est organisé au sein d'Apache et est aujourd'hui émancipé d'Oracle.

                Eclipse pas Oracle.

                mais il le fait au même titre que RedHat, Google ou IBM pour parler de très grosses boite

                Je ne vois pas comment on peut sous-entendre que Java prend le même chemin que MySQL si on s'est un peu intéressé au sujet.

                Tant que Java reste sur HotSpot, il y a effectivement peu de chances que les choses bougent. La dynamique introduit par Sun que quasiment tout le monde utilise gratuitement la plateforme Java est difficile à remettre en cause. Ce qui explique la passage progressif vers la situation actuelle d'OpenJDK.

                Par contre HotSpot est plutôt en fin de vie. Oracle a clairement fait le choix de basculer ses effectifs vers les étapes futures plutôt que vers la maintenance. C'est pour ça qu'ils ont refourgué la gestion des LTS à la communauté depuis Java 11 (le travail de backport sur Java 8 avait été monstrueux par exemple). Si Graal est techniquement extrêmement intéressant, Oracle semble aussi profiter du mouvement pour casser le statuquo du tout libre & gratuit. Une partie sera open source et utilisable gratuitement. Mais les fonctionnalités d'entreprise / performance ne le seront sûrement pas. Pour moi le risque est là. Soit un gros pivot de stratégie si Graal prend, soit que Graal ne prenne pas et que la plateforme ait perdue beaucoup d'efforts.

                • [^] # Re: le meilleur langage pour les projets d'entreprise

                  Posté par  . Évalué à 2.

                  Eclipse pas Oracle.

                  Tout à fait Jarkata EE c'est eclipse.

                  Si Graal est techniquement extrêmement intéressant, Oracle semble aussi profiter du mouvement pour casser le statuquo du tout libre & gratuit.

                  En créant un projet libre & gratuit ? Aujourd'hui graal est microscopique et ne pourra jamais se faire une place sans quarkus de Red Hat. Je ne suis pas sûr qu'il supporte un jour l'ensemble de java et a 1 ans et demi de retard sur son support de java. C'est vraiment s'embêter beaucoup pour pas grand chose. D'autant qu'ils continuent de libérer leurs outils maisons inclus dans leur distribution de java.

                  Pour moi le risque est là.

                  Hotspot est effectivement en fin de course, mais OpenJ9 est là et a l'avantage d'être accessible en remplacement directe. Graal n'est intéressant pour le CPU bound et est moins bon que hotspot en mémoire. Il est très peu probable que Java passe à graal.

                  Ce ne serait même pas intéressant pour Oracle qui ne pourrait plus vendre ses licences OSB, weblogic, etc et ça c'est du cash qu'ils font aujourd'hui pas de l'hypothétique dans 5 ans.

                  […] soit que Graal ne prenne pas et que la plateforme ait perdue beaucoup d'efforts.

                  Dans le monde des techno (voir scientifique) un travail n'est jamais perdu. Le truc qui arrivera après pourra s'appuyer de l'expérience en question (si c'est un échec). PHP6 n'a pas tué PHP par exemple alors qu'il a consommé en proportion beaucoup plus d'énergie.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: le meilleur langage pour les projets d'entreprise

          Posté par  . Évalué à 1.

          Et sans oublier les javacard, qui sont devenues bon gré mal gré le standard des applications embarquées dans les cartes à puces et NFC !

  • # VSCode

    Posté par  (site web personnel) . Évalué à 5.

    Juste pour info, que reproche tu à VSCode ?

    • [^] # Re: VSCode

      Posté par  . Évalué à 6.

      C’est basé sur cette merde d’electron.

      J’utilise pas vscode et j’ai des bons retours par mes collègues front-end, mais ce truc ça fait quand même mal au cul quand tu vois toute la place occupée (disque et RAM) pour un éditeur de texte…

      • [^] # Re: VSCode

        Posté par  . Évalué à 3. Dernière modification le 20 août 2020 à 20:14.

        Et chez moi, tout programme Electron qui reste ouvert plus de 24h se met à ramer et consommer une quantité de mémoire indécente !

        • [^] # Re: VSCode

          Posté par  (site web personnel) . Évalué à 3.

          24 h ? Chez moi c’est au bout de même pas 24 minutes… ><

          • [^] # Re: VSCode

            Posté par  . Évalué à 1.

            J'ai probablement une machine bien trop puissante pour mon usage ;)
            Mais j'ai probablement exagéré les 24h. En général, je m'en rend compte quand je reprend le taf après avoir laissé le PC la veille sans avoir quitté une des 2 applis Electron que j'utilisent parfois (Insomnia et VSCode si quelqu'un connait de bons remplacements pour du Go). Le PC est alors limite utilisable ; quand ça arrive, mon premier réflexe est de chercher l'une des ces deux applis :D

            • [^] # Re: VSCode

              Posté par  . Évalué à 0.

              Pour le go, j'utilise goland. C'est pas libre et c'est payant, mais ça me permet de bosser en go. Je n'aime pas ce langage à la base, et j'avais vraiment du mal avec vscode/codium qui ne fonctionnaient pas comme chez mes collègues - sûrement de ma faute). Depuis que je suis passé à Goland, j'arrive à travailler sans râler toutes les 5 minutes (je suis passé à 15 :D)

        • [^] # Re: VSCode

          Posté par  . Évalué à 2. Dernière modification le 20 août 2020 à 23:51.

          Aujourd'hui j'ai pingé la collègue avec laquelle je partage une machine son VSCode (enfin le plugin C++) utilisait 39GO de mémoire résidente.
          Le serveur est un monstre mais ça se remarquait quand-même !
          Elle ne l'utilisait même pas, elle avait juste laisser la fenêtre ouverte depuis Lundi..

          Après il n'y a pas de bon IDE pour les projets C++ de grande taille..

          • [^] # Re: VSCode

            Posté par  . Évalué à 3.

            Dans ton cas, je sais pas si on doit blamer VSCode, Electron ou ce qu'est devenu C++…

          • [^] # Re: VSCode

            Posté par  . Évalué à 3.

            CLion commence à faire pas mal de truc, mais y'a quand même des fois où je resorts emacs :(

            Par contre pour le java y a rien de mieux qu'IntelliJ

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: VSCode

              Posté par  . Évalué à 3.

              Il faut être trèèèsss patient pour utiliser CLion sur le projet sur lequel je suis..
              Après il y a un collègue qui m'a dit que ça allait en changeant la configuration pour que CLion utilise la RAM plutot que des fichiers, sans le COVID je l'aurais déjà torturé pour en savoir +

              • [^] # Re: VSCode

                Posté par  . Évalué à 3.

                Ah oui faut de la ram, déjà faut bien modifier la ram de la vm

                dans clion/bin/clion64.vmoptions

                j'ai largement modifié le xmx; par contre je suis intéressé pour savoir si y'a d'autre paramètres existants; car y a des fois il le blo (en même temps l'antivirus à tendance à me geler les IHM de manière complètement aléatoire, et de me faire un segfault avec dump de ram (c'est ça qui gèle tout j'imagine)); donc je ne sais pas si je dois accuser l'un ou l'autre.

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: VSCode

                  Posté par  . Évalué à 2.

                  j'ai largement modifié le xmx; par contre je suis intéressé pour savoir si y'a d'autre paramètres existants;

                  Les gc java ont des quantités folles d'options ! Le problème va plus être dans le temps que tu veux y accorder. Il faut regarder quel GC est utiliser et chercher ses options (voir activer les logs du gc). À minima jouer sur les tailles des générations peut pas mal jouer.

                  car y a des fois il le blo (en même temps l'antivirus à tendance à me geler les IHM de manière complètement aléatoire, et de me faire un segfault avec dump de ram (c'est ça qui gèle tout j'imagine));

                  Pourquoi ne pas désactiver les coredump ? Je crois qu'il est possible de les désactiver de manière général et ne les activier que ponctuellement.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: VSCode

                    Posté par  . Évalué à 3.

                    Pourquoi ne pas désactiver les coredump ? Je crois qu'il est possible de les désactiver de manière général et ne les activier que ponctuellement.

                    Si j'étais root… Ce *$£¤#?§ d'anti virus laisserai mes IDE tranquille (emacs compris), et ne générerai pas de dump que je ne peux de toute façon pas exploiter. Et ce ne serait pas McAfee.

                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: VSCode

        Posté par  . Évalué à 2.

        VSCode est tout de même plus qu'un éditeur de texte. Sinon vire tous les plugin de VSCode. Et Netbeans ou Eclipse ont le même genre de problème à ramer passer un certain temps et trop de choses ouvertes…
        Netbeans et Eclipse restent relativement plus efficace (surtout qu'ils ont un peu plus de fonctionnalités avancées) mais ce n'était pas le cas à leurs début il y a 10 ans.

        En théorie, pour que ce soit rapide je suis d'accord qu'il faudrait tout écrire en C++ ou mieux en Rust mais ce n'est pas le même taf…

        • [^] # Re: VSCode

          Posté par  . Évalué à 2.

          Je doute que des utilisateurs qui gardent des semaines des logiciels ouverts en préférant se plaindre plutôt que se demander si le logiciel qu'ils utilisent est fait pour être utilisé comme ça et est-ce qu'il y a des configuration à appliquer pour cet usage, ils seront malheureux quelque soit le logiciel que tu leur met entre les mains.

          En théorie, pour que ce soit rapide je suis d'accord qu'il faudrait tout écrire en C++ ou mieux en Rust mais ce n'est pas le même taf…

          On parle de consommation mémoire (comme ça avait l'air d'être question plus haut) ou de vitesse ? Faut se demander ce qu'il fait et voir comment le configurer peut être (les historiques, le filewatch, les indexes,…), il y a même de quoi surveiller ce qui consomme au sein de vscode.

          Pour être économe en mémoire avec des langages comme C++ ou rust1, il va falloir éviter de fragmenter la mémoire et je ne crois pas que soit inclus dans ces langages et cette gestion va aussi avoir un overhead mémoire (probablement inférieur à celle d'un gc je suis d'accord).

          Si on ne connaît pas la cause du problème, comment proposer une solution ?

          1. pourquoi "mieux" rust d'ailleurs ? il n'apporte que très peu pour la performance par rapport au C++ dans ce contexte ↩

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: VSCode

            Posté par  . Évalué à 1.

            pourquoi "mieux" rust d'ailleurs ? il n'apporte que très peu pour la performance par rapport au C++ dans ce contexte

            Oui, je dis mieux surtout pour la stabilité et ses autres avantages propre. Cela reste un avis personnel.

    • [^] # Re: VSCode

      Posté par  (site web personnel) . Évalué à 3.

      Son client Git surtout !

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Trolldi

    Posté par  (site web personnel) . Évalué à 1.

    la gestion des dernières nouveautés de Java (le meilleur langage pour les projets d'entreprise): records, pattern matching, bloc de textes) ;

    Ah c'est pas mal ce nouveau support de Scala 1. Espérons qu'ils ajoutent Scala 2 avant la sortie du 3.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.