COBOL vaut-il encore la peine d'être appris? [fermé]

Est-ce que l'apprentissage du COBOL a toujours du sens?

Je ne pense pas, sauf si vous êtes déjà sur le marché de niche où COBOL est toujours maintenu.

Non, bien sûr que non. COBOL est une langue morte, après tout. Ou est-ce?

Le problème avec cette vue est que les programmeurs sur des sites comme celui-ci travaillent généralement avec des entreprises de haute technologie, à fonctionnement rapide (et à épuisement tout aussi rapide). Pour eux, le COBOL est une langue morte - il est introuvable. Cela ne fait plus depuis longtemps, c'est vrai.

Mais COBOL n'était pas fait pour eux. L'industrie du logiciel ne se limite pas à cela. Les ordinateurs n'ont pas été inventés pour les personnes ayant un besoin irrationnel de mise à niveau et de remplacement d'anciens par de nouveaux tout le temps. Ils ont été faits à des fins commerciales.

Vous voulez voir COBOL? Accédez à une entreprise qui traite la paie, gère le camionnage de marchandises ou l'expédition (comme dans les navires) ou gère votre compte bancaire. Il existe un énorme système de code invisible qui est pratiquement invisible pour les utilisateurs, et la plupart d'entre eux n'y pensent jamais bien qu'ils le rencontrent d'une manière ou d'une autre tous les jours (GAB?)

Non, ce n'est pas mort. Mais c'est "hérité" à coup sûr ... ou n'est-ce pas?

Encore une fois, cela dépend de la façon dont vous le voyez. De nos jours, beaucoup de gens utiliseront Java, C ou autre chose au lieu de COBOL, réécrivant à partir de zéro ... introduisant de nouveaux bugs au fur et à mesure, naturellement. Cela ne veut pas dire que COBOL n'a pas de bugs et de bizarreries. Il le fait, autant que la langue suivante. Bien sûr que oui. Mais en «temps COBOL», les entreprises qui prenaient les bogues plus au sérieux que d'habitude (assurances, banques) avaient tendance à produire un code de meilleure qualité avec des groupes de services de qualité spéciale; aujourd'hui, il y a des délais où le temps et le budget l'emportent toujours sur la qualité. De plus, ces systèmes ont été développés à l'origine pour des périodes plus longues à l'époque par rapport à leur équivalent actuel.

Si certains logiciels fonctionnent depuis plus de 30 ans, où est l'incitation à changer? Des entreprises entières ont cessé leurs activités parce qu'elles ont ignoré le vieil adage «si ce n'est pas cassé, ne le répare pas». Beaucoup ont essayé de réécrire la chose ... puis la première réécriture a coûté cher, puis la seconde a coûté encore plus ... et aucune de ces nouveautés et améliorations n'a réussi à la remplacer. Comme je l'ai dit, cette industrie brûle rapidement, et elle a également tendance à oublier rapidement.

Dans les années 70, COBOL était mort ou mourrait bientôt, le C / C ++ allait régner. Puis au début des années 80, Pascal prenait le relais. Puis dans les années 90 c'était Java comme LE Langage ...

Pensez à Unisys Mapper, dBase, Clipper, Cold fusion ... les gens s'en souviennent-ils même? Chacun d'eux allait être le fossoyeur de COBOL.

En tenant compte de cela, et du fait qu'il est idéal pour traiter des volumes élevés de transactions, un traitement par lots ou un traitement orienté enregistrement / transaction, et que l'on peut compiler (sans erreurs) un sous-programme écrit depuis 30 ans en tant que code COBOL géré et appeler à partir d'un COBOL.NET géré si l'on souhaite passer à Windows et .NET, j'ai du mal à trouver un remplaçant approprié. (J'ai également du mal à trouver une technologie Microsoft qui a duré plus d'une décennie.)

Oui, un nouveau code COBOL est en cours d'écriture aujourd'hui. Il suffit de savoir où chercher.

Pour ceux qui rient de COBOL, à mon humble avis, c'est comme rire des pyramides égyptiennes, ils sont là depuis 5000 ans et ils seront toujours là dans les 5000 prochaines années, tandis que le logement "bonjour" d'aujourd'hui nécessitant 24 contrôles pour fonctionner sera supprimé, remplacé, oublié le mois prochain.

Alors, où sont tous ces programmeurs COBOL?

Ah, car là réside le hic. Le fait est que beaucoup d'entre eux n'ont aucune formation en informatique. Beaucoup d'entre eux ne sont pas des programmeurs professionnels (comme dans les diplômés universitaires d'un programme CS / SE). Pour la plupart, ce sont des personnes dans la fin de la trentaine ou la cinquantaine, de tous les domaines d'expertise, entièrement formées par l'entreprise spécifiquement pour ce travail. Ce ne sont donc pas des "programmeurs COBOL" - la formation qu'ils ont reçue est spécifique à l'entreprise qui fait la promotion de l'intérieur. Et cela les rend à peu près invisibles.

Si vous pouvez vous voir comme programmeur COBOL, alors allez-y. Il reste des milliards de lignes écrites en COBOL qui nécessitent une maintenance.

En fait, il n'y a pas de connaissances inutiles, alors élargissez les connaissances et les opportunités plus larges que vous aurez (aurez).

L'apprendre a-t-il un sens?
Eh bien, il est un créneau et il y a des tonnes de travail code existant qui doivent être maintenues et ne peut pas simplement être réécrite. Donc, même si ce n'est pas vraiment une option pour la grande majorité de tous les programmeurs, c'est une perspective pour un revenu stable pour les particuliers.

Cependant, si vous êtes intéressé à créer de nouvelles solutions, plutôt que d'améliorer lentement celles qui existent depuis des décennies, COBOL n'est probablement pas le bon langage.

De nombreuses entreprises européennes dépendent encore fortement de mainframes fonctionnant comme les programmes z / vse et cobol. Il y a une demande de programmeurs de cobol qualifiés que personne ne pense que le marché va combler, ce qui fait augmenter le salaire, beaucoup.

La question devrait être, "vais-je jamais développer quelque chose de nouveau en utilisant cobol?" car à peu près tout est de la maintenance ou des variations de choses critiques existantes.

Je travaillais pour IBM où le code COBOL et PL / I était écrit tous les jours. Également des grandes entreprises qui s'appuient sur les mainframes IBM comme de nombreuses banques qui nécessitent des milliers de transactions par seconde, ces langues sont encore largement utilisées.

Si vous ne voulez pas travailler dans un endroit comme ça (c'est pourquoi j'y ai juste travaillé pendant 6 mois) alors ne pensez même pas à apprendre ces langues.

Nous écrivons tous les jours du nouveau code Cobol et nous sommes constamment à la recherche de nouveaux programmeurs. L'offre est trop petite ici.

Si vous voulez avoir un travail en tant que programmeur COBOL, alors allez-y et apprenez-le.

Pour toute autre raison, comme essayer d'apprendre quelque chose d'utile qui pourrait vous aider avec des techniques de programmation modernes, non, ne vous embêtez pas.

En l'an 2000, j'ai lu une statistique selon laquelle il y avait plus de lignes de COBOL écrites que toutes les autres langues combinées.
Ajoutez à cela la garantie IBM que tout deck TEXT (code objet), compilé sur n'importe quel système MVS est exécutable sur tous leurs systèmes MVS et vous avez la garantie qu'il y aura une programmation COBOL aussi longtemps que le soleil brille.

Je peux vous dire comment je l'ai "appris":
j'étais employé pour travailler avec, sans avoir la moindre idée de quoi il s'agissait, et je n'ai eu aucune difficulté à l'apprendre du jour au lendemain.

Donc, si vous en avez besoin, vous pouvez l'apprendre. Pas besoin de vous surcharger de connaissances inutiles. Il n'y a rien d'intéressant ni de ses engagements, sauf si vous en avez un réel besoin pratique.

La réponse générique: apprendre les principes de codage, pas leurs implémentations spécifiques (comme les langages, etc.)

Je ne passerais pas de temps dessus.
Quoi qu'il en soit, COBOL est la pierre angulaire de nombreux programmes d'application hérités qui sont essentiels à la mission de plusieurs grandes entreprises lancées il y a 20 ou 30 ans.
Donc, si vous êtes embauché pour une entreprise qui a une partie de son cœur de métier à COBOL, il y a des chances que vous deviez commencer à l'apprendre.

Apprenez-le si vous aimez, après tout, savoir comment les choses fonctionnent (ou fonctionnaient auparavant) ne peut pas être une mauvaise chose.

Cependant, je recommanderais de ne pas trop insister sur vos compétences COBOL dans votre CV.

Dans certains endroits (par exemple, dans la Silicon Valley où j'habite), avoir COBOL dans votre CV va être un handicap. Oh bien sûr, vous pourriez trouver un endroit ici et là qui a besoin de votre expertise, et dans ce cas allez-y et faites-en la publicité uniquement dans ces endroits . Mais en général, faites-vous plaisir et oubliez de mentionner que vous connaissez COBOL.

Alors oui, apprenez-le si vous êtes curieux, ne le dites à personne.

Peut-être que cela ne vaut pas du point de vue du marché du travail, mais vous voudrez peut-être y jeter un coup d'œil juste pour avoir une idée de la façon dont les choses ont été faites "au bon vieux temps". ^^

D'un point de vue personnel, je dirais qu'il y a de meilleures choses à apprendre en premier. Cependant, de nombreuses grandes entreprises ont de très gros investissements dans leur base de code COBOL qu'elles ne seront probablement jamais vraiment en mesure de laisser derrière elles, créant une industrie pour les programmeurs COBOL pour maintenir la base de code ainsi que pour écrire un nouveau code. La société pour laquelle je travaille est une grande société financière et notre division technologique pour les développeurs est d'environ 30% COBOL, 40% Java et 30% C #.

Je viens de faire une recherche de "cobol" sur le plus grand site d'emploi d'Australie. Il a renvoyé 87 résultats, et (à partir d'un survol rapide), ils semblent principalement être des postes de maintenance hérités dans les banques et les institutions financières. Généralement nettement mieux rémunéré que les emplois basés sur des langues plus "modernes" - probablement en raison de la rareté de l'expérience Cobol.

Donc oui, il semble que Cobol mérite d'être appris si vous 1) ne vous occupez pas de faire de la maintenance héritée et 2) vous voulez entrer dans un créneau bien rémunéré et probablement pas très compétitif car c'est quelque chose que peu de gens apprennent plus.

(Je suppose que le marché du Cobol serait similaire dans la plupart des économies du premier monde, mais pourrait se tromper?)

Pensez aux types de domaines problématiques dans lesquels vous souhaitez travailler. Généralement, ces domaines ont un ensemble de langues généralement utilisées à cette fin. Si COBOL correspond à cela, allez-y.

Il n'y a aucun moyen que je touche au cobol ou au (x) domaine (s) problématique (s) qui l'utilisent fortement avec un poteau de 10 pieds. Je préfère retourner les hamburgers.

Vérifiez également si le langage offre un bonus / amélioration à votre capacité / concepts de programmation. Je ne peux penser à rien que COBOL puisse faire / implémenter / fonctionnalités qui ne soit pas mieux fait ou qui puisse être mieux démontré dans une autre langue.

Vous et les autres pouvez vous sentir différemment.

Il existe encore de nombreux systèmes hérités écrits en COBOL. Que vous souhaitiez les maintenir ou les porter sur d'autres langages de programmation, cela vaut toujours la peine d'apprendre COBOL.

Quoi qu'il en soit, certaines connaissances dans plusieurs langages de programmation seront un plus car les connaissances que vous avez vous permettent de choisir un langage ou une approche de programmation pour différents besoins de projet. Vous pouvez utiliser vos connaissances dans les langages de programmation pour construire des codes meilleurs, plus propres et plus efficaces et pour éviter les pièges.