• # 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

    AI is a mental disorder

    • [^] # 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.

        AI is a mental disorder

        • [^] # 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.

          Merci de prendre le commentaire ci-dessus avec: un peu de recul, le premier degré, et si possible le second !

          • [^] # 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 - https://github.com/link-society/flowg

            • [^] # 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 . É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).

      Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board

      • [^] # 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 ?

      Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board

    • [^] # 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.