Bonjour à tous,
Je ne lis pas souvent WealthSimple Magazine, mais voici un article fort intéressant sur la persistance du langage COBOL :
The Code that controls your money
J'aime en particulier le passage suivant :
Au début de Covid-19, les entreprises ont fermé en masse. Les employés licenciés s'agglutinaient en ligne pour demander des allocations de chômage, et les sites Web de nombreux gouvernements d'État se sont effondrés sous la charge. Dans le New Jersey, le gouverneur a déclaré à la presse que leurs systèmes COBOL avaient désespérément besoin d'aide pour faire face aux nouvelles demandes. «Littéralement, nous avons des systèmes vieux de plus de 40 ans», a-t-il noté.
Mais les techniciens qui travaillaient dans les coulisses pour résoudre les problèmes savaient que le COBOL "broyeur de nombres" n'était pas le problème. Ce vieux truc fonctionnait bien. Non, ce sont les trucs modernes qui ont planté - les programmes alimentant le site Web lui-même.
«Ce qui a foiré, c'est cette application Web entre le mainframe et le monde extérieur. C’est ce qui s’est en quelque sorte effondré », déclare Marianne Bellotti, une programmeuse et écrivaine qui a travaillé pendant des années sur les systèmes gouvernementaux et qui a observé le système du New Jersey. Mais il est trop embarrassant, comme le souligne l'historien Hicks, d'admettre que «oh, nos systèmes Web sont tombés en panne»."
Bellotti a vu la même chose se produire avec d'autres agences gouvernementales, comme l'IRS. Elle a été appelée une fois pour dépanner une application Web IRS qui ne fonctionnait pas. Lorsqu'ils ont enquêté, ils ont constaté qu'en effet, le problème était dans les programmes plus récents, «ce morceau de code Java mal écrit». Le mainframe fonctionnant en COBOL, en revanche, roulait comme une Ferrari.«Les mainframes», dit-elle, «répondaient en quelques millisecondes.»
# Sauf que ...
Posté par Colin Pitrat (site web personnel) . Évalué à 8. Dernière modification le 22 novembre 2020 à 09:07.
Je ne suis pas un spécialiste de ce dont il est question dans l'article, mais les références aux choses que je connais me font penser que l'article est probablement bourré de mensonges:
Pour avoir travaillé dans le secteur, c'est faux. Ce qui dominait autrefois c'était TPF, les mainframes IBM. Le code était en assembleur. À ma connaissance presque tous les acteurs du secteurs ont réussi à s'en débarrasser presque complètement (oui ça fait beaucoup de presques). En tout cas, pas de Cobol en vue. Oui les terminaux texte sont toujours présents et compatibles (souvent dans une fenêtre Windows de nos jours), ça ne veut pas dire que ce n'est pas du
C++/Java/Go/Python/Rust sous Linux qui tourne côté serveur.
[^] # Re: Sauf que ...
Posté par _kaos_ . Évalué à 7.
Salut,
Dans un autre secteur, j'ai pu voir un "rétropédalage".
Le moteur de calcul du logiciel est en fortran. On souhaitait petit à petit migrer ça parce que presque plus personne en interne n'était capable d'intervenir en cas de besoin. Donc classique :
Globalement, ça se passait bien, sauf que le fortran gérait énormément mieux des cas spécifiques (variables imbirquées par exemple).
Du coup, on a gardé la librairie (propriétaire) trouvée pour d'autres besoins (fin de partenariat avec une société, donc il fallait combler des trous, et là, ça fonctionnait), mais le fortran lui… je crois qu'il est toujours là, et pour longtemps :)
Matricule 23415
[^] # Re: Sauf que ...
Posté par abgech . Évalué à 4.
Je ne sais pas à quelle période tu as travaillé sur "mainframe". Parce que, l'assembler sur les mainframe, c'était pratiquement totalement fini en fin des années 1960.
Ensuite, c'était COBOL pour les applications commerciales.
FORTRAN était déjà bien implanté pour les applications scientifiques 1963, année de mes premières lignes de FORTRAN.
L'assembler c'était pour la programmation dite "system" et le temps réel.
Le C est venu bien plus tard, en fin des années 1970.
Je ne suis donc pas surpris que passablement de lignes COBOL sont encore exécutées de nos jours en gestion.
[^] # Re: Sauf que ...
Posté par Colin Pitrat (site web personnel) . Évalué à 4.
Pas sur TPF(en tout cas ce que j'en ai côtoyé). C'était soit du C soit de l'assembleur TPF. Le C était du vieux C bien pourri et le compilo mal optimisé, les perfs n'etaient pas vraiment au rendez-vous. Donc tout ce qui était non-critique niveau perfs était en C, le reste en assembleur.
D'ailleurs, pendant que des devs migraient à du C++/Linux, d'autres bossaient à convertir du C en assembleur TPF pour récupérer du CPU et compenser l'augmentation de traffic.
# trente six quiinze
Posté par mr_maurice . Évalué à 6.
Un de mes précédents employeurs travaillait beaucoup pour une mutuelle Française qui avait besoin de développeurs (?) Cobol,il y a quelques années.
J'avais été formé la dessus quelques jours, ça avait l'air carré et rigoureusement imbitable.
Je me souviens particulièrement de leur IDE qui était une sorte de minitel avec une UX défaillante (le curseur pouvait se perdre en dehors des limites de l'écran). En fin de compte j'avais trouvé dommage de devoir utiliser des outils de 1980 pour programmer dans un langage.
[^] # Re: trente six quiinze
Posté par AncalagonTotof . Évalué à 9.
Le rapport signal/bruit du COBOL est à peu près le même que celui du XML …
[^] # Re: trente six quiinze
Posté par Boa Treize (site web personnel) . Évalué à 2.
Maintenant il y a des IDE franchement meilleurs, voire même sous forme de plug-in dans Eclipse. Pas d'obligation à travailler avec des outils de 1980, c'était probablement ton client qui ne voulait pas faire évoluer son outillage.
[^] # Re: trente six quiinze
Posté par claudex . Évalué à 2.
Il n'avait peut-être plus de rein à vendre pour faire évoluer l'outillage.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Autre article
Posté par Colargol . Évalué à 6.
En complément je signale cet article plus technique qui explique qu'en COBOL les calculs se font en virgule fixe et que faire la même chose en python ou java est moins performant car nécessitant l'appel à des bibliothèques externes.
[^] # Re: Autre article
Posté par Colin Pitrat (site web personnel) . Évalué à -1.
J'ai pas encore lu l'article mais la virgule fixe, c'est juste tout multiplier par une valeur fixée (216 par exemple). Du coup je ne vois pas en quoi ça poserait problème à un langage.
[^] # Re: Autre article
Posté par Colin Pitrat (site web personnel) . Évalué à 7.
Maintenant que je l'ai lu, l'article est intéressant tout en étant à côté de la plaque. Parler du "coût d'import" d'une librairie n'a pas de sens d'une manière générale. Une implémentation fixed point header only en C++ n'a pas de "coût d'import".
Ce qui est marrant c'est que l'auteur est consciente de ça et termine l'article en donnant les vraies raisons: pourquoi réécrire quelque chose qui marche et réécrire coûte plus cher qu'écrire.
[^] # Re: Autre article
Posté par harlock974 . Évalué à 0.
Intéressant cet article.
Dans le même ordre d'idée, Il est remarquable de voir comment les vieux ordinateurs de poche programmables en Basic des années 80 géraient beaucoup mieux les calculs en virgule flottante que les langages de programmation actuels.
Par exemple sur un SHARP PC-1475 en double précision (20 digits), 0.1 + 0.2 = 0.3
En Python (18 digits) : 0.1 + 0.2 = 0.30000000000000004
[^] # Re: Autre article
Posté par _kaos_ . Évalué à 5. Dernière modification le 22 novembre 2020 à 11:35.
Salut,
Ce n'est pas une question de précision, c'est une norme pour le calcul flottant.
Il n'y a pas qu'en python que c'est comme ça.
Voir eps
Matricule 23415
[^] # Re: Autre article
Posté par Colin Pitrat (site web personnel) . Évalué à 2.
Et aussi une question d'arrondi au moment de l'affichage.
[^] # Re: Autre article
Posté par _kaos_ . Évalué à 1. Dernière modification le 22 novembre 2020 à 13:09.
Salut,
Oui, bien sûr :)
Ça fait partie des pièges classiques :
1/3=0.333333333… (autant qu'on veut).
Donc 1/3+1/3+1/3, ça vaut quoi ?
1 en calcul formel, certes, sinon 0.99999999… (autant qu'on veut).
Matricule 23415
[^] # Re: Autre article
Posté par Ytterbium . Évalué à 5.
Alors ce n'est pas un super exemple, parce que formellement 0,99999… est égal à 1.
[^] # Re: Autre article
Posté par _kaos_ . Évalué à 2.
Salut,
Tu me préviens quand tu vois une machine compter non formellement jusqu'à l'infini, hein ? :)
Matricule 23415
[^] # Re: Autre article
Posté par Faya . Évalué à 3. Dernière modification le 22 novembre 2020 à 15:15.
Sinon vous avez les 456 commentaires de ce fabuleux journal qui, je pense, a couvert l'entièreté du sujet des méthodes de calcul possibles/disponibles/imaginables :
https://linuxfr.org/users/reynum/journaux/humour-vers-un-monde-different
[^] # Re: Autre article
Posté par abgech . Évalué à 2.
C'est un piège classique des débutants en programmation.
Exemple :
float a;
…
if (a == 0.0)
…
=> BUG
Alors que :
…
if (abs(a) < 1e-6) // l'exposant dépend de la précision souhaitée
…
=> OK
[^] # Re: Autre article
Posté par vmagnin (site web personnel) . Évalué à 3.
Une banque qui tiendrait ses comptes en virgule flottante (IEEE754), ça serait embêtant…
[^] # Re: Autre article
Posté par Colin Pitrat (site web personnel) . Évalué à 3.
Sur un uint64 par contre ce serait drôlement bien!
[^] # Re: Autre article
Posté par wismerhill . Évalué à 5.
Dans les banques communistes, les montants des compte sont stockés dans des entiers 16 bits non signés, sans détection des overflow ;-)
# Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par AncalagonTotof . Évalué à 10.
Pour les plus jeunes : qui est Higgins …
Attention, pas mal de n'importe quoi et de +/- hors sujet dans le sujet ! Et je ne préviendrai pas quand ça tiendra du troll …
La dernière fois que j'ai fais du COBOL, c'était en 1990 en TP à l'IUT, sur l'AS400 tout neuf. Souvenir de souffrances … Tout neuf, mais sous dimensionné : parfois 30 secondes entre l’appui sur une touche et l'apparition du caractère dans le code. Compilation de code et de "grilles écran" longues, très longues ! OK, c'était probablement l'entrée de gamme, trop faible pour gérer 12 terminaux en parallèle dans la salle de TP. Wait ! 12 ??? Seulement ???
De nos jours, l'AS400 existe encore. Je ne sais pas si c'est programmé en COBOL, mais dans de nombreux cas, un vendeur d'une grande enseigne réalise ses ventes en faisant apparaître une magnifique "grille écran" dans une fenêtre Windows 10 ! Quel décalage …
Je ne dis pas que ces vieux systèmes sont à cramer ! Un pote a bossé sur du Bull dans les 90/2000, et il me vantait souvent la puissance de l'espèce de BASIC très orienté gestion et super adapté au tâches demandées.
Et puis Java est arrivé ! Et les écoles ont commencé à pondre des cohortes de "p'tit jeunes" pisseurs de lignes et de grand principes et adeptes de "t'as vu la dernière techno machin, tout le monde en parle". Hein ? Quoi ? Ça fait plus de 15 ans que je code à l'aide de Qt & C/C++, et je suis loin d'en avoir fait le tour, très loin. Minute quoi !
Là, j'ai essayé de m'y mettre, à Java, quand même un peu, mais j'ai toujours du mal. Mon job étant plutôt dans la prog proche du système et embarqué, j'ai pleuré le jour où on a essayé de faire un projet en Android Things. Tous les types sont signés, aucun non signé ! Comment gérer des octets proprement en Java quand le type byte est signé ? Facile, y'a qu'à utiliser la taille au dessus sur 16 bits ! Et puis déployer des trésors de calculs inefficace pour faire les conversions ! On a abandonné quand l'appli commencé à crasher juste parce qu'elle était trop gourmande en RAM. Aucun contrôle pour empêcher ça.
Dans un autre registre, le même pote a changé de boite, et il a vu passer quelques perles. La plus belle : un batch journalier qui prenait plus de 24 heures. Batch en Java … Bah oui, fallait faire du SQL dedans. Avec une requête à 900 niveaux de parenthèses. 900 ! Oui, c'était fait par un générateur de requête. Mais les mecs ne se posent plus la question des ressources, est-ce que je pousse pas un peu le bouchon, ça pourrait pas être un poil optimisé …
Ça lui est arrivé plusieurs fois de faire concurrence aux p'tits jeunes codeur Java sur du traitement de fichier texte. Encore une fois, ils sortent leur Java là où un peu de script ou de awk va des dizaines ou des centaines de fois plus vite.
Et puis y'a ma boite, plutôt grosse, avec plein de magasins en France, un site Web qui doit être remplacé, il y a deux ans … Ouais, deux ans de retard pour passer des vieilles technos "moches" sur AS400 (plein et des gros qui vont assez vite ici) à un empilement de dizaines de techos et d'outils gérés par 10 % d'internes et 90 % d'externes. J'ai eu l'occasion de voir le taf d'un type du "back" et d'un autre du "front" : il leur faut un site avec les liens vers chacun des outils utilisés. Au moins 20 ou 30 sur le premier. Sinon, impossible de se rappeler de tout.
Et pour avoir bien merdé sur notre petit projet Android Things au niveau de la gestion des versions de dépendances, je n'ose pas imaginer la fragilité du château de carte sur lequel ce site Web doit reposer !
OK, j'ai bientôt fini de vider mon sac n'importe comment. Mais ce qui me fait peur, c'est l'empilement monumental de techno non maîtrisée, consommatrices de ressources machine et humaine, avec des humains qui ne se préoccupent pas de la prod parce qu'ils sont con à la prod, franchement, ils pourraient mettre des machines qui tournent plus vite et plus de serveurs.
Mais bon, qui suis-je pour aborder ces sujets quand mon quotidien est plus proche d'un micro-contrôleur … Je serais plutôt une vieille casserole, parmi les vieilles marmite, et qui avait envie de vider son sac …
En plus, il existe MicroEJ sur micro-contrôleurs …
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Colin Pitrat (site web personnel) . Évalué à 3.
Pas la peine de te mettre au Java, la mode touche à sa fin. Essai le Rust plutôt :)
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par YBoy360 (site web personnel) . Évalué à 7.
J'ai beau apprécier Rust, même utiliser des logiciels Rust car c'est plus sécure, le reconnaitre, ça n'est pas tout à fait pour les mêmes usages. Il y a quand même des développeurs qui arrivent à faire des applications fluides en Java, sur serveurs, desktops ou téléphones, codées très rapidement, qui gèrent parfaitement beaucoup de dépendances, sans aucun problème.
Comme on est plus vendredi, il serait bon de passer à autre chose.
Concernant l'étalage d'expérience, j'ai connu presque pire. Ce que l'on constate en général, c'est que tout dépend de l'encadrement des projets, et des compétences techniques de la hiérarchie. L'idéal est que le chef de projet soit aussi l'intégrateur car en Java, c'est le poste clé (idem en C++). Il faut faire preuve de prudence, bien choisir les dépendances est ce qui demande de l'expérience.
Combiens d'idées "géniales" ou projets miraculeux doivent finir à la benne avant d'avoir de l'expérience? Je ne sais pas, mais je ne pense pas que la réponse à cette question soit propre à un langage particulier. Pour développer en C/C++/Java/Python/Kotlin/Groovy, 4 stagiaires sur 5 fait du code inutilisable en production après l'école. Peut-être que d'autres langages offrent un cadre plus restrictif, donc permettrait de changer ce ratio, mais je n'y crois pas trop, ou alors, le prix à payer ne serait pas négligeable.
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Depuis quand c'est un langage de programmation qui doit encadrer les stagiaires? C'est pas plutôt le rôle du maître de stage?
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
Trop de projets je le crains, et c'est pas plus mal …parce-que je vois parfois des « tests » ou des « POC » qui sont poussés en production et franchement la benne aurait été un cadeau (et de réels économies) !
Alors, il y a deux raisons principales à cela à mon avis.
Premièrement l'école ne fait qu'une/un initiation/survol au/du langage et les élèves n'ont généralement pas assez de pratique/heures pour bien les familiariser au langage : le stage d'entreprise est donc un TP en grandeur nature pour le coup. Or les langages ont des spécificités et des subtilités qui s'acquièrent avec le temps, contrairement aux principes d'enseignement qui font apprendre quelques motifs et pour le reste les gens vont taper sur un moteur de recherche et copier des lignes sans trop comprendre ce que ça fait…
Deuxièmement, les élèves ne sont plus formés à l'analyse et à l'algorithmique, et du coup ces futurs devs ne se rendent pas compte de certaines énormités qui ne sont pas liées à la syntaxe du langage mais à l'algo sous-jacent. Je remarque que trop de notions que j'aurais cru basiques (comme comprendre le type de structure qu'on est en train de manipuler ou comment dérécursiver etc.) sont incomprises.
C et pensé et conçu pour être très proche du matériel (c'est quasiment le niveau qui suit l'assembleur pur et dur) et laisse donc beaucoup de libertés (après tout on est sensé savoir ce qu'on fait.) Du coup c'est catastrophique par rapport aux formations actuelles qui survolent un peu trop, et c'et aussi de là que vient la réputation (certes infondée) de difficulté.
C++ et Java, ainsi que tous les langages qui reprennent la syntaxe du C essayent de limiter certains travers (on dit par exemple que C++ est une surcouche de C mais il y a plein de constructions bordeline permises par la norme qu'un compilateur purement C accepte mais que le compilo Cpp ne laisse pas passer) ; mais ce n'est pas assez cadrant par rapport à ce que font les stagiaires. Dans le cas de C, vu sa non maîtrise, une approche quand on ne doit pas exploiter certains aspects de l'architecture matériel (donc programmes un peu génériques), serait de revenir au Pascal qui est plus structurant. On peut aller encore plus loin en passant à Ada dont le compilateur est à la fois plus strict et un peu didactique. Ces deux langages sont en plus syntaxiquement moins laxistes (Ada encore plus car ayant appris appris de tous ses prédécesseurs) et supportent le paradigme objet aussi. Il doit y avoir d'autres langages comme ça mais qui malheureusement ne sont pas à la mode…
Par contre, on ne traite qu'un point et il n'y a pas d'outil à ma connaissance pour remplacer l'analyse.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Non ? si ? a je comprends mieux …
Comment peu tu coder sans analyser ?
recherche google puis copier / coller ?
pauvre de nous …
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
copier/coller surtout sans vraiment comprendre, en mode un peu magique…
https://www.jesuisundev.com/apprentissages-developpeurs/ : ce billet, et d'autres du blog, pointe(nt) du doigt les mauvaises manières/habitudes des générations actuelles.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Et je vis cela tout les jours …
dans la société qui m'emploi, tout problème qui n'est pas compris devient du "système"
Et c'est désolant
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par stopspam . Évalué à 10. Dernière modification le 22 novembre 2020 à 14:54.
Je croise de plus en plus de collègues qui n'ont pas ou plus la passion du métier, la volonté d'un travail bien fait mais sont juste là pour payer les factures.
Même constat. Comme d'autres professions, je pense que le métier de développeur a été victime de son succès. Puisque tu parles des années 1990, en 30 ans il s'est énormément popularisé à cause d'une filière qui a du répondre vite à la forte demande. Tous les stagiaires dont je m'occupe arrivent avec l'un de ces 2 profils :
A chaque fois, je reprends pas mal de choses et j'ai l'impression de jouer le rôle qu'aurait du avoir son prof. Alors oui, le stage en entreprise sert justement à ça mais il devrait y avoir un minimum.
Je pourrais faire un copier/coller avec les nouveaux recrutés. J'en suis arrivé à un point ou ce qui va faire le bon candidat c'est un candidat qui :
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par AncalagonTotof . Évalué à 1.
D'accord, sauf pour le casque ! Dans un open space de >600 personnes, sans, tu deviens dingue …
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par aiolos . Évalué à 2.
Oo ça exite vraiment ? C'est un hall d'aéroport reconverti ?
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par AncalagonTotof . Évalué à 1.
Yep, ça existe, mais là, c'est un ancien magasin reconverti.
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par stopspam . Évalué à 1.
Si le casque c'est pour s'échapper d'un environnement bruyant et se concentrer je trouve ça tout à fait normal.
Mais j'en vois mettre un casque pour s'isoler, se planquer derrière les claustras et ne participer à rien. Ça casse l'équipe à moyen terme.
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Yannick (site web personnel) . Évalué à 7.
J'ai un collègue qui a écrit un batch journalier (mais qui doit aussi pouvoir être appelé plusieurs fois dans la journée) qui prenait 9 heures et qu'il "n'a pas réussi à optimiser". J'ai dû passer quelques jours dessus pour rattraper le coup. Après, ça ne prenait plus que 2-3 minutes. Et encore, je n'ai pas fait des trucs de malade, juste des trucs plus propres dans le code et les appels SQL. Je ne pouvais pas faire de vraies optims plus poussées car pas le temps et pas de possibilité de faire des tests de non-régression derrière. Tout ça pour dire que d'expérience, c'est pas forcément le Java le problème, mais plus souvent l'interface chaise/clavier. Le même collègue nous avait aussi fait le coup du batch journalier de 26h…
Sinon, je suis aussi d'accord sur un point, le nombre d'outils / bibliothèques disponibles en Java en incite quelques-uns à en ajouter à tort et à travers dans les projets pour faire mumuse avec, être dans le vent, ou juste pour ajouter une ligne clinquante dans le CV. Le tout sans prendre de temps de maitriser le truc. Il ne faudrait pas qu'ils passent plus que 5-10 minutes sur un "Get started", hein !
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Cela me fait penser que je rencontre beaucoup de dev TelLangage + SQL …et pour la partie SQL c'est incapable de pondre un SELECT tout basic (sans jointure) : c'est toujours fait avec des ORM qui sont pas maitrisées (par exemple par défaut ça prend tous les champs et demande quasiment toutes les lignes …parce-que pour cibler plus précisément il faut des utiliser des options/paramètres mentionnés dans la doc que personne ne prend la peine de lire ou pas jusqu'au bout.)
Donc je confirme : bien que chaque langage ait ses points faibles et ses écueils, on en est rarement loin et le souci est souvent à des kilomètres entre la chaise et le clavier…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Psychofox (Mastodon) . Évalué à 4.
Souvent le problème c'est dans les requêtes SQL et l'absence possible d'index, pas vraiment dans le reste du code. Donc effectivement le fait que ce soit en java ou autre ne change rien. Je crois que beaucoup de DEV manquent de formation DB.
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
J'ai travaillé pour MicroEJ il y a quelques années et globalement l'équipe était composée de gens qui savent ce qu'ils font en terme de performances et optimisation.
Leur SDK répond a des besoins bien spécifiques, par exemple la nécessité d'avoir sur le même cpu du code temps réel (écrit en C) et une interface graphique (écrite en Java, sans contraintes temps réel, et relativement bien isolée malgré l'absence de protection mémoire matérielle).
L'utilisation d'une machine virtuelle java a bien sûr un coût, mais elle permet aussi de faire mieux que le C sur certains points, par exemple c'est possible de défragmenter la mémoire, d'allouer dynamiquement la stack de chaque thread par tout petits morceaux (512 octets) qui ne sont utilisés que très ponctuellement, …
Le tout peut fonctionner avec seulement quelques dizaines de Ko de RAM pour une application complète (code C temps réel + interphace graphique)
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Hmm, et-ce vraiment la machine qui était sous-dimensionnée ou le paramétrage qui était mal fait ? Ce que tu décrits ressemble fort à un problème de liaisons (mais je pense que les terminaux étaient directement connectés et ne passaient pas par Internet avec une connexion 12k si ?) ou de configuration du terminal…
Oui, ça s'est appelé eServer iSeries, puis maintenant System i5 tournant sur processeur Power5.
Le système n'a jamais été programmé en COBOL mais a toujours été livré avec les compilateurs pour COBOL, EGL, RPG, PL/1, Pascal, C, BASIC, Smalltalk, FORTRAN ; et maintenant également Java, PERL, PHP, Python, C++
Je crois RPG ou alors CLP ?
Le Control Language Procedure est plutôt une surcouche (ajout de structures de contrôles au CL) compilée de batch du système OS400. Ce serait un peu l'équivalent des scripts shell de base.
Le Report Program Generator et un autre langage compilé qui reprend effectivement des mots d'assembleur (move, clear, goto) ainsi que du BASIC et du COBOL (avec lequel il partage la position fixe car c'est en fait un langage qui date de l'époque des cartes perforées et était présent sur d'autres machines avant d'être porté sur AS400). Dans son objectif, c'est un peu l'équivalent de AWK ou PERL actuellement.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par AncalagonTotof . Évalué à 2.
Temps de réponse normal seul ou quand tout le monde ne fait qu'éditer du code.
Lamentable quand une ou plusieurs compilation de grille écran ou de code sont en cours.
Rien à voir avec la liaison entre les vieux terminaux et l'AS400, largement assez rapide.
Au passage, séquence vieux con : le terminal ressemblait à ça. Le clavier était magique, à peu près au niveau de sensation d'un modèle M.
Mais il fait un bruit d'enfer, facilement désactivable.
En effet, il suffisait de passer un doigt par une ouverture à l'arrière pour attraper les fils de l'électro-aimant.
Oui, un électro-aimant ! Appuis sur une touche = électro-aimant qui attire une plaque de métal qui fait un gros "clac" !
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
OK, c'est le setup système en fait. Mais cela semble normal car on privilégiait plutôt les processus en fond (faut pas oublier que ce sont des machines de batch…) De plus je pense que vous étiez tous dans le même espace de travail (AS400 fait des espaces comparables aux machines virtuelles de java ou les conteneurs de nos jours puisque c'est au niveau OS)
Au passage, ce sont ce genres d'aventures qui font qu'on pensait avant de coder… De nos jours, les gens n'ont pas honte de déboguer en live, tellement ils n'y a plus de limitation ressenti (même quand on fait une boucle infinie) ; et quand tu parles d'optimisation tu passes pour une sorte d'extraterrestre (et répondre que de toute façon la RAM ne coûte plus rien ou que tout le monde a l'ADSL et un processeur qui a moins de deux ans)
Merci pour les photos ; côté claviers on faisait compacte aussi (et on s'étonne qu'il y ait de plus en plus de TMS de nos jours)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par Xinul . Évalué à 3.
Tout ceci me rappelle une réflexion d'Etienne KLEIN qui disait que "nous avons une mauvaise connaissance de nos connaissances".
Nous avons trop tendance à tout déléguer à des machines, des outils, du code "déjà fait" sans rien comprendre de ce qu'il y a derrière. Et en vrai, presque tout est comme ça, de moins en moins de personnes maîtrisent ce qu'ils font.
Un exemple très parlant : la navigation déléguée à notre smartphone, presque plus personne ne consulte une carte papier avant un trajet, et donc la connaissance de la lecture d'une carte tend à se perdre chez la plupart des gens.
On "fait confiance" à des outils / entreprises / personnes tierces.
# Le cobol est loin d'être mort
Posté par xulops (site web personnel) . Évalué à 0.
… vu que vos (et mes) comptes en banque sont gérés par des programmes écrits en Cobol (ou en Pacbase, langage de 4ème génération qui génère du … Cobol) qui tournent depuis plus de 30 ans.
Je suis curieux de savoir s'il y a une seule grosse banque au monde qui n'utilise pas de mainframe, et donc de Cobol.
Le domaine des mainframes, ce sont les banques et les assurances, et vu la criticité des transferts de fonds, les programmes gérant les transactions bancaires sont ultra-surveillés, et on ne va pas les changer pour le nouveau langage à la mode (encore moins le moribond java, même s'il aura fallu 20 ans au monde de l'IT pour s'apercevoir de la bouse que c'était).
Des entreprises qui utilisent des mainframes, en dehors des banques et assurances, il n'y en a pas des masses. les entreprises ont préféré opter pour le petit frère mois coûteux (c'est relatif) : l'AS/400, qui lui fait tourner des programmes compilés écrits en RPG (GAP jusqu'à la version 3, ILE ensuite). En RPG, une ligne de code tenait sur une carte perforée, le premier caractère de la ligne indiquant le type de carte (F pour déclarer un accès à un fichier, C pour du code, D pour déclarer une variable, …)
Les développeurs Cobol et RPG n'ont pas à craindre le chômage, ils craignent juste de mourir d'ennui à travailler dans un environnement technique pas vraiment sexy.
[^] # Re: Le cobol est loin d'être mort
Posté par Boa Treize (site web personnel) . Évalué à 5.
Ah ben si ça se fait. Et en Java.
[^] # Re: Le cobol est loin d'être mort
Posté par xulops (site web personnel) . Évalué à 0.
Ben voilà, une seule ligne de troll dans le post et tu es tombé dedans… bon cela dit on était pas vendredi.
Pour redevenir serieux, tu affirmes donc que certaines banques (au moins une) utilisent java pour gérer les comptes bancaires, dis m'en donc davantage. Que des applications périphériques soient en java, sans doute (par exemple la saisie des infos d'un virement), mais la coeur de la gestion, je n'y ai vu que des mainframes, je suis donc curieux de ton "Ah ben si ça se fait, et en Java", développe un peu svp.
[^] # Re: Le cobol est loin d'être mort
Posté par Boa Treize (site web personnel) . Évalué à 3.
Assurance, pas banque. (Mais on en parle de plus en plus pour les banques.) Gestion des paiements (plusieurs centaines de milliers de transactions par an, plusieurs milliards d'euros par an) réécrite en Java tout simplement. Et je parle bien du cœur des traitements (règles métier et persistance) et des batch d'échange de données.
[^] # Re: Le cobol est loin d'être mort
Posté par xulops (site web personnel) . Évalué à -2.
Je dis que les lapins mangent des carottes et pas des choux, tu me réponds "si, des choux".
Du coup je demande quels lapins, tu me réponds "une chêvre".
Bref, faut rester concentré un peu.
Compare donc tes centaines de milliers de transactions par an avec :
- virements bancaires en France (uniquement) en 2018 : 4 milliards (+ d'un côté, - de l' autre)
- paiements par CB (en France toujours) : 12 milliards
Ca fait 54 millons de transactions par jour (vs moins d'un million par an). Alors certes, c'est toutes banques confondues, mais les banques ne travaillent pas qu'en France non plus, je n'ai pas trouvé de chiffres mondiaux en moins de 30s.
Java et Cobol, ce n'est pas le même monde, un point c'est tout.
Les mainframes coûtent très (très très très) chers, et les banques ne les ont pas encore balancés pour de très bonnes raisons.
[^] # Re: Le cobol est loin d'être mort
Posté par Boa Treize (site web personnel) . Évalué à 5.
C'est toi qui a inclus l'assurance dans ton message initial…
[^] # Re: Le cobol est loin d'être mort
Posté par xulops (site web personnel) . Évalué à -5.
Quand on sait pas lire correctement … ou qu'on ne veut pas … 没办法
Je disais récemment sur un autre journal que la langue française, malgré toutes ses qualités, n'était pas la meilleure langue pour débattre. Force m'est d'admettre que ce n'est pas qu'un problème de langue. Comme disait Brassens : "Quand on est c.., on est c.."
[^] # Re: Le cobol est loin d'être mort
Posté par xulops (site web personnel) . Évalué à 1.
Je me rends compte après coup que la citation de mon précédent message est quelque peu ambigüe. Mon cher Boa Treize, il n'était point dans mes intentions te t'associer à cette magnifique oeuvre de Brassens ; elle m'était bien entendu auto-destinée, vu que je suis encore bien con de venir sur un journal francophone ramener ma science, sachant pertinemment que ça ne génèrera qu'incompréhensions mutuelles.
Le fait d'avoir fait du Cobol sur mainframe dans ma jeunesse, d'avoir passé une bonne partie de ma carrière sur AS/400, ou d'avoir travaillé dans différentes banques ne me donne absolument le droit d'en comparer les technos avec le monde merveilleux de Java qui peut sans doute facilement atteindre les 50 millions de transaction par jour si on y met les moyens, vu que dans la vie tout est une question de temps et d'argent.
Je retourne donc dans ma tanière numérique. Bises (numériques aussi, covid oblige).
[^] # Re: Le cobol est loin d'être mort
Posté par nouknouk (site web personnel) . Évalué à 0.
Je connais un clearer: c'est une sorte de 'super banque' qui gère le registre des dépôts des banques et autres opérateurs notamment dans les chaînes d'acteurs des fonds d'investissements. C'est lui qui détient les registres 'ultimes' et qui dit qu'untel a x parts de truc, y de machin, etc. T'en a 2 dans le monde. Ultra sensible, ça a de la redondance même pour parer à des scénarios incluant plusieurs attaques nucléaires simultanées dans plusieurs capitales. Et c'est pensé pour redémarrer dans l'heure. cf. Wikipédia, ICSD.
C'est du mssql + vb.net
# c'est cette application Web entre le mainframe et le monde extérieur.
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
Oui le COBOL fonctionne mais le problème c est que personne ne veut toucher au COBOL, du coup on met des rustine partout autour plutôt que de faire évoluer le code. Ça coûte moins cher sur le coût car les devs COBOL sont devenus cher. Mais les rustines finissent par lâcher et pire le système devient tellement complexe que personne ne veut plus y toucher.
Pour prendre une analogie c est comme si tu avais une lampe à huile pour éclairer une pièce et pour pouvoir l alumer avec un bouton tu met une étincelle déclenché par un arc électrique en appuyant sur un bouton. Puis tu veut pouvoir le commander avec un ordinateur alors tu rajoute un petit activateur qui appui sur le bouton. La lampe a huile marche très bien mais le système est pas fiable. Ce n est pas les patch qui sont foireux c est qu aujourd hui tu remplace le tout par une led et en plus tu n a plus a le recharger avec de l huile. CQFD.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: c'est cette application Web entre le mainframe et le monde extérieur.
Posté par claudex . Évalué à 3.
Il n'y a pas que ça. Cela implique aussi de modifier un programme existant qui n'a souvent pas une grande couverture de test et une spécification qui s'est perdue (ou qui est contraire au code qui tourne depuis 20 ans). Donc personne ne sait si on peut le modifier, donc c'est plus simple de mettre une rustine que de modifier un truc qui pourrait faire une erreur qui va coûter très cher à la boîte.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# un peu tard mais...
Posté par tisaac (Mastodon) . Évalué à 2.
… cet article paru dans le monde informatique me paraît intéressant par rapport aux discussions ci-dessus.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: un peu tard mais...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
j'avais aussi ceci de SO
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.