Journal bon anniversaire

Posté par  .
Étiquettes :
13
21
sept.
2009
Eh oui, joyeux anniversaire COBOL ! Ce vénérable langage fête ses 50 ans.
Il est né en 1959, officiellement le 18 septembre.
Selon les estimations, environ 200 milliards de lignes de code Cobol sont actuellement en utilisation.
Ça méritait bien un journal. non ?

Bon, quelques liens :
article Wikipedia : http://fr.wikipedia.org/wiki/COBOL
annonce par Clubic : http://www.clubic.com/actualite-300798-langage-cobol-fete-50(...)
Même chose sur PCWorld : http://www.pcworld.fr/2009/09/21/materiel/50-bougies-souffle(...)

  • # Commentaire supprimé

    Posté par  . Évalué à 6.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Plus que 15 ans...

      Posté par  . Évalué à 8.

      La retraite, pour cobol, souvent annoncée, mais toujours reculée.

  • # Divergence d'opinion

    Posté par  . Évalué à 9.

    Ça méritait bien un journal. non ?

    Non, ca méritait une euthanaise....

  • # A quand la bronsonisation ?

    Posté par  . Évalué à 5.

  • # Mouais

    Posté par  . Évalué à 1.

    Je verserai pas une larme à sa disparition.... Quel horreur syntaxique !

    • [^] # Re: Mouais

      Posté par  . Évalué à 4.

      voyon qu'est ce que tu reproche au COBOL, au moins dans ce langage, on sait quand on fait un calcule
      COMPUTE Va = TO ** 3
      Et au moins on est pas obligé de se taper des lignes de 200 caractères ! Ça commence au 8e et ça tronque au 80 voila un langage simple!!!

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Mouais

        Posté par  . Évalué à 5.

        HAI
        BJR, G ENVI D4APPRNDR LE KBOL
        VS AVZ UN BON LIEN AVC D TUTO ??
        KTHXBYE


        Ah non ça c'est pour du COBOLOLCODE...

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Mouais

        Posté par  . Évalué à 0.

        Oui enfin comme Fortran 77 quoi.


        .
        .
        .


        Grmbl. /me repart lire du code écrit il y a moins de 3 ans en Fortran. :-/

  • # Trolls velus

    Posté par  (site web personnel) . Évalué à 6.

    La news de Clubic est quand même pleine de Trolls :

    Depuis 50 ans les administrations ont misé sur le COBOL, ce qui témoigne de sa résilience et de sa flexibilité
    Moi j'aurais dit que ça témoigne de la résistance au changement des administrations et des entreprises.

    Et puis le très beau :
    l'un des seuls langages écrits ces cinquante dernières années qui soit lisible et compréhensible [...] aussi ridicule que cela puisse paraître, les langages de programmation modernes sont difficiles à comprendre

    • [^] # Re: Trolls velus

      Posté par  . Évalué à 8.

      Rigolez, rigolez...
      Moi qui ai plus de 50 ans, je peux vous assurer que jadis on disait qu'un programme COBOL bien écrit se lit comme un roman policier.
      On ne peut pas en dire autant de la plupart des langages actuels.

    • [^] # Re: Trolls velus

      Posté par  (site web personnel, Mastodon) . Évalué à 7.

      >Moi j'aurais dit que ça témoigne de la résistance au changement des administrations et des entreprises.

      Tu aurais bossé dans ce genre de boite, tu n'aurais pas dit ça ;-)

      j'ai bossé il y a une douzaine d'année dans une grosse boite d'assurances. Ce genre de boite ont des dizaines de milliers de programmes en COBOL qui tournent en permanence (il y en avait 150 000 et des poussières à l'époque dans la boite où je bossais, donc en gros des millions de lignes de codes), sur des gros systèmes qui bouffent du calcul à l'heure comme jamais le serveur de linuxfr n'en fera dans sa courte vie. Beaucoup de ces programmes sont critiques, où la moindre erreur de calcul peut être catastrophique.

      Bref, migrer ce genre de système d'information, c'est très compliqué car c'est un énorme chantier. On ne peut pas se dire qu'on va migrer les programmes les uns après les autres, parce qu'en fait il y a beaucoup d'interdépendance. Donc quand il faut migrer, il faut migrer par paquet de centaines ou de milliers. Et réécrire ces programmes pour un autre environnement, ça ne se fait pas à coup de baguette magique. ça demande litteralement des années (quoi que, depuis quelques temps, on a des outils de transcodage très intéressant, voir https://linuxfr.org//2008/09/10/24462.html , qui peuvent raccourcir un peu ces délais). De plus il faut être sûr que les nouveaux programmes feront les mêmes calculs, donc écrire des milliers de tests, faire de longues procédures de recettes...

      Il y a aussi le fait que ce n'est pas seulement un changement de langage de développement ou autre, mais aussi un changement de système complet : migrer d'une architecture gros systèmes vers une autre, ou vers un truc mixte (parce que quand même, se priver de la puissance de calcul d'un gros système, c'est dommage).

      Si en plus on compte les heures de formation à assurer aux "informaticiens", qui pour certains, n'ont jamais vu autre chose que du COBOL (genre les employés qui sont là depuis 20 ans, qui ont été formé en interne au développement informatique etc..), et le cout de migration du materiel (si il y a encore des vieux terminaux) ou logiciel sur les postes clients.

      Alors voilà, je te laisse imaginer les budgets à débloquer sur de nombreuses années pour passer à des technologies plus modernes.

      Les systèmes d'information des moyennes et grosses boites ont une inertie énorme. ça ne se change pas en quelques mois. Surtout qu'il faut avoir l'assurance que le nouveau système aura une certaine perenité (histoire qu'à la fin de la migration, ça ne soit pas déjà complètement obsolète), donc demande de belles études pour le futur cahier des charges.

      • [^] # Re: Trolls velus

        Posté par  . Évalué à 3.

        Plutôt d'accord, mais sur la fin le ça ne se change pas en quelques mois, ça doit bien faire 15 ans que le COBOL c'est "obsolète", donc bon ...

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 7.

          Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Trolls velus

        Posté par  . Évalué à 3.

        oui mais ce qu'il faut voir, c'est que ça va coûter de plus en plus cher à maintenir ces vieux trucs. J'ai fait du COBOL en IUT, autour du passage à l'euro, j'ai fait mon stage d'iut sur du COBOL; et bien si tu veux que j'écrive du COBOL, va falloir me payer cher, (c'est une compétence rare, même si elle s'acquiert facilement; c'est un langage extrêmement lourd à écrire.

        Par contre il faut avouer que coté caclul, le cobol n'est limité que par la taille que l'on donne aux nombre si on veux qu'un nombre prennent 50 chiffres, il peut (par contre c'est du 50 octet pour le coder :) )

        Par contre dire qu'on peut pas migrer morceau par morceau, est à mon avis une erreur; si un programme dépend des autres, il suffit de lui donner les même interface, et il est migré. De plus il est bien plus facile de tester un morceau que l'ensemble. (la où je suis il y a des vieux code fortran 77 et fortran 90 qui tournent, et ils sont très bien incorporé au reste de l'appli qu'il y a derrière.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Trolls velus

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          > c'est que ça va coûter de plus en plus cher à maintenir ces vieux trucs.

          c'est certain. mais le cout de maintenance dans certains cas est peut être encore moins cher que de migrer.


          >Par contre dire qu'on peut pas migrer morceau par morceau, est à mon avis une erreur; si un programme dépend des autres, il suffit de lui donner les même interface, et il est migré.


          Tout dépend de comment cela a été codé et maintenu ! Quand des dizaines (centaines ?) de programmes de batch s'enchainent les uns aux autres pour faire des calculs en tout genre, il n'est absolument pas évident de les remplacer les uns après les autres. Je ne sais pas si des ponts existent entre cobol et java par exemple, mais je vois mal un batch en cobol appeler un batch en java, qui va ensuite appeler un batch en cobol etc... surtout quand lesdites interfaces sont floues, mal documentées, appelé par 25 programmes différents etc...

          Tu aurais par exemple vu la gueule de certains programmes dans lesquels j'ai dû plonger, avec des goto dans tout les sens, du véritable code spaghetti, accompagnés de formules de calculs complexes à souhait (enfin de mon point de vue, la finance et moi...).

          bref, migrer, c'est loin d'être aussi simple que tu le dis, sinon il n'y aurait déjà plus de COBOL !

    • [^] # Re: Trolls velus

      Posté par  . Évalué à 3.

      La new de Clubic cite surtout des commentaires de DSI bling bling et de décideurs pressés, qui font tout pour justifier que leur si leur Système d'Information fonctionne à base de COBOL, langage aux cheveux gris, c'est pour des questions de performance et de qualité. Hohoho.

      En fait, ce n'est n'est pas vrai.

      Attention, l'idée ici n'est pas de monter un troll sur "COBOL c'est vieux, c'est moche" (je suis même sûr que c'est très fiable, ça a 50 ans, les bogues sont éliminés depuis un bout de temps), mais comprendre POURQUOI on utilise encore COBOL.

      Pourquoi d'ailleurs ? Qui utilise COBOL ? Et pourquoi pas autre chose ?

      Souvent, les utilisateurs de COBOL sont des banques, des assurances, de gros industriels. Les premiers utilisateurs à grande échelle de l'outil informatique, en somme. Par exemple, dans la plupart des banques françaises, le coeur du bouzin qui gère nos comptes fonctionne en COBOL. D'ailleurs, Unilog embauche beaucoup de gens pour pisser du COBOL chez eux.

      Pensez-vous qu'il est possible, aujourd'hui, de réécrire le SI de la Société Générale en Java (Y compris avec l'aide de PTramo) ? C'est un projet qui se chiffre probablement en centaines de millions d'€, et bonjour le plan de migration. Donc, la Société Générale continue à utiliser COBOL, c'est vieux mais ça marche, et avec, elle ne risque pas de se gauffrer.

      Le même genre de phénomène se produit avec IMS [1], la première base de données de l'histoire informatique, qui a servi à gérer le système de facturation des premières missions Apollo, il y a ... 40 ans. Elle est encore très utilisée chez les assurances, les banques, etc...

      On se retrouve donc avec des "utilisateurs captifs", qui se sont (volontairement ? consciemment ?) enfermés dans une technologie donnée, et qui sont obligés d'en accepter les contraintes sur du long terme (n'éxagérons pas, parfois, ce n'est pas si contraignant non plus). C'est arrivé avec COBOL, avec IMS, qui nous dit que cela ne se reproduira pas avec Java dans 30 ans ?

      [1] IMS: [http://fr.wikipedia.org/wiki/Information_Management_System]

      • [^] # Re: Trolls velus

        Posté par  . Évalué à 2.

        s/Unilog/Logica/

        Explication : Unilog, Logica et CMG ont fusionné pour devenir Logica (fusion devenue totalement effective en février 2008).

      • [^] # Re: Trolls velus

        Posté par  . Évalué à 3.

        « On se retrouve donc avec des « utilisateurs captifs », qui se sont (volontairement ? consciemment ?) enfermés dans une technologie donnée, et qui sont obligés d'en accepter les contraintes sur du long terme (n'exagérons pas, parfois, ce n'est pas si contraignant non plus). C'est arrivé avec COBOL, avec IMS, qui nous dit que cela ne se reproduira pas avec Java dans 30 ans ? »

        Le problème ne viens pas de la technologie. Ça serait en Java, en perl, en C/C++, en barinfuck ou en malbolge que ça ne changerais pas grand chose.
        C'est l'organisation du système d'information qui n'a pas était fait avec les connaissances que nous avons aujourd'hui. Aujourd'hui on sait bien mieux organiser les projets d'envergures qu'il y a 20 ou 30 ans. Et même pour les débuts des codes en cobol, il n'y avait pas encore les grands préceptes Unix qui ont grandement aidé à écrire des programmes de qualités.

        Moi ce qui me surprend c'est qu'il y a du y avoir des changements de matériel. En 1959, je doute qu'il y ait encore autant de machines qui fonctionnent et qui sont sorties avant les années 60 à 70 (les plus petits GNU/Linux ne fonctionnent pas dessus par exemple). Donc lors de mises à jour matériel il y aurait pu y en avoir logiciel.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Trolls velus

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          >Le problème ne viens pas de la technologie. Ça serait en Java, en perl, en C/C++, en barinfuck ou en malbolge que ça ne changerais pas grand chose.

          si, ça vient quand meme de la techno, du langage. Quand je voyais du code avec des goto dans tout les sens, du veritable spaghetti, le premier reflexe de beaucoup de développeurs étaient : "ça marche ? je n'y touche surtout pas, même si l'envie me prend de vouloir faire du refactoring pour faire plus propre ou plus performant". Et si il y avait un souci, c'était la galère.


          >Donc lors de mises à jour matériel il y aurait pu y en avoir logiciel.

          t'inquiète pas, les fabricants de mainframe ont bien fait gaffe de vendre des machines et OS compatibles avec l'existant. De toute façon, si ils ne le faisaient pas, les clients ne signaient pas. Changer de matériel était très onéreux. Si en plus à chaque upgrade il fallait mettre à jour les 150 000 programmes COBOL de la boite...

          De toute façon, le COBOL a peu d'API bas niveau (voir pas du tout). la façon d'accéder au contenu d'un fichier est très transparent (comme le fopen en C sur unix, tu ne sais pas vraiment la nature du système de fichier). Donc changer le hardware avec des nouvelles générations de système de stockage, ou je ne sais pas quoi d'autres, c'était transparent pour les programmes COBOL. Au pire, et c'est ce qui se faisait là où je bossais, il y a avait des couches de compatibilité dans les sous-systemes ou les API.

          Donc oui, les machines ont évolué, les utilisateurs ont upgradé/remplacé leur mainframes vers des mainframes plus puissants. IBM et cie ont bien fait leur beurre ;)

      • [^] # Re: Trolls velus

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Sans compter les performances ! On dira ce qu'on voudra, mais avec des applications transactionnelles (pour les batches c'est moins visible) qui tournent sur des gros systèmes et qui sont généralement écrites en Cobol, quand l'utilisateur valide sa transaction sur son écran en mode bloc, l'écran suivant arrive quasi-instantanément.

        J'ai vu des utilisateurs fortement déçus après une migration vers une application en intranet / J2EE : les promoteurs de la nouvelle solution avaient beau leur expliquer que celle-ci était beaucoup plus jolie et plus « ergonomique » que l'ancienne - ce qui était objectivement vrai -, ils n'en avaient rien à faire. Qu'il faille taper sur Ctrl-PF3 pour passer d'une partie de l'écran à l'autre, ce n'est certes pas intuitif pour un nouvel utilisateur, mais pour ceux qui font ça à longueur d'années, ça ne pose aucun problème... Mais que la validation prenne 30 s, ça, ça leur semblait insupportable !

        C'est sûr que les coûts de fonctionnement (matériel + logiciel) sont très élevés, mais le genre de boîte où ça tourne en a généralement les moyens.

        • [^] # Re: Trolls velus

          Posté par  . Évalué à 4.

          Ha, joli lancé de troll sur la lenteur de Java ...

          • [^] # Re: Trolls velus

            Posté par  . Évalué à 2.

            Euh .. ce n'est pas forcément Java en lui même qui est lourd, mais toutes les couches XML/JEEE et compagnie qui posent problème ...

            Un programme Java "de base" s'exécute assez rapidement.

  • # Nombre de lignes de code

    Posté par  (site web personnel) . Évalué à 4.

    Selon les estimations, environ 200 milliards de lignes de code Cobol sont actuellement en utilisation.
    Je me demandais si c'était possible, mais en effet oui, ça ne fait que 10 000 lignes de code pour 10 millions de développeurs. En 50 ans, c'est possible.


    Je me pose surtout la question, combien de lignes de code de Java, de C, C++ .... Smalltalk ?

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.