Discussion :

[GPPro]

Justement, vu que le COBOL n'est plus vraiment enseigné nulle part, le nombre de dev COBOL va baisser. Je suppose (et c'est peut-être là que je me plante) que les devs COBOL vont devenir plus chers tout en étant pas forcément aussi bons ni aussi expérimentés.

Bref, est-ce qu'il ne serait pas intéressant pour une banque de prévoir un projet de "recherche" financé en partie par du CIR pour passer à un langage plus répandu, éventuellement avec quelques morceaux dans un DSL adapté aux calculs pour avoir plus d'experts compétents sous la main ?

Vu que le COBOL fonctionne bien, qu'il y a encore des devs compétents et expérimentés, ils peuvent tranquillement se donner 10-20 ans pour recoder un nouvel environnement en parallèle et le tester à fond.

Trop cher coco, et les actionnaires t'en fais quoi ?

[Logan Mauzaize]

De toutes façons COBOL et MVS zOS s'apprennent en moins de deux semaines.

[Ecva233]

De toutes façons COBOL et MVS zOS s'apprennent en moins de deux semaines.

Ouais ... C'est comme le poker 10 minutes pour apprendre les règles, toute une vie pour apprendre à y jouer ...

Typiquement le type de réflexion, que j'ai déjà entendu de la part de collègues, qui maitrisait DB2 soi disant et qui s'estimait "EXPERT" (pas de smiley vomir dommage), pour en discutant s'apercevoir que c'était SQL dont il parlait, et en regardant leur requête de près, c'était bourré dans les clauses de recherches de "OR", "LIKE", "IN" ... A jeter.

Si pour toi apprendre COBOL et ZOS en 15 jours, pour ma part il me faudra 2 heures pour absorber PHP, JAVA, JAVASCRIPT, FLEX et 1 heure pour me tapper UNIX et LINUX ...

Même après 10 ans (entre autre) de dev en cobol (d'AP à Chef de projet), j'estime que j'ai toujours à en apprendre sur cette technologie...

[souviron34]

ils peuvent tranquillement se donner 10-20 ans pour recoder un nouvel environnement en parallèle et le tester à fond.

Très certainement, mais alors il n'y a pas beaucoup de choix de langage, hein ?

Parce que des langages qui survivent les modes et tiennent plus de 20 ans, il n'y en a pas des dizaines.... Or..... il se trouve que COBOL, comme C et Fortran, en font partie (et maintennant sans doute Java)

[gangsoleil]

et maintennant sans doute Java

Avec un bemol tout de meme pour Java, qui est l'obsolescence de certaines API par les nouvelles version de Java : un code pas trop esoterique en Java 1.3 ne tournera pas en 1.7, du moins pas sans un certain nombre d'adaptations.

Cela implique que si tu fais un gros developpement dans une version, tous les correctifs devront etre fait dans cette version, sans pouvoir utiliser les nouveautes des versions futurs, car utiliser ces nouveautes impliquerait une re-ecriture de pas mal de codes.

[GPPro]

Avec un bemol tout de meme pour Java, qui est l'obsolescence de certaines API par les nouvelles version de Java : un code pas trop esoterique en Java 1.3 ne tournera pas en 1.7, du moins pas sans un certain nombre d'adaptations.

Cela implique que si tu fais un gros developpement dans une version, tous les correctifs devront etre fait dans cette version, sans pouvoir utiliser les nouveautes des versions futurs, car utiliser ces nouveautes impliquerait une re-ecriture de pas mal de codes.

Je veux bien des exemples là... D'un point de vue bibliothèque standard c'est juste faux cette affirmation.

[Logan Mauzaize]

Ouais ... C'est comme le poker 10 minutes pour apprendre les règles, toute une vie pour apprendre à y jouer ...

Typiquement le type de réflexion, que j'ai déjà entendu de la part de collègues, qui maitrisait DB2 soi disant et qui s'estimait "EXPERT" (pas de smiley vomir dommage), pour en discutant s'apercevoir que c'était SQL dont il parlait, et en regardant leur requête de près, c'était bourré dans les clauses de recherches de "OR", "LIKE", "IN" ... A jeter.

Si pour toi apprendre COBOL et ZOS en 15 jours, pour ma part il me faudra 2 heures pour absorber PHP, JAVA, JAVASCRIPT, FLEX et 1 heure pour me tapper UNIX et LINUX ...

Même après 10 ans (entre autre) de dev en cobol (d'AP à Chef de projet), j'estime que j'ai toujours à en apprendre sur cette technologie...

Attention je parle pas de dévenir un expert mais de faire de la maintenance sur des chaînes de calcul.

Pour COBOL, si on parle du langage pur les bases s'apprennent en quelques jours et il n'y a pas énormément de "tricks" vu la pauvresse du langage. Seuls les outils apporter par zOS ou ACU workbench (pour mes deux expériences) prennent un peu plus de temps à apprendre mais on en saisi très rapidement la logique. Et puis c'est même pas vraiment apprendre, tu prends la doc, tiens il existe tel truc tu reprends le snippet et c'est partie.

Pour zOS, j'avoue que c'est un poil plus complexe. Mais l'essentiel étant JCL et CICS, je pense que ca s'apprend également très rapidement.

Pour DB2 dont je n'ai pas parlé ici, je pense pas qu'on voit souvent tourner des trucs ultra-sorcier. La totalité des programmes que j'ai manipulé faisaient de l’appareillage ou de la recherche simple. C'est comme pour Oracle tu peux faire des requêtes analytiques, hiérarchiques ou autre mais combien les utilisent ?

De toutes façons, je parlais pas de devenir expert mais développeur de maintenance.
Et c'est idem pour Java, ca s'apprend en quelques jours si on fait l'impasse sur quelques "surprises" du langage. L'essentiel étant l'utilisation de la Javadoc et l'écosystème, pas le langage en lui-même.

Avec un bemol tout de meme pour Java, qui est l'obsolescence de certaines API par les nouvelles version de Java : un code pas trop esoterique en Java 1.3 ne tournera pas en 1.7, du moins pas sans un certain nombre d'adaptations.

Cela implique que si tu fais un gros developpement dans une version, tous les correctifs devront etre fait dans cette version, sans pouvoir utiliser les nouveautes des versions futurs, car utiliser ces nouveautes impliquerait une re-ecriture de pas mal de codes.

Java 1.3 est largement déprécié, le strict minimum aujourd'hui est Java 1.4 qui lui même est également "obsolète" mais au moins l'API est stabilisée et suffisamment étoffée.
Depuis il y a relativement moins de problèmes. Après rien n'empêche de continuer à travailler sur la version de départ.

Je veux bien des exemples là... D'un point de vue bibliothèque standard c'est juste faux cette affirmation.

Justement le langage est rétrocompatible mais concernant les APIs c'est beaucoup moins vrai. C'est d'ailleurs une erreur courante.

Ce qui est d'ailleurs un vrai casse-tête quand tu as une API qui peut être utilisée par plusieurs versions de la Java.

PS : :vomi

[gangsoleil]

La liste des deprecated de la 1.7 : ici

Elle est encore plus longue en 1.6, a peu pres pareil en 1.5, et j'ai pas regarde pour 1.4

La liste des incompatibilites entre 1.7 et 1.6 est disponible ici
La liste des incompatibilites entre 1.6 et 1.5 est disponible ici

Je n'ai pas trouve la liste d'incompatibilite entre 1.3 et 1.5, mais ca doit etre interessant, vu que les changements entre 1.4 a 1.5 sont legions.

Enfin, lorsqu'on voit que des jeux comme minecraft ne supporteront bientot plus java 5, c'est a dire que tu ne pourras plus jouer avec cette JVM, je pense que ce n'est pas juste pour embeter le monde.

Java 1.3 est largement déprécié, le strict minimum aujourd'hui est Java 1.4 qui lui même est également "obsolète" mais au moins l'API est stabilisée et suffisamment étoffée.
Depuis il y a relativement moins de problèmes. Après rien n'empêche de continuer à travailler sur la version de départ.

Oui, c'est largement deprecie comme tu dis, et c'est bien le soucis sur des applications ecrites pour durer plus de 15 ou 20 ans.

PS : ceci dit, je m'en fou, je fais du C

[GPPro]

La liste des deprecated de la 1.7 : ici

Elle est encore plus longue en 1.6, a peu pres pareil en 1.5, et j'ai pas regarde pour 1.4

La liste des incompatibilites entre 1.7 et 1.6 est disponible ici
La liste des incompatibilites entre 1.6 et 1.5 est disponible ici

Je n'ai pas trouve la liste d'incompatibilite entre 1.3 et 1.5, mais ca doit etre interessant, vu que les changements entre 1.4 a 1.5 sont legions.

Enfin, lorsqu'on voit que des jeux comme minecraft ne supporteront bientot plus java 5, c'est a dire que tu ne pourras plus jouer avec cette JVM, je pense que ce n'est pas juste pour embeter le monde.


Oui, c'est largement deprecie comme tu dis, et c'est bien le soucis sur des applications ecrites pour durer plus de 15 ou 20 ans.

PS : ceci dit, je m'en fou, je fais du C

C'est bien ce que je dis, ton affirmation est fausse. Deprecated ne veut pas dire incompatibilité hein... Juste qu'il y a un remplaçant dans la nouvelle version, mais l'ancienne version est toujours là. Au niveau source la rétro-compatibilité existe.

[ManusDei]

Parce que des langages qui survivent les modes et tiennent plus de 20 ans, il n'y en a pas des dizaines.... Or..... il se trouve que COBOL, comme C et Fortran, en font partie (et maintennant sans doute Java)

Vu les discussions que j'ai lues sur le forum, en dehors de la finance (combien de divisions ? comme dirait l'autre), le COBOL est aussi courant que le Brainfuck. Et il n'est plus vraiment enseigné nulle part, contrairement au C ou C++ qui sont toujours autant utilisés et enseignés, justement.

J'ai l'impression, avec ce que j'ai lu sur ce forum et ailleurs, que le COBOL est là par habitude (ce qui n'est pas un mal), et vu qu'une pénurie d'informaticiens expérimentés sur COBOL guette, je trouve ça risqué de rester là dessus.

[souviron34]

Vu les discussions que j'ai lues sur le forum, en dehors de la finance (combien de divisions ? comme dirait l'autre), le COBOL est aussi courant que le Brainfuck. Et il n'est plus vraiment enseigné nulle part, contrairement au C ou C++ qui sont toujours autant utilisés et enseignés, justement.

J'ai l'impression, avec ce que j'ai lu sur ce forum et ailleurs, que le COBOL est là par habitude (ce qui n'est pas un mal), et vu qu'une pénurie d'informaticiens expérimentés sur COBOL guette, je trouve ça risqué de rester là dessus.

Tu crois que le Fortran est plus enseigné ??

Ce qui n'empêche pas - il suffit d'allez voir le forum dédié - que c'est toujours très utilisé dans son milieu de prédilection..

Pour Cobol, je ne sais pas, mais je doute que ce soit franchement différent.. Cela fait plus de 15 ans que j'entend dire que le Fortran ou le C vont disparaître, parce que soi-disant etc etc.. Ce que je constate, c'est que non seulement ils continuent, mais même ils progressent par rapport à il y a 6 ou 7 ans, certaines boites s'étant finalement aperçues que faire une migration pour faire une migration, c'était franchement pas terrible... pour des oiseaux de mauvais augures qui, eux, se sont plantés (par exemple où est l'omni-potence du C++ qu'on nous promettait entre 2002 et 2006 ?? )

[gangsoleil]

C'est bien ce que je dis, ton affirmation est fausse. Deprecated ne veut pas dire incompatibilité hein... Juste qu'il y a un remplaçant dans la nouvelle version, mais l'ancienne version est toujours là. Au niveau source la rétro-compatibilité existe.

Il faut regarder plus que le premier lien : les deux suivants listent les incompatibilites entre versions successives des JVM.

Et quand je lis des phrases comme ca :

However, the changes made in the JDBC 3.0 API are not source compatible.

je pense qu'il y a des incompatibilites.

http://www.oracle.com/technetwork/ja...atibilities1.4

[GPPro]

Il faut regarder plus que le premier lien : les deux suivants listent les incompatibilites entre versions successives des JVM.

Et quand je lis des phrases comme ca : je pense qu'il y a des incompatibilites.

http://www.oracle.com/technetwork/ja...atibilities1.4

Jdbc n'est pas dans le standard (à ma connaissance).

[Logan Mauzaize]

Tu crois que le Fortran est plus enseigné ??

Ce qui n'empêche pas - il suffit d'allez voir le forum dédié - que c'est toujours très utilisé dans son milieu de prédilection..

Pour Cobol, je ne sais pas, mais je doute que ce soit franchement différent.. Cela fait plus de 15 ans que j'entend dire que le Fortran ou le C vont disparaître, parce que soi-disant etc etc.. Ce que je constate, c'est que non seulement ils continuent, mais même ils progressent par rapport à il y a 6 ou 7 ans, certaines boites s'étant finalement aperçues que faire une migration pour faire une migration, c'était franchement pas terrible... pour des oiseaux de mauvais augures qui, eux, se sont plantés (par exemple où est l'omni-potence du C++ qu'on nous promettait entre 2002 et 2006 ?? )

Fortran (ou ces équivalents) sont uniquement enseignés aux étudiants scientifiques (SM, Physique, etc.) comme initialisation à la programmation. Dans les formations informatique, ils ne sont pas du tout abordés ils me semblent.

Concernant le COBOL, il n'est plus enseigné en région Centre (une région avec un fort historique bancaire) depuis longtemps à ma connaissance. Pour Midi-Pyrénées, ils ont arrêtés de l'enseigner entre 2007-2009.

C'est bien ce que je dis, ton affirmation est fausse. Deprecated ne veut pas dire incompatibilité hein... Juste qu'il y a un remplaçant dans la nouvelle version, mais l'ancienne version est toujours là. Au niveau source la rétro-compatibilité existe.

En règle générale, une méthode passée "deprecated" en version N est supprimée en N+1. C'est d'ailleurs l'intérêt du "deprecated" (Attention, ca va disparaître !).
Par ailleurs il y a de nombreuses méthodes qui sont modifiées/supprimées sans passer par la case "deprecated".

Jdbc n'est pas dans le standard (à ma connaissance).

Si si depuis Java 1.1

[el_slapper]

Justement, vu que le COBOL n'est plus vraiment enseigné nulle part, le nombre de dev COBOL va baisser. Je suppose (et c'est peut-être là que je me plante) que les devs COBOL vont devenir plus chers tout en étant pas forcément aussi bons ni aussi expérimentés.

Ce raisonnement parait cohérent, mais ce n'est pas ce que je constate. Ceux qui survivent, les rares qui entrent, sont de niveau de plus en plus haut. C'est mon impression, et elle peut être fausse, mais celà fait des années que je n'ai plus vu en cobol de mauvais en nombre. Alors qu'en nouvelles technos, il en sort des pelletées chaque année(des bons aussi, hein).

Il me semble qu'un filtrage a été appliqué. Celui qui fait encore du Cobol en 2013, c'est rarement un mauvais.

Bref, est-ce qu'il ne serait pas intéressant pour une banque de prévoir un projet de "recherche" financé en partie par du CIR pour passer à un langage plus répandu, éventuellement avec quelques morceaux dans un DSL adapté aux calculs pour avoir plus d'experts compétents sous la main ?

Euh, Cobol est simple, mais puissant dans son domaine. Il permet, en natif, de faire des trucs impensables en JAVA/.NET :

• une gestion native des formats numériques étendus et binaire codé décimal, en plus du classique binaire.
• une gestion simple et intuitive des formats en virgule fixe
• un switch (true)
• des performances inégalées sur du traitement de fichiers

... et sans doute bien d'autres.
Il y a aussi des astuces de code très difficille à convertir. Le REDEFINES est devenu le cauchemar de toute personne impliquée dans un projet de conversion cobol==>Nouvelle techno.

Autre détail amusant, il n'y a pas de gestion dynamique de la mémoire en cobol. C'est une faiblesse. C'est aussi une force, parceque ça garantit, dès la compilation, qu'il n'y aura aucune fuite mémoire.

Tout ça, ça n'existe pas dans un langage moderne mainstream.

Vu que le COBOL fonctionne bien, qu'il y a encore des devs compétents et expérimentés, ils peuvent tranquillement se donner 10-20 ans pour recoder un nouvel environnement en parallèle et le tester à fond.

Combien ça coute? Combien ça rapporte?

J'ai déjà cité cette anecdote, mais je la répète. été 2011, on me charge de chiffrer un nouveau batch en cobol. Voyant que je reçoit des fichiers d'UNIX au début, que je renvoie des fichiers sous UNIX à la fin, et que mes référentiels sont parfaitement accessibles depuis UNIX, je demande
"_Mais pourquoi vous ne faites pas ça en JAVA, histoire d'avoir tout en UNIX - on a un historique catastrophique sur les applis bisystème MVS-UNIX?
_COBOL coute deux fois moins cher à développer que JAVA, connard. Alors tu fais ton boulot."

Qui va investir 20 ans de refonte manuelles de programmes fonctionnant bien, vivant sur un environnement stable, pour les migrer sur des environnements instables, deux fois moins performants, et deux fois plus couteux à développer?

[GPPro]

En règle générale, une méthode passée "deprecated" en version N est supprimée en N+1. C'est d'ailleurs l'intérêt du "deprecated" (Attention, ca va disparaître !).
Par ailleurs il y a de nombreuses méthodes qui sont modifiées/supprimées sans passer par la case "deprecated".

Pas pour la lib standard Java, tu peux voir le détail dans les liens fournis par Gangsoleil.

It is recommended that programs be modified to eliminate the use of deprecated APIs, although there are no current plans to remove such APIs entirely from the system.

[ManusDei]

Ce raisonnement parait cohérent, mais ce n'est pas ce que je constate. Ceux qui survivent, les rares qui entrent, sont de niveau de plus en plus haut. C'est mon impression, et elle peut être fausse, mais celà fait des années que je n'ai plus vu en cobol de mauvais en nombre. Alors qu'en nouvelles technos, il en sort des pelletées chaque année(des bons aussi, hein).

Ok. J'avais cru comprendre qu'il y avait de moins en moins de gens compétents en COBOL, et que ça allait continuer à décroitre avec les départs à la retraite.

Ce qui à terme allait poser problème.

[Ecva233]

J'ai déjà cité cette anecdote, mais je la répète. été 2011, on me charge de chiffrer un nouveau batch en cobol. Voyant que je reçoit des fichiers d'UNIX au début, que je renvoie des fichiers sous UNIX à la fin, et que mes référentiels sont parfaitement accessibles depuis UNIX, je demande
"_Mais pourquoi vous ne faites pas ça en JAVA, histoire d'avoir tout en UNIX - on a un historique catastrophique sur les applis bisystème MVS-UNIX?
_COBOL coute deux fois moins cher à développer que JAVA, connard. Alors tu fais ton boulot."

Euh véridique dans la terminologie ?

[jouana]

En même temps les entreprises forment les entrant au COBOL.

J'ai fait un mois de formation en COBOL pour faire du Flex/java et maintenant de l'asp.net/C#.

Et le COBOL et loins de mourir la plupart des gros systèmes de gestion tourne la dessus, il y a un patrimoine vieux mais qui fonctionne et les entreprises ne veulent pas vraiment le changer, question de coût et c'est risqué.

Je pense que cette techno à encore de beaux jours devant elle.

Après c'est vrai que les "EXPERTS" commence a disparaître avec les départs en retraite, je vois la personne qui ma formé qui est parti à la retraite il connaissait des bugs sur des bouts de code qui était bon juste à cause de pb de compilation. Mais bon y a 40 ans de décorticage du COBOL compilé pour voir la réaction de certaines actions.

Le futur de l'informatique et pas mal sur le java, c#, php et toutes les technos de ce style, elle nécessite moins de compétence que le C et le C++ ou d'autres langage de (plus) bas niveau, ce qui permet de boucher les trous(postes) avec des gens aux compétences discutable.

[rmaker]

Le futur de l'informatique et pas mal sur le java, c#, php et toutes les technos de ce style, elle nécessite moins de compétence que le C et le C++ ou d'autres langage de (plus) bas niveau, ce qui permet de boucher les trous(postes) avec des gens aux compétences discutable.

Ouh lala, ça va péter quand des gens comme gangsoleil vont lire ça...

Au dela, le plus simple, c'est peut être une question d'affinité aussi avec le domaine fonctionnel. Si tu kiffes l'embarqué et l'électronique, C, C++, ARM. Si tu aimes les banquiers tape des pieds fais plutot du java c#... Trouver le métier qui plait, puis les standards de fait.

Cela dit, au lieu trouver un domaine fonctionnel intéressant, on peut déja orienter vers industrie ou banque finance, ou embarqué. Ca dégrossit déja pas mal.