Discussion :

[tpericard]

Typiquement la réaction de personnes qui n'y connaissent rien en technique et recrutement, vous lui avez fait une fleur en jetant son CV.

Quand on a une personne avec 7 ans d'expérience, on ne parle pas seulement d'expérience dans un langage, c'est surtout 7 ans d'expérience PROFESSIONNELLE, avec tout ce que ça comporte comme apprentissage: travail en équipe, gestion des priorités, gestion du stress, connaissance du flux de travail, des outils de ticketting, test, documentation...
...

Le problème de nos jours c'est l'instantanéité. Une entreprise ne peut attendre qu'une personne expérimentée soit au top de la technique demandée. Il faut qu'elle la connaisse déjà. Après, c'est l'image complètement surannée (à tort) que renvoie le Cobol. Pourtant, vu la sensibilité financière de certaines applications qui gèrent des transactions énormes, il est clair qu'une personne expérimentée dans ce cas est précieux.

En résumé, c'est réellement dommage de se priver d'une telle expérience. La technique ça s'apprend toujours ... pas l'expérience !

[ShigruM]

Le problème de nos jours c'est l'instantanéité. Une entreprise ne peut attendre qu'une personne expérimentée soit au top de la technique demandée. Il faut qu'elle la connaisse déjà. Après, c'est l'image complètement surannée (à tort) que renvoie le Cobol. Pourtant, vu la sensibilité financière de certaines applications qui gèrent des transactions énormes, il est clair qu'une personne expérimentée dans ce cas est précieux.

En résumé, c'est réellement dommage de se priver d'une telle expérience. La technique ça s'apprend toujours ... pas l'expérience !

oui sauf que on avait 11 cv et il y'en avait des bien plus intéressant que le dev cobol...
Le dev cobol n'étais pas le seul a postuler à notre offre, et d'autres avait de 'expérience et connaissait très bien le python et la data science.

Ton dev cobol il vas devoir faire face a une concurrence de profil féroce quand il cherchera un nouveau poste. Si j'ai un dev qui as de l'expérience et connais les technos que nous demandons dans l'annonce je vois pas pourquoi je prendrais le développeur cobol à la place.

les CV quand on en reçoit trop de toute manière on fait un trie rapido, faute d'orthographe (oui oui je sais je suis mal placé pour faire cette remarque) ou mots clé qui nous intéresse inexistant = poubelle
Le dev cobol avait quand même réussie cette épreuve mais il a échoué a la 2ieme.

[el_slapper]

Depuis 2002 COBOL est censé supporter la POO.

cf la réponse de pyramidev. la POO en COBOL, c'est juste pour être compatible avec JAVA. L'utiliser dans un autre cadre, c'est être assez maso.

(.../...) le kéké qui ira dire au patron, "pas de soucis Boss, on va migrer tout ça en Java en 2 temps 3 mouvements !", soit il est pas encore né, soit il sort de l'asile :-))

soit il va couter 100M€ à son patron(vécu) sur un projet qui va finir à la poubelle.

Il ne faut pas que s'attarder sur la technique, parce que ça s'apprend (même rapidement si le gars est pas trop mauvais).

Par contre, la rigueur et l'algorithmie, c'est autre chose .

Exactement. La formation intellectuelle, il n'y a que ça de vrai.

(.../...)En tous cas, merci de démontrer que quand on se fait rembarrer c'est pas forcément parce qu'on est mauvais, ça peut être ceux d'en face qui le sont.

dans mes bras. Certains employeurs ne nous méritent pas(et, dans certains cas, même si on est très mauvais, ils ne nous méritent pas quand même).

[Aiekick]

ya pas moyen de convertit des turc cobol vers d’autres langages ? le cobol est assez simple mine de rien, mais si sa lecture est ardue.

[Portekoi]

Typiquement la réaction de personnes qui n'y connaissent rien en technique et recrutement, vous lui avez fait une fleur en jetant son CV.

Quand on a une personne avec 7 ans d'expérience, on ne parle pas seulement d'expérience dans un langage, c'est surtout 7 ans d'expérience PROFESSIONNELLE, avec tout ce que ça comporte comme apprentissage: travail en équipe, gestion des priorités, gestion du stress, connaissance du flux de travail, des outils de ticketting, test, documentation...

Une personne qui fait un virage technologique comme ça, c'est soit un désespéré (peu probable vu qu'il y a de la demande, mais d'autres facteurs peuvent entrer en compte), soit quelqu'un qui est vraiment motivé à apprendre ou professionnaliser sa connaissance personnelle, et ça, sans entretien, impossible de le savoir.

En tous cas, merci de démontrer que quand on se fait rembarrer c'est pas forcément parce qu'on est mauvais, ça peut être ceux d'en face qui le sont.

Parfaite ta réponse.

Perso, quand je suis arrivé en 2005 dans le monde bancaire, d'autres devs étaient présents mais aucun n'a voulu se mettre à Cobol alors que c'est une opportunité unique.

Je n'étais pas devenu un expert mais dans une petite structure, tu n'as pas le choix alors je m'y suis mis. Aujourd'hui, j'ai quitté la banque mais je garde sur mon CV Cobol à côté de langages comme C#/VB.net, ASP/PHP etc.

Le plus dur pour moi, c'était d'appréhender le main frame. Toutes les commandes à apprendre... pas évident.

Après, quand tu crées des MQ Listener avec un programme Java ou un autre interfaçage, ça devient vraiment intéressant. Pareil avec la consommation d'API.

Quand j'ai découvert STRPCCMD pour lancer IE sur un lien afin de faire la transition de l'AS400 vers le web, mon boss a eu l'impression que j'avais découvert le feu.

Bref, Cobol, c'est de la boulette sur un CV et ça vaudra de l'or d'ici 10 ans.

[Portekoi]

ya pas moyen de convertit des turc cobol vers d’autres langages ? le cobol est assez simple mine de rien, mais si sa lecture est ardue.

C'est compliqué. C'est pas tant Cobol qui pose souci mais bien les écrans et c'est juste un enfer. Avec les fonctions d'appel, les déclencheurs etc.

[Demi Humain]

Bonjour,

Ayant 30 ans d'expérience dans le Mainframe et Formateur Mainframe depuis plusieurs années, je vois passer beaucoup de "Profils" différents, issus le plus souvent de Pole Emploi, voulant se reconvertir dans ce domaine.

Pour l'instant, j'avoue n'avoir pas réussi à savoir quel Candidat serait le plus apte à suivre une formation ou pas. J'ai pu constater des "Doctorant" ayant un parcours impressionnant (que j'aimerais avoir :-), ne trouvant pas de travail à cause de leur spécialisation, avoir beaucoup de mal à écrire un programme COBOL et d'autres "Doctorant" ayant vraiment la "fibre de la programmation" et réussir très bien.

Moi-même, n'ayant aucun diplôme, j'ai été embauché par une ESN (Entreprise du Service Numérique) comme CAP GEMINI, merci à Elle de m'avoir donné ma chance, qui m'a certainement trouvé des qualités pour m'avoir gardé des années comme salarié, après une reconversion.

On voit bien qu'il existe une "sorte de fonctionnement d'esprit" qui correspond à un Programmeur et je suis persuadé que la personne qui possède ce mode de fonctionnement peut réussir dans n'importe quel langage.

Ayant moi-même suivi le parcours du CNAM ,Analyste Programmeur d'application en JAVA CP16, j'ai eu la meilleur note 19/20 quand il a fallu écrire un projet entièrement en JAVA (UE NFA019), certainement que mon expérience de programmeur en COBOL m'a beaucoup aidé et a été un atout supplémentaire.

J'avoue que je suis comme Obélix, ce domaine m'a toujours passionné quand je suis tombé dedans, avec les premiers micros ordinateurs ayant 1K de mémoire :-) sur lequel on programmait du BASIC et on affichait le résultat sur notre télé parce qu'il n'y avait pas d'écran :-) et les programmes étaient enregistrés sur des cassettes dans les vieux magnétophones qu'on voit dans les marchés aux puces maintenant :-).

Il est vraiment très difficile de définir "un type de Profil", tellement la passion et la volonté de réussir sont des atouts qui peuvent changer complètement toute la donne, mais c'est vrai, c'est un risque pour la Société qui embauche ce type de Candidat.

Cordialement

René

[Jean GVE]

Je suis ancien développeur COBOL et viens de prendre la retraite... J'ai formé quelques jeunes à ce langage durant ces quelques dizaines d'années de pratique donc la relève existe car je ne suis pas seul dans ce cas !
Je pense qu'à l'avenir il faut ajouter une possibilité plus simple de définition des chaines de caractères (quelque chose ressemblant au C ou au Pascal) en conservant celle, très "verbieuse", existante car elle est rigoureuse et souvent nécessaire voire même indispensable ; mais il faut surtout normaliser les interfaces avec les autres langages en particulier ceux du Net et plus généralement ceux de l'interface Homme/Machine, CICS avec ses écrans 80*24 a fait son temps et ses ouvertures sont insuffisantes...
L'idéal serait au niveau matériel de disposer d'extension au PC pour effectuer des calculs sur des chaînes de caractères (chiffres) type DISPLAY du COBOL, sur des chaines DCB (Décimal Codé Binaire, le COMP-3 du COBOL). Extension sous forme d'un Coprocesseur ou d'une Carte Opérateur qui serait activé à la rencontre d'instructions Cobolistiques spécifiques.

Sans faire de politique, je vais paraphrasé M. MACRON « T'as qu'à traverser la rue pour trouver du boulot », je pense qu'à la place de rue il dire pays. Mais proposer à un jeune (d'Aquitaine ou du Roussillon) de se former au COBOL et de lui assurer du travail très bien payé... en région parisienne ! Je pense que la motivation sera nettement moindre, il acceptera la formation permettant de toucher quelques subsides mais limitera sa recherche qu'à sa région voire à sa ville et restera à la charge des ASSEDIC.

[Jean GVE]

ya pas moyen de convertit des turc cobol vers d’autres langages ? le cobol est assez simple mine de rien, mais si sa lecture est ardue.

Tu as à la fois raison et tord !
Le code du programme est assez proche du langage parlé (les Étasuniens, à l'origine du COBOL, ne parlant pas français comme tout le monde) par contre il est vrai que les descriptions de données, peuvent inspirer une certaines méfiances envers les Cobolistes, et faire fuir tout adepte des langages plus récents.
ON NE NOUS DIT PAS TOUT (je cite) ! Les différentes normes ont simplifié un peu (mais pas encore suffisamment) toutefois dans de nombreuses boîtes les règles de codage empêchent certaines élucubrations mais au prix d'un plus grand nombre de lignes (ce qui peut affoler encore plus).
Mais ce qui n'arrive pas qu'aux (vieux) programmes COBOL c'est qu'il ont subi les outrages de dizaines de maintenances effectuées par des programmeurs différents et toujours dans le feu de l'action (le nez dans le guidon, comme on dit) et la documentation date de l'Époque ??? Celle dont même le programme d'origine n'a pas respecté (pour de bonnes raisons mais qui n'ont jamais été transcrites).
Dans une vie de développeur et/ou de chef de projet a-t-on déjà vu un programme avec une doc correspondant ?
C'est comme : Avec l'informatique ON n'utilisera plus de papier... ON n'a jamais consommé autant de papier depuis que l'Informatique sévit !

[Artemus24]

Salut à tous

Tous ces vieux systèmes bancaires (en COBOL ou non) sont des bombes à retardement.

Ce ne sont pas des vieux systèmes bancaires.
Ce n'est pas le langage qui fait d'un système, un vieux machin obsolète, mais plutôt l'incapacité à le faire évoluer.

Je suis d'accord avec vous que ce sont des bombes a retardement.
A commencer par le manque de programmeurs en cobol sur le marché du travail.
Puis le niveau de compétences des jeunes en cobol. Ce ne sont pas de leur faute mais bien des écoles qui ne font plus de formations en cobol.
Ils ont décrété que ce langage étaient devenus obsolètes !

Ensuite, la connaissance des systèmes bancaires se perd car la transmission des anciens vers les jeunes ne se font plus.
Pour cause, il y a de moins en moins de jeunes qui ont la double compétence, bancaire et informatique.

J'ai vu des vieux projets tournant toujours, personne n'ayant plus aucune compétence sur la techno utilisé.

J'ai connu cela avec l'assembleur sur mainframe dans les années 1980. Tôt ou tard, les banques ont dû faire un audit et migrer vers du cobol.
Ce sera aussi le cas avec le cobol, mais y aura-t-il la volonté de le faire avant une catastrophe ?

Autant dire que ces vieux systèmes sont totalement à la ramasse en terme de sécurité, ...

C'est toalement faux ! Avez-vous déjà entendu parlé de RACF sous mainframe IBM ?

...mais en cas d'intrusion sur le réseau interne c'est la catastrophe assurée.

Vous dites n'importe quoi. On parle de mainframe en gros système IBM, pas d'un serveur windows ou linux.

C'est de voir que des personnes se croient "supérieures" à d'autres parce qu'elles utilisent un langage plus récent.

Entièrement d'accord avec vous. Et quand ils ont un grave problème, ils se tournent justement vers ces gens qu'ils dénigrent parce qu'ils ont la compétence.
Moins ils en ont dans la tête et plus ils se sentent supérieurs.

COBOL est beaucoup plus proche de l'assembleur.

Encore un qui n'a jamais programmé en Cobol et qui l'a ramène.
Il n'y a rien de mieux que d'apprendre la programmation avec un langage de bas niveau.

Ben oui, avec des langages comme python, vous n'avez presque rien à faire, vu que vous avez à votre disposition une multitude de fonctionnalités.

Si ca se trouve, le gars fait du Python sur son temps libre.

Ca ne le rend pas pour autant incompétent en la matière.

l'inconvénient du mainframe, c'est que c'est horriblement coûteux.

Parce que le travail demandé est critique pour une banque, en terme de performance, de sécurité et de volume à traiter.

L'avantage, c'est que c'est horriblement sécurisé.

C'est vrai !

[quote="El_Slapper"]COBOL lui-même a exactement 0 couches de sécurité, parce qu'il est apparu dans un contexte ou l'accès aux machines était très restreint.[quote]
D'ailleurs, qu'est-ce que la sécurité au niveau d'un langage ? Ça n'existe pas !
La sécurité se fait sur les accès aux répertoires, aux comptes, et aux machines.
C'est le rôle du système d'exploitation, ainsi que du réseau de gérer cela, pas dans un langage.

Sous mainframe, c'était toujours le cas.

Il n'y a rien de mieux, point du vue sécurité que les gros systèmes. A votre avis, pourquoi sont-ils encore en usage dans les banques ?

Il est très facile, quand on a les accès, de changer le montant de son compte en banque. C'est détecté en quelques minutes, et personne n'est assez fou pour le faire.

Parce que vous croyez que cela ne soit pas le cas avec des serveurs windows ou linux ?
J'aimerai connaitre votre définition de la sécurité.

Bon, et je raconte toujours cette histoire de 2011. Un jour, on est venus nous demander de chiffrer une refonte d'une chaîne de traitement COBOL. On est arrivé à 110 jours. La dame a râle, dit "il n'y a pas besoin de tout refaire"; mais après analyse, j'ai insisté : sur les 120 composants, seuls 4 étaient réutilisables. La dame a dit "grmble grmlb grmbl", et a demandé des specs techniques. Au final, on a consommé moins de 120 jours. Ce que je n'ai su qu'après, c'est qu'auparavant, elle avant demandé aux gens du JAVA, et que ceux-ci avaient largement dépassé les 200 jours dans leur estimation. Pour faire la même chose.

Qu'essayez-vous de nous dire ? Que les gens de JAVA sont moins compétents que les gens de cobol ?
Franchement, s'il y a une morale à votre histoire, je n'ai rien compris.

Après, évidemment, c'était essentiellement du traitement de masse de fichiers plats, le point fort du COBOL.

Pas de VSAM, NI de DB2, et encore moins du CICS. Juste du JCL, du COBOL et des fichiers séquentiels.
C'est une application bien pauvre !

Le JAVA, c'est facile. L'assembleur, c'est difficile.

Non. Si vous préférez, chaque langage a sa façon de raisonner. Autrement dit, à chacun ses compétences.

j'ai dis que des Cobolistes pour faire des programmes/algorithmes de type calcul/gestion en mode batch n'ont pas besoin d'avoir une très forte connaissance des langages.

N'importe quoi ! Parce que en cobol, vous savez faire des calculs de taux.

Les gars a qui on a dit il y a 30 ans : "z'êtes foutu les loulous, le Cobol c'est HasBeen !"
Je pense que ça les fait bien marrer :-))

Je me marre parce que personne n'a jamais dit ça ! C'est même le contraire, on se marrait en voyant des gens faire des sites web.
Vous voyez bien que personne ne peut deviner à l'avance de quoi sera fait l'avenir.

Pour avoir bossé pour les banques je peux vous dire que c'est très rarement les programmeurs COBOL qui font de la merde mais plutôt les programmeurs JAVA.

Je n'aurai pas dit mieux. Juste une question, les organigrammes et les algorithmes sont-ils encore enseignés à l'école ?

En résumé, c'est réellement dommage de se priver d'une telle expérience. La technique ça s'apprend toujours ... pas l'expérience !

Merci pour votre appréciation !

Moi-même, n'ayant aucun diplôme, j'ai été embauché par une ESN (Entreprise du Service Numérique) comme CAP GEMINI, merci à Elle

Avant vous, il y avait un dénommé M. Georges Cohen, sans diplôme (on dit plus souvent autodidacte) qui a fondé transiciel. Il est devenu millionnaire.

Je suis ancien développeur COBOL et viens de prendre la retraite...

Vous n'êtes pas le seul.

Le gros problème du cobol pour le convertir dans un autre langage, ce sont les zones en "redefines".
Plusieurs zones peuvent porter des noms différents et être associées à la même zone mémoire.

@+

[Pyramidev]

D'ailleurs, qu'est-ce que la sécurité au niveau d'un langage ? Ça n'existe pas !

Ben, si.

Par exemple, le fait qu'un dépassement de tampon puisse entraîner dans certaines circonstances une exécution de code arbitraire n'est possible que dans un langage qui autorise le compilateur à générer un code optimisé qui ne vérifie pas qu'il ne dépasse pas les bornes du tampon dans lequel il écrit.

Autre exemple : une erreur de programmation de type use after free peut entraîner une vulnérabilité. Or, une erreur de type use after free arrive plus facilement dans certains langages que dans d'autres, selon comment la mémoire est gérée dans le langage. En C, cela peut facilement arriver. En Rust, cela ne peut arriver que dans un bout de code dans lequel on désactive explicitement les contrôles du compilateur. Dans un langage comme Java où la mémoire de tout objet est gérée par le ramasse-miettes, un use after free ne peut arriver.

[Artemus24]

Salut Pyramidev.

Je parlais de la sécurité informatique :
--> https://fr.wikipedia.org/wiki/S%C3%A...%27information

@+

[mitteljc]

Ingénieur système dans le monde bancaire, j'ai démarré comme chef de projet avec comme seul bagage, le COBOL. Et j'ai fait de suite du développement en... assembleur. L'adaptation a été très rapide (moins de 2 mois), même si j'ai dû apprendre sur le tas. Comme quoi, passer d'un langage à un autre peut être aisé. Il est donc ridicule de juger un candidat sur ses connaissances des langages. Evidemment, c'est plus simple s'il connaît déjà le langage requis, mais après tout, le langage n'est que la concrétisation d'algorithmes. C'est la logique qui devrait être le meilleur critère de recrutement pour un programmeur. C'est elle qui fait le bon développeur et qui fera gagner du temps donc de l'argent à la société qui le recrute, même si elle doit le former un minimum. Et ce n'est pas parce qu'un programmeur connaît un langage qu'il sait bien programmer. On voit tellement d'horreurs... Je pense que les recruteurs devraient apprendre à recruter. Comme dans beaucoup de domaines, on réfléchit trop à court terme.

Personnellement, j'ai 60 balais et aujourd'hui, dans le cadre de mon boulot, j'écris en PHP, javascript, Perl, Shell script, etc... Comme quoi, même l'âge n'est pas un frein. Ne me parlez plus de COBOL, mais je sais qu'il est encore bien vivant et que dans mon entreprise, on continue à recruter dans ce domaine.

[TJ1985]

Bonjour à tous,

Pour avoir utilisé COBOL pendant une vingtaine d'années, j'affirme que sa disparition est un effet de mode et n'a pas de causes techniques réelles. Entendons-nous, COBOL est un langage particulier, dédié préférentiellement à un domaine particulier : La gestion. Le langage embarque tout le nécessaire pour écrire une application de gestion rapide, performante, fiable et efficace. Dans le cas d'une petite entreprise, un compilateur COBOL et un PC antédiluvien peuvent largement suffire pour répondre aux besoins administratifs de la boîte.

COBOL embarque des structures de données évoluées, une gestion de fichiers sophistiquée, la gestion directe d'écrans, la génération de rapports et les trappes d'exception.
On peut considérer qu'il embarque nativement un quasi-modèle MVC. Ainsi la FILE SECTION serait le modèle, la SCREEN SECTION la vue et la PROCEDURE DIVISION le contrôleur. Il est capable aussi d'attaquer à bas niveau en passant par les structures de données adaptées. Certains compilateurs (je travaillais sous VMS) offrent une interface quasi-complète sur les routines système, permettant de travailler à très bas niveau.

Comme dans tout langage, il est possible soit d'écrire proprement, soit de faire de la m... COBOL est certes verbeux, mais dans le premier cas on obtient un code lisible même par un non-initié ; quelqu'un qui ne connait ni le langage ni le domaine peut se faire assez rapidement une idée du fonctionnement d'une application bien écrite en COBOL simplement à partir de ses sources.

Bien que n'étant pas vraiment généraliste, on peut faire pas mal de choses avec ce bizarre langage. J'ai en mémoire par exemple un système de validation de droits d'accès dans le domaine bancaire. En fait, un parser a été écrit en quelques instructions, qui permet de dire que tel utilisateur du système peut accéder à l'ensemble des comptes commençant par 34, aussi au 56789, surtout pas au 34567 et à l'ensemble de la réception 10 si la rubrique est 00, etc. La syntaxe de définition n'est pas limitée, on peut mettre autant de contraintes que l'on veut, le système retourne un GO / No GO. L'ensemble tient dans une cascade d'instruction INSPECT imbriquées. Il tourne sur un environnement de 2500 postes à chaque interrogation des bases de données centrales, et n'est pas perceptible de l'utilisateur.

Je pense que COBOL est victime de la mode du tout-nouveau-tout-beau, celle qui veut que chaque nouvelle génération de développeurs estime que le passé n'a rien à nous apprendre. C'est une erreur. Dès lors qu'il s'agit de données structurées, tabulaires, COBOL peut être efficace, soit seul, soit en s'appuyant sur une base de données à travers un pré-compilateur. Dans ce cas il est possible d'écrire directement du code SQL dans le source COBOL, ce qui augmente encore la lisibilité du tout. Sur les systèmes centraux il est d'usage de déléguer les tâches de gestion des écrans et des transactions à des couches dédiées, comme, sous VMS toujours, DecFORMS et ACMS - les équivalents existent chez IBM, évidemment. On était capables de faire tourner des applications performantes sur des machines dont la puissance semble ridicule aujourd'hui, avec des temps de réponse qui rendraient jaloux n'importe quel bidouilleur internet actuel (bon, certains travaillent quand même pas mal, d'accord, mais ce n'est pas la règle !)

Bref, COBOL semble faire peur, peut-être aussi parce qu'il a permis à des générations de personnes formées à la comptabilité d'exprimer leurs (absences d') idées en informatique. Les résultats n'ont pas toujours été à la hauteur, ce qui explique la crainte de certains devant des montagnes de code spaghetti, incompréhensible. Cela est un vrai problème. Mais aujourd'hui, je ne vois pas de réelle raison de passer à la poubelle un langage qui permet depuis trente ans de résoudre le même problème : Régler les rapports entre l'entreprise, ses clients et ses fournisseurs, surveiller l'état d'un stock, passer des commandes et les réceptionner, l'activité administrative quotidienne, quoi. COBOL fait tout cela très bien, en offrant l'avantage insigne de fournir des résultats de calcul financier absolument précis, contrairement aux langages courants, même pour les grands chiffres.

En passant, lorsque je lis que la candidature d'un gars est rejetée uniquement parce qu'il a fait 7 ans de COBOL, je tombe de ma chaise : Un gars qui fait du COBOL dans le domaine bancaire est quelqu'un qui non seulement doit maitriser le langage, ce qui s'obtient assez facilement, mais en plus sait comprendre un environnement plutôt complexe à partir d'éléments de code. Car à coup sûr il n'aura pas fait que développer de merveilleuses Apps from scratch, il aura passé l'essentiel de son temps à adapter les applications existantes aux variations réglementaires ou du marché. C'est donc quelqu'un qui sait extraire la substantifique moelle d'un bout de code et est capable de l'enrichir. Toujours dans ce cas, un gars qui travaille depuis 7 ans en informatique bancaire a montré qu'il s'intègre à un groupe, qu'il sait interagir avec les autres et qu'il est fiable. Bref, si j'étais le boss de la boîte qui a reçu ce CV, et partant de l'idée que je ne cherche pas quelqu'un dans le big data ou l'intelligence artificielle, je souhaiterais parler très rapidement à ceux qui l'ont balancé à la poubelle histoire de vérifier la position de leurs bretelles.

Accessoirement, qui sait si dans dix ans la mention de Python sur un CV ne suscitera pas la même hilarité chez certains que celle de COBOL aujourd'hui ? Et qui sait si dans dix ans COBOL ne sera pas en tête des compilateurs dans le domaine commercial ? Après tout, le reporting intégré est tout à fait capable de générer du HTML & similaires et selon le système d'exploitation il est aussi facile d'écrire un serveur en COBOL, si, si !

A part ça, ma langue maternelle est Pascal, j'ai travaillé dans à peu près tout ce qui est procédural, ainsi qu'avec une cohorte de langages dédiés, spécialisés. J'ai aussi sévi avec des langages objets, j'avais d'ailleurs étendu certaines librairies de TurboPascal à l'époque en créant les prémisses de ce modèle, non encore documenté. Ca ne me rend pas plus intelligent pour autant, mais ça démontre que considérer qu'on est un cador uniquement parce qu'on se débrouille avec le dernier langage à la mode est un peu court.

Voilà !

A part ça, excellente journée,

Thierry

[Artemus24]

Salut et merci Thierry pour votre retour d'expérience.

Le première langage que j'ai appris est bien le cobol.
Mais j'ai appris aussi le PL/1, le fortran, l'algol, l'apl, quelques assembleurs, comme le 6502, le z80, le 68000, le 8080 en son temps.
Apprendre des langages, ça forme l'esprit, et donc notre expérience.

Selon moi, Python est un langage à la mode, plus tourné vers les débutants qu'un langage qui va perdurer comme le cobol.
Dans les grands comptes, on ne rencontre pas trop ce langage pour la simple raison qu'il y a déjà un existant et que l'on continue à développer dans le même langage afin de conserver une certaine uniformisation des traitements.
J'ai toujours eu du mal avec les langages interprétés qui consomment beaucoup de temps CPU.

Tout ce que je peux dire, c'est "longue vie au cobol" !
Il n'y a rien de mieux pour faire de la gestion.

@+

[ALT]

[je-raconte-ma-vie]
Oui, je confirme, CoBOL est un langage facile d'accès : je l'ai appris en 1998, puisqu'à l'époque on cherchait des gens pour corriger le bug de l'an 2000.
Donc, des stages de remise à niveau ont été organisés.
Nous étions plusieurs à passer le test de sélection (juste de la logique, rien concernant le langage). La plupart étant des anciens cobolistes.
En algorithmique, certains ont fait de somptueuses usines à gaz, là où quelques instructions suffisaient.
Bref, j'ai été sélectionné, bien que n'ayant jamais connu CoBOL auparavant.
Et j'ai appris l'essentiel en trois semaines, pendant que beaucoup d'autres se contentaient de réviser. Avec des rudiments de MVS, CICS, DB2...
Et je n'ai pas eu l'impression de vivre un cauchemar.
En revanche, ce qui me dépasse, c'est toute la partie d'en-tête du programme (plusieurs centaines de lignes), dont personne ne sait plus très bien ce qu'elles font, mais qui sont indispensables à l'initialisation du programme. Et qu'on recopie religieusement d'un programme à l'autre.

Je me souviens qu'à l'époque, CoBOL était considéré comme dépassé, mais comme beaucoup d'applications bancaires ou pour les compagnies aériennes (entre autres) étaient encore en usage, il fallait intervenir dessus pour changer les formats des dates. D'où les recrutements massifs, y compris de retraités ! Et qu'après, ce serait fini.

À lire certains, je m'aperçois que CoBOL bouge toujours.

[/je-raconte-ma-vie]

Au fait, je suis d'accord avec beaucoup d'entre vous : éliminer un candidat uniquement parce qu'il n'avait pratiqué que le CoBOL est très crétin. Surtout en se payant sa fiole. Il y a une différence entre dire « Bon, on a des candidats qui sont plus adaptés, on l'élimine. » & dire « Hé, regardez-moi ce débile qui en est encore à jouer avec CoBOL ! ».

[Pyramidev]

Pour avoir utilisé COBOL pendant une vingtaine d'années, j'affirme que sa disparition est un effet de mode et n'a pas de causes techniques réelles. Entendons-nous, COBOL est un langage particulier, dédié préférentiellement à un domaine particulier : La gestion. Le langage embarque tout le nécessaire pour écrire une application de gestion rapide, performante, fiable et efficace. [...]

Je pense que COBOL est victime de la mode du tout-nouveau-tout-beau, celle qui veut que chaque nouvelle génération de développeurs estime que le passé n'a rien à nous apprendre. C'est une erreur. [...]

Bref, COBOL semble faire peur, peut-être aussi parce qu'il a permis à des générations de personnes formées à la comptabilité d'exprimer leurs (absences d') idées en informatique. Les résultats n'ont pas toujours été à la hauteur, ce qui explique la crainte de certains devant des montagnes de code spaghetti, incompréhensible. Cela est un vrai problème. Mais aujourd'hui, je ne vois pas de réelle raison de passer à la poubelle un langage qui permet depuis trente ans de résoudre le même problème : Régler les rapports entre l'entreprise, ses clients et ses fournisseurs, surveiller l'état d'un stock, passer des commandes et les réceptionner, l'activité administrative quotidienne, quoi. [...]

Accessoirement, qui sait si dans dix ans la mention de Python sur un CV ne suscitera pas la même hilarité chez certains que celle de COBOL aujourd'hui ? Et qui sait si dans dix ans COBOL ne sera pas en tête des compilateurs dans le domaine commercial ? Après tout, le reporting intégré est tout à fait capable de générer du HTML & similaires et selon le système d'exploitation il est aussi facile d'écrire un serveur en COBOL, si, si !

De mon point de vue, un langage qui permet d'écrire de gros programmes en maximisant la productivité devrait :

• être concis et intelligible, pour permettre d'écrire du code auto-documenté qui se comprend vite ;
• offrir de puissants outils d'abstraction pour permettre de respecter au mieux le principe DRY (Don't Repeat Yourself), ce qui permet d'écrire du code plus robuste et qui se met plus facilement à jour ;
• faciliter l'analyse des dépendances quand on lit le code, ce qui facilite la mise à jour de la conception et la mise en place de tests automatisés pertinents ;
• faire beaucoup de contrôles à la compilation, parce que plus tôt on repère les erreurs, mieux c'est ;
• faciliter la génération de code machine performant.

Si on regarde les langages populaires en entreprise :

Concision et intelligibilité

Du côté de la concision et de l'intelligibilité, les nouveaux langages de haut niveau sont un progrès. D'ailleurs, même des langages relativement verbeux comme C++ évoluent (C++11, C++14, C++17, etc.) et deviennent plus concis et plus expressifs qu'avant.

DRY (Don't Repeat Yourself)

Du côté du DRY :

• Les meilleurs langages sont ceux qui ont un bon support de la métaprogrammation, en particulier les dialectes du Lisp.
• Ensuite, on a les langages qui ne sont pas très forts en métaprogrammation mais qui ont un support correct de l'inversion des dépendances. L'inversion des dépendances est présentée comme un principe objet mais, en fait, elle est mieux supportée par le paradigme fonctionnel.
• Encore plus bas, on a des langages comme C qui sont nuls en abstraction mais qui facilitent légèrement le découpage du code en sous-fonctions.
• Et tout en bas, on a des langages de merde comme Batch dans lesquels, quand on veut exporter N fonctions, il faut écrire N fichiers, à moins de faire une fonction qui cumule N responsabilités et de parser à la main ses arguments pour savoir quelle est la fonctionnalité souhaitée.

Aujourd'hui, les dialectes du Lisp sont peu utilisés. Je ne sais pas s'ils étaient plus utilisés par le passé.
En tout cas, du côté des non-Lisp, il y a quand même eu du progrès.
J'espère que le niveau d'abstraction va progresser dans les programmes codés en entreprise.

Analyse des dépendances

L'analyse des dépendances d'un programme est facilitée quand le langage supporte des fonctionnalités comme l'encapsulation, les fonctions pures et l'immuabilité. De ce côté, le paradigme fonctionnel est meilleur que le paradigme objet qui est meilleur que le procédural.

À ce niveau, les langages comme C++ et Java qui supportent vraiment l'encapsulation étaient un progrès par rapport au C.
Haskell supporte très bien à la fois l'encapsulation, les fonctions pures et l'immuabilité, mais ça m'étonnerait qu'il devienne populaire dans les entreprises, à cause de la courbe d'apprentissage.
Je ne sais pas comment ça va évoluer dans les programmes codés en entreprise.

Contrôles à la compilation

De bons contrôles à la compilation impliquent, entre autres, d'avoir un typage statique et de faire de la programmation générique.

Je crois qu'on a provisoirement régressé avec les langages dynamiquement typés comme Python 2 et JavaScript. Mais le typage statique redevient populaire petit à petit. Par exemple, Python 3 a un typage statique optionnel en progression et une partie du JavaScript se fait remplacer par du TypeScript.

Performances

Là, par contre, il y a eu un gros déclin. Et c'est dommage, parce que, en concevant un langage comme il faut, il est possible d'avoir à la fois les performances du C et une puissance d'abstraction supérieure à celle du Python. J'en ai pris conscience en apprenant le langage D.

À quoi ressemblera le futur de la programmation ?

Si on regarde mes critères, parmi les langages les plus connus, aucun n'est vraiment bon.

Du côté des langages les plus utilisés en entreprise, va-t-on évoluer dans le bon sens ? Je vois deux tendances opposées :

• D'un côté, j'ai l'impression que le niveau des experts est meilleur qu'avant. La programmation orientée objet est devenue plus populaire que le procédural. La programmation fonctionnelle gagne en popularité. Remarque : je ne suis pas toujours pour du code qui suit à 100% le paradigme fonctionnel non plus, car l'immuabilité est parfois contradictoire avec les performances. Mais, en moyenne, j'approuve les principes de la programmation fonctionnelle.
• D'un autre côté, les entreprises veulent que n'importe quel débutant puisse faire du développement logiciel, ce qui limite l'utilisation de langages complexes. D'ailleurs, c'est surtout pour ça que Java est plus populaire que C++ : Java est moins compliqué pour les débutants. Aujourd'hui, le langage dont les caractéristiques techniques sont vraiment dédiées aux débutants est le langage Go. Je pense que, pour cette raison, le langage Go continuera de progresser, à mon grand désarroi.

Et le futur de COBOL dans tout ça ?

Avec les descriptions que l'on m'a données du COBOL, je ne vois pas comment ce langage aurait la moindre chance de remonter.
Quand on a besoin de bonnes performances, parmi les concurrents directs du COBOL, on a le C et le C++, qui eux-même finiront peut-être par se faire balayer par Rust.

Et le futur de Python dans tout ça ?

Aujourd'hui, Python est le seul langage qui est à la fois très connu et en forte progression. Il est déjà quasiment partout où on n'a pas besoin de très grosses performances. À terme, il se fera peut-être battre par un autre langage. Mais, à mon avis, ce sera dans bien plus longtemps que 10 ans.

[gerard093]

L'esprit du langage cobol est d'être, pour un financier anglais, très proche du langage parlé. Le cobol est donc verbeux. Il permet au british de contrôler l'activité du programmeur sur le plan de l'algorithme. Car le cobol est proche du langage naturel.

Toutefois, son interaction avec l'assembleur et le système mainframe (exec cics ...) augmenté de DL1 ou de SQL, l'a rendu moins vertueux. Et quand on est financier et qu'on ne veut pas parler anglais, le cobol devient aussi tordu que les autres langages.

Pourquoi le cobol encore aujourd'hui ? Parce qu'il est stable dans le temps. Il évolue peu. Ceci permet aux sociétés d'assurances de gérer leur contrat en codant tout de suite un contrat vie sur 40 ans. Et d'imputer immédiatement, dès le premier versement, les frais de gestion aux clients. On code tout de suite, on facture tout de suite, et on garde 40 ans. Génial !

Pourquoi des mainframes ? parce que le cloud est moins bien sécurisé. Parce que les mainframes peuvent vivre sans internet. Parce que la gestion de crise est facilitée. Parce que l'identification des risques est meilleure. Parce que tout le monde ne dispose pas d'un Z-OS dans sa cuisine pour aller hacker.

Python est un langage d'expérimentation (robotique, IA ...) et de recherche, plus qu'évolutif. Cobol est un langage de production, de gestion et de méthode. On parle d'industrialisation.

Les deux peuvent donc coexister. Sur cette planète on a des espèces animales très anciennes. Comme le scorpion. Elle seront peut être là après nous, au fond. Alors que les I.A domineront un monde devenu désertique.

A méditer ...

Et je vous recommande le post sur Xbash ! tout les scripts d'attaque implantés dans pyinstall qui a peut être fait un malheur sur vos machines. A voir ...

[TJ1985]

L'esprit du langage cobol est d'être, pour un financier anglais, très proche du langage parlé. Le cobol est donc verbeux. Il permet au british de contrôler l'activité du programmeur sur le plan de l'algorithme. Car le cobol est proche du langage naturel.

Non, vous prenez le problème à l'envers. COBOL a été conçu et créé pour permettre aux comptables d'informatiser leurs besoins, avec un strict minimum de formation. Ce qui est bien le cas. Un programme COBOL bien écrit permet de savoir relativement facilement exactement ce qu'on va traiter, d'où ça vient, qu'est-ce qu'on en fait et comment. Mais à mon sens, il n'est pas plus proche du langage naturel qu'un programme Pascal ou C / C++ bien écrit.

Toutefois, son interaction avec l'assembleur et le système mainframe (exec cics ...) augmenté de DL1 ou de SQL, l'a rendu moins vertueux. Et quand on est financier et qu'on ne veut pas parler anglais, le cobol devient aussi tordu que les autres langages.

En ce qui concerne l'assembleur, je ne l'ai jamais pratiqué sur Mainframe, sauf pour reprendre, corriger puis jeter quelques routines écrites par d'autres. Franchement, ça n'en valait pas la peine. Et de nouveau, l'intelligibilité d'un langage dépend de l'application qu'on met à l'apprendre, puis à la qualité de celui qui code.

Pourquoi le cobol encore aujourd'hui ? Parce qu'il est stable dans le temps. Il évolue peu. Ceci permet aux sociétés d'assurances de gérer leur contrat en codant tout de suite un contrat vie sur 40 ans. Et d'imputer immédiatement, dès le premier versement, les frais de gestion aux clients. On code tout de suite, on facture tout de suite, et on garde 40 ans. Génial !

Euh, je ne pige pas ce que vous voulez dire. Un contrat d'assurance est une donnée, indépendante de l'outil qui l'a créée. Donc...

Bon, si on regarde d'un peu plus haut, il permet de résoudre facilement des problèmes simples connus depuis les débuts de la gestion. Une chose me frappe régulièrement lorsque vous observez l'écran de l'ordinateur de l'administratif que vous allez voir, que ce soit en entreprise, à la mairie, à la préfecture : L'information qu'il traite est présentée sous forme tabulaire, et son interaction passe souvent par un maximum de clavier et un minimum de souris. En gros, les écrans graphiques ne servent à rien pour la gestion telle qu'elle est pratiquée généralement. Dans ce contexte, COBOL offre tout ce qu'il faut, jusqu'à la gestion des touches de fonction, de caractères semi-graphiques permettant de simuler un écran graphique. Alors à quoi bon se compliquer la vie ? Tant que l'utilisateur se satisfait de la pauvreté de ces interfaces, pourquoi s'inquiéter ? Notez bien que lorsqu'on prend la peine de sortir un peu de la facilité, les compliments pleuvent et ça fait très plaisir, comme j'ai pu le vérifier en salle de trading...

Pourquoi des mainframes ? parce que le cloud est moins bien sécurisé. Parce que les mainframes peuvent vivre sans internet. Parce que la gestion de crise est facilitée. Parce que l'identification des risques est meilleure. Parce que tout le monde ne dispose pas d'un Z-OS dans sa cuisine pour aller hacker.

Eh oui, et aussi qu'on se connecte sans problème à un mainframe depuis Tombouctou à travers du réseau cuivre et qu'on peut donc gérer depuis Paris une banque locale sans risquer de piratage puisque personne ne comprend plus rien à ces technologies.

Python est un langage d'expérimentation (robotique, IA ...) et de recherche, plus qu'évolutif. Cobol est un langage de production, de gestion et de méthode. On parle d'industrialisation.

Partiellement d'accord. Python est un vieux langage, si, si, et il permet réellement de faire de jolies choses. Je ne l'ai pas suffisamment utilisé pour en juger vraiment, mais autant j'étais dubitatif à mes premiers contacts, autant je suis séduit chaque fois que je joue un peu avec. Surtout, il est un ciment très efficace pour jouer avec les librairies IA (Keras, TensorFlow,...). Il permet aussi tout seul de gérer des interfaces graphiques rudimentaires, mais bien suffisantes pour les besoins de la gestion (a priori).

Les deux peuvent donc coexister. Sur cette planète on a des espèces animales très anciennes. Comme le scorpion. Elle seront peut être là après nous, au fond. Alors que les I.A domineront un monde devenu désertique.

Euh, une IA, aujourd'hui, tourne grâce à Python, souvent ! On considère de plus en plus d'ailleurs que l'Intelligence en général est un processus, non une entité.

Et je vous recommande le post sur Xbash ! tout les scripts d'attaque implantés dans pyinstall qui a peut être fait un malheur sur vos machines. A voir ...

Je verrai ! Je n'utilise pas pyinstall, donc je ne suis pas trop anxieux...

[macgawel]

ya pas moyen de convertit des turc cobol vers d’autres langages ? le cobol est assez simple mine de rien, mais si sa lecture est ardue.

Il y a des tentatives, mais jusqu'à présent ça ne fonctionne que sur des petits programmes. Sur des "vrais" programmes du monde réel on se retrouve vite à devoir tout vérifier/réécrire à la main