Discussion :

[el_slapper]

S'il y a besoin d'une semaine, alors ce n'est pas un problème de langage, mais un problème de process ou un manque d'automatisation des tests ou des déploiements.
Et si tout dépend de tout dans le code, c'est un problème d'architecture du programme. On peut programmer correctement en POO, en architecturant un programme dont les dépendances forment un graphe orienté sans cycles (ou bien avec uniquement de tout petits cycles).

On peut, mais c'est plus difficile. COBOL étant facile, on peut faire des choses fonctionnelles et efficaces sans pour autant avoir à recruter des cadors. Faire de la POO propre, c'est difficile. C'est plus élégant, mais plus difficile.

Perso je ne connais rien à ce domaine mais ce genre d'affirmation, c'est vraiment n'importe quoi : aujourd'hui beaucoup d'interfaces utilisateur sont des appli web, donc si ça se trouve, 80 % "de toutes les transactions financières se font à l’aide de programmes écrits en JavaScript". Et au passage, la citation de Gary Barnett date de 2005 (https://www.theregister.co.uk/2007/0...systems_part2/)...

L'un n'empêche pas l'autre. Du web coté client, du cobol/mainframe coté serveur. C'est vers ça qu'on se dirigeait à la BNP/Paribas quand j'y traînais mes guêtres, au début des années 2000. La partie client du COBOL(souvent, mais pas toujours, en CICS), elle, est bel et bien en train de disparaître. Mais coté serveur, ça reste gigantesque. Cette taille et cette ancienneté posent deux problèmes majeurs aux décideurs qui voudraient remplacer ça. Ca coûtera un bras et demie, et surtout, on perdrait 40 ans de fiabilisations massives(je dis 40 ans, j'ai bossé sur des codes de 1972, soit 47 ans). Refaire à zéro, c'est prendre un risque de fiabilité - pas le genre des banquiers.

[Darkzinus]

Perso je ne connais rien à ce domaine mais ce genre d'affirmation, c'est vraiment n'importe quoi : aujourd'hui beaucoup d'interfaces utilisateur sont des appli web, donc si ça se trouve, 80 % "de toutes les transactions financières se font à l’aide de programmes écrits en JavaScript". Et au passage, la citation de Gary Barnett date de 2005 (https://www.theregister.co.uk/2007/0...systems_part2/)...

Ce n'est pas parce que ton interface est dans une technologie que le "moteur" de la transaction n'est pas en COBOL. Dans le domaine des banques/assurances en tout cas la majorité des applications fonctionne comme ça.