Discussion :

[el_slapper]

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.

[bernard59139]

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

[Pico-----]

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

[didier.durand]

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

[bugsan]

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.

[teurastaja]

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.