À part les logiciels hérités, existe-t-il des raisons d'utiliser COBOL?

11

COBOL est encore (fortement?) Utilisé pour le calcul financier. C'est un ancien langage, et AFAIK la plupart des programmeurs détestent, ou du moins n'aiment pas, COBOL. Cela pose une question: est-ce la seule raison pour laquelle COBOL est toujours utilisé que les logiciels hérités l'utilisent, ou at-il de réels avantages par rapport aux autres langages de programmation?

Juste curieux.

— Anto
source

3

L'ancien n'est pas une raison en soi.

Non, mais il manque probablement de fonctionnalités modernes à cause de cela. Ce n'est pas si important si le langage est par ailleurs bien conçu.

— Anto

Également encore largement utilisé au sein du gouvernement, pas seulement dans les banques.

— BBlake

6

"la plupart des programmeurs détestent COBOL" - eh bien, je suis presque sûr que la plupart des programmeurs ne l'ont jamais utilisé non plus. Je serais surpris si plus de 5% de ces "haineux" avaient une idée de sa syntaxe ou de sa forme. Ils l'utilisent simplement comme un exemple du mal des systèmes hérités sans vraiment savoir ce qui se passe. Similaire à la façon dont FORTRAN est souvent considéré.

— TZHX

@TZHX: La citation devrait cependant être "AFAIK, la plupart des programmeurs détestent, ou du moins n'aiment pas, COBOL". Je ne dis pas qu'il est comme ça, il est juste que je l' ai interprété la situation. Mais ce que vous dites pourrait être vrai, mais je ne le sais pas assez bien pour dire quoi que ce soit moi-même, je n'ai utilisé que des observations personnelles sur les opinions des gens (qui peuvent souffrir exactement de ce que vous avez dit).

— Anto

12

C'est surtout hérité maintenant. De nombreux systèmes d'entreprise critiques sont toujours dans COBOL simplement parce qu'ils sont si grands et intégrés que le coût de la réécriture ne semble pas en valoir la peine. Il n'est probablement plus possible d'écrire un nouveau système dans COBOL, car la plupart des développeurs COBOL sont si rares qu'ils peuvent retirer une somme considérable d'argent pour la compétence spécialisée (similaire à un développeur Foxpro maintenant). Il y a peu ou pas de raisons de garder une application COBOL, mais malheureusement, le raisonnement commun est lorsque l'application COBOL est déjà en place, fiable et étroitement couplée avec d'autres systèmes là où elle est presque impossible à remplacer. Ce raisonnement est exactement pourquoi il devrait être remplacé avant d'arriver à une situation où le seul matériel qui exécute l'application doit être construit sur mesure à partir de pièces Ebay des années 80/90.

— Ryan Hayes
source

Qu'est-ce qui vous fait dire "c'est surtout un héritage maintenant"? Je ne pense pas que vous sachiez vraiment de quoi vous parlez. Je travaille actuellement sur un nouveau projet COBOL de plusieurs millions de dollars. Je connais également plusieurs autres projets de développement très importants utilisant COBOL comme langage de mise en œuvre principal. Un vœu pieux de votre part ne devient pas réalité.

— NealB

1

Ne me le prenez pas. Les recherches d'O'Reilley indiquent que les ventes de livres Cobol sont presque inexistantes par rapport à toutes les autres langues. C'est soit parce qu'il n'y a pas d'intérêt pour les développeurs, soit parce qu'il n'y a pas assez de développeurs qui l'utilisent. Je suis sûr que vous pouvez trouver de nouveaux développements à l'aide de COBOL, mais c'est toujours MÉDIATEMENT hérité (pas tous hérités). Je suis sûr que quelqu'un comme vous qui se spécialise dans le COBOL aurait des liens avec d'autres personnes qui n'utilisent que du COBOL. Tout comme ce serait le cas avec moi, avoir seulement des amis qui utilisent une seule langue ne signifie pas que je ne suis pas la minorité.

— Ryan Hayes

Dans notre entreprise, nous copions / collons à peu près le code existant, le modifions en fonction de nos besoins et disons «terminé». Heureusement, je peux faire mon développement en C # / VB

— Wayne Werner

4

COBOL est encore (fortement?) Utilisé pour le calcul financier.

C'est ça?

Cela dépend de ce que vous appelez l'informatique financière. Si vous appelez tout le code géré par les institutions financières, c'est probablement le cas. La plupart ont des règles commerciales écrites dans les années 60 et 70. Le risque + le coût de la mise à niveau de systèmes comme celui-ci vers un nouvel environnement n'en vaut pas la peine. Je doute qu'il y ait quelqu'un qui écrive un nouveau code COBOL. Il existe aujourd'hui des compilateurs COBOL qui s'intègrent dans la pile .NET, par exemple. Il existe souvent des outils pour intégrer et exploiter les applications héritées dans des piles de logiciels modernes, mais ces outils sont souvent inconnus des personnes qui n'ont pas à les utiliser, car il s'agit d'un marché très spécialisé.

Maintenant, si vous appelez l'informatique financière quelque chose de plus semblable à un logiciel de finance quantitative, je n'ai jamais entendu parler de quelqu'un utilisant COBOL. C ++ est beaucoup plus courant, le long de certains langages de niche comme k, un dérivé APL.

— Vitor Py
source

ket ses descendants qsont une telle douleur

— Andrey

@Andrey C'est une question de goût. J'apprécie.

— Vitor Py

vous êtes chanceux. L'un des plus gros problèmes pour moi est le manque d'IDE normal et les messages d'erreur inutiles

— Andrey

2

@Andrey Oui, s'éloigner de l'environnement de développement traditionnel est le plus gros problème lors de l'utilisation de langages de niche. J'avais l'habitude de faire du code C ++ lourd avant de l'utiliser, donc je suis un peu habitué aux messages d'erreur inutiles :)

— Vitor Py

@Andrey, IBM dispose d'outils basés sur Eclipse pour Cobol.

4

COBOL voit principalement l'héritage utilisé maintenant. Sa base d'utilisateurs diminue lentement par attrition, car aucune nouvelle application n'est en cours d'écriture et les anciennes sont progressivement, mais sûrement, supprimées.

La plupart des systèmes COBOL qui pourraient être remplacés rapidement et à moindre coût ont déjà été remplacés. Ceux qui ne sont pas devenus de plus en plus chers à réparer ou à remplacer, mais moins chers et moins chers à entretenir par rapport aux systèmes plus récents - ils fonctionnent bien sur du matériel bon marché et obsolète et, après de nombreuses années de service, ne sont plus montrant plus de nouveaux bugs. La plupart des bogues ont été corrigés ou ont des traditions de longue date qui conviennent comme solutions de rechange. La maintenance a généralement été réduite à un ou deux employés spécialisés qui, après avoir longtemps travaillé sur le système, le connaissent plus intimement que vous ne pouvez l'imaginer.

Même d'un point de vue technique, il existe généralement de bonnes raisons de conserver les anciens systèmes. Ils sont relativement stables, ont été corrigés pour la plupart par des bogues et sont bien connus / compris par l'utilisateur final.

Vous verrez cependant que le système sera éventuellement remplacé. En règle générale, cette décision vient du côté des affaires:

Les utilisateurs du système actuel sont remplacés par des utilisateurs plus jeunes, qui ne peuvent pas être convaincus d'apprendre à utiliser l'interface archaïque
L'entreprise ne trouve personne à embaucher pour maintenir le système, à un salaire qui n'est pas scandaleux par rapport à celui des autres employés
Quelqu'un avec un gros budget devient gêné de découvrir qu'un système de base pour l'entreprise fonctionne sur du matériel qui peut être remplacé par un vm sur un ordinateur portable
Un nouveau système de produits de base arrive, ce qui est vraiment très bon marché pour commencer à utiliser
L'entreprise qui utilise les anciens systèmes est acquise, fait faillite ou cesse de réellement exister
Un élément crucial de nouvelles fonctionnalités requises de toute urgence ne peut pas être fabriqué à moindre coût pour interagir avec le système hérité

— blueberryfields
source

2

Quel est votre parcours pour être si certain?

Je peux affirmer catégoriquement que votre certitude est déplacée - nous avons plusieurs nouveaux employés (20-30 ans) qui écrivent du nouveau code Cobol (mise à jour et / ou copie et modification des systèmes existants), et nous avons au moins 10% de nos ~ 200 développeurs qui passer 80% + de leur temps de développement à Cobol. Je pense que vous constaterez que la plupart des endroits qui utilisent Cobol sont exactement le contraire de ce que vous décrivez.

— Wayne Werner

4

me demande ce que vous entendez par «la plupart des programmeurs». Je travaille dans une grande boutique informatique au même étage que les programmeurs cobol, les programmeurs Java, le programmeur .NET (au singulier), les programmeurs VB à l'ancienne. Il n'y a ni haine ni aversion. cobol est un langage comme tout autre langage de programmation - les gens qui programment en cobol le font parce que c'est un travail qui n'est pas différent pour eux de programmer en java ou de conduire un camion. Contrairement à la conception populaire aux États-Unis, de nombreux cobols continuent à être écrits, mais la plupart se trouvent en Inde où chaque jour de nouveaux programmeurs Cobol commencent à travailler.

Je pense que la raison pour laquelle pas trop de nouveaux systèmes nets sont écrits en Cobol est parce que le type de systèmes qui convient à cobol (traitement de fichiers à gros volume) est déjà écrit. Très peu de nouvelles grandes sociétés sont créées de nos jours. Et ceux qui le font pourraient sous-traiter des éléments comme la paie et les avantages sociaux à des entreprises qui gèrent des systèmes Cobol hérités.

2

Une grande partie du code principal de PeopleSoft est écrite en COBOL.

— bit-twiddler
source

Je dois comprendre, en discutant avec les représentants de PeopleSoft lors d'une conférence informatique en 2004 avant qu'Oracle ne les ait acquis, que ce n'était à l'époque qu'un module du produit qui était encore en COBOL.

— Kennah

Comment cela donne-t-il un avantage à COBOL par rapport aux autres langues?

— Matthieu

2

Avec 20 ans d'expérience COBOL, sur trois mainframes différents, il est à mon humble avis qu'il y a peu de vrais programmeurs COBOL et à la place il y a des programmeurs IBM, des programmeurs Sperry (Unisys 2200), des programmeurs Burroughs (Unisys MCP) et Tandem (HP NonStop) programmeurs. En signe de respect à leur égard, je dois également mentionner la présence de programmeurs HP 3000, de programmeurs BULL et de programmeurs DEC.

COBOL fonctionne sur de grandes boîtes en fer, pour la plupart. Peut-être que les seuls vrais programmeurs COBOL, selon mes propres normes, sont ceux qui écrivent COBOL sur une boîte UNIX. Wow, je vais en entendre parler.

Parce que le matériel est l'élément central, la plupart des programmeurs qui écrivent COBOL s'identifient par le matériel sur lequel le code qu'ils écrivent s'exécute. Au fil des ans, en écoutant d'autres programmeurs me parler des mérites de Sperry, Burroughs ou Tandem, je me suis souvent demandé quel genre de guerre s'ensuivrait si je les rassemblais et les plaçais ensemble dans une pièce incapable de partir jusqu'à ce qu'ils convenu d'une plate-forme matérielle pour tous les COBOL. Je n'ai pas mentionné les autres plateformes car je n'ai jamais travaillé dessus.

J'ai rencontré et parlé avec de nombreux programmeurs IBM, et ils se qualifieront de programmeurs COBOL. Cependant, si l'on les engage dans la conversation, ils commencent rapidement à se référer aux procédures et outils spécifiques d'IBM. Compte tenu de la nature matérielle de COBOL, cela est très compréhensible, pour toutes les plates-formes matérielles.

Parce que COBOL est généralement lié à un matériel très coûteux, tant que ce matériel exécute les programmes COBOL compilés dessus, il n'y a pas de forte volonté de migrer de COBOL pour le bien de la migration. Cependant, avec une population vieillissante de programmeurs COBOL, la migration est inévitable.

Étant donné que toutes les grandes boîtes de fer exécutant COBOL exécuteront également Java, Java est le chemin naturel de migration loin de COBOL. Le code peut être converti, en particulier maintenant dans une économie en baisse, pour un prix plutôt économique. Une fois qu'il n'y a pas de COBOL, seulement Java, sur ce gros matériel coûteux, alors quelqu'un plus haut dans l'organisation va commencer à se demander s'il est possible de déplacer le code Java vers un autre matériel beaucoup moins cher.

Les programmeurs IBM, Sperry, Burroughs et Tandem le savent, ils ne proposeront donc JAMAIS l'idée. Ce serait un sacrilège pour certains.

— Kennah
source

+1, très cher en effet. De plus, soulignant que Java est en train de devenir le nouveau Cobol - ce que j'ai vu moi-même et je ne suis qu'un jeune mâle, il est donc intéressant de voir quelqu'un ayant de l'expérience faire la même observation.

— Wayne Werner