• # Nope

    Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†2.

    Je comprendrai jamais l'int√©r√™t que porte les gens sur Java. Ce langage principalement utilis√© en √©cole et en entreprise promeut tant de choses qu'on dit ¬ę¬†bonnes¬†¬Ľ juste par principe mais finalement n'apporte rien¬†:

    • Abus de l'h√©ritage. Les langages r√©cents comme Rust et Go d√©montrent que l'on peut faire des projets sans orient√© objet. Ce paradigme est probablement vou√© √† disparaitre √† terme, il n'apporte que peu de solutions.
    • Abus des getters/setters. Les projets en Java sont ceux qui ont d√©finitivement le plus de boilerplate juste parce ¬ę¬†qu'il ne faut pas modifier une variable directement, saypabien¬†¬Ľ.
    • Lenteur excessive. Les langages interpret√©s c'√©tait bien avant (#boomer). On a des boites √† outils pour faire du natif sans se casser la t√™te (merci LLVM). ‚ÄúJava, write once, run away‚ÄĚ.
    • Verbosit√© inutile. Il y a tellement d'abus des exceptions que tu te retrouves √† √©crire des horreur comme private RS232 connect() throws NoSuchPortException, PortInUseException, UnsupportedCommOperationException, IOException, TooManyListenersException, Exception {
    • Overengineering √† outrance. Pour faire une chose simple en Java il faut instancier une factory qui cr√©e une interface qui cr√©e des objets.

    java

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Nope

      Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†10.

      Je pense que ta vision de Java doit dater des années 90.

      Accessoirement, la majorité de tes points ne sont pas liés au langage lui-même mais à ce que certaines personnes en font.

      Lenteur excessive. Les langages interpretés c'était bien avant

      Celle-là m'a bien fait rire.

      Bref, on ne te fera pas changer d'avis mais, des fois, c'est pas mal de se poser la question de pourquoi tant de gens aiment quelque chose quand on a des idées préconçues comme ça.

      • [^] # Re: Nope

        Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†4.

        Lenteur excessive. Les langages interpretés c'était bien avant

        Celle-là m'a bien fait rire.

        Je ne parle pas sans connaissance de cause, je maintien des applications en Java à mon travail et je t'assure que j'ai envie de trucider l'ancien développeur qui s'est dit que ça allait être une bonne idée de faire du Java sur de la Raspberry et de la BeagleBone.

        Le simple démarrage de l'application met déjà plus de 3 secondes avant même d'arriver dans nos premières fonctions. L'application en elle même n'est pas spécialement compliquée, mais tout est lent. Dire que Java est performant est de la pure mauvaise foi ;)

        J'ai fait du Java pendant plusieurs années, je ne parle pas dans le vent. Je m'intéresse à beaucoup de langages et c'est clairement celui dont je ne comprends toujours et encore pas l'intérêt. Comme c'est sujet à débat, je t'invite à me dire ce qui te plait dans ce langage et serait fortement ravi de savoir de quoi il s'agit.

        git is great because linus did it, mercurial is better because he didn't

        • [^] # Re: Nope

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†3. Derni√®re modification le 11 ao√Ľt 2022 √† 13:18.

          Le simple démarrage de l'application met déjà plus de 3 secondes avant même d'arriver dans nos premières fonctions.

          Moi c'est libreoffice qui est lent comme ça sur mon pi. Dire que C++ est un langage performant est de la pure mauvaise fois.

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

        • [^] # Re: Nope

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†5.

          Java sur un rpi, si tu cherches la petit bête aussi…

          Tout le monde sait qu'il faut travailler des machines des processeurs un tant soit peu puissants, avec un minimum de ram et des disques potables avec java. Et là, on commence à parler :-)

          Un peu plus sérieusement, chez nous ce sont les containers java qui prennent a peu près une minute pour être fonctionnels quand des applications plus élaborées en python sont dispo quasiment instantanément. Ce sont les même développeurs (java à la base) qui ont fait les deux codes. Et je ne parle pas de la consommation de mémoire …

          Sur certains points, c'est pas encore ça.

          Par contre, point de vue vitesse d’exécution y'a pas photo, java a une longueur d'avance.

          • [^] # Re: Nope

            Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†0.

            Tout le monde sait qu'il faut travailler des machines des processeurs un tant soit peu puissants, avec un minimum de ram et des disques potables avec java. Et là, on commence à parler :-)

            L'intérêt de Java et de la JVM c'est pas write once, run everywhere ?

            L'argument est douteux, si tu configure proprement ta JVM, et optimise correctement ton appli, Java va très bien tourner même sur un grille pain.

            https://link-society.com - https://kubirds.com

            • [^] # Re: Nope

              Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

              L'intérêt de Java et de la JVM c'est pas write once, run everywhere ?

              Ça n'a jamais voulu dire que ça doit s'exécuter partout avec la même performance. Par contre il me semble que java ne s'exécute pas sans utiliser une virtualisation en plus sur M1, sur risc-v et sur ios. Et il ne s'exécute plus sur navigateur non plus.

              Ça doit être pour ça que le slogan est mort avec son créateur : sun microsystems. C'est un peu comme utiliser le premier non de c++ pour en parler "c with classes".

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

              • [^] # Re: Nope

                Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†5.

                Par contre il me semble que java ne s'exécute pas sans utiliser une virtualisation en plus sur M1, sur risc-v et sur ios.

                Sur risc-v et ios, je ne sais pas, mais sur M1, non, on n’est pas obligé de passer par l’émulation x86_64 (même si c’est possible). Il y a des JVM ciblant directement l’architecture arm.

                Et c’est heureux, parce que pour avoir testé les deux (JVM x86_64 sous émulation vs JVM arm64 native), les performances de la version native sont bien meilleures, malgré tout ce que peut dire Apple sur la qualité de son émulation x86_64 qui soi-disant autoriserait à utiliser des programmes x86_64 sur M1 sans qu’on ne puisse jamais voir la différence…

        • [^] # Re: Nope

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†4. Derni√®re modification le 11 ao√Ľt 2022 √† 15:40.

          Quelle JVM usitlises-tu ?

          Il y a eut beaucoup d'amélioration concernant le RPi, celle par défaut n'est pas performante.

          Les tél Android ne sont pas tellement plus puissant qu'un RPi, les applications ne mettent pas beaucoup de temps pour se lancer.

        • [^] # Re: Nope

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†5. Derni√®re modification le 11 ao√Ľt 2022 √† 15:53.

          Sauf que tu parles d'anecdotes, de plus sur des systèmes ultra spécifiques. Il y a beaucoup de gens qui utilisent Java et sont très contents des performances.

          Pour des applications serveurs, le compilateur JIT de Java est assez redoutable.
          Si tu veux faire des applications type CLI, tu as GraalVM de nos jours (qui fait de la compilation AOT, ce qui dans certains cas sera moins performant que de la compilation JIT car le JIT peut optimiser des choses basées sur les motifs d'exécution).

          Pour prendre un exemple, mon bot GitHub en Quarkus pour le projet Quarkus (dont je compte parler un de ces jours sur ce site) démarre en 20ms compilé en natif avec GraalVM.

          Et l'implémentation d'une action simple avec le framework Quarkus GitHub App que j'ai développé pour ça est en tout et pour tout :

          class MyGitHubApp {
          
              void onOpen(@Issue.Opened GHEventPayload.Issue issuePayload) throws IOException {
                  issuePayload.getIssue().comment("Hello from MyGitHubApp");
              }
          }

          C'est à dire qu'avec juste cela, tu auras un bot GitHub qui répond aux requêtes et ajoute un commentaire pour tout nouvel issue GitHub créé. Rien besoin d'autre mis à part un fichier de configuration pour les clés de signature. Et l'IOException est là juste à cause de l'API Java GitHub qui devrait virer cette exception dans la prochaine version majeure.

          Le fait qu'on puisse mal bosser en Java ne dit rien sur le langage. Tu peux mal bosser dans tous les langages.

          Bon et puis parfois, ce n'est juste pas le bon langage pour la t√Ęche. Et c'est pas bien grave, utilise autre chose dans ce cas.

        • [^] # Re: Nope

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†8.

          Et pourtant via Java sur Android on a des centaines de milliers d'applications rapides et performantes sur des plateformes embarquées.
          Dans la même veine, quand on paie sans contact avec notre carte bancaire, tu as un système d'exploitation qui démarre, initialise une JVM, et fait tourner du Java(card), le tout en 1 ou 2 secondes, le temps du bip.
          √Ä l'heure o√Ļ les technos web, de plus en plus d√©complex√©es, s'assoient sur une montagne de ressources et o√Ļ on a tendance √† bouder de plus en plus le logiciel applicatif hors navigateur web/electron, je ne m√®nerais pas ma guerre pour l'optimisation √† l'encontre de Java.

    • [^] # Re: Nope

      Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†10.

      Sur quelques points, java a évolué.

      Abus de l'héritage.

      Aujourd'hui on préfère la composition à l'héritage. Les cadriciels d'injection de dépendance encourage cette pratique.

      Abus des getters/setters

      Depuis Java 17, les records permettent de simplifier la syntaxe.

      Lenteur excessive. Les langages interpret√©s c'√©tait bien avant (#boomer). On a des boites √† outils pour faire du natif sans se casser la t√™te (merci LLVM). ‚ÄúJava, write once, run away‚ÄĚ.

      Graalvm permets de compiler une application native. Sur un petit web service migré récemment, j'ai divisé le démarrage par 5 (de 10 à 2 secondes) et la consommation mémoire par 30 (de 300mo à 10mo).

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

      • [^] # Re: Nope

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†4. Derni√®re modification le 11 ao√Ľt 2022 √† 13:22.

        Lenteur excessive. Les langages interpret√©s c'√©tait bien avant (#boomer). On a des boites √† outils pour faire du natif sans se casser la t√™te (merci LLVM). ‚ÄúJava, write once, run away‚ÄĚ.

        Graalvm permets de compiler une application native. Sur un petit web service migré récemment, j'ai divisé le démarrage par 5 (de 10 à 2 secondes) et la consommation mémoire par 30 (de 300mo à 10mo).

        Java est généralement compilé en natif même sans graalvm. Pour le temps de démarrage c'est logique (il y a un travail en cours à OpenJDK pour ça par contre la mémoire c'est surprenant. Graalvm ne fait pas grand chose pour ça, il permet au gc d'être plus rapide mais c'est à peu près tout. C'est pas que la jvm n'était pas tunnée ?

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

    • [^] # Re: Nope

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†8.

      Lenteur excessive

      Même que c'est pour ça que ça n'a jamais été utilisé pour faire des jeux vidéo sur les vieux téléphones… laissez-moi réfléchir… j'ai comme l'impression d'oublier un détail important, la?

      Plus sérieusement, je ne pense pas que Java soit la raison derrière le gouffre en RAM et la faible lenteur.
      J'accuserai plus volontiers des développeurs qui ne se sont pas cassés la tête, parce que "le client rachètera de la RAM au pire" (entendre ça de la part d'un prof, ça fait rêver… et c'était pas sur du java!), parce qu'il faut release rapidement ou autre.
      Ainsi, pour les serveurs, que les admins qui n'ont pas paramétré la JVM selon les besoins de l'application.

      Le java dont je me souviens (je n'ai jamais aimé ce langage) a effectivement des "problèmes" hein:

      • d√©finir la fonction main() comme √©tant une fonction statique d'une classe qui sera instanci√©e qu'une seule fois, parce que seule la POO devrais exister (oupa)
      • des namespace avec une profondeur telle qu'on se demande si a force de creuser on va pas finir en enfer

      Mais globalement, les exceptions bien spécifiées je trouve ça au contraire génial: si C++ avait ça, ben les exceptions je m'en servirais!
      Les getter/setter, j'ai toujours eu ça en horreur, mais c'est pas lié à java, juste a du cargo cult.
      Overengineering? Idem.

      Tous les trucs que je reprochais à Java, je les ai vus dans des codes dans d'autres langages. Tous.
      D'autres langages? Lesquels? C. Et C++.

      Oui, j'inclue le C, parce que j'ai vu des gens réimplémenter l'héritage (c'est pratique faut dire, quand c'est bien utilisé) en C, et en abuser. Les namespaces n'existent pas en C? Pas grave, le workaround c'est des "conventions de nommage" du style un_truc_comme_ca_et_ajoutons_encore_un_peu_de_texte_pour_la_route(). Le truc, c'est que tant C++ que Java permettent de faire du using pour réduire ça. Avec le C, on ne peut pas, on est obligé de recourir à des #define…

      Ah. Le Go et le Rust, c'est mieux. C'est probablement vrai, mais‚Ķ l'astuce, c'est l'√Ęge.
      Rust a été nommé comme ça parce que justement il n'inventait rien, il se base sur ce qui a été fait par les autres langages, et essaie d'en corriger les erreurs.
      En face, C, C++, Java, Pascal… ces langages ont de l'historique. Et, non, faire comme python2 vers python3 n'est pas acceptable pour des langages de leur importance. A titre d'exemple, le programme ppp que l'on utilise pour les liaisons point à point (modems, entres autres, et sisi c'est toujours utilisé) utilise a certains la endroits des résidus de K&R.
      Il arrive que quelques points soient interdits dans des versions plus à jour (auto_ptr pour C++, pour le C les trigrammes sont retirés dans C11 il me semble) mais c'est rare et ne casse pas 90% des bases de code.

      • [^] # Re: Nope

        Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†3.

        Rust a été nommé comme ça parce que justement il n'inventait rien, il se base sur ce qui a été fait par les autres langages, et essaie d'en corriger les erreurs.

        Même si c'est l'explication qu'on trouve sur wikipedia par exemple, ce n'est pas la vraie origine (ceci dit ça a j'imagine aussi été gardé pour le double sens) :

        https://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/

        TL;DR: Rust is named after a fungus that is robust, distributed, and parallel. And, Graydon is a biology nerd.

        (Graydon étant un des créateurs)

  • # Commentaire de jeudredi

    Post√©¬†par¬† . √Čvalu√©¬†√†¬†5. Derni√®re modification le 11 ao√Ľt 2022 √† 15:36.

    Si on a besoin de faire des entrées de blogs pour expliquer qu'un langage ne se porte pas mal, c'est peut-être qu'on est un tout petit peu anxieux aussi, non?

    Si un langage est immensément populaire, j'aurais pensé qu'on n'a pas besoin de le dire, parce que ça se voit tout seul.
    Comme par exemple des devs Java qui recodent des clients de Tribune en langage populaire. Je dis ça, je dis rien (mais je viens de l'écrire quand même!).

    D'ailleurs, StackOverflow avait fait un classement non pas basé sur la demande mais basé sur l'intérêt des codeurs pour le langage qu'ils utilisent:
    the programming languages they use and if they're interested in continuing to develop with them.

    Edit: J'avais oublié l'URL /o\
    https://www.businessinsider.com/stack-overflow-developer-survey-14-most-loved-programming-languages-2020-5?op=1#14-scala-1

    Et Java n'est même pas dans ce classement qui affiche les 14 premiers…

    • [^] # Re: Commentaire de jeudredi

      Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†8. Derni√®re modification le 12 ao√Ľt 2022 √† 09:04.

      Comme par exemple des devs Java qui recodent des clients de Tribune en langage populaire

      Le passage de jb3 à gb3 était logique : Go n'est jamais qu'un Java en moins bloated.

      A propos de langage populaire, personne n'a encore écrit de clients de tribune ou de tribune en Rust, pourtant premier dans le classement de stackoverflow. Parce qu'il n'est pas assez performant ?

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

    • [^] # Re: Commentaire de jeudredi

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†5.

      Il est pas loin derrière C++.

      Après Elixir en 2ème, Clojure en 3ème, Delphi en 7ème, SQL en 9ème, solidity en 15ème (un langage pour ethereum),… Le survey me semble donner avantage à certains langages de relativement de niche. Par contre si on va dans la partie "want" java est 10ème.

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

Suivre le flux des commentaires

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