Discussion :

[Gordon Fowler]

« COBOL est plus vivant que jamais ! »
D’après Micro Focus qui met en avant la simplicité et l’adaptabilité du langage



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 ?

[manudwarf]

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

Normal, quand on compare le nombre de lignes de code nécessaire pour faire la même chose

(commentaire tout aussi objectif que Micro Focus)

[metalange]

Interessant (étant dev COBOL) mais manque clairement d'objectivité

[el_slapper]

Cobol est un langage de niche. très fort dans sa niche(en gros, le traitement massif de données comptables ou similaires), abominable en dehors.

Le besoin de mon client est dans la niche, alors je fais ouah-ouah!


Je crois que la plus grande menace, c'est l'extinction du savoir-faire. Si plus personne ne sait maintenir, alors les utilisateurs seront bien obligés de le remplacer.

@manudwarf : le java est assez bavard, comme langage, lui aussi. Parle-moi de Lisp - ça c'est un langage concis(et illisible pour qui n'est pas Paul Graham).

Sur le coût, j'ai quand même toujours en mémoire cette réponse de la MOA, quand je lui avait dit que le batch qu'ils nous demandaient serait mieux sous Java : "C'est possible, mais vous êtes tellement moins chers!". En gros, deux fois moins chers. Mais c'est moins lié, à mon sens, au langage lui-même qu'à son environnement. Pour tester un pet de mouche, le programmeur java doit monter son composant sous clear-case, puis remplir 4 papiers pour que la cellule d'intégration prenne en compte son composant. Moi, je fais une misérable action ENDEVOR, et basta. Le jour ou les gens qui travaillent sur des langages "modernes" auront appris à découper leur travail en tous petits projets, l'avantage de productivité sera beaucoup moins évident.

Tant qu'ils feront un méga-projet pour toutes les applis de la boite, coté productivité, nous serons tranquille. 4 heures pour ouvrir the projet dans Eclipse, c'est l'apocalypse. Quel que soit le langage.

[sviardot]

Dans notre cas, le problème vient du fait que nous n'utilisons pas directement Cobol mais un progiciel RH qui génère du Cobol. Du coup, si tenté que ce langage ait réellement un intérêt par rapport à d'autres (en particulier le c - c++ ), il est de toute façon masqué par un méta compilateur qui produit du code obscur voir crade.
L'éditeur du méta compilateur mais Micro Focus voyons ... ... ...

[BernardBZH]

A mon sens COBOL a encore de beaux jours devant lui.

Par l'intermédiaire de ma SSII j'ai eu l'occasion de travailler pour plusieurs banques, assurances, industries et autres opérateurs de téléphonie (qu'on pourrait croire friands de "nouvelles technos"). La grosse majorité des applications stratégiques de ces entreprises tourne en COBOL sur mainframe, et non seulement pour "le traitement massif de données comptables ou similaires" comme le dit si justement el_slapper mais aussi pour de nombreuses applications TP, certaines entreprises se contentant de faire un habillage web "sexy" alors que l'exécution des requêtes se fait sur mainframe avec des programmes COBOL. Et les réflexions entendues sur ces sites rejoignent le souvenir d'el_slapper : le COBOL au moins ça marche, on sait ce que ça fait et c'est pas trop cher ... Au sujet du coût la réflexion d'el_slapper sur les usines à gaz que mettent en œuvre les projets en langages dits "modernes" est on ne peut plus pertinente.

Effectivement on n'enseigne plus COBOL mais on ne demande pas trop son avis à un jeune embauché en SSII et je ne compte plus le nombre de ceux à qui j'ai appris les rudiments de ce langage (et quelques siouxeries si le budget du projet le permettait) et qui continuent à le pratiquer avec bonheur après avoir surmonté les premiers moments de répulsion.

[pelebianco]

travaillant depuis 20 ans dans la reservation aerienne, je vous assure qu'aucune ligne de code Cobol n'est utilisee dans ce domaine.
les sytemes furent ecrit initialement en Assembleur/C/C++ & egalement Java pour le web.
donc c'est un peu de la propagande..

[Hédhili Jaïdane]

Je l'ai utilisé sur la plupart des plateformes micro, mini et mainframe et ce dans divers environnements d'entreprise mais en particulier de la gestion. Je l'utilise encore sur les mini d'IBM dans des PME/PMI avec DB2 (sans passer par SQL). Il m'a toujours donné satisfaction. Avec les dernières versions ILE (mini) et LE (mainframe) et ses supports pour Java, XML et SQL, il offre des possibilités énormes. Il existe même des versions graphiques.

Déjà à l'occasion du 50è anniversaire : http://www.developpez.net/forums/d81...s/#post4656086

[BernardBZH]

Je ne pense pas que ce soit de la propagande mais juste un état de fait et une réponse à des besoins spécifiques.

Quand les SI brassant des millions de données par nuit dans leurs nombreux traitements batchs ont été mis en place, le seul langage répondant sérieusement à ces besoins et accessible au commun des développeurs était le COBOL. Certes il y avait l'assembleur (au moins aussi efficace) mais, pour l'avoir un peu pratiqué, ce n'est pas le plus intuitif des langages et pour la maintenance ultérieure c'est catastrophique.

Après il faut bien sûr ne pas être sectaire et savoir reconnaître les mérites de chaque langage et architecture pour des situations spécifiques. Ce serait par exemple une horreur, à mon sens, de développer des applications web en COBOL, bien que j'ai eu sous le nez des bouquins traitant de ce sujet. En revanche je ne vois pas à l'heure actuelle de concurrent sérieux à des architectures COBOL/Mainframe pour traiter en une nuit les données comptables des banques et assurances.

[bugsan]

Rappelez moi sur quoi tourne Facebook, Twitter, Google, Amazon ...
Il serait peut être temps de se réveiller


Évidemment quand on parle de traitement de données en cobol qui seraient soit disant plus rapide qu'avec d'autres langage, on n'a rien pour comparer. Aucun chiffre, aucun benchmark ... Il faut juste croire aveuglément les VRP d'IBM en fait ...

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€ ...


Je rajouterais enfin que dans n'importe quel langage on peut développer un framework permettant de programmer "à la cobol" ...

[Karsus]

Perso je suis en pleine migration vers une solution SAP parce que l'ancien logiciel ( en cobol ) coutait trop cher en maintenance !

Sans aucune modif l'ancien système nous coutait beaucoup trop cher. Par contre c'était un logiciel parfaitement adapté et qui a été créé sur mesure il y a plus de 10 ans et qui fonctionne encore très bien alors que SAP demande 4x plus de temps pour réalisé une simple action !

Genre création d'un nouvel article : créer l'article -> créer une caractéristique -> l'asigner à la bonne classe -> créer la nomenclature -> créer la condition de sélection -> créer la procédure -> encodé les données pour le temps de traitement -> encoder le prix pour l'assurance

bref c'est LOURD et ca prend un temps fou. sans compter la lenteur de SAP en lui même par rapport à notre bon vieux soft.

L'informatique aujourd'hui tourne trop autour de l'argent et du timing ! Il faut aller très vite et faire pas cher donc beaucoup moins de place pour la qualité et l'optimisation.

[renloft]

La plupart du temps on critique cobol mais je constate à chaque fois quand on tente de changer vers un nouveau langage c'est pour faire la même chose.
Néanmoins, je vous invite à regarder cette présentation du projet NACA cobol vers Java.
http://www.parleys.com/#st=5&id=1907&sl=3

Ce qui motive le changement, c'est le prix des machines et des soft IBM.
Or il est tout à fait possible de faire du cobol sur PC ou Linux avec des performance excellente comparable au mainframe.

Il serait intéressant de réaliser un test de comparaison.

[bilbot]

Perso pour en avoir fait un peu le cobol est très rebutant rien que la limitation des 80 caractères. Et peut être que c'est moins cher en maintenance, mais en exploitation c'est autre chose (cf projet naca).

[el_slapper]

Le projet NACA, de mémoire, ça a donné du Jobol, pas du java : ça tourne sur une machine java, ça utilise des mots-clefs java, mais la manière de penser est extrêmement cobol. En bref, on a tous les défauts de java, sans aucun des avantages.

La limite des 80 caractères(moins six de commentaires amont, moins 8 de commentaires aval, moins un de colonne de type de ligne, moins 4 utilisables seulement pour les labels, ça fait 61), c'est une habitude à prendre. C'est un peu casse-bonbon pour les longs libellés en dur(dont il ne faut pas abuser de toutes façons). Pour le reste, rien n'empêche de coder sur plusieurs lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
DIVIDE LENGTH OF     W-ID-TIERS-EN-COURS     
    BY LENGTH OF     W-ID-TIERS           (1)
       GIVING        W-ID-TIERS-MAX

C'est bavard, certes, mais un non-coboliste, voire un non-programmeur peut comprendre que c'est une division. Alors qu'un opérateur ternaire java...


Le cout des machines est un vrai problème, mais ce sont aussi des machines rares, donc avec peu de compétences chez les crackers.


Celà étant dit, m'étant récemment cogné aux limitations du cobol(la couche objet est une sinistre blague, il n'y a pas de collections.....), je rêve d'un langage plus moderne(genre C#) qui inclue les features les plus utiles du cobol :

1. contrôle absolu du type de la donnée numérique : binaire, binaire codé décimal, numérique étendu, signé ou non, position de la virgule... le tout géré en natif par le compilateur.
2. gestion de formats de fichiers plats complexes, avec gestion du multiformat(le Redefines, angoisse absolue de tous les convertisseurs)
3. la flexibilité du PERFORM

Avec ça, on peut quasiment tout faire ce que fait le cobol, en plus moderne. Reste à ne pas tout mettre dans le même projet, sinon.....

Mais en fait, l'évolution des langages modernes va dans l'autre sens : toujours plus d'introspection, de typage dynamique, de trucs invisibles. Or, nous bossons dans des applis ou le contrôle du traitement est essentiel. Je conçois tout à fait que Google aie à faire un maximum de typage dynamique. La Banque Du Sud-Est-Ouest ne peut pas se le permettre. En aucun cas.

[bugsan]

1. contrôle absolu du type de la donnée numérique : binaire, binaire codé décimal, numérique étendu, signé ou non, position de la virgule... le tout géré en natif par le compilateur.
2. gestion de formats de fichiers plats complexes, avec gestion du multiformat(le Redefines, angoisse absolue de tous les convertisseurs)
3. la flexibilité du PERFORM

1) On pourrait créer des classes de type, un peu comme le BigInt. Le problème c'est que ces formats sont totalement inconnus des processeur ... Je ne m'avancerais pas trop mais je crois même qu'ils devraient être bannis ...
2) Il existe des frameworks pour faire du binding de record=>objet java et inversement. Smooks possède un truc assez complet. Rien n'empêche d'en faire un soit même, ce n'est pas trop compliqué. Pour le redefine, je me suis confronté au problème... Dans de nombreux cas en fait il faudrait utiliser du XML ... (qui a l'inverse est lolesque en cobol).

[Patriarch24]

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à...

[BernardBZH]

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.

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.

[herzleid]

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 ^^)

[bugsan]

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 ...

[Hédhili Jaïdane]

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...