IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Cobol Discussion :

« COBOL est plus vivant que jamais ! », d'après Micro Focus


Sujet :

Cobol

  1. #1
    Expert éminent sénior

    Inscrit en
    Juillet 2009
    Messages
    3 407
    Détails du profil
    Informations forums :
    Inscription : Juillet 2009
    Messages : 3 407
    Points : 149 059
    Points
    149 059
    Par défaut « COBOL est plus vivant que jamais ! », d'après Micro Focus
    « 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 ?

  2. #2
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2009
    Messages
    277
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2009
    Messages : 277
    Points : 742
    Points
    742
    Par défaut
    "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)

  3. #3
    Membre du Club
    Inscrit en
    Mars 2009
    Messages
    49
    Détails du profil
    Informations forums :
    Inscription : Mars 2009
    Messages : 49
    Points : 48
    Points
    48
    Par défaut
    Interessant (étant dev COBOL) mais manque clairement d'objectivité

  4. #4
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  5. #5
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Mai 2009
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2009
    Messages : 3
    Points : 14
    Points
    14
    Par défaut Cobol ?
    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 ... ... ...

  6. #6
    Membre régulier
    Homme Profil pro
    Développeur et formateur Mainframe
    Inscrit en
    Février 2007
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur et formateur Mainframe
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2007
    Messages : 44
    Points : 103
    Points
    103
    Par défaut
    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.

  7. #7
    Candidat au Club
    Homme Profil pro
    Inscrit en
    Janvier 2012
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2012
    Messages : 1
    Points : 2
    Points
    2
    Par défaut Pas tout a fait juste quand meme...
    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..

  8. #8
    Expert confirmé
    Homme Profil pro
    ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    Juin 2007
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 096
    Points : 4 155
    Points
    4 155
    Par défaut
    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

  9. #9
    Membre régulier
    Homme Profil pro
    Développeur et formateur Mainframe
    Inscrit en
    Février 2007
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur et formateur Mainframe
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2007
    Messages : 44
    Points : 103
    Points
    103
    Par défaut
    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.

  10. #10
    Membre confirmé
    Inscrit en
    Octobre 2007
    Messages
    210
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 210
    Points : 459
    Points
    459
    Par défaut
    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" ...

  11. #11
    Futur Membre du Club
    Homme Profil pro
    Gestionnaire IT et developpeur .net
    Inscrit en
    Février 2012
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Gestionnaire IT et developpeur .net
    Secteur : Service public

    Informations forums :
    Inscription : Février 2012
    Messages : 1
    Points : 5
    Points
    5
    Par défaut
    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.

  12. #12
    Candidat au Club
    Profil pro
    Inscrit en
    Août 2011
    Messages
    1
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2011
    Messages : 1
    Points : 2
    Points
    2
    Par défaut
    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.

  13. #13
    Membre averti

    Inscrit en
    Juin 2008
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 307
    Points : 364
    Points
    364
    Par défaut
    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).

  14. #14
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  15. #15
    Membre confirmé
    Inscrit en
    Octobre 2007
    Messages
    210
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 210
    Points : 459
    Points
    459
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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).

  16. #16
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2003
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2003
    Messages : 1 047
    Points : 1 640
    Points
    1 640
    Par défaut
    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à...
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

  17. #17
    Membre régulier
    Homme Profil pro
    Développeur et formateur Mainframe
    Inscrit en
    Février 2007
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur et formateur Mainframe
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2007
    Messages : 44
    Points : 103
    Points
    103
    Par défaut
    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.

  18. #18
    Membre confirmé Avatar de herzleid
    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    Juin 2002
    Messages
    393
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Directeur des systèmes d'information

    Informations forums :
    Inscription : Juin 2002
    Messages : 393
    Points : 509
    Points
    509
    Par défaut
    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 ^^)

  19. #19
    Membre confirmé
    Inscrit en
    Octobre 2007
    Messages
    210
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 210
    Points : 459
    Points
    459
    Par défaut
    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 ...

  20. #20
    Expert confirmé
    Homme Profil pro
    ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    Juin 2007
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 096
    Points : 4 155
    Points
    4 155
    Par défaut
    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...

Discussions similaires

  1. Richard Stallman : « Le logiciel libre est plus important que jamais »
    Par Hinault Romaric dans le forum Actualités
    Réponses: 62
    Dernier message: 14/10/2013, 12h20
  2. 8 est plus grand que 28 ??!!
    Par n@n¤u dans le forum Général JavaScript
    Réponses: 4
    Dernier message: 23/05/2006, 16h14
  3. [DBCOMBOBOX] liste est plus large que le combo lui-même
    Par valoji dans le forum Bases de données
    Réponses: 3
    Dernier message: 18/05/2006, 17h59
  4. DBExpress est plus lent que BDE?
    Par palassou dans le forum Bases de données
    Réponses: 4
    Dernier message: 02/07/2004, 09h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo