Version imprimable
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 .
C'est pas standard ? 8O Mais tu vis dans quelle galaxie ? :weird:Citation:
Envoyé par darklinux
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.
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.
Que dire que dire.....Citation:
Envoyé par Marco46
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.
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.Citation:
Envoyé par GordonFreeman
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.
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
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
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
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 ?Citation:
Envoyé par GordonFreeman
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é ...
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).Citation:
Je t'invite à t'interroger sur pourquoi la totalité du Fortune 500 a migré ses applis web de whatever vers Node.js.
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.
Aie...Citation:
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.
Double Aie...Citation:
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.
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
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 dedansCitation:
Envoyé par Marco46
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.
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 :roll:Citation:
Envoyé par Marco46
https://dzone.com/articles/devops-to...us-integration
https://www.guru99.com/devops-tools.html
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...Citation:
Envoyé par Marco46
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.
Encore une fois appuie tes propos! Ça sort du cul du chat ton affirmation la ou-bien ?!Citation:
Envoyé par Marco46
-> Je te reposte donc le lien https://www.developpez.com/actu/1920...le-classement/
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é.Citation:
Envoyé par Marco46
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 :aie:
Citation:
Envoyé par Marco46
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.Citation:
Envoyé par Marco46
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.Citation:
Envoyé par Pyramidev
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?
Qu'appelles-tu des accesseurs "riches" ? Pourrais-tu développer ce point avec un ou plusieurs exemples ?Citation:
Envoyé par el_slapper
<troll>Citation:
Envoyé par Mickael Baron
Mais est-ce qu'il existe des projets Cobol avec du corba et du rmi?
</troll>
<!Meta name="désolé"/>
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 ...Citation:
Envoyé par el_slapper
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.
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.Citation:
Envoyé par Pyramidev
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.
Bonjour,Citation:
Envoyé par el_slapper
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.Citation:
Envoyé par GordonFreeman
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.
@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.
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/settersCitation:
Envoyé par deltree
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 ;)
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.Citation:
Envoyé par Pyramidev
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.
En fait il n'y a pas de confusion si on respecte la norme en c#.Citation:
Envoyé par GordonFreeman
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é?