Le fil des geeks informatiques

[neuneu2k]

Les problèmes de lisibilité du code ne sont un problème que quand la modularité est mauvaise.

 

Si le système est découpé en modules les plus simples possibles, de deux choses l'une, soit c'est assez simple pour être réécrit en un ou deux jours, et dans ce cas, la lisibilité du code n'est pas un problème (au pire, on refait le module), soit il y a réellement un problème complexe à résoudre, et dans ce cas, le code risque fort de ne pas être lisible parce que la solution est non triviale.

 

Les histoires de lisibilité >> tout le reste, c'est vrai dans un schéma particulier, le cumul de plusieurs facteurs qui n'ont rien d'absolus, et qui devraient etre fuis plutot que d'essayer de s'y adapter.

 

• Turn over elevé
• Compétences "variables"
• Systèmes insuffisamment modulaires
• Une croyance que le code ça a de la valeur, qu'il faut valoriser le code, alors que le code c'est juste la dette à payer aux démons du chaos pour avoir un module qui marche.

Ce n'est pas que le code lisible soit un problème, mais c'est souvent un symptôme des déboires de l'ingénierie logicielle, le logiciel, c'est pas de l’ingénierie, les développeurs, c'est pas des ouvriers qualifiés.

 

Le logiciel c'est la phase de conception, pas la phase d’exécution, les gens s'imaginent qu'il faut rendre la partie humaine prédictible et répétable, alors que si c'est prédictible et répétable, c'est justement que ça ne doit pas être fait par un humain du tout !

 

 

 

 

 

 

[h16]

Oui.

En gros, l'écrasante majorité des programmes devrait être composé de petits modules indépendants, ultra testés, et solides, à l'interface connue.

On en est très loin. Les outils Unix s'en rapprochent.

[Rincevent]

Je suis d'accord. Mais dessiner une interface potable actuellement est finalement plus compliqué que jadis. Précisément parce qu'on peut se permettre bien plus de trucs. L'exemple des formulaires à la con avec 36.000 clics n'est pas fortuit. Dans un écran 80x25, c'est juste pas possible.

Moins de possibilités de faire des conneries, c'est moins de conneries faites. D'où la survie du Cobol (j'attends toujours le framework Cobol on Cogs ).

 

Par ailleurs, je suis un grand partisan de découper l'informatique en deux, le bottomware et l'applicatif, et l'applicatif, idéalement, c'est des users qui le font, ou des devs integrés dans les équipes utilisateurs, et eux, il leur faut un langage de haut niveau UNIQUEMENT, et vérifier qu'ils ne font QUE du business et pas du systeme.

Laisser des utilisateurs programmer ? Mais tu n'y penses pas !

En revanche, ne faire que du haut niveau, ça me semble tout à fait souhaitable dans mon cas. Je sais pertinemment que si on me laisse jouer avec des pointeurs et des registres, ça va tourner au cauchemar : mon taf, c'est de pondre par exemple du SQL, et de laisser la machine se démerder pour me trouver les données que je lui demande. La manière dont elle s'y prend m'intéresse vraiment parce que je suis curieux de tout, mais ce n'est pas ce pour quoi je suis payé.

 

Non c'est fait pour être écrit !

C'est fait pour expliquer quelque chose a un ordinateur, et pour ça il vaut mieux un langage qui soit proche de lui et de son fonctionnement.

Si on est loin de l'ordinateur et de sa façon de penser on s'expose a des malentendus avec lui (des bugs, lui faire faire des trucs inutiles, etc.).

J'insiste, le code, c'est fait pour être lu. Si ton seul objectif est d'être compris par la machine dans un langage proche du métal, alors prends de l'assembleur, ou du C pondu dans un service de tératogénie. Ca donne des trucs qui marchent bien, hein, après tout TCC a commencé sa carrière en remportant l'IOCCC en 2001.

[jubal]

Sais-tu combien de lignes de code sont embarquées dans une voiture moderne ? Il n'y a pas que les ordis dans la vie.

 

Quand un type bosse sur un algo d'ABS, il a intérêt à ne pas se chier. Et dans ce cas par exemple un code maintenable est fortement préférable à du Q&D, quelque soit la différence de performance.

Non pour l'ABS justement il faut surtout du code qui marche, pas du code qui fait des choses inattendues qu'on ne comprend pas. C'est vraiment l'exemple typique ou il faut comprendre ce qu'on fait et ce que l'ordinateur va en faire, et pas se faire plaisir en inventant des concepts abstraits a 1000 lieux de la machine parce qu'on trouve ça joli.

 

Si un jour ou j’apprends que mon ABS est codé en java, je change de voiture.

 

Quand a la performance on s'en fout dans 90% des cas, c'est pas la question.

La question c'est: "est ce que je sais ce que mon code fait exactement ?"

 

 

[jubal]

J'insiste, le code, c'est fait pour être lu. Si ton seul objectif est d'être compris par la machine dans un langage proche du métal, alors prends de l'assembleur, ou du C pondu dans un service de tératogénie. Ca donne des trucs qui marchent bien, hein, après tout TCC a commencé sa carrière en remportant l'IOCCC en 2001.

 

J'insiste, non

Un code qui serait uniquement lu par des humains ne servirait absolument a rien, sauf dans un contexte académique.

Un code peut en revanche ne jamais être lu et être utile.

 

Un code il sert a quelque chose en principe, et c'est pas a distraire ceux qui le lise, ni a faire plaisir a celui qui l'ecrit. C'est pas un roman.

[Malky]

Si un jour ou j’apprends que mon ABS est codé en java, je change de voiture.

 

 

Ça risque pas, le code de ton ABS c'est très probablement du code Ada vieux de 20 ans (voir plus), régulièrement adapté au hardware par des personnes différentes (qui ne l'ont pas écrit, ce code, donc). En moyenne dans une voiture moderne il y a ~100 millions de lignes de code, ça situe le truc entre la codebase de Windows Vista et celle de Seven.

[neuneu2k]

Java le langage est tout à fait déterministe, bas niveau et simple (voir simpliste), la plateforme est déterministe également quand l'allocation mémoire est stable (et les implémentations normales de malloc sont de fait moins déterministes q'un GC moderne).

 

Dans tous les cas, si on souhaite faire du real-time, il faut des allocateurs spécifiques pour le real-time, et si on souhaite etre totalement déterministes en temps (et pas juste mettre une barre haute à la latence), il faut un systeme déterministe, autrement dit pas un CPU moderne avec une hierarchie de caches et un OS multitaches.

 

J'aurai bien plus confience en un systeme a agents distribués écrit en java RT q'un systeme old scool monolitique écrit dans un langage plus complexe.

 

Au quotidien, je ne fait pas de hard real time, mais le soft real time en java ce n'est pas un problème, et le hard real time a haute fréquence le langage est le dernier des soucis, java c'est juste une syntaxe simplifiée de C pour ce genre de cas.

 

J'ai testé des prototypes hard RT de scala sur des cores Kepler (pour le coup, eux ils sont plutot du coté hard RT) qui marchent très bien, je ne les utiliserai pas en production pour l'instant, mais c'est parfaitement déterministe.

 

Non, la bonne raison de ne pas le faire en java, c'est tout simplement que la majorité des gens qui font de l'embarqué ne le connaissent pas, c'est culturel pas technique.

 

(Et en embarqué, on à un langage parfaitement déterministe ET de très haut niveau: le Forth).

[Malky]

Après c'est pas non plus que de l'embarqué : gestion de trafic aérien, gestion d'une installation nucléaire, etc.
 

[jubal]

 

Non, la bonne raison de ne pas le faire en java, c'est tout simplement que la majorité des gens qui font de l'embarqué ne le connaissent pas, c'est culturel pas technique.

 

 

J’étais certain que tu réagirais pour défendre java

Et je suis d'accord le problème de java est essentiellement culturel, si c'est toi qui code mon ABS en java je garde ma voiture.

 

[Mathieu_D]

Laisser des utilisateurs programmer ? Mais tu n'y penses pas !

C'est pourtant très clairement la tendance.

En ce moment les SSII restructurent leur discours marketing pour aller vers le conseil. La consigne c'est d'entrer par le métier.

On anticipe très nettement une baisse de l'importance des SI.

 

J'insiste, non

Un code qui serait uniquement lu par des humains ne servirait absolument a rien, sauf dans un contexte académique.

Un code peut en revanche ne jamais être lu et être utile.

 

Un code il sert a quelque chose en principe, et c'est pas a distraire ceux qui le lise, ni a faire plaisir a celui qui l'ecrit. C'est pas un roman.

Vu le nombre de fois où on intervient pour optimiser du code (et optimiser c'est une manière de dire "heu on comprend rien à ce que font nos programmes") je dis très clairement que la mantenabilité est plus importante que l'effectivité. (Dans une logique business bien sûr, pas dans une logique de vie ou de mort on est d'accord.)

[Malky]

Tiens je viens de voir que pour la JamaicaVM (Certifiée DO-178B Level D, c'est déjà pas mal) il existe Linux/x64 gratos, évidemment sans support par contre.

[Malky]

... il existe une version Linux/x64 gratos. Trop tard pour éditer.

[Calembredaine]

Oui.

En gros, l'écrasante majorité des programmes devrait être composé de petits modules indépendants, ultra testés, et solides, à l'interface connue.

 

En théorie oui mais dans les faits, la technologie évolue tellement vite que "les petits modules ultra testés" sont le meilleur moyen de prendre du retard, ne pas innover.

 

Rincevent à raison: le code doit être le plus lisible possible pour un humain. Le rendre proche de la machine et le plus efficace possible c'est le boulot du compilateur.

[Sloonz]

En théorie oui mais dans les faits, la technologie évolue tellement vite que "les petits modules ultra testés" sont le meilleur moyen de prendre du retard, ne pas innover.

Non, bien au contraire, travailler en petits modules, c’est l’assurance d’avoir rapidement des livrables fonctionnels au lieu de se dire « on attend d’avoir implémenté à 100% notre grande idée pour livrer » (qui est pour le coup le meilleur moyen de prendre du retard)

[Malky]

Silk Road 2.0 est ouvert, bordel ça a pas mis longtemps !

[jubal]

 

Rincevent à raison: le code doit être le plus lisible possible pour un humain. Le rendre proche de la machine et le plus efficace possible c'est le boulot du compilateur.

 

C'est mieux si le code est lisible, mais c'est pas sa finalité ultime.

Si le prix a payer pour qu'il soit lisible c'est qu'il ne marche pas, alors c'est trop cher payé.

 

Et puis "lisible" n'est pas synonymique de "loin de la machine", ni de "abstrait et abscon", c'est souvent le contraire pour moi.

 

 

[Calembredaine]

Non, bien au contraire, travailler en petits modules, c’est l’assurance d’avoir rapidement des livrables fonctionnels au lieu de se dire « on attend d’avoir implémenté à 100% notre grande idée pour livrer » (qui est pour le coup le meilleur moyen de prendre du retard)

 

Oui, les petits modules c'est très bien. L'erreur c'est de les croire ultra-fiables car ultra-testés. S'ils sont ultra testés, ils sont déjà dépassés.

[Calembredaine]

Si le prix a payer pour qu'il soit lisible c'est qu'il ne marche pas, alors c'est trop cher payé.

 

Excuse moi mais ce que tu dis n'a pas de sens. Un code lisible fait ce qu'il est censé faire. Un code abscons a besoin d'être testé pour savoir ce qu'il fait.

[Poil à gratter]

Ça dépend, c'est avant ou après un changement majeur du langage Java ?

 

Sinon c'est aussi mon opinion (jusqu'à peu j'avais 'Premature optimisation is the root of all evil' dans ma signature )

Bof, ce qu'il y a de bien avec Java c'est que le langage évolue très peu et très lentement.

 

Le micro-benchmark n'est pas pertinent pour mesurer la performance d'un système. Une routine critique genre memcopy qui met 50ms au lieu de 25, c'est au final un programme deux fois plus lent une fois en prod.

Avec l’essor de l'embarqué sous toutes ses formes et du green computing, même les frameworks JIT type JBoss/Tomcat ont maintenant tendance à laisser place au C/C++, tout du moins pour les backends. L'évolution Java/C est flagrante sur les dix dernières années quand on regarde l'indice TIOBE.

Oui, pour le backend, mais je n'ai pas le sentiment que c'est si nouveau que ça. Bon avant c'était peut-être plus du C que du C++. Enfin je ne dis pas le contraire pour les micro-benchmarks, je soulignais juste que pour optimiser, encore faut-il savoir quoi optimiser dans un système. Et pour moi qui travaille dans le monde du web, un système ça commence depuis le browser et ça se termine avec le système de logging, avec au milieu une base de données, des serveurs d'application, et des services tiers. Dans ce contexte, optimiser un memcopy c'est bien, mais c'est plutôt le boulot du fournisseur de DB, on a un peu d'autres choses à optimiser avant ça. Si tant est qu'on a besoin d'optimiser...

Les problèmes de lisibilité du code ne sont un problème que quand la modularité est mauvaise.

 

Oui et non, voir plus bas ma réponse à Jubal.

Oui.

En gros, l'écrasante majorité des programmes devrait être composé de petits modules indépendants, ultra testés, et solides, à l'interface connue.

On en est très loin. Les outils Unix s'en rapprochent.

La moindre webapp Java intègre désormais des dizaines de composants qui sont ultra testés et solides, implémentant une interface connue. On est franchement plus très loin de fonctionner sur ce modèle.

 

J'insiste, non

Un code qui serait uniquement lu par des humains ne servirait absolument a rien, sauf dans un contexte académique.

Un code peut en revanche ne jamais être lu et être utile.

 

Un code il sert a quelque chose en principe, et c'est pas a distraire ceux qui le lise, ni a faire plaisir a celui qui l'ecrit. C'est pas un roman.

J'insiste, si

 

En fait je veux du code lisible et propre, sans fioritures, parceque c'est le seul moyen d'avoir un audit correct. Et pour être sûr que du code est utile et fait ce qu'il doit réellement faire, je ne connais pas de meilleure méthode que la relecture systématique. De plus je ne connais pas de code qui ne doit pas être modifié dans le futur, alors effectivement on peut tout réécrire, mais c'est quand même plus économique si c'est possible de simplement améliorer l'existant. D'ailleurs lorsque ce n'est pas possible de modifier et qu'il faut réécrire, c'est pas vraiment pour un problème de lisibilité (on trouve toujours quelqu'un pour comprendre), mais plutôt un problème de conception.

[h16]

La moindre webapp Java intègre désormais des dizaines de composants qui sont ultra testés et solides, implémentant une interface connue. On est franchement plus très loin de fonctionner sur ce modèle.

 

Les composants sont encore loin d'être 'self-contained'. Bonjour le barnum des librairies partagées.

[Rincevent]

C'est pourtant très clairement la tendance.

En ce moment les SSII restructurent leur discours marketing pour aller vers le conseil. La consigne c'est d'entrer par le métier.

On anticipe très nettement une baisse de l'importance des SI.

Ah que les SI hyperintégrés (et donc facturés à prix d'or, puisqu'il faut des armées de gens pour que tout soit livré en temps et en heure) perdent la cote, je veux bien le croire. Mais laisser les utilisateurs programmer, ça promet des moments de grande solitude quand il faudra maintenir toutes ces conneries.

En théorie oui mais dans les faits, la technologie évolue tellement vite que "les petits modules ultra testés" sont le meilleur moyen de prendre du retard, ne pas innover.

Rincevent à raison: le code doit être le plus lisible possible pour un humain. Le rendre proche de la machine et le plus efficace possible c'est le boulot du compilateur.

Les deux sont vrais simultanément. Les petits modules, ça rend le code plus lisible ( si je devais estimer ça à la louche, la lisibilité varie selon l'inverse du carré du nombre de lignes, je dirais... en ajoutant un facteur Murphy pour l'utilisation "créative" de détails à la con).

Et les petits modules ultra testés, c'est la possibilité d'intégrer de nouvelles techniques au fur et à mesure qu'elles arrivent... y compris dans le cerveau du codeur. Jamais je n'aurais tenté de "Evaluate" zarbi dès mes premières lignes de Cobol.

Si le prix a payer pour qu'il soit lisible c'est qu'il ne marche pas, alors c'est trop cher payé.

Si il y a un tel prix à payer, c'est soit que les contraintes sont extraordinaires (auquel cas il faut des ingés système, comme le préconise Neuneu2k), soit que la technologie a été mal choisie (implémenter une bibliothèque de Regexps en SQL pur, c'est du n'importe quoi en barre).

Et puis "lisible" n'est pas synonymique de "loin de la machine", ni de "abstrait et abscon", c'est souvent le contraire pour moi.

Tout le monde ne naît pas avec une machine de Turing hard-wired dans le cerveau.

Bof, ce qu'il y a de bien avec Java c'est que le langage évolue très peu et très lentement.

Heu... C'est une blague ? En Cobol, il y a eu 5 révisions en 50 ans. Et à ma connaissance, un seul élément du langage est considéré comme obsolète et sera supprimé du standard dans la prochaine révision. C'est, je crois, une première dans l'histoire du langage. Ca, c'est de la stabilité, et c'est aussi ce qui fait son succès.

[Jesrad]

Mais laisser les utilisateurs programmer, ça promet des moments de grande solitude quand il faudra maintenir toutes ces conneries.

La recette du désastre: obliger des informaticiens à enseigner et coacher.

[h16]

laisser les utilisateurs programmer, ça promet des moments de grande solitude quand il faudra maintenir toutes ces conneries.

 

Voilà.

 

C'est un peu comme dire: avec les moyens modernes, plus besoin de faire appel à un plombier, un serrurier, un chirurgien. Do It Yourself.

[neuneu2k]

Quand je parle de laisser les utilisateurs programmer, il s'agit de dire que les développeurs applicatifs doivent être plus proches du métier que du backend, pas forcément que tous les utilisateurs programment.

 

C'est avant tout une question de mettre les outils entre les mains des gens qui en ont besoin, si l'outil c'est un développeur "tactique" et pas juste un logiciel programmable, ainsi soit il, mais ce qu'on observe c'est que souvent les applications "line of business" sont sur-ingénierées et correspondent à une volonté de faire du logiciel "professionnel" alors que ce que souhaite l'utilisateur, c'est juste des outils pour l'aider à bosser, pas une appli "vendable".

 

Le problème de l'informatique business telle qu'elle est actuellement, c'est qu'il faut vendre les outils à deux personnes différentes, le business, et l'informatique, or l'informatique ajoute des critères qui sont souvent sans le moindre rapport avec le business lui meme, et dont la seule fonction discernable est de fabriquer du travail au service informatique.

 

J'ai vécu, plusieurs fois, la transition excel -> progiciel (qu'il soit interne ou externe) et si les défauts du full user-controlled sont évidents (*kof* kerviel *kof*), la solution est hyper-coûteuse et au final très nuisible au business.

 

On a tendance à sous-estimer la capacité des utilisateurs à résoudre leurs propres problèmes, sous prétexte que leur code est dégueulasse, mais ce code immonde, il les aide au quotidien, le problème c'est quand on envisage de pérenniser "le code" comme si il avait une valeur, au lieu de pérenniser l'analyse du besoin qui est dans l'existence même de l'outil.

 

 

 

 

 

 

 

[Mathieu_D]

Je sors d'une mission où les actuaires étaient adim de leur serveur pour en revenir aux utilisateurs.

 

(Effectivement pour la maintenance c'était funky, on a retrouvé des francs belges en dur dans le code.)

[Poil à gratter]

Les composants sont encore loin d'être 'self-contained'. Bonjour le barnum des librairies partagées.

Les bibliothèques (librairies, ça n'est pas français ) partagées c'est juste une implémentation facile et rapide pour résoudre le problème de la réutilisabilité: ça marche pas trop mal, mais ça devient vite ingérable lorsqu'il y a des dépendances communes dans des versions différentes. En fait c'est un peu comme l'héritage d'implémentation: facile, rapide, un cauchemar à maintenir sur le long terme.

 

Idéalement, si on veut du self-contained, il faut tout organiser en web services, mais comme je dis à chaque fois: de quel genre d'applications parle-t-on ? Se lancer dans du web service, ou même de l'OSGI, c'est carrément over kill pour une large majorité des applications web. Ajouter quelques dépendances Maven suffit largement.

 

En revanche j'ai le sentiment qu'on va dans la bonne direction avec J2EE 6 et supérieurs, et le mieux c'est que ça devient utilisable dans des conteneurs web légers (comme Tomee). On a enfin des composants réutilisables et modulaires. Le soucis c'est de convaincre les développeurs que les EJBs c'est pas la mal incarné, et que Spring c'est en fait pas terrible.

 

Heu... C'est une blague ? En Cobol, il y a eu 5 révisions en 50 ans. Et à ma connaissance, un seul élément du langage est considéré comme obsolète et sera supprimé du standard dans la prochaine révision. C'est, je crois, une première dans l'histoire du langage. Ca, c'est de la stabilité, et c'est aussi ce qui fait son succès.

COBOL c'est pas un langage, c'est un fossile

 

Blague à part, Java, le langage, n'a que peu changé (le SDK c'est autre chose): j'ai commencé avec la 1.3 il a fallu attendre la version 1.5 - renommée 5.0 - pour voir un changement significatif dans le langage: génériques, mot clé enum. Java 7 - 5 ans plus tard - n'amène pas grand chose: c'est surtout du syntactic sugar pour le développeur. Donc il va falloir attendre Java 8 - qui doit sortir incessamment sous peu - pour voir arriver les lambdas et les streams.

 

Comparé à des langages utilisés aussi pour le web, c'est très conservateur et lent, ce qui explique sans doute en grosse partie son succès, comme COBOL.

[h16]

Les bibliothèques (librairies, ça n'est pas français ) partagées c'est juste une implémentation facile et rapide pour résoudre le problème de la réutilisabilité: ça marche pas trop mal, mais ça devient vite ingérable lorsqu'il y a des dépendances communes dans des versions différentes. En fait c'est un peu comme l'héritage d'implémentation: facile, rapide, un cauchemar à maintenir sur le long terme.

En gros, 95% des applis ont ces problèmes très vite. Les shared-libraries (et hop comment je tacle bibliothèque, moi), c'est un non sens dans un monde où le To vaut moins de 100€.

 

Idéalement, si on veut du self-contained, il faut tout organiser en web services, mais comme je dis à chaque fois: de quel genre d'applications parle-t-on ? Se lancer dans du web service, ou même de l'OSGI, c'est carrément over kill pour une large majorité des applications web. Ajouter quelques dépendances Maven suffit largement.

Et obtenir des trucs jetables ; v1 ok, v2 aïe aïe aïe et v3 on renonce parce que compatibilité impossible.

COBOL c'est pas un langage, c'est un fossile

Franchement, entre javouille et cobof, je préfère cobof.

 

Comparé à des langages utilisés aussi pour le web, c'est très conservateur et lent, ce qui explique sans doute en grosse partie son succès, comme COBOL.

Mh. Je pense plutôt que c'est parce que des milliers de petits programmeurs ont été formé avec ce truc et qu'il faut les rentabiliser. Les autres, ceux qui savent, s'en sont tenu soigneusement à l'écart.

[jubal]

Excuse moi mais ce que tu dis n'a pas de sens. Un code lisible fait ce qu'il est censé faire.

 

Je parle d’expérience très concrète, ou le fait d’être loin de la machine (et des trames réseaux en l’occurrence) empêchait la personne de faire un truc qui marche (6 mois a tourner en rond).

 

Et non pas du tout, un code lisible ne fait pas forcement ce qu'il est cense faire. De toute facon avec un language de haut niveau on n'a aucune idée de ce que le code fait.

 

[Poil à gratter]

En gros, 95% des applis ont ces problèmes très vite. Les shared-libraries (et hop comment je tacle bibliothèque, moi), c'est un non sens dans un monde où le To vaut moins de 100€.

Oui et non: ça n'a pas pour unique but de faire gagner de la place sur disque mais aussi en mémoire. Tu vas me répondre: le Go de mémoire ne coute rien. Certes, mais quand on héberge plusieurs apps sur un serveur, ça commence à changer la donne. Sans compter les temps de chargements qui sont réduits aussi.

 

Et obtenir des trucs jetables ; v1 ok, v2 aïe aïe aïe et v3 on renonce parce que compatibilité impossible.

Je ne te suis pas trop. Par exemple, je bosse avec des trucs comme Apache commons-collections depuis des années, il n'y a que très peu de soucis de compatibilité entre les versions, sauf bug, la compatibilité ascendante est respectée. Et ça évite de réinventer la roue carrée.

 

Franchement, entre javouille et cobof, je préfère cobof.

Pour ce que tu fais - et je ne sais pas ce que c'est - sans doute que COBOL est utilisable, mais pour faire des applications web, j'ai comme un gros doute Les websockets en COBOL, je ne le sens pas trop...

 

Mh. Je pense plutôt que c'est parce que des milliers de petits programmeurs ont été formé avec ce truc et qu'il faut les rentabiliser. Les autres, ceux qui savent, s'en sont tenu soigneusement à l'écart.

C'est une des raisons, mais si on apprend Java au jeunes développeurs, c'est avant tout parce que c'est fortement utilisé dans l'industrie. À quoi bon leur apprendre C++ si ce n'est pas une compétence recherchée ? Oui, aujourd'hui les (des ?) employeurs cherchent des devs C++, mais des expérimentés, pas des juniors.

[h16]

Oui et non: ça n'a pas pour unique but de faire gagner de la place sur disque mais aussi en mémoire. Tu vas me répondre: le Go de mémoire ne coute rien. Certes, mais quand on héberge plusieurs apps sur un serveur, ça commence à changer la donne. Sans compter les temps de chargements qui sont réduits aussi.

Ben en fait c'est même plus vrai puisque les applis de nos jours tournent dans des VM, ce qui veut dire qu'elles ne peuvent même pas se partager les libs. Et sinon, pour les trucs internalisables, on fait des petits modules bien fichus qui n'ont pas besoin d'être des librairies linkées.

Je ne te suis pas trop. Par exemple, je bosse avec des trucs comme Apache commons-collections depuis des années, il n'y a que très peu de soucis de compatibilité entre les versions, sauf bug, la compatibilité ascendante est respectée. Et ça évite de réinventer la roue carrée.

Oh, je ne dis pas que c'est impossible. Sur les grosses équipes, avec des douzaines d'applis différentes, la compatibilité est rapidement passée par la fenêtre en 3 à 5 ans (observé). Il doit bien exister des trucs solides bien fichus et propre, mais comme je n'en ai jamais vu en plus 20 ans, j'en déduis que je suis ou bien très mal tombé, ou bien que c'est une règle immanente

 

Pour ce que tu fais - et je ne sais pas ce que c'est - sans doute que COBOL est utilisable, mais pour faire des applications web, j'ai comme un gros doute Les websockets en COBOL, je ne le sens pas trop...

Je parlais sur un plan purement "langage", pas application monde réel. Java est adapté au web, pas Cobol. Donc pour faire une appli web en Cobol, je pense qu'il faut être profondément méchant.

C'est une des raisons, mais si on apprend Java au jeunes développeurs, c'est avant tout parce que c'est fortement utilisé dans l'industrie.

Je ne sais pas quel âge tu as, mais en 96/97, au tout début de Java, donc, il était évident que le calcul ci-dessus ne tenait pas. Personne n'employait ce truc hideux.

Si j'avais le temps, je reprendrais l'histoire abominable et triste de Java depuis ce moment-là. Java, c'est un coup marketing ignoble de Sun qui a réussit.

Snif.