IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Débats sur le développement - Le Best Of Discussion :

Java 11 : migrer ou changer de langage


Sujet :

Débats sur le développement - Le Best Of

  1. #81
    Membre extrêmement actif Avatar de darklinux
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Novembre 2005
    Messages
    570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2005
    Messages : 570
    Points : 1 023
    Points
    1 023
    Par défaut
    Personnellement et je suis en train de le faire , je préfère écrire en DevOps avec du Java dedans . Je ne veux pas entendre parler de Python sur du code critic , à ce niveau , c 'est soit Java , soit C++ . Je veux même pas entendre parler de Go et d 'autre XUL . Ce n 'est pas standard . Nous sommes censé écrire des logiciels fiable et stable , nous ne sommes pas des hipsters de graphistes , qui ce sont crée ce truc de UX/UI .

  2. #82
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    Citation Envoyé par darklinux Voir le message
    je préfère écrire en DevOps avec du Java dedans . Je ne veux pas entendre parler de Python sur du code critic , à ce niveau , c 'est soit Java , soit C++ . Je veux même pas entendre parler de Go et d 'autre XUL . Ce n 'est pas standard . Nous sommes censé écrire des logiciels fiable et stable , nous ne sommes pas des hipsters de graphistes , qui ce sont crée ce truc de UX/UI .
    C'est pas standard ? Mais tu vis dans quelle galaxie ?

    Docker, Kubernetes, Ansible, Puppet, etc ... Tous ces outils qui composent le coeur de métier des DevOps ils sont écrits en Go, en Python, en Ruby, etc ... Java c'est vraiment le dernier choix possible pour des outils de ce type.

    Java c'est très bien pour faire des trucs qui consomment une tonne de CPU, des Hadoop, des ElasticSearch, etc ... En gros pour tout ce qui pourrait être fait en C/C++ mais que c'est trop cher / pénible.

    Pour tout le reste c'est sorti du range des choix raisonnables dans les organisations qui font une véritable veille techno. Il y a de bien meilleures technos qui scalent point de vue réseau et qui sont moins chères à exploiter.
    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. #83
    Membre habitué

    Femme Profil pro
    Architecte de système d’information
    Inscrit en
    Mai 2015
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d’information
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2015
    Messages : 35
    Points : 170
    Points
    170
    Billets dans le blog
    7
    Par défaut Le meilleur langage de développement est celui qui répond aux besoins et aux contraintes dans un contexte
    Bonjour,

    Pour une entreprise l'informatique n'est pas son métier et bien souvent elle ne possède pas de R&D.
    Par exemple dans le secteur de la banque ou l'assurance, on se réfère à la concurrence et à l'existant.
    Pour les développements spécifiques métier, Java est de loin le langage le plus utilisé, ce qui n'empêche pas d'être en DevOps avec des logiciels réalisés à l'aide de langages plus adaptés.
    Même les progiciels métier sont bien souvent réalisés en Java ainsi que les ERP.

    Maintenant, en mode startup, les références et les contraintes ne sont pas les mêmes.

    Il est vrai qu'en 1995, on pouvait dire la même chose de C/C++/COBOL face à la sortie d'un nouveau langage en l'occurrence Java.
    Rhona Maxwel
    https://www.urbanisation-si.com/

    "Ce n'est pas parce les choses sont difficiles que nous n'osons pas, c'est parce que nous n'osons pas qu'elles sont difficiles." Sénèque

  4. #84
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2017
    Messages
    101
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Février 2017
    Messages : 101
    Points : 656
    Points
    656
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    C'est pas standard ? Mais tu vis dans quelle galaxie ?

    Docker, Kubernetes, Ansible, Puppet, etc ... Tous ces outils qui composent le coeur de métier des DevOps ils sont écrits en Go, en Python, en Ruby, etc ... Java c'est vraiment le dernier choix possible pour des outils de ce type.

    Java c'est très bien pour faire des trucs qui consomment une tonne de CPU, des Hadoop, des ElasticSearch, etc ... En gros pour tout ce qui pourrait être fait en C/C++ mais que c'est trop cher / pénible.

    Pour tout le reste c'est sorti du range des choix raisonnables dans les organisations qui font une véritable veille techno. Il y a de bien meilleures technos qui scalent point de vue réseau et qui sont moins chères à exploiter.
    Que dire que dire.....

    Aller vas-y, je pense que c'est le bon moment pour tout switcher tout tes projets sur Go : https://www.developpez.com/actu/1920...le-classement/
    Citation de l'article : RedMonk explique que « si sa réputation de langage back end est incontestable, il manque à Go la polyvalence des langages comparables comme Java qui lui permettrait d'accéder à de nouveaux marchés et donc à une nouvelle croissance. »

    Du coup par 'pas standard' peut-être entend il pas très répandu/manque de dev formé/ou même langage qui à du mal à prendre ?! (c.f. lien ci-dessus)

    Concernant ceci :
    Java c'est très bien pour faire des trucs qui consomment une tonne de CPU, des Hadoop, des ElasticSearch, etc ... En gros pour tout ce qui pourrait être fait en C/C++ mais que c'est trop cher / pénible.
    Je pense qu'il faut s'abstenir de faire des commentaires assassins surtout quand il sont infondés/non-objectifs/pas étayés ou que les arguments datent d'il y a 25 ans (lourdeur à l'exécution)...

    Et pour ceci :
    Pour tout le reste c'est sorti du range des choix raisonnables dans les organisations qui font une véritable veille techno. Il y a de bien meilleures technos qui scalent point de vue réseau et qui sont moins chères à exploiter.
    Honnêtement ça ne veut pas dire grand chose.. Choix raisonnable ?! Développeurs compétents sur le marché? technologie qui répond aux besoins du projet ? Etc, etc. Il y a beaucoup d'aspect à prendre en compte pour le choix d'une techno.
    Il ne faut pas juste encourager un nouveau langage parce que c'est le buzz du moment et basher un autre parce qu'on ne l'aime pas (surtout quand on ne la connais pas..)

    Enfin bref, c'est pas le premier poste assassins vide de sens sur Java que je vois de ta part. C'est clair que Java à des défauts. Comme tout les langages j'ai envie de dire.
    Perso j’attends à un peu plus de maturité de la part d'un modérateur...

    Sur ce, bonne journée.

  5. #85
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    Citation Envoyé par GordonFreeman Voir le message
    Que dire que dire.....

    Du coup par 'pas standard' peut-être entend il pas très répandu/manque de dev formé/ou même langage qui à du mal à prendre ?! (c.f. lien ci-dessus)
    Ta remarque est hors sujet. darklinux parlait de l'écriture d'outils pour des tâches DevOps, pas de réaliser du développement classique de gestion. Dans ce cas de figure, ne t'en déplaise, le standard c'est des langages comme Go, Python, Rails, ... Et certainement pas Java.

    Je t'invite à aller regarder dans quels langages sont écrits les outils utilisés par les DevOps si tu veux en avoir le coeur net.

    Citation Envoyé par GordonFreeman Voir le message
    Concernant ceci :
    Java c'est très bien pour faire des trucs qui consomment une tonne de CPU, des Hadoop, des ElasticSearch, etc ... En gros pour tout ce qui pourrait être fait en C/C++ mais que c'est trop cher / pénible.
    Je pense qu'il faut s'abstenir de faire des commentaires assassins surtout quand il sont infondés/non-objectifs/pas étayés ou que les arguments datent d'il y a 25 ans (lourdeur à l'exécution)...
    Tu m'as mal compris. Tu as pris mon commentaire comme étant ironique alors que non il faut le prendre littéralement. Java est bon langage quand on a besoin d'implémenter des traitements qui réalisent beaucoup de calculs, donc qui consomment beaucoup de CPU. Donc ce que je dis c'est que Java est rapide à l'exécution, tout autant que C/C++ et que donc il n'y a aucune raison de s'embêter avec du C/C++ quand on peut faire avec du Java.

    Citation Envoyé par GordonFreeman Voir le message
    Pour tout le reste c'est sorti du range des choix raisonnables dans les organisations qui font une véritable veille techno. Il y a de bien meilleures technos qui scalent point de vue réseau et qui sont moins chères à exploiter.

    [...]

    Il ne faut pas juste encourager un nouveau langage parce que c'est le buzz du moment et basher un autre parce qu'on ne l'aime pas (surtout quand on ne la connais pas..)
    C'est pas une histoire de buzz mais de fait. La norme aujourd'hui c'est de développer des applis sur http, et pour ça le Java c'est un choix dégueulasse. Je t'invite à t'interroger sur pourquoi la totalité du Fortune 500 a migré ses applis web de whatever vers Node.js. Ça c'est un fait avéré. C'est pas du buzz. Je ne prendrais même pas la peine de te linker un lien tellement c'est facile de trouver des liens sur ce sujet, que ce soit des stats ou des comptes rendus de migration. Le problème c'est que les Javaïstes français ne font pas leur veille techno en dehors du monde Java, et donc ils sont dans le déni.

    Citation Envoyé par GordonFreeman Voir le message
    Enfin bref, c'est pas le premier poste assassins vide de sens sur Java que je vois de ta part. C'est clair que Java à des défauts. Comme tout les langages j'ai envie de dire.
    C'est pas la première fois qu'un Javaiste français rage parce qu'il refuse de voir que son langage chéri est sur le déclin.

    Citation Envoyé par GordonFreeman Voir le message
    Perso j’attends à un peu plus de maturité de la part d'un modérateur...
    Parce que je suis modérateur je n'aurais pas le droit d'énoncer des faits avérés qui battent en brèche ta vision obsolète de l'industrie ?

    C'est pas la première fois qu'on me fait cette remarque et ça commence à sérieusement me courir que lorsque quelqu'un n'est pas d'accord avec moi il me jette à la figure cet argument : "ouin t'es modo t'as pas le droit de pas être d'accord avec moi ouin". Et c'est moi qui manque de maturité ...
    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

  6. #86
    Membre émérite
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Inscrit en
    Juillet 2008
    Messages
    1 468
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 468
    Points : 2 996
    Points
    2 996
    Par défaut
    Je t'invite à t'interroger sur pourquoi la totalité du Fortune 500 a migré ses applis web de whatever vers Node.js.
    En pratique, bien que les front-ends passent de plus en plus en Node.js plutot qu'en Java EE/Web, Java garde une belle part de marche chez justement pas mal de boites, comme on peut le voir sur https://stackshare.io/stacks#! . En fait, avec l'approche microservices et les VM et les frameworks qui s'adaptent tres bien, Java est en fait en techno plutot bien placee -performante, robuste, bien outillee, bien polyvalente- sur les architectures de ce genre (ce qui est pas etonnant parce que toute la recherche sur la SOA de 2010 se faisaient deja sur Java).
    Donc on parle de migrer a ci ou ca, mais en realite ce n'est pas un abandon de Java, mais une diversification. Les boites diversifient les stacks technos pour s'assurer plus de perenite et une certaine agilite technique/organisationnelle/RH... Tout miser sur une techno, c'est un risque fort, et Java avait amene ces grosses boites dans cette zone de risque. L'arrivee de Node.js et l'amelioration de l'ecosysteme JavaScript leur permettent d'eviter de mettre tous leurs oeufs dans le meme panier. Et du coup je pense que dans la plupart des cas, l'adoption de Node.js traduit plutot cette volonte de ne pas laisser trop de place a une techno plutot qu'un choix ideologique ou technologique. Et qu'ainsi, Java restere perenne un bon moment.
    Pour du HTML, CSS, JavaScript, TypeScript, JSon, Yaml, Node... dans Eclipse IDE, installe Eclipse Wild Web Developer
    Pour du Rust dans Eclipse IDE, installe Eclipse Corrosion
    Follow me on twitter

  7. #87
    Rédacteur

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    Juillet 2005
    Messages
    14 974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : Juillet 2005
    Messages : 14 974
    Points : 73 024
    Points
    73 024
    Par défaut
    Le problème c'est que les Javaïstes français ne font pas leur veille techno en dehors du monde Java, et donc ils sont dans le déni.
    Aie...

    C'est pas la première fois qu'un Javaiste français rage parce qu'il refuse de voir que son langage chéri est sur le déclin.
    Double Aie...

    Si un jour je démissionne de la rubrique Java, vous aurez compris que Java n'est plus mon langage chéri ;-) En y réfléchissant, il faudrait peut être que j'arrête de contribuer sur autres rubriques

    Mickael
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de Developpez.com : mbaron.developpez.com
    Twitter : www.twitter.com/mickaelbaron
    Blog : mickael-baron.fr
    LinkedIn : www.linkedin.com/in/mickaelbaron
    DBLP : dblp.uni-trier.de/pers/hd/b/Baron:Micka=euml=l

  8. #88
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2017
    Messages
    101
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Février 2017
    Messages : 101
    Points : 656
    Points
    656
    Par défaut PAs facile tous les jours...
    Citation Envoyé par Marco46 Voir le message
    Ta remarque est hors sujet. darklinux parlait de l'écriture d'outils pour des tâches DevOps, pas de réaliser du développement classique de gestion. Dans ce cas de figure, ne t'en déplaise, le standard c'est des langages comme Go, Python, Rails, ... Et certainement pas Java.

    Je t'invite à aller regarder dans quels langages sont écrits les outils utilisés par les DevOps si tu veux en avoir le coeur net.
    Alors moi je n'ai pas compris la phrase de Daklinux comme toi : Personnellement et je suis en train de le faire , je préfère écrire en DevOps avec du Java dedans
    Vu le sujet du topic et la formulation j'ai plutôt compris qu'il préfère coder en Java en utilisant des outils DevOps. Donc partant de la... Mais bon passons, c'est pas super clair comme formulation.

    Citation Envoyé par Marco46 Voir le message
    Je t'invite à aller regarder dans quels langages sont écrits les outils utilisés par les DevOps si tu veux en avoir le coeur net.
    Oui alors je suis allé voir. En effet ceux que tu cite sont écrit en Go ou Python. Mais en même temps tu en cites 4 sur des dizaines et des dizaines, ce n'est donc pas très relevant.. Le pire, il y en à même écrit en Java
    https://dzone.com/articles/devops-to...us-integration
    https://www.guru99.com/devops-tools.html

    Citation Envoyé par Marco46 Voir le message
    La norme aujourd'hui c'est de développer des applis sur http, et pour ça le Java c'est un choix dégueulasse
    Aujourd'hui... Je dirait que ça fait en tout cas 10 ans que c'est la norme, et Java à toujours été fortement présent dans le credo des applis web d'entreprise...

    Enfin bref je vais pas m'amuser à répondre à tous les points. Le sujet parle de Java. Toi tu viens parler de Go et Python, après tu me parle des Fortune 500 qui ont migré sous Node.js ?! (le rapport avec le sujet ?)

    Quand je dit : Enfin bref, c'est pas le premier poste assassins vide de sens sur Java que je vois de ta part. C'est clair que Java à des défauts. Comme tout les langages j'ai envie de dire.
    Je te disais juste qu'il serait bien d'étayer un peu tes affirmation plutôt que d'affirmer simplement des choses à l'emporte pièce.

    Citation Envoyé par Marco46 Voir le message
    C'est pas la première fois qu'un Javaiste français rage parce qu'il refuse de voir que son langage chéri est sur le déclin.
    Encore une fois appuie tes propos! Ça sort du cul du chat ton affirmation la ou-bien ?!
    -> Je te reposte donc le lien https://www.developpez.com/actu/1920...le-classement/

    Citation Envoyé par Marco46 Voir le message
    Parce que je suis modérateur je n'aurais pas le droit d'énoncer des faits avérés qui battent en brèche ta vision obsolète de l'industrie ?

    C'est pas la première fois qu'on me fait cette remarque et ça commence à sérieusement me courir que lorsque quelqu'un n'est pas d'accord avec moi il me jette à la figure cet argument : "ouin t'es modo t'as pas le droit de pas être d'accord avec moi ouin". Et c'est moi qui manque de maturité ...
    Bien sur que si tu as le droit de donner ton avis en tant que modo. Mais ne soit pas agressif, je ne l'ai pas été.
    Encore une fois affirmer que c'est des faits avérés (pour reprendre tes dires) ne prouve rien. et de citer que tel ou tel boite à migrer vers telle ou telle techno non plus..

    Perso tu sais, je m'en fout un peu royalement. J'ai fait bcp de C, PHP, C#, du JS et mnt du JAva qui me convient bien et évolue de manière toujours très intéressante à mon sens. Et ça me va bien!

    Si c'est pas la première fois qu'on te dis ça :C'est pas la première fois qu'on me fait cette remarque .... il y a peu être une raison ?! Je dis ça je dis rien hein

    Voilà, je pense pas que cette discussion nous mènera quelque part et on pollue le sujet donc je m'arrêterai là...

    Sur ce, bonne soirée et Joyeux Noël

  9. #89
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    Java c'est très bien pour faire des trucs qui consomment une tonne de CPU, des Hadoop, des ElasticSearch, etc ... En gros pour tout ce qui pourrait être fait en C/C++ mais que c'est trop cher / pénible.
    Citation Envoyé par Marco46 Voir le message
    Donc ce que je dis c'est que Java est rapide à l'exécution, tout autant que C/C++ et que donc il n'y a aucune raison de s'embêter avec du C/C++ quand on peut faire avec du Java.
    De nos jours, Java fait effectivement partie des langages performants, non seulement car il est plus rapide qu'avant et car des langages lents comme Python progressent.
    Mais il ne faut pas non plus mettre Java dans le même panier que C et C++. Java reste un langage avec ramasse-miettes obligatoire.

  10. #90
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    De nos jours, Java fait effectivement partie des langages performants, non seulement car il est plus rapide qu'avant et car des langages lents comme Python progressent.
    Mais il ne faut pas non plus mettre Java dans le même panier que C et C++. Java reste un langage avec ramasse-miettes obligatoire.
    Ces histoires de performances, ça me fait toujours ricaner. La qualité des algorithmes et de la programmation comptent bien plus.

    Allez, anecdote. à la fin des années 2000, un grand compte a voulu virer toute son info COBOL et la remplacer par du JAVA. Y compris les gros batches de fin d'année. Ils ont abandonné le projet après 100M€ de dépenses. La goutte d'eau qui a fait déborder le vase? Un traitement batch de fin d'année qui passait en 6 heures coté COBOL pour 95% de la volumétrie...et en une semaine en JAVA sur les 5% restants. COBOL est certes particulièrement performant pour ce genre de traitements, mais on ne me fera pas croire que le code JAVA était optimisé. un rapport de performances de 1 à 4 ne m'aurait pas surpris, mais un rapport de 1 à 532(19 fois plus de traitements en 28 fois moins de temps)?

    Je suis sur que fait en Python par des gens compétents, ça aurait été plus vite que ça.

    Simplement, moi qui vient du COBOL et ait appris l'objet sur le tard, je constate qu'il est tentant de faire des accesseurs "riches" en langage objet, parce-que c'est beau et pratique, alors qu'en procédural, on doit tout refaire à chaque fois..... et il est plus facile, cognitivement parlant, de se contenter du strict minimum. La vraie lenteur du JAVA, elle est là, à mon sens : la manière la plus naturelle de faire n'est pas la plus performante. Même si le langage est réellement performant(et il l'est), si le programmeur moyen trouve plus simple de faire des trucs propres qui se répètent sans cesse, et ne se fait pas chier à optimiser ses accesseurs, on se retrouve avec des horreurs d'une lenteur insupportable. Genre mon exemple du dessus, qui fait partie de la légende noire des mauvaises performances du JAVA. Légende pas totalement méritée, évidemment, mais pas non plus dénuée de sens.

    Passer du JAVA au C/C++ pour améliorer les performances n'a de sens que si on a des programmeurs au dessus de la moyenne. Des moyens feront de la merde ultralente en JAVA, mais ils finiront le projet, ils ne seront même pas capables de finir le projet en C/C++. Et, par définition, la majorité des boites n'a pas de programmeurs au dessus de la moyenne. Et celles qui en ont auront des performances déjà bonnes en java. Certes encore optimisables, mais est-ce que le jeu en vaut la chandelle?
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  11. #91
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Simplement, moi qui vient du COBOL et ait appris l'objet sur le tard, je constate qu'il est tentant de faire des accesseurs "riches" en langage objet, parce-que c'est beau et pratique, alors qu'en procédural, on doit tout refaire à chaque fois.....
    Qu'appelles-tu des accesseurs "riches" ? Pourrais-tu développer ce point avec un ou plusieurs exemples ?

  12. #92
    Membre confirmé
    Inscrit en
    Mai 2007
    Messages
    335
    Détails du profil
    Informations forums :
    Inscription : Mai 2007
    Messages : 335
    Points : 511
    Points
    511
    Par défaut
    Citation Envoyé par Mickael Baron Voir le message
    Oui je pense, comme il existe encore des projets en Cobol

    Mickael
    <troll>
    Mais est-ce qu'il existe des projets Cobol avec du corba et du rmi?
    </troll>
    <!Meta name="désolé"/>

  13. #93
    Membre confirmé
    Inscrit en
    Mai 2007
    Messages
    335
    Détails du profil
    Informations forums :
    Inscription : Mai 2007
    Messages : 335
    Points : 511
    Points
    511
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Ces histoires de performances, ça me fait toujours ricaner. La qualité des algorithmes et de la programmation comptent bien plus.
    [...]
    Passer du JAVA au C/C++ pour améliorer les performances n'a de sens que si on a des programmeurs au dessus de la moyenne. Des moyens feront de la merde ultralente en JAVA, mais ils finiront le projet, ils ne seront même pas capables de finir le projet en C/C++. Et, par définition, la majorité des boites n'a pas de programmeurs au dessus de la moyenne. Et celles qui en ont auront des performances déjà bonnes en java. Certes encore optimisables, mais est-ce que le jeu en vaut la chandelle?
    Oui sur la majorité des projets la rapidité n'est pas l'essentiel (tant que c'est pas la cata, on va pas revenir à du BASIC hein) . Pour faire simple, la plupart des problèmes de perfs viennent de mauvaises requetes SQL, éventuellement de dead lock ou de live lock. Et ça quel que soit le langage ...

    Le choix va se faire sur la facilité de prise en compte du langage, et sur la richesse de l'api et des lib. La fiabilité, la maintenabilité.

    J'en profite pour rebondir sur les dérivés du Java: Kotlin, Scala, Xtend, Ceylon : Ils ont en communs de pouvoir attaquer les API java donc être compatible avec les libs Java, mais ils ont de toutes façon besoin du runtime jvm Java, ce qui décale le problème de licence.

  14. #94
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Qu'appelles-tu des accesseurs "riches" ? Pourrais-tu développer ce point avec un ou plusieurs exemples ?
    Ben, dans une classe, on peut mettre pas mal de chose sur les getters/setters des données. Par exemple, sur une donnée "numéro de RIB", tu peux faire un getter qui te renvoir la clef RIB calculée sans jamais avoir à la stocker. Avantage : c'est plus beau, et on ne se trimballe pas des clefs RIB partout(problème de sécurité). Inconvénient : si on a besoin de 20 fois la clef RIB, on la recalcule 20 fois.

    Je ne dis pas que de bons développeurs JAVA feraient l'erreur, hein, et j'ose penser que les JAVAistes qui nous lisent sont au dessus de la moyenne. Et qu'ils ne feraient pas ce genre d'abomination.

    Autre exemple. Authentique. Une société appartenant à une SSII édite un progiciel qui permet soi-disant à des "non informaticiens" de transformer des données métier suivant des règles simples(je reste flou pour ne pas dévoiler de qui il s'agit). En gros, on définit des formats(genre numérique sur 3 ou alpha sur 7), on définit des données d'entrée et de sortie(chacune ayant son propre format), on définit des structures(ou on peut réutiliser les données définies), et on définit des structures de structures. Et on définit aussi des transformations(MTTVA = MTHT*TXTVA et MTTOTAL=MTHT+MTTVA, par exemple). Un client se plaint qu'il n'existe pas de fonction qui permet de copier-coller des structures de structures, et que faire 200 copier-coller à la main, c'est casse-bonbons. On charge donc un stagiaire(pas moi) de créer un "super copier-coller". Celui-ci fait une méthode qui copie-colle un format, incluant un code qui vérifie que le format est valide. Puis une méthode qui copie-colle la donnée, et qui vérifie que la donnée est valide. Il copie aussi le format, en dé-doublonnant si ça existe déjà, mais revérifie à chaque fois que la structure est valide. Etc à chaque niveau. Si le format numérique sur 1 est utilisé 4000 fois, alors le format sera validé 4000 fois. Résultat : le super-copier coller prend plusieurs heures à s'exécuter.

    Pour ce qui est de la remarque de deltree : oui, les accès base comptent aussi, et parfois fortement. Mais c'est aussi une question de culture. En COBOL, pour faire un batch de masse, on attend la nuit quand les gens qui utilisent les transactions dorment, on décharge la base dans un fichier plat, on traite le fichier plat, et on recharge la base une fois le traitement terminé. Les bourrins vont même faire un drop de table puis la recréer avec les nouvelles données(avec les indexations, et tout). Ca a plein d'inconvénients, le code est moche, nettement plus compliqué qu'un UPDATE futé(surtout si on décharge quelques bases d'un coup, ça fait 4 à 5 fichiers à trier et lire en même temps pour les rapprocher) - mais les soucis que deltree cite sont impossibles. Il n'y a pas de lock sur un fichier plat. Et les soucis de performances sont beaucoup plus rares.

    Donc un bon choix dépendra aussi de la volumétrie que l'on a. Quand on a des millions de clients avec des produits financiers complexes, prendre le langage le plus maintenable peut être risqué. COBOL, c'est lourdingue, c'est répétitif, c'est verbeux, c'est moche, c'est vieux, mais c'est fiable et surtout très performant - même quand codé par des gnous. Et oui, il y a encore des projets en COBOL. Je n'en fait plus, mais j'ai été chassé il y a un an pour revenir dessus. Ca n'a rien d'aberrant. C'est un langage de niche qui correspond à certaines configurations très particulières(en gros du traitement de masse de données de masse de type comptable ou ressemblant). Plus personne ne l'utilise pour le temps réel, ou presque, d'ailleurs, ni pour des algos compliqués, et ça n'a rien d'aberrant non plus - trop d'inconvénients, pas assez d'avantages. Mais pour du traitement de masse avec une myriade de règles métier et des masses massives de données comptables et assimilées, ça reste pertinent, même en 2018.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  15. #95
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2017
    Messages
    101
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Février 2017
    Messages : 101
    Points : 656
    Points
    656
    Par défaut Le bien ... Le mal ^^
    Citation Envoyé par el_slapper Voir le message
    Ben, dans une classe, on peut mettre pas mal de chose sur les getters/setters des données. Par exemple, sur une donnée "numéro de RIB", tu peux faire un getter qui te renvoir la clef RIB calculée sans jamais avoir à la stocker. Avantage : c'est plus beau, et on ne se trimballe pas des clefs RIB partout(problème de sécurité). Inconvénient : si on a besoin de 20 fois la clef RIB, on la recalcule 20 fois.
    Bonjour,
    Oui effectivement on peut le faire... En fait, en prog on peut à peu près tout faire dans les limites du compilo. Cela ne veut pas dire qu'on doit le faire
    Dans les conventions (et à mon sens), un getter et un setter ne doivent que définir la valeur d'un attribut ou retourner sa valeur et en aucun cas réaliser une autre opération.

    Le cas du numéro RIB est un bon exemple (je ne sais pas ce qu'est un RIB mais je comprend que sa se détermine à l'aide plusieurs infos);
    A mon avis, la méthode ne devrait pas s’appeler getRib() si l'objet ne possède pas de propriété rib. Elle devrait s'appeler generateRib(), computeRib() ou un autre truc du genre. L'important est qu'on sente que c'est quelque chose de déterminé par calcul.

    Mais cet avis n'engage que moi hein

  16. #96
    Membre confirmé
    Inscrit en
    Mai 2007
    Messages
    335
    Détails du profil
    Informations forums :
    Inscription : Mai 2007
    Messages : 335
    Points : 511
    Points
    511
    Par défaut
    Citation Envoyé par GordonFreeman Voir le message
    Bonjour,
    Oui effectivement on peut le faire... En fait, en prog on peut à peu près tout faire dans les limites du compilo. Cela ne veut pas dire qu'on doit le faire
    Dans les conventions (et à mon sens), un getter et un setter ne doivent que définir la valeur d'un attribut ou retourner sa valeur et en aucun cas réaliser une autre opération.

    Le cas du numéro RIB est un bon exemple (je ne sais pas ce qu'est un RIB mais je comprend que sa se détermine à l'aide plusieurs infos);
    A mon avis, la méthode ne devrait pas s’appeler getRib() si l'objet ne possède pas de propriété rib. Elle devrait s'appeler generateRib(), computeRib() ou un autre truc du genre. L'important est qu'on sente que c'est quelque chose de déterminé par calcul.

    Mais cet avis n'engage que moi hein
    Non, pas de getter pour les champs calculés je suis assez d'accord, puisqu'on parle de Java autant parler aussi de framework d'introspection massive: Jackson, Spring, Jaxb, Hibernate, j'en passe et de meilleures, il vont vont taper sur ton getter et te générer un tag ou autre alors que tu n'as rien demandé, ce qui t'oblige à annoter @JsonIgnore par exemple pour jackson.


    Les getter/setter ça a toujours été con d'ailleurs (avis personnel) on aurais du avoir des properties depuis le début comme ça existait déjà dans des tas de langages. Au final ça fait la même chose, mais ça aurait été prévu par le langage au lieu que chaque framework se fasse sa sauce: cad je prends les privés, ou je prends les méthodes, ou je prend les 2, bon c'est configurable ceci dit.

  17. #97
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    @el_slapper :

    Merci pour les précisions.

    Dans ton exemple de la clef RIB, je comprends le rapport entre l'encapsulation et les problèmes de performance : l'encapsulation encourage à transformer l'objet en boîte noire dont on cache le coût des opérations, par exemple un accesseur getRib() qui recalcule le RIB.

    Par contre, dans ton deuxième exemple avec le contrôle sur la validité d'un certain format, je ne vois pas en quoi l'encapsulation inciterait à répéter les mêmes contrôles. Au contraire, l'encapsulation favorise l'écriture d'un code dans lequel on évite de répéter plusieurs fois les mêmes contrôles.

    Par exemple, admettons que l'on ait une chaîne de caractères qui représente un code utilisateur et qu'il existe une fonction matchesUserCodeFormat qui prend en paramètre une chaîne et retourne un booléen. Pour éviter d'appeler cette fonction plein de fois sur la même chaîne, une solution consiste à créer une classe UserCode qui encapsule la chaîne en question. Alors, on fait un contrôle lors de la conversion d'une chaîne en UserCode. Ensuite, on peut manipuler un objet de type UserCode sur lequel il n'y a plus besoin de faire ce contrôle.
    C'est grâce à l'encapsulation que l'on n'a plus besoin de refaire ce contrôle : la chaîne encapsulée est privée, donc aucun code extérieur à la classe UserCode ne peut casser directement cette chaîne.

    De manière générale, quand un ensemble de données doit respecter des invariants, c'est un signe très fort qu'il faut encapsuler ces données dans une classe. Sans encapsulation, il faut soit répéter les contrôles, soit prier que les invariants soient respectés.

  18. #98
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2017
    Messages
    101
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Février 2017
    Messages : 101
    Points : 656
    Points
    656
    Par défaut
    Citation Envoyé par deltree Voir le message
    Non, pas de getter pour les champs calculés je suis assez d'accord, puisqu'on parle de Java autant parler aussi de framework d'introspection massive: Jackson, Spring, Jaxb, Hibernate, j'en passe et de meilleures, il vont vont taper sur ton getter et te générer un tag ou autre alors que tu n'as rien demandé, ce qui t'oblige à annoter @JsonIgnore par exemple pour jackson.


    Les getter/setter ça a toujours été con d'ailleurs (avis personnel) on aurais du avoir des properties depuis le début comme ça existait déjà dans des tas de langages. Au final ça fait la même chose, mais ça aurait été prévu par le langage au lieu que chaque framework se fasse sa sauce: cad je prends les privés, ou je prends les méthodes, ou je prend les 2, bon c'est configurable ceci dit.
    Je ne comprend pas la première partie de ton message sur les framework qui font 'de l'introspection massive' ... Ils n'ont pas vraiment le choix pour aller lire les annotations présentes sur les classes. De plus il n'y a pas forcément de lien avec les getters/setters

    Hibernate s'occupe des entités que tu a explicitement annotés via les annotations javax.persistence. ou hibernate.
    Jackson / JAxB sont des api de sérialisation Json/XML, il est donc clair que tes objets doivent être lu d'une manière ou d'une autre pour être représenté en XML ou autre.
    Spring idem mais sur des annotations qui ont été définie explicitement ( enfin, faut encore voir de quel partie des tools Spring on parle)


    Ce qui m'embête dans ta réponse, c'est le 'alors que tu n'as rien demandé'. Si tu utilise ces API/framework, il faut quand même connaitre leurs façon de travailler et la manière de les utiliser.
    Pour moi rien de choquant, ou alors j'ai loupé un truc ?

    Concernant les properties (comme en C# p. ex.), personnellement je suis contre (encore plus depuis que j'ai du les utiliser).
    La raison est simple, avec les properties on ne sait pas si on tape sur un champ public (le mal) ou sur un getter (ex nomObjet.nom).
    A mon sens c'est un sucre syntaxique qui amène de l’ambiguïté plus qu'autre chose.

    Et si vraiment faire générer les getter/setter par ton EDI est encore trop chiant, il y a des outils comme 'Lombok' (je ne suis pas fan non plus) qui vont te générer automatiquement tout tes getter et tes setters.

    M'enfin petite parenthèse hein

  19. #99
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    (.../...)Par contre, dans ton deuxième exemple avec le contrôle sur la validité d'un certain format, je ne vois pas en quoi l'encapsulation inciterait à répéter les mêmes contrôles. Au contraire, l'encapsulation favorise l'écriture d'un code dans lequel on évite de répéter plusieurs fois les mêmes contrôles.(.../...)
    Oui, mais ça ça suppose une certaine qualité du programmeur. Un programmeur basique qui fait du procédural, il va bêtement vérifier tous les formats, puis toutes les donnes, puis......... Moche, mais ça marche. Un bête programmeur en objet, lui va pondre des horreurs.

    Dit encore autrement, si toi bon programmeur(pour perdre son temps sur un forum comme DVP, il faut aimer son boulot, et la plupart de ceux qui aiment leur boulot sont bons - donc j'assume que tu est supérieur à la moyenne) tu feras mieux en objet qu'en procédural, il n'en va pas forcément de même pour le drone moyen qui a fait une école d'info parce-que c'est porteur, qui saura se dépatouiller d'un fizzbuzz parce-qu'il n'est pas nul, mais ne sera pas capable de penser son code dans son intégralité. Pour arriver au niveau d'analyse que tu nous propose, il faut des qualités cognitives(et l'envie de les utiliser) que nombre de collègues n'ont pas. C'est dans ce cadre que je propose mon analyse, pas en partant du principe que tous les programmeurs sont bons. L'expérience montre que non, tous les programmeurs ne se valent pas.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  20. #100
    Expert confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Novembre 2009
    Messages
    2 004
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Novembre 2009
    Messages : 2 004
    Points : 5 423
    Points
    5 423
    Par défaut
    Citation Envoyé par GordonFreeman Voir le message
    Concernant les properties (comme en C# p. ex.), personnellement je suis contre (encore plus depuis que j'ai du les utiliser).
    La raison est simple, avec les properties on ne sait pas si on tape sur un champ public (le mal) ou sur un getter (ex nomObjet.nom).
    A mon sens c'est un sucre syntaxique qui amène de l’ambiguïté plus qu'autre chose.
    En fait il n'y a pas de confusion si on respecte la norme en c#.
    Un champ public ne devrait pas exister, il faut toujours créer une propriété (avec une majuscule nomObjet.Nom). D'ailleurs sous visual studio le snippet prop ou propfull est bien pratique.
    Si le langage autorise les champs en public c'est certainement pour des cas bien particuliers où tu as un besoin de performance (la propriété est forcement un peu plus lourde) et que tu es certain que l'accès ou l'affectation de ton champ n'entrainera jamais de traitement.
    Mais quand bien même la norme n'est pas respectée, qu'est-ce qui te chagrine dans le fait de ne pas savoir si c'est un champ ou une propriété?

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. changer le langage sur excel
    Par kaquelle dans le forum Excel
    Réponses: 4
    Dernier message: 06/04/2011, 12h30
  2. Changer de langage, vos avis sur ce cas ?
    Par bewidia dans le forum Langages de programmation
    Réponses: 0
    Dernier message: 30/10/2009, 18h39
  3. Java modifié sera-t-il le langage de référence et le meilleur ?
    Par Orvinfait dans le forum Général Java
    Réponses: 7
    Dernier message: 04/10/2009, 23h01
  4. Changer le langage utilisé pour le projet
    Par Thierry Chappuis dans le forum Code::Blocks
    Réponses: 4
    Dernier message: 23/04/2007, 13h23
  5. Changer de langage, mais pour lequel ?
    Par reptils dans le forum Langages de programmation
    Réponses: 5
    Dernier message: 02/02/2006, 17h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo