La pandémie de Covid-19 a créé des manques. Parmi eux, le secteur de la finance est à la recherche de programmeurs spécialisés dans le langage COBOL, un langage de programmation créé il y a plus de 60 ans et jugé par beaucoup comme obsolète.
Faut appeler Starbuck!
Comprenne qui pourra
Ou les Lords
Ce n’est pas parce qu’un langage est performant qu’il n’est pas désuet… à ce prix là, ASM serait au top de la modernité.
viper VII ?
en 2006 j’ai croisé un ancien programmeur KOBOL qui avait fini « formateur » aigri dans une section informatique de l’AFPA, faute de travail en tant que dev sur ce language qui était sa spécialité.
Voir ce genre de niouze en 2020 est… bizarre on va dire.
Oui et même si vous un programmeur en Algol68, c’est demandé !
Mk VII
Oublie pas le Mk
en 2006 j’ai croisé un ancien programmeur KOBOL qui avait fini « formateur » aigri dans une section informatique de l’AFPA, faute de travail en tant que dev sur ce language qui était sa spécialité.
Voir ce genre de niouze en 2020 est… bizarre on va dire.
Bah, tu sais, les employeurs, ils veulent pouvoir virer quand ils veulent. Et ils s’attendent à retrouver la personne disponible quand ils en auront besoin… 10 ans après…
Quand tu vire des gens et qu’ils ne trouvent plus de boulot, ils changent de métier ou de spécialité et même parfois de région. Après les employeurs viennent pleurer : ouin,ouin on trouve pas de programmeur en machin chose. Ouin,ouin les gens veulent pas travailler. Ouin, ouin l’état ne nous fournit pas tout ce qu’on demande.
Si un employeur à besoin de programmeurs en Cobol ? Et bien c’est facile, il embauche des programmeurs et il leur paye des formations en cobol. Et après il les garde…
IMHO c’est pas au contribuable de payer des formations alors qu’il y a quelques années, on a recyclé des tas de vieux programmeurs en livreur de pizza.
Ce n’est pas parce qu’un langage est performant qu’il n’est pas désuet… à ce prix là, ASM serait au top de la modernité.
En même temps, rappelons qu’aucun langage de programmation ne peut fonctionner sans le langage machine(appelé assembleur par abus de langage) qui est pour rappel le seul langage qu’un processeur peut comprendre.
Bien qu’il soit aujourd’hui moins pratiqué de manière directe, la programmation en langage machine reste pratiquée dans beaucoup plus de cas de figure que beaucoup de gens l’imaginent.
En tant que coboliste (et d’autres langages bien plus récents), je peux vous certifier que le language fonctionne parfaitement (pourquoi donc en changer, et par quoi?), est omniprésent (chaque jour vous l’utilisez sans le savoir), et qu’il y a depuis bien longtemps une pénurie de développeurs en Cobol: ce n’est pas une question de covid.
Dans ma région nous recherchons constamment des cobolistes et n’en trouvons pas, et c’est le cas dans beaucoup de pays.
Le Cobol s’apprend en une journée si on a un QI normal…
Donc, si je comprend bien, savoir programmer en COBOL fait partie des comorbidités du COVID-19… Est-ce que par hasard Fortran et ADA n’en feraient pas eux aussi parti ? Parce que dans ce cas, je serais vraiment mal; c’est qu’il me reste un ouvrage de chaque dans ma bibliothèque !
Bon, à partir de maintenant, je jure solennellement de ne plus taper que du Javascript, et ce exclusivement pour du projet web jetable !!!
Bonjour [Ma_Be]
Vous écrivez :
« Dans ma région nous recherchons constamment des cobolistes et n’en trouvons pas » :
Cela m’intéresse, j’ai 10 ans d’expérience cumulée sur Cobol, et je cherche actuellement une mission.
Savez-vous qui je pourrais joindre ?
Cordialement.
Le langage machine c’est une suite de 0 et de 1. Assembleur n’est pas du langage machine. C’est le langage qui s’en rapproche le plus, parce qu’une simple « traduction littérale » permet de passer de l’asm au binaire, mais ce n’est pas similaire.
Ce n’est pas qu’un langage de programmation ne peut fonctionner sans langage machine, ce sont deux choses différente. L’un permet une représentation compréhensible par l’homme d’un programme, l’autre est le représentation compréhensible par le processeur de ce même programme.
Mais, je ne vois pas pourquoi tu réponds ça par rapport à mon commentaire… ASM est ultra performant (s’il est bien utilisé), puisqu’il représente exactement ce à quoi le processeur s’attends, il n’en reste pas moins que, lorsque l’on peut l’évider, on l’évite, parce que le gain en performance ne justifie que rarement l’énorme perte de temps, de risque d’erreur et difficulté de maintenabilité.
Je doute que, comme tu le dis, beaucoup de développement se font encore en ASM. Même la part de code ASM des noyaux Linux ou Windows est minime, le reste c’est du C/C++, pareil en électronique.
Les banques françaises grosses consommatrices de cobolistes vont les former puis chercher au Magreb. Ca revient moins cher. Et on peut les virer facilement.
(un coboliste de 40 ans d’expérience toujours actif et qui en a mare).
meme si c’est exact tu peux pas te permettre aujourdhui de te passer des langages modernes pour la rapidite d’exuction et la visibilite du programme !
Personne ne dit le contraire.
Mon propos était d’expliquer que la programmation en langage évoluée et la programmation en langage machine ont chacun leur domaine d’application.
Même si le temps ou l’on programmait beaucoup de choses en langage machine est révolu, cela ne rends pas pour autant cette programmation obsolète. Parce qu’il y a des choses qu’on ne peut tout simplement pas faire dans un langage de haut niveau.
Si qq a besoin d’un programmeur assembleur Motorolla 6502, je peux aider…
Le langage machine c’est une suite de 0 et de 1. Assembleur n’est pas du langage machine. C’est le langage qui s’en rapproche le plus, parce qu’une simple « traduction littérale » permet de passer de l’asm au binaire, mais ce n’est pas similaire.
Pas tout à fait.
Le langage machine binaire et sa forme symbolique compréhensible par l’humain sont juste deux représentations différentes de la même chose.
A l’origine, le mot « assembleur » désigne le programme qui permet de passer de passer de la forme compréhensible par l’humain à celle compréhensible par la machine. Et le désassembleur permet de faire l’inverse. Au passage, je précise que j’ai écrit dans ma vie plusieurs compilateurs et même un assembleur.
Donc, c’est par abus de langage qu’on a utilisé le mot assembleur pour parler du langage machine et de la forme symbolique compréhensible par l’humain. Mais bon, ce n’est pas un problème puisqu’en général on se comprends.
Et puis, si on était rigoureux en informatique, on ne pourrait plus s’amuser à voir les mathématiciens et les scientifiques devenir fous
Ah le kilo à 1024, quel bonheur pour tromper l’ennemi. Et le signe égal pour les assignations…
Ce n’est pas qu’un langage de programmation ne peut fonctionner sans langage machine, ce sont deux choses différente. L’un permet une représentation compréhensible par l’homme d’un programme, l’autre est le représentation compréhensible par le processeur de ce même programme.
Ce qui ne change rien à ce que j’ai affirmé, à savoir que votre joli programme écrit en langage évolué ne servira jamais à rien s’il n’est pas traduit en langage machine ou interprété par quelque chose qui est exécutable.
D’ailleurs, pour les langages évolués, ce que vous dites la peut se discuter (même si ce n’est pas non plus complètement faux) dans la mesure ou il s’agit plus d’une translation que d’une représentation différente. Il n’existe pas de correspondance directe entre une instruction en langage évoluée et une instruction en langage machine.
Même si on considère le concept de groupes d’instructions, il n’existe pas non plus de correspondance simple, ni une manière unique de traduire une instruction en langage évoluée vers un groupe d’instructions en langage machine. Deux compilateurs ne vont pas générer le même code et la compilation n’est que partiellement réversible (dé-compiler est très difficile).
Mais, je ne vois pas pourquoi tu réponds ça par rapport à mon commentaire… ASM est ultra performant (s’il est bien utilisé), puisqu’il représente exactement ce à quoi le processeur s’attends, il n’en reste pas moins que, lorsque l’on peut l’évider, on l’évite, parce que le gain en performance ne justifie que rarement l’énorme perte de temps, de risque d’erreur et difficulté de maintenabilité.
Programmer en langage machine n’est ni une perte de temps, ni une source d’erreur si vous utilisez ce langage à bon escient, quand son utilisation est indiquée et de la manière dont il faut le faire.
Ce qu’il faut comprendre c’est que contrairement aux idées reçues, la programmation en langage machine n’est pas obsolète et ne le sera jamais si l’on considère les usages qui sont pertinents pour ce langage.
Je doute que, comme tu le dis, beaucoup de développement se font encore en ASM. Même la part de code ASM des noyaux Linux ou Windows est minime, le reste c’est du C/C++, pareil en électronique.
Sauf que la quantité de lignes de code ne dit rien sur la pratique d’un langage. Car cela n’est ni représentatif du temps passé, ni de l’importance de ce code.
Aujourd’hui, le langage machine est utilisé pour de petites portions de code très fortement optimisées (donc qui comptent beaucoup dans la performance d’un ordinateur) ou pour utiliser certaines fonctions particulières des processeurs. Dans ce cadre, cela peut demander plus de temps d’écrire 10 lignes de code en langage machine que 5000 lignes pissées en Java.
Donc ce n’est pas en comptant les lignes de code que vous aurez une idée du nombre d’heure que les programmeurs consacrent a du langage machine.
Au passage, il n’y a pas que les noyaux et les drivers qui utilisent des portions de code en langage machine. C’est le cas de beaucoup de logiciels performants.
Et il y a bien d’autres usages, par exemple dans le déverminage de programmes. Devant un comportement aberrant et incompréhensible dans un programme dont le code est correct, il faut soupçonner un bug du compilateur. L’étude et le traçage au niveau langage machine permet de savoir rapidement ce qui se passe.
Même si c’est un cas de figure qui n’arrive pas tous les jours, j’ai rencontré le cas plus d’une fois. Et ceux qui ne pratiquent que les langages évolués seront incapables de trouver le problème.
On pourrait ajouter que la maîtrise et la compréhension du langage machine améliorent beaucoup la compréhension des programmeurs par rapport à ce qu’ils écrivent en langage évoluées. Ce qui améliore en pratique beaucoup leur capacité à écrire du code efficient.
pareil en électronique.
Pas vraiment.
Dès lors qu’il y a besoin d’un contrôle du timing au delà d’une certaine précision, on peux oublier tous les langages évolués, même le C.
Et il existe bien d’autres cas de figure. Par exemple sur les petits microcontrôleurs, la programmation en langage évoluée peut s’avérer pénible. J’ai vu plus d’un programmeur s’y casser les dents à tenter de faire ça en C. « je comprends pas, j’appelle la fonction et ça fait n’importe quoi, ça fait 3 semaines que je tourne en rond ». Bah ouais jeune padawan, t’as une pile riquiqui et c’est vraiment vite fait de l’écraser. T’aurais fait ça en langage machine, t’aurais gagné du temps… et cerise sur le gâteau, t’aurait encore des cheveux