Envoyé par Jean Elyan avec IDG NS
Envoyé par Jean Elyan avec IDG NS
Bonjour,
L'etude a ete demandee par une entreprise (micro focus) qui, par le plus grand des hasards, vient d'ouvrir un programme de formation pour "former la prochaine generation de developpeurs COBOL".
Apres, c'est bien beau de demander a des universites (lesquelles, dans combien de pays ? Qui repond ?) et a leurs dirigeants (c'est drole, mais le doyen de mon universite est un chimiste reconnu, qui ne connait probablement pas bien l'informatique...) ce qu'ils pensent de l'avenir du COBOL, mais si on regardait plutot quelle est la part du COBOL dans les langages utilises actuellement ? On trouve des chiffres ici et la qui parlent de 1%, mais c'est difficile a verifier.
Et quelle est la part dans les investissements des entreprises ? La encore, difficile a dire, car il s'agit souvent de systemes critiques (banques), domaine dans lesquels les investisseurs ne communiquent pas beaucoup.
Mais j'y pense, lorsqu'on forme un bac +5, ou meme un bac+8 (si si, c'est bien ce que font les universites), est-ce qu'on ne forme pas des cerveaux capables d'etre independant du langage, capables de s'adapter a un nouveau langage rapidement ?
Bonjour,
Dans le cas du COBOL, plus que le langage (qui est sans doute l'un des plus simples qui soient), je pense que c'est l'environnement MVS qui peut être difficile à appréhender au départ, de même que la partie JCL.
Au final, heureusement que le COBOL est peu "enseigné" car il permet à des ingénieurs non informaticiens comme moi d'avoir pu le devenir
Tout à fait d'accord! Imaginez de plus un enseignant en Cobol qui arrive devant un amphi ou dans une école d'ingénieur pour dire: "Bon, on a 5 banques en France qui sont à fond Cobol, on va vous coller 200h de ce langage au détriment du Java et du C# que le reste du monde utilise abondamment."
Pourquoi serait ce aux facs de trouver une solution à un problème de banques qui n'ont pas su anticiper un énorme problème de dette technique et de langage obsolète? Si vraiment c'est critique pour une banque, elle appelle un centre de formation quelconque, prend une dizaine de prestas, leur paie la formation, et les met sur du Cobol. Tout bête, tout simple. Laissons les facs former aux langages du moment.
les raisonnables ont duré, les passionné-e-s ont vécu
[HS]
Si c'est critique, il ne faut pas prendre des prestas
[/HS]
Je pense qu'une personne qui a appris la programmation, et non pas un langage, est capable de s'adapter. Bien sur, passer de C++ a Java, ou l'inverse, est plus simple que de passer de Ruby a Cobol.
Mais si une personne a une formation dans laquelle elle apprend a reflechir, et non pas a pisser du code en XXX sans reflechir, alors effectivement, une petite formation en YYY lui permettra de se former rapidement.
Bien sur, cela ne pas aider nos amis les mauvais RH qui ne font que des grep sur les CV a la recherche du bon mot-clef (genre : je vois que vous avez 15 ans d'experience sur 5 langages de programmation, mais vous n'avez pas d'experience Cobol, on ne peut vraiment pas vous recruter, vous ne pouvez pas etre competent dans ce domaine).
Encore que je reste d'accord avec notre ami Darkzinus. Le cobol, c'est du lourd parce que les gros systèmes, c'est du lourd (sans jeu de mots). De même, quelqu'un qui connait bien le C ne sera pas compétent sur du système embarqué directement. Et comme personne n'enseigne le grand système, puisqu'on a fait pas mal de progrès depuis... De même, l'embarqué, ce n'est pas juste connaitre les langages de l'embarqué. Enfin, il me semble...
Là, pour le coup, tout à fait d'accord
les raisonnables ont duré, les passionné-e-s ont vécu
Bien sur qu'il ne suffit pas de connaitre un langage pour etre competent dans les domaines ou l'on emploie ce langage.
Neanmoins, une personne un peu adaptable connaissant bien les concepts sous-jacents sure tout a fait a meme de s'adapter rapidement a son nouvel environnement.
Et le but des etudes n'est pas de former les etudiants a etre aptes en embarque ou en gros systemes ou en web, mais de former un cerveau pour qu'il sache s'adapter. C'est pour cette raison qu'on peut identifier des formations orientees bas-niveau, d'autre haut-niveau, et qu'au sein d'une meme formation, selon les apetences de chacun, on trouvera A qui est plus competent en bas-niveau et B qui est meilleur en temps-reel, etc .
Oula, j'ai travaillé 3 ans dans une SSII qui s'occupais de groupe bancaire, et c'est du 70%, pas du 1%... ça ne sera jamais remplacé par une autre techno, puisque :mais si on regardait plutôt quelle est la part du COBOL dans les langages utilises actuellement ? On trouve des chiffres ici et la qui parlent de 1%
- C'est robuste.
- Plus personne ne sais vraiment comment tout marche, mais ça marche.
- On parle de dizaine de millions de ligne de code.
Pour ce que j'en ai vu, le COBOL n'est pas près de disparaître et c'est une compétence très apprécié du milieu bancaire (on peux effectivement les compter sur les doigts de la mains les gus capable de faire du J2EE et de passer en mode débug dans du COBOL (XPED) avec l'environnement MVS).
Pour finir, quand mes comptes seront géré avec du java, je pense que je mettrais tout sous mon matelas
Je parlais du nombre de projets en COBOL dans l'informatique en general, et de la part des investissements sur les nouveaux projets en COBOL.
Je sais bien que certains systemes bancaires sont uniquement en COBOL, et il y a certaines banques qui demandent a ce que leur "nouveautes" soient egalemnet en COBOL.
Mais dans la part de l'informatique, quelques banques par rapport au reste du monde, ca ne pese pas bien lourd.
Il n'y a pas de raisons de former des gens au COBOL, pas plus qu'en Fortran, en Ruby ou en Javascript. Il faut former des gens a reflechir, et a utiliser des outils, que sont les langages de programmation.
En formation courte web, on prendra effectivement comme outil Javascript. En formatien temps-reel, on pourra prendre le C, et voir aussi le java temps-reel, ce qui permettra d'ouvrir un peu les esprits.
Dans d'autres formation, il faudra voir de la base de donnees, et ailleurs encore autre chose.
Là ou l'article pêche, c'est que la difficulté n'est pas le COBOL. C'est un langage facile à lire, un peu lourdingue mais pas très difficille à coder(sauf algos à la noix, mais on a rarement des algos très complexes à se farcir dans ce genre de domaines fonctionnels)
La difficulté, c'est l'environnement. Faire un JCL qui marche pour lancer le programme que l'on vient de coder est généralement plus difficile, plus subtil, plus technique. Et l'environnement grand système, c'et quand même une autre manière de penser - raison pour laquelle les diplomés en info fuient en masse.
Donc, enseigner COBOL, bof. Un type à l'esprit orienté développement apprend le cobol en quelques semaines si il n'a jamais développé, en quelques jours si il maitrise déjà d'autres langages. Quand à enseigner le grand système, je crois qu'il est encore préférable d'apprendre sur le tas. Ca marche mieux. D'ou des profils genre Darkzinius ou moi.
EDIT : après avoir lu le commentaire de l'article qui disait que le cobol a toujours été vomi par le monde universitaire, je tiens à rajouter que c'est normal : quelqu'un de pas assez calé en maths pour entré à la fac peut faire du cobol. C'est un langage simple, verbeux, qui rejette les astuces élégantes réservéées aux seuls initiés. Des mots complets, pas d'opérateurs ternaires, pas de signes cabalistiques, bref, trop simple pour trouver grâce aux yeux de ceux qui se gargarisent de leur propre intelligence. Mais ça marche.
Par contre, Cobol a une spécificité qui est, euh, interessante mais pas sans défaut : il n'y a pas de gestion dynamique de la mémoire. C'est évidemment une plaie quand on fait des algorithmes complexes(c'est rarissime), mais c'est une bénédiction pour l'exploitation qui SAIT qu'elle n'aura pas de fuite mémoire. Mais le for each (et tout ce qu'il y a autour pour qu'il marche) me manque un peu, parfois... Il n'y a pas de langage parfait.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Notons quand même que, à défaut, il dispose d'astuces inélégantes réservées aux seuls initiés.
je ne crois pas que d'autre langages possèdent cette monstruosité
Code : Sélectionner tout - Visualiser dans une fenêtre à part ALTER MyProc TO PROCEED TO OtherProc.
(bon, mes souvenirs de Cobol remontent à 87 ou 88 ....)
Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
Je citais cela pour l'anecdote.
Je crois que cette syntaxe est rejetée ou au moins flaggée "obsolete" dans les normalisations les plus récentes. Même à l'époque où j'ai "fait" un peu de Cobol (86-88) c'était considéré comme une horreur caricaturale que personne n'utilisait.
Elle a eu son interêt, je crois, au début des 70' car cela permettait de gagner quelques octets en mémoire en modifiant les branchements inconditionnels par un échange dans les jump tables, à l'époque où les octets comptaient pour cher.
Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
L'IUT de Lille forme en COBOL. A hauteur de quelques heures semaines, un peu moins que de JAVA/C. (Heureusement )
Maintenant:
Est-ce que je vais faire du COBOL parce que j'ai été formé à ça? Surement pas.
Est-ce que des gens de ma promos font du COBOL? Ceux qui ont pas trouvé de taff dans les domaines qu'ils souhaitaient oui..
Est-ce que j'ai entendu, ne serait-ce qu'un personne, dire: "Énorme les cours de COBOL, je veux faire ça"? Non.
Pour moi, on fait un métier parce qu'il nous plait. Si c'est pour faire un métier chiant, autant en choisir un qui paye un peu plus que l'informatique.
Il manque du monde en COBOL? Tant mieux, les rémunérations de ceux qui font ça par dépit augmentera. Ça compensera.
PS: Désolé pour ceux qui aiment le COBOL ^^'
Je n'ai pour ma part jamais eu la moindre afinité pour ce langage, (que je n'ai plus utilisé depuis plus de 20 ans) mais entre peste et choléra, entre Cobol et Javascript, par exemple, si j'avais à faire ce genre de choix, je ne suis pas sur du tout que j'éliminerais le Cobol préférentiellement.
Il a au moins le mérite de permettre de gérer des problématiques métier complexes avec un langage simple, dès l'instant où une algorithmie sophistiquée n'est pas nécessaire.
Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
Un peu dans la lignée de ce qui est dit plus haut, j'ajouterai qu'une difficulté n'est pas le COBOL lui-même, mais la difficulté à pratiquer le langage chez soi avec tout l'environnement (JCL, DB2...) et étant donné que les ressources pour apprendre cet environnement sont moins nombreuses que pour les autres langages.
Avez-vous des commentaires sur l'avis de "videovoyage" sous l'article du Monde Informatique: le mainframe est-il réellement moins rentable ?
Pas forcément: au moins pour les développeurs de base, les SSII peuvent recruter des non-informaticiens, payés au minimum conventionnel, les former elles-mêmes en quelques semaines, et profiter de cette formation pour leur imposer un dédit-formation, qui les empêchera d'aller chercher un poste mieux payé avant d'avoir été suffisamment rentables.
Pas de souci, chacun ses gouts. Ce que je constate, c'est que si plein de choses sont plus faciles dans les langages modernes, pour le noyau comptable d'un grand groupe, le COBOL est très performant. Et pas si désagréable.
C'est un langage de niche. Pour faire ce que je fais professionellement, Java, C#, .NET me semblent inutilement complexes(je ne parle pas du ALTER PROCEED désactivé par tous les bons compilateurs depuis 1993), et la programmation orientée objet une fausse bonne idée.
Maintenant, en dehors de cette niche, j'en ai à peu près la même vision que toi. C'est une horreur.
Hélas non. Nous vivons dans un stalinisme à capitaux privés ou les salaires sont décidés au bon vouloir ducomité centralconseil d'administration, loin de toute logique économique. Et donc nous sommes un à deux pourcent en dessous des programmeurs java(la dernière fois que j'ai regardé, il y a longtemps).
Pas de soucis, si ton domaine fonctionnel n'est pas le mien, COBOL est à fuir.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
J'ai fait du Cobol sur Mainframe pendant 3 ans.
Pour infos, ce n'est pas que "quelques banques isolées" qui ont leur coeur de métier en Cobol, mais la plupart d'entre elles (SG, LCL, CA, BNP....). De même de nombreuses compagnies d'assurances.
Comme dit précédemment, le Cobol en soi n'est pas difficile. Mais le Mainframe...c'est assez compliqué, TSO/ISPF, IMS, CICS, JCL...toutes ces technos ne sont pas enseignées. On ne trouve pas de tuto pour ça. Il faut passer par une formation dédiée.
Tout frais sorti de l'école et blindé de C, Java et autres langages "à la mode", lorsqu'on sort des études, on a tendance à croire que "Pouah ! c'est quoi cette horreur de Mainframe, donnez moi 10 PC en parallèle et je fais pareil".
Grave erreur !! Si des systèmes entiers sont encore sur Mainframe c'est parceque c'est fiable et puissant.
Pas de virus sur Mainframe, le système de sécurité (RACF) est blindé à mort, pas de mises à jour pourries qui font rebooter le serveur, pas de process qui partent en vrille sans qu'on sache pourquoi...et encore plein d'autres bonnes raisons.
Après, le Cobol / Mainframe, c'est assez chiant quand on aime vraiment programmer, faut bien le reconnaître ;-)
Salut,
oui heureusement, je suis d'accord: Docteurs en biologie, sociologie, sciences physiques, ingénieurs en chimie, ... la liste est longue
L'étudiant lambda fait tourner l'économie car une formation ça coûte, puis il démarre à un petit salaire car il a bien galéré pour trouver un taf, il ne va pas faire la fine bouche ... hein et ensuite il fait appel aux crédits.
Au fond on se plaint du chômage mais le système est beaucoup plus subtil qu'on ne peut l'imaginer.
Donc tant mieux si de jeunes étudiants au chômage ont cette porte de sortie: coboliste de la dernière heure ça va douiller les enfants
A+
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager