Dommage... Juste au moment où je n'en ai plus besoin

J'ai pensé à toi une minute en le lisant... j'ai eu un peu de nostalgie de cet AS/400 qui nous giclait le code sans plus d'explication, puis je me suis réveillé, c'était qu'un cauchemar.

Mais ça n'empêche que le bouquin était fun à lire, plus pour l'historique que pour le côté pratique

Déjà en 1995, je trouvais ça complètement obsolète. 15 ans plus tard, j'ose espérer que le but de ce livre est d'aider des "nouveaux" à faire évoluer de vieux machins en COBOL vers un truc plus moderne.
Quant aux banques et assurances, elles ont de moins en moins de COBOL qui reste dans les placards.

Et le COBOL objet, ça me fait doucement marrer. Encore plus que le Perl objet. Je me souviens de ma prof de COBOL nous disant que le COBOL objet étant arrivé largement après les autres n'avait pas reproduit les mêmes erreurs que le C++. Mouahaha.

Le bouquin c'est surtout axé sur la maintenance en fait.

D'autres le savent probablement mieux que moi, mais il doit rester qqs gros comptes qui continuent à faire tourner du COBOL parce que: "if it ain't broken, don't fix it"

Je ne sais pas d'ou tu tiens cette information, mais pour avoir des connaissances dans les banques et assurances, ils continuent d'engager pas mal de gens (et de les former, vu que l'on apprend quasiment plus COBOL nul part), pour maintenir ET realiser de nouveaux developpement.

Et ne parlons pas des surcouches, genre screen reader, pour essayer de cacher la merde.

A l'armée belge, ils sont toujours en Cobol aussi

oula Merlin

Même si Java ou .Net on prit le pas pour le développement décentralisé, les mainframes continuent d'être largement alimenté en développement Cobol

Keeper > +1

zion > Et avant l'AS/400, y avait le mainframe du ministère. Nom du système: Roscoe

Oh putaaa*n oui, j'avais oublié ce nom! (et le JCL :o)
Tu vas me faire faire des cauchemars