« COBOL est plus vivant que jamais ! »
D'après Micro Focus, qui met en avant la simplicité et l'adaptabilité du langage : et d'après vous ?

Le , par Gordon Fowler, Expert éminent sénior
Chaque jour, un consommateur solliciterait 13 fois des applications COBOL dans ses actes de la vie courante. C'est ce qu'avance en tout cas Micro Focus pour qui le langage est derrière plus de 70% des applications stratégiques des entreprises.

« Force est de constater que, malgré la récurrence des critiques contre le COBOL depuis plus de 20 ans, les détracteurs de ce vieux langage n’ont toujours pas eu raison de lui. Depuis sa création en 1959 par un groupe d’informaticiens et de scientifiques travaillant pour le Pentagone, plus de 220 milliards de lignes de codes ont été générées ; et selon une étude de Datamonitor de 2008, 5 milliards de lignes de codes continueront à être ajoutées chaque année aux systèmes existants », écrit Micro Focus dans son communiqué, avant de continuer sur les usages professionnels. « Ce sont entre 60 à 80% des activités des entreprises internationales qui reposent sur des applications COBOL selon Gartner, tous secteurs confondus : le COBOL est le langage avec lequel ont été écrites les applications cœur de métier des banques, des compagnies aériennes (pour les réservations de vol notamment), des grands réseaux d’hôtellerie, des transporteurs (applications gérant plus de 72000 containers), de l’industrie pharmaceutique et santé publique (plus de 60 millions de patients), etc. Les applications COBOL servent à opérer 80% des transactions commerciales et à connecter plus de 500 millions d’utilisateurs de téléphones mobiles ».

Bref, « autant de chiffres qui confirment son rang de 1er langage utilisé pour les développements informatiques professionnels – au niveau de l’encodage comme des tests logiciels ».

Pourtant, lorsque l’on parle aux « professionnels de la profession », beaucoup cherchent des profils Java, .NET, Objetcive-C,ou de développeur mobiles. Mais très peu évoquent encore COBOL.

Une situation difficilement compréhensible pour l’éditeur qui se positionne en véritable avocat du langage. « Le COBOL a de nombreux atouts. Il a été conçu à l’origine pour simplifier la programmation logicielle afin de la rendre accessible à un plus grand nombre de personnes et de l’adapter à des approches orientées métier. Sa syntaxe est proche de celle de la langue anglaise, elle utilise des mots anglais, et le processus d’encodage a été simplifié. […] L’une des principales forces de COBOL est en effet sa capacité à être intégré et interopéré avec les autres langages informatiques, y compris les plus récents : on a eu du COBOL avec les assembleurs mainframe, puis avec du C++ pour les systèmes ouverts et aujourd’hui avec .Net, les JVM et le cloud. Le COBOL tourne aussi sur toutes les machines (mainframes, zOS, micro ordinateurs, terminaux mobiles). Il est compatible avec tous les environnements d’exploitation fixes et mobiles, et supporte tous les types d’architecture, jusqu’au cloud. Les développeurs peuvent donc moderniser des applications COBOL pour les porter dans des environnements comme Azure, .Net comme les intégrer avec les JVM écrites en Java ».

Micro Focus évoque également une très grande évolutivité (« les cartes et les rubans perforés ont cessé d’être développés car devenus inutiles avec l’apparition d’innovations type iPhone et sites web de dernière génération. En revanche, le COBOL est utilisé aujourd’hui pour coder des applications métier stratégiques dédiées au cloud et aux terminaux mobiles ») et un coût inférieur à d’autres langages (« le coût pour réparer une ligne de code Java est de 5,42 dollars, contre 1,26 dollar pour une ligne COBOL […] moderniser une application cœur de métier historique en travaillant sur son code source COBOL revient in fine 4 fois moins cher que de la réécrire intégralement et dix fois moins cher que d’installer un applicatif métier totalement nouveau »).

Bref, COBOL serait « plus vivant que jamais ! ». Mais visiblement mal aimé.

Par soucis d’objectivité, rappelons que Micro Focus a édité il y a tout juste 6 mois une offre de développement pour COBOL.

Source : Micro Focus

Et vous ?

Que pensez-vous de COBOL ?
Trouvez-vous le langage injustement mal-aimé ?
Pensez-vous qu’il va disparaitre, ou comme Micro Focus qu’il est plus vivant que jamais ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Patriarch24 Patriarch24 - Membre expérimenté https://www.developpez.com
le 03/02/2012 à 14:14
Des outils de traitement massif de données il en existe en C/C++/Java/... au choix. Très efficaces. A comparer au COBOL... ou pas.

autant de chiffres qui confirment son rang de 1er langage utilisé pour les développements informatiques professionnels

Il existe un grand héritage en COBOL, et réécrire l'intégralité de ces applications prendrait un temps trop long pour être envisageable. Donc oui, COBOL a encore de beaux jours devant lui, mais de là à dire que c'est le meilleur et le plus utilisé...

le coût pour réparer une ligne de code Java est de 5,42 dollars, contre 1,26 dollar pour une ligne COBOL

Je la trouve géniale celle-là...
Avatar de BernardBZH BernardBZH - Membre régulier https://www.developpez.com
le 03/02/2012 à 14:20
Citation Envoyé par bugsan  Voir le message
Pourquoi ne pas lancer un concours de perf plutôt ? On va bien voir si un mainframe à 10 millions d'euros ça va plus vite qu'une Radeon 7950 à 500€ ...

Un concours de bécane ? Oui ce serait instructif pour tout le monde.

Citation Envoyé par bugsan  Voir le message
Je rajouterais enfin que dans n'importe quel langage on peut développer un framework permettant de programmer "à la cobol" ...

Il n'est justement pas question de programmer "à la cobol". Chaque langage a ses richesses qui le rendent performant dans un contexte spécifique mais catastrophique si on le transpose ailleurs ou si on tente de plaquer ailleurs une pseudo-structure qui lui ressemblerait. Ca me fait penser à quelques douloureux projets de migration de SGBD vers un autre que j'ai connus : accéder à une structure relationnelle à partir d'un code préalablement écrit pour naviguer dans une structure hiérarchique c'est du n'importe quoi et pourtant ça s'est fait, tout ça parce qu'on n'a pas eu le courage de mettre à plat un SI pour de basses raisons financières mais le relationnel c'était quand même plus clinquant que ces vieux dinosaures d'IMS, IDMS ou IDS2.

Ceci pour dire que je ne suis pas vendu à IBM et que j'aime suffisamment mon boulot pour ne pas craindre de remettre les choses à plat quand c'est nécessaire et explorer de nouvelles pistes, conserver les trucs qui tournent (parce que c'est reposant aussi d'avoir un socle stable) et réfléchir à plusieurs fois avant de les jeter sous prétexte qu'ils ont été développés avec des outils qui ne sont plus dans l'air du temps. Et si on veut se faire plaisir on trouve toujours le moyen de bidouiller chez soi ou au boulot.
Avatar de herzleid herzleid - Membre confirmé https://www.developpez.com
le 03/02/2012 à 16:03
Sur l'ensemble des entreprises possédant du mainframe, j'ai rien vu capable de traiter des fichiers de taille supérieur à 100Go aussi vite.

La vitesse de développement est aussi supérieur à ce que font les autres ETL.

Maintenant le développement COBOL concerne rarement les mêmes applicatifs.

Cobol est loin d'être mort, mais sa fin se rapproche de toute façon. (on trouvera bientôt plus personne pour savoir lire une ligne de Cobol ^^)
Avatar de bugsan bugsan - Membre confirmé https://www.developpez.com
le 03/02/2012 à 18:32
Citation Envoyé par BernardBZH  Voir le message
Un concours de bécane ? Oui ce serait instructif pour tout le monde.

Je voulais dire résoudre un même problème en cobol, C, et java... (ou mixer les langages, je suis pour le polyglote programming). On voit tellement de comparatifs C/java sur un même algo, et rien avec cobol... je trouve ça dommage.

On comparerait la vitesse de traitement, le nombre de ligne de code nécessaire, la mémoire utilisée ...
Avatar de Hédhili Jaïdane Hédhili Jaïdane - Membre expert https://www.developpez.com
le 03/02/2012 à 19:09
amha, il n'est pas question de programmer n'importe quel problème en Cobol. Il est bien adapté à des opérations de calcul simples mais dans des traitements complexes sur des gros volumes et sur une multitude de fichiers de tout type. Il n'est pas fait pour faire des calculs scientifiques ou statistiques avancés, ou programmer des jeux bien chiadés, quoiqu'on ait pu faire ça quand on n'avait pas d'autres possibilités. Il n'est pas question de programmer des applications graphiques par exemple. Actuellement avec le ILE et le LE on a certaines possibilités mais ça reste limité. Sur certaines versions on a la possibilité, par exemple, de traiter des nombres sur 63 digits et des tableaux à 7 indices.

Il fut un temps où on se tapait en Cobol des calculs de trigo (en passant par les DL) ou le calcul d'une racine carré par simulation de l'opération manuelle, ou les fonctions de traitement des dates. D'ailleurs, même en Fortran on se tapait ça et cela a enrichi les biblios scientifiques. Elles ne sont pas tombées du ciel comme ça, il y a des gens qui ont trimé pour le faire.

Maintenant ces fonctions et divers algo ont intégré la plupart des nouveaux langages et on ne s'embêtent pas à réinventer la roue.

Je pense que Cobol a encore de l'avenir de lui, mais il faut l'utiliser en collaboration avec les autres langages adaptés à chaque besoin. S'il faut le développer, les éditeurs devraient penser à intégrer :
- plus de fonctions intrinsèques,
- les traitements graphiques,
- les supports intégrés d'autres langages comme ce fut le cas de Java, XML et SQL,
- les traitements des chaines de caractères,
- la ligne libre de code
- une meilleure et plus simple utilisation des varchar,
- etc...
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 06/02/2012 à 15:20
Citation Envoyé par bugsan  Voir le message
Je voulais dire résoudre un même problème en cobol, C, et java... (ou mixer les langages, je suis pour le polyglote programming). On voit tellement de comparatifs C/java sur un même algo, et rien avec cobol... je trouve ça dommage.

On comparerait la vitesse de traitement, le nombre de ligne de code nécessaire, la mémoire utilisée ...

Le truc, aussi, c'est la philosophie de codage qui va avec. Qui est hautement dépendante des outils disponibles. Un batch de mise à jour d'une base de données relationelle, dans un langage moderne, ça donnerai un programme simple, avec un gros ordre SQL au milieu. En cobol, on va décharger la base sur un fichier plat, faire un programme de traitement enreg par enreg, puis recharger l'intégralité de la base. Comment veux-tu comparer ça?

Oui, oui, j'ai vraiment une table qu'on droppe et qu'on recrée toutes les nuits dans son intégralité. Un langage moderne ne fait pas ça, pour plein de raisons très valables. Mon batch marche du tonnerre, pourtant, et les interfaces JAVA tapent avec bonheur sur ma base. Pendant la journée.

Sinon, +1 pour l'aspect "surprenant" du XML façon cobol. Il est plus efficace, parfois, de le gérer "à la main". Ce qui est assez déplorable, je suis d'accord. On avait fini par générer sous cobol un fichier plat, qui passait ensuite par une moulinette datastage, dont la seule fonction était de transformer tout ça dans un XML digne de ce nom.

Ah, et j'oubliais un aspect tellement pratique du COBOL : le niveau 88. Il parait qu'on peut faire à peu près pareil en C# avec des attributs, mais je n'y suis pas parvenu.

Et encore un : comme la mémoire est purement statique(à moins de jouer avec les pointeurs, mais j'en ai vu 1 en 12 ans, et encore, en lecture seule, c'est pas comme si c'était une pratique courante), les fuite mémoire sont impossibles. J'aime beaucoup les collections, mais elles sont dangereuses. L'exploitation aime les programmes à utilisation mémoire prédéfinie.
Avatar de bernard59139 bernard59139 - Membre chevronné https://www.developpez.com
le 07/02/2012 à 7:06
Bonjour

Ouf, je ne suis pas encore au chomage. Ca fait longtemps que je n'ai pas vu du "pur" cobol codé avec des petits doigts. Dans ma boutique, les prog cobol sont développés depuis Pacbase (officiellement en fin de vie).
Avatar de Pico----- Pico----- - Membre actif https://www.developpez.com
le 08/02/2012 à 12:35
Bonjour,

Déjà, comme cela a déjà été globalement dit, chaque langage a ses forces et ses faiblesses en fonction des besoins : faire de l'embarqué en PHP et du web en LISP ne serait techniquement pas impossible, mais personne le fait pour des raisons évidentes. Et dans ce cadre, le COBOL a peu de concurrence dans certaines applications notamment dans "le traitement massif de données comptables ou similaires" (el_slapper).

Ensuite, il faut revenir aux sources COBOL signifie COmmon Business-Oriented Language. Il est orienté business et est principalement utilisé dans les gros traitements de business. Et là, partout le cœur des réflexions est loin d'être technique mais surtout très axé business et donc gros sous. Et même si il pourrait être intéressant (enfin ça reste à démontrer) financièrement sur le long terme de migrer un SI reposant sur COBOL/mainframe vers des langages et systèmes plus récents, personne dans les réels décisionnaires n'osera lancer un tel projet qui aurait un coût immédiat faramineux.

L'exemple de PACBASE est intéressant : initialement IBM avait annoncé une fin de support en 2012 (c'était début des années 2000). Ce qui n'a pas plus aux différents groupes utilisateurs de PACBASE qui se sont réunis dans l'association le guépard (http://www.guepard.asso.fr/). Je ne sais plus si l'association existait avant l'annonce, cependant quoiqu'il en soit, les utilisateurs ont fait pression sur IBM qui a repoussé la fin de PACBASE en 2015 et a garanti une solution générant du COBOL rétro compatible avec le code généré par PACBASE. Ceci dit, d'autres éditeurs (CA, microfocus justement) ont saisi l'opportunité de prendre des parts de marché et se sont lancés dans la course en proposant des solutions répondant à ces conditions.

Les groupes ayant des systèmes reposant sur du COBOL ont eu une opportunité de changer et de passer à autre chose : mais clairement ils ont fait le choix d'imposer la pérennité du COBOL aux éditeurs, donc je ne pense pas que celui ci soit près de la disparition...
Avatar de didier.durand didier.durand - Nouveau Candidat au Club https://www.developpez.com
le 09/02/2012 à 5:02
Nous offrons chez Eranea une technologie de migration automatique de Cobol vers Java.

C'est une approche pragmatique et iconoclaste qui surprend parfois les puristes de l'orienté objet.

Mais, elle a de grands avantages que les fans de Java comprennent à la fin: on peut migrer très vite une application complète et éprouvée de mamière 100% iso-fonctionnelle vers un environnement moderne et 10x fois moins cher (si, si! - apprécié en cette période de crise...))

Ensuite, on peut injecter ces énormes économies dans une ré-écriture progressive de l'application originelle migrée pour profiter de tous les avantages de la plate-forme Java.

Nous le faisons actuellement pour une application de 10+ millions de lignes de Cobol et le client en est ravi: les avantages pratiques tirés sont largement supérieurs aux défauts théoriqques.

Le premier bénéfice d'une telle migration par iso-transcodage est le fait que les développeurs initiaux retrouvent très facilement leurs petits et leur productivité n'est pas perturbée.

Donc, pour revenir au 1er commentaire, cette approche issue du projet Naca n'est pas sûrement pas parfaite au plan théorique mais elle permet de quitter aisément le monde propriétaire. Alors, le reste....

didier
Avatar de bugsan bugsan - Membre confirmé https://www.developpez.com
le 09/02/2012 à 12:47
Citation Envoyé par el_slapper  Voir le message
Le truc, aussi, c'est la philosophie de codage qui va avec. Qui est hautement dépendante des outils disponibles. Un batch de mise à jour d'une base de données relationelle, dans un langage moderne, ça donnerai un programme simple, avec un gros ordre SQL au milieu. En cobol, on va décharger la base sur un fichier plat, faire un programme de traitement enreg par enreg, puis recharger l'intégralité de la base. Comment veux-tu comparer ça?

Oui, oui, j'ai vraiment une table qu'on droppe et qu'on recrée toutes les nuits dans son intégralité. Un langage moderne ne fait pas ça, pour plein de raisons très valables. Mon batch marche du tonnerre, pourtant, et les interfaces JAVA tapent avec bonheur sur ma base. Pendant la journée.

Je t'arrête tout de suite. Faire un extract de table dans un fichier, traiter le fichier, puis faire un load replace, c'est une technique de traitement, indépendante du langage. Si il n'y a pas de contrainte de disponibilité, c'est la méthode la plus rapide (surtout car les index et les intégrités sont revérifiés en une passe).

Au boulot nous l'avons déjà fait en java, en utilisant SpringBatch. Ce dernier propose une bonne base pour réaliser des batchs, mais je le trouve néanmoins très incomplet et pas trop performant au final. Il faut écrire soit même les ItemReader/ItemWriter si on veut avoir un truc sympas.
Avatar de teurastaja teurastaja - Nouveau Candidat au Club https://www.developpez.com
le 11/02/2012 à 5:13
D'un point de vue global,*l'évolution et l'émergence perpétuelle des languages de programmation se justifie par la quête de nouvelles méthodes de développement.

Un language est une convention qui permet d'attacher une sémantique à une syntaxe. Autrement dit, un language donne un sens à une syntaxe dans un contexte donné; il permet de partager l'interprétation d'un encodage à travers un médium (dans ce cas-ci, les électrons).

Tant que la langue utilisée est "Turing-complete" on peut l'utiliser pour encoder n'importe quel algorithme; parfois au détriment de la performance, ce qui dépend aussi de l'implémentation sous-jacente. Autrement dit, en programmant des compilateurs/interpréteurs, on apprend qu'il n'est pas nécessaire de faire appel à d'autre language que celui utilisé, peu importe comment le language sera décodé au final.

Le language optimal est celui qui permet de traiter clairement et correctement le moins de données et de code possible dans son environnement d'exécution.

Malheureusement, la plupart des développeurs ne choisissent pas les languages qu'ils apprennent et utilisent, souvent au détriment d'une connaissance diversifiée des algorithmes et paradigmes.

Pour ce qui est de cet article, il semble grandement exagéré à première vue mais je ne suis pas une référence sur COBOL. Ce que je sais, c'est que les langues évoluent en s'influençant mutuellement, puis disparaîssent. Ce processus est vraisemblablement accéléré dans le monde de l'informatique.
Offres d'emploi IT
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Spécialiste systèmes informatiques qualité et référent procédure H/F
Safran - Ile de France - Colombes (92700)
Architecte systèmes études & scientifiques H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil