Reprise du message précédent :
https://pbs.twimg.com/media/DXOv_OmW4AADQY7.jpg  

 
called it!  
 
heureusement que je facture au temps

J’tai envoyé une facture pour me détendre

vous connaissez Idiocracy ?  
 
Donc apparemment le Bachelor local a foutu en cloque une nana pendant l'émission
 

Moi rien compris quoi toi parler

Bachelor c’est une émission de télé réalité à la con. Mais ça existe aussi en France il me semble.

Oui et donc le mec pendant l'émission il a mis en cloque une des nanas ?

Oui

c'est interdit ?  

Disons que l’idée de diffuser une émission où un mec baise 20 nanas en met une en cloque, file une bague à une autre, gagne des dizaines k$ pour et devient un hero populaire, ça viole peut-être aucune loi, mais ça sent pas le nivellement par le haut.

 
Java est un langage qui est vieux. Comme l'ont dit les autres, il va évidemment souffrir de la comparaison avec des langages plus récents (Rust, Kotlin, ...). Je pense qu'on est d'accord sur ce constat.
Par contre dire qu'il vieillit mal c'est faux. En gardant les contraintes de compatibilité avec l'existant ET les autres langages de la JVM, Java fait un excellent job pour intégrer des nouveautés et gagner en expressivité.
 
Il faut noter aussi que pendant longtemps, le process de release de Java a été d'une lenteur extrême et que ça a fini par devenir intenable (Jigsaw a mis en lumière ce problème) et que ça a retardé pas mal de bonnes choses. Le rythme va rapidement s'intensifier. Alors que Java 8 est loin d'être adopté partout, il y a Java 10 qui va pointer le bout de son nez.

https://uproxx.com/movies/what-was- [...] f-the-jedi

 
 
Tout fou l'camp dans cette jeunesse.  

Je pense quand même que les langages « modernes » n’apportent pas grand chose par rapport à ocaml, et Lang et leur potes.

 
Gelatine me fait penser à un candidat reçu récemment.
 
Qui nous sort en entretien que "oui, je veux plus faire de projets en Java, parce que bon, c'est dépassé quand même, c'est plus vraiment adapté aux problématiques qu'on a aujourd'hui"
 
Selon moi, il n'a rien compris : un langage c'est un outil, qui a des capacités propres. Si on essaie de l'utiliser pour faire un truc qu'il ne sait pas faire, généralement c'est du bricolage.
 
Java est un outils très polyvalent : on peut presque tout faire avec : forcément, ça vient avec des compromis.
 
L'approche qui consiste à avoir un outil ultra spécialisé et donc ultra performant/utilisable/agréable pour chaque type de tâche, pourquoi pas, mais c'est overkill dans 80% des cas, comme tout
 
Ensuite, sur la durée de vie et l'avenir... Disons que quand on entend les fans de JS qui il y a 3 ans reprochaient à Java d'être compilé, trouver absolument génial de transpiler du TypeScript, on se dit que les principes d'hier peuvent redevenir ceux de demain, et que Java dont on annonce la mort depuis 15 ans a encore de très beaux jours devant lui, et probablement plus que beaucoup des langages hype d'aujourd'hui (ça marche aussi pour les frameworks : en 2012, Play devait enterrer JEE...)
 
 
 

OCaml a le même âge, Smalltalk pouvait conduire et voter, Self avait plusieurs années. Les types génériques & HoFs & closures & autres c'étaient des outils connus de longue date et déjà "en production", pas des inventions récentes.

L'âge de Java est tout relatif (c'est pas FORTRAN ou C) et imo pas une excuse. On peut d'ailleurs le voir dans le design de Go, pas besoin d'être vieux pour être en retard.

Je dis pas que Java était particulièrement moderne dans les années 90, mais que les choix étaient alors pertinents.
Par exemple :

C'était discutable, mais pas fou, à l'époque.
 

Bah ça c'est certain.
Tous les aspects fonctionnels des langages récents viennent des ML et copains.
Et les aspects OO, les modèles de concurrence/parallélisme, etc. c'est encore plus vieux.
 
Y a peut-être que Cyclone puis Rust qui ont amené des choses un peu nouvelles au 21e siècle?

 
L'âge de Java veut juste dire que le poids des choix de design à l'origine commence à se faire sentir, je sais bien que les concepts qui sont intégrés maintenant n'ont rien de bien neufs.

 
J'irai pas jusque là, tu peux très bien considérer qu'un langage est moisi mais reconnaître qu'il est utile (PHP est l'exemple qui me vient immédiatement en tête).
 

Loin de moi l'idée d'avoir voulu lancer un débat sur Java hier en disant que le monde avait besoin de s'en purger (quoique...), mais je demande juste un truc, UN SEUL truc, et c'est même pas au langage que je le demande mais aux développeurs de librairies tierces : ARRETEZ DE FOUTRE DES ANNOTATIONS PARTOUT !!!

Après 11 ans de C#, j'ai du me remettre au Java l'année dernière dans le cadre de 2 missions. Rien de grave, les langages sont relativement proches (même si j'aurais bien envie de chier dans la bouche de celui qui a commis l'API stream() et son corollaire collect() en Java 8 tellement c'est lourdingue à utiliser en comparaison de LINQ, mais passons), et j'ai découvert Spring. Et là ce fut le drame...

Des annotations à coller partout, des classes magiques dont le comportement est influencé par ces merveilleuses annotations (super pratique pour débugger), une verbosité qui ferait passer le plus long mot de la langue allemande pour un micro pénis (si si, la classe TransactionAwarePersistenceManagerFactoryProxy.PersistenceManagerFactoryInvocationHandler existe vraiment), une complexité de mise en place telle qu'il a fallu créer "un framework pour le framework" nommé Spring Boot, la dispersion de plusieurs fichiers Spring dans différents modules, eux même dispatchés dans d'autres jars (un pur bonheur quand tu dois savoir qui fait quoi), les fichiers de configuration XML de 30 écrans de haut (ou alors on passe par de la config Java, non testable bien sur, et Sonar me crache à la gueule ma couverture de code)... et j'en ai tant d'autres à dire...

Bref, rideau !

Surtout que l’argument qu’un langage a un domaine de prédilection sous-tend qu’il soit bon à son job. Force est de constater que C comme assembleur portable, on re-passera. Java pour tourner partout, il faudrait peut-être exposer un peu plus d’api système pour que ce soit utile (et surtout il a fini sur Linux ).
 
JavaScript sur le client, si c’est pour exposer les éléments avec l’API DOM c’était mal barré dès le départ d’être bon à son job.

 
Faut voir de quelles annotations on parle. Trop de magie, c'est probablement naze, c'est un biais connu.  
Les gens qui découvrent Spring se disent "haha, on va tout faire en annotations" et c'est imbitable.
 
Sur le nom de la classe ultra longue, question honnête : est-ce que tu en as quoi que ce soit à carrer ? Réellement ?
 
Spring Boot est là pour fournir des "good defaults" et permettre de monter des applications déployables rapidement. Il est ultra magique et oui c'est un problème.
C'est encore relativement neuf et les bonnes pratiques pour sont utilisations sont pas claires. Pour prototyper c'est génial, mais pour sortir de cette phase là c'est l'emmerdement. Je crois que ce problème est commun à tous les outils de scaffolding.
 
Le fichier de configuration XML de 30 écrans de haut, c'est tes devs qui sont nuls. La complexité de la configuration ça se gère comme la complexité du code.
Dans un format de config où tu peux nommer arbitrairement les fichiers et faire des imports, c'est pas la faute du framework si t'as une config monolithique super longue.
 
La config java Spring est évidemment testable, on appelle ça un test d'intégration, qui appelle la config en question. D'ailleurs, elle est éminemment plus testable que la configuration XML, qui au mieux peut être validée localement par ton IDE s'il est correctement configuré.
 
Pour finir, si Sonar gueule parce que la config n'est pas couverte, c'est un problème d'utilisation et de compréhension de Sonar. Soit tes objectifs de couverture de code sont irréalistes, soit le code qui est important n'est pas assez couvert, ou une combinaison des deux.
 

tl;dr you're using it wrong.
 
Après y a pas que Spring dans la vie.
Et question sérieuse, est-ce que ASP.NET est vraiment moins complexe sur des projets d'envergure comparable?

 
C'était volontairement exagéré.
 
Après, dire que Java (ou un autre langage "correct", c'est à dire ni VB ni PHP ) est moisi, je trouve que c'est exagéré aussi.
 
C'est comme les mecs qui t'expliquent que XML c'est vraiment de la merde et que JSON est tellement plus élégant, toussa..
 
Mais putain, un peu d'objectivité :  
 
Entre  
 

 
et  
 

 
il n'y a pas de différence fondamentale.
 
JSON a pour lui d'être un peu moins verbeux (les end tags en moins, mais les virgules en plus), MAIS il perd beaucoup de cet avantage si on veut qualifier les objets (parce que là, on n'a pas l'info de la nature de "truc" qu'on a en XML)
 
Et surtout, putain, mais qu'est-ce qu'on s'en balance les couilles que ça soit plus ou moins verbeux? Personne ne tape jamais ça, c'est des programmes qui le font.
 
et si jamais tu dois taper un fichier de test, n'importe quel éditeur moderne te ferme les tags proprement.

Volontiers un peu d'objectivité Entre XML-RPC et JSON-RPC sur des données à traiter (infra XenServer de 500 VMs) on diminue **légèrement** le temps de parsing de la requête initiale, en étant environ 250 fois plus rapide

Dans la majorité des cas, les JSON « suffit » et le XML ne sert qu'à rajouter des couches inutiles et du temps de traitement CPU. Après si t'es AWS, j'imagine que ça te déplaît pas

 
Ouais enfin ca dépend comment tu exploites ton XML et ton JSON.
 
Si on exploite les deux de la même manière (validation, manière de parser, etc..) il n'y a pas de raison que ça soit plus lourd avec du XML qu'avec du JSON.
 
Après, qu'il n'existe pas d'outillage pour exploiter rapidement du XML, c'est possible, mais c'est un autre débat : je parlais simplement du format, et du reproche qui est souvent fait à xml que "oui, c'est verbeux".
 
(et perso, je m'en balance, hein. J'utilise les deux selon mes besoins)

Je disais justement que pour un usage répandu (juste vaguement structurer des données, rien de plus), tu vas manger très cher parce que les outils autour (parser) sont prévu pour des degrés de complexité supérieur (validation etc).
 
Bref, ya eu une mode d'utiliser du XML partout pour des trucs simple alors que c'est vraiment inutile dans 80% des cas.
 
Après oui, quand ça répond au besoin, là bien entendu c'est OK Mais comme d'hab, utiliser les bons outils ça reste un des gros challenge de nos métiers
 
Je pense que c'est la surutilisation du XML à toutes les sauces qui a fait sa « mauvaise réputation »

On est bien d'accord, surtout qu'aux annotations Spring se rajoutent d'autres annotations Hibernate, ou Lombok (un vrai cancer ce truc au passage, quand les devs en mettent partout c'est une horreur, car tu n'as pas forcément le réflexe de vérifier si la classe est annotée, et tu te retrouves avec du code inutile déjà implémenté dans l'annotation)
 

Ben j'ai du reprendre un projet dans ma mission actuelle (à base de Spring Batch), et je t'avoue que quand tu passes ta journée à lire du code (assez mal écrit, le mec avant moi a fait du dégat), tu dois lire vite pour comprendre vite, ce qui n'est pas facilité par ces noms à rallonge
 

Ceci ne révèle t'il pas un défaut de conception de Spring dés le départ ? Je veux dire, si un framework a besoin d'un tel outil pour simplifier son déploiement, n'aurait il pas mieux fallu penser à la problématique résolue par Spring Boot dés le début de la conception de Spring ?  
 

Je ne te contredirai pas sur ce point, mais sur la pertinence d'une configuration XML (résolue par Spring Boot) : en tant que programmeur Java, j'ai pas du tout envie de me faire chier à coder du XML, qui plus est des trucs finalement assez sensibles comme le liage de dépendances.
Sans compter, et c'est du vécu, que ce fichier peut être édité à partir de n'importe quel éditeur de texte. Et j'ai eu le cas d'un dev qui avait codé son XML avec Notepad++, et qui l'avait sauvegardé dans un encodage de caractères différent de celui utilisé par Eclipse. Et pour une raison que j'ignore, Eclipse a refusé de me le prendre en me balançant des erreurs de parsing, j'ai du tout copier/coller dans un nouveau fichier créé par Eclipse. Quand tu as un seul fichier, ça passe, mais quand tu en as une tétrachiée...
 

Sur ce point, OK, le Sonar du client est configuré avec les pieds, avec des objectifs maximum de 1 journée de dette logicielle et des règles.... qui sont ce qu'elles sont

Si tu n'as pas besoin de commentaires par exemple
 

 
Certainement.
 
Et de mon point de vue de recruteur, l'adhésion à ce genre de préjugé est un signe pas neutre du tout.  

 
Ton taf c'est pas de créer des programmes qui font les trucs chiants à la place des gens?
 
 

 
Faut les recruter à la sortie d'école, ils ont pas de préjugés (ou ils tiennent pas 2 jours )

 
Tu veux dire comme élire Trump comme président ?

 
Tu parles, ils s'imaginent qu'ils seront CP dans 2 ans
 
 
Bon, sinon, rebondissement dans l'affaire de la réversibilité de la TMA du ministère.....
 
 
Depuis le début de la semaine, on a du monde à nous au MJ avec les équipes de HGJ pour ds formations théoriques.
 
La semaine prochaine ils devaient venir à 3 chez nous (en bus, donc)
 
Finalement, après que le MJ leur ait collé un tir parce qu'ils ne sont pas super assidus, ils seront 5.
 
Mais sans PC.
 
 
On hésite à leur suggérer de fouiller la soute du bus pendant la nuit pour en trouver.
 

suffit de demander à kadreg qu'il nous ponde un plugin Eclipse pour parser correctement le XML quel que soit l'encodage

clébard au bord de la syncope : https://gfycat.com/FlippantHorribleHalicore

t'aurais pas la même avec un chat?

ça ne va pas être facile à trouver ça sur l'internet

tiens, ce matin Masklinn parlait de Go... je viens de m'apercevoir d'un truc rigolo : https://play.golang.org/p/by7TE9Vr2O4
RUN => -128 !
what is this sorcery ?

La même chose que -1*Integer.MIN_VALUE en java?

Dépassement de capacité?

https://stackoverflow.com/questions [...] en-compare