Journal Sursis pour le Cobol ??

Posté par  .
Étiquettes :
2
11
déc.
2008
Cher journal,
après de âpres hésitations, je me décide enfin de poster un journal concernant un langage, assez vieux, datant d'une cinquantaine d'années. J'ai nommé le Cobol.

Dernièrement dans ma boîte, on m'a proposé de basculer au Cobol (pour des raisons que j'ignore) moi qui suis un fan de Java et surtout le langage C, le langage des dieux. Pour ce faire, on m'a envoyé un article, que je partage avec vous avec un grand plaisir, ventant le Cobol et surtout sa seconde vie:

http://www.zdnet.fr/actualites/informatique/0,39040745,39384(...)

et un second lien:

http://www.01net.com/article/260094.html

Donc, j'ai décidé de m'y intéresser et croyez moi ce n'est point une tâche facile. J'ai découvert qu'il y'avait une version du Cobol orientée objet et même une start-up "Cobol-IT" [1] qui se veut LA boîte qui promeut (ou re-booste) le Cobol dans les entreprises utilisant des application de gestion en back-office (les banques, assurances, caisses de retraites...), et le tout, linuxFr-iens, linuxFr-iennes, en Open Source!! :

http://www.01net.com/editorial/396759/une-toute-nouvelle-ssi(...)

Pour faire court, j'aimerais bien avoir votre avis, vos remarques, vos impressions... sur ce langage qui, pour le moins que l'on puisse dire, très mystique. Est-ce vraiment bien d'avoir une double compétence nouvelles-tech / anciennes tech?

Et euuuh avant d'oublier, les trolls bien sûr sont les bienvenus!!! Merci à vous chers linuxFr-ien(ne)s :}

[1] Cobol-IT : http://www.cobol-it.com/

  • # c'est une expérience...

    Posté par  . Évalué à 3.

    J'ai toujours entendu dire que le Cobol était incontournable dans les banques et assurances.
    Personnellement j'ai un ami qui vit du Cobol depuis 8 ans et en vie vraiment bien.
    Ces missions sont longues, mais les inter-contrats aussi (jusque 3 mois je crois).

    Le Cobol a toujours été présent et a toujours évolué mais il fait ringard dans la presse alors qu'il fait sérieux dans les domaines banques/assurances.

    De plus avoir des doubles compétences n'a jamais nuit, ça peut te faire une expérience...

    • [^] # Re: c'est une expérience...

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

      Pourquoi changer du code qui marche ? Les procédures de validation des programmes dans les banques sont longues. Alors si ça marche en COBOL, pourquoi migrer à quoi que ce soit d'autre ? En plus, il existe COBOL.NET, il est moderne ce langage !

      • [^] # Re: c'est une expérience...

        Posté par  . Évalué à 1.

        Je suis d'accord avec toi, mais il y a une vrai pénurie de développeur COBOL.
        Ce langage à mauvaise presse surtout auprès des jeunes et j'ai l'impression que ca vient de la 'presse informatique people' et des enseignants qui, j'ai l'impression, ne font rien pour ce langage, à telle point qu'il n'est apparemment plus enseigné sauf dans les formations de reclassement et là c'est dommage.

        • [^] # Re: c'est une expérience...

          Posté par  . Évalué à 2.

          à telle point qu'il n'est apparemment plus enseigné sauf dans les formations de reclassement et là c'est dommage.

          Il était enseigné à l'IUT de Paris 5 il y a encore 2 ans. Et j'ose espérer que pour toi, un IUT n'est pas une formation de reclassement ;)

          Et tiens, puisque je parle des IUT... http://www.iut-fr.net/petitions/?petition=2

          • [^] # Re: c'est une expérience...

            Posté par  . Évalué à 1.

            >>Il était enseigné à l'IUT de Paris 5 il y a encore 2 ans. Et j'ose espérer que pour toi, un IUT n'est pas une formation de reclassement ;)

            Non, les IUT/écoles d'ingé/dess que je côtoie n'ont jamais fait de COBOL.
            La seule personne que je connaisse est un physicien qui a fait une formation par l'ANPE en 1999/2000.
            En discutant avec lui, j'ai l'impression que beaucoup de coboliste ont son profile.

            • [^] # Re: c'est une expérience...

              Posté par  . Évalué à 1.

              Non, les IUT/écoles d'ingé/dess que je côtoie n'ont jamais fait de COBOL.

              Si, l'IUT de Paris 5 faisait du COBOL il y a deux ans. J'ajouterai qu'il en fait surement encore. Mais je t'avoue que je n'ai pas entendu parler d'un autre IUT qui en fasse. Et je dois aussi ajouter que COBOL faisait partie d'un des deux choix de seconde année proposés par l'IUT (un choix rempli de Java, l'autre de COBOL et C++).

              • [^] # Re: c'est une expérience...

                Posté par  . Évalué à 1.

                A l'IUT A de Lille en informatique on enseigne encore le COBOL également (avec PL/SQL sur AS400).
                A l'IUT de Lens il existe un enseignement de COBOL optionnel.

              • [^] # Re: c'est une expérience...

                Posté par  . Évalué à 1.

                Non, les IUT/écoles d'ingé/dess que je côtoie n'ont jamais fait de COBOL.

                J'en ai fait à l'IUT de Blagnac en 2005/2006.

            • [^] # Re: c'est une expérience...

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

              A l'IUT d'Orsay, en 89, c'était enseigné (bon, ça ne passionnait pas les foules).

              Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

        • [^] # Re: c'est une expérience...

          Posté par  . Évalué à 6.

          En même temps, est-ce que ça vaut le coup de continuer avec de tels langages ?

          Il est peut-être temps de passer à quelque chose de plus haut-niveau.

          • [^] # Re: c'est une expérience...

            Posté par  . Évalué à 1.

            Tu sais kaouete, les entreprises pensent au coup de migration. ET parfois ces mêmes entreprises ne voient pas à long terme.....

    • [^] # Re: c'est une expérience...

      Posté par  . Évalué à 1.

      Le cobol est bien en vie! la plupart des entreprises font appel à ce qu'on appelle des Tierce_Maintenance_Applicative.
      Le développement se déroule sur des machines connectées sur des mainframes à base de Z/OS, dans un environnement TSO vert sur fond noir, Time Sharing Operation, dont l'éditeur de texte est d'une archaïcité (loin loin loin mais vraiment loin de valoir un Vim ou un Emacs)... je vous laisse deviner :}

      Mais faudrait aussi vanter la stabilité de ce langage!!

      • [^] # Re: c'est une expérience...

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

        > dont l'éditeur de texte est d'une archaïcité (loin loin loin mais vraiment loin de valoir un Vim ou un Emacs)

        ed ?

        Adhérer à l'April, ça vous tente ?

      • [^] # Re: c'est une expérience...

        Posté par  . Évalué à 3.

        T'es-tu déjà connecté à un mainframe pour dire de telles choses ?

        Pour programmer, l'éditeur est vraiment super, surtout si on l'agrémente de macros en Rexx.
        Pour créer des outils d'aide au développement, ISPF, qui peut être comparé à curses (donc en mode texte), est tout à fait correct.

        Le vrai problème de COBOL est que les fonctions intéressantes fournies par l'os ne sont directement utilisables (à qq exceptions près). Pour faire des trucs sexys, il faut sortir l'assembleur. Mais à côté de ça, on fait des choses très rigolotes comme des analyseurs syntaxiques, des parseurs XML, etc. :-)

        Mais la plus grosse différence se trouve être le type de traitements que l'on fait tourner sous z/OS. Valoriser des millions de contrats quotidiennement n'est pas à la porté de tous les environnements...

        Le système de fichiers est paradoxal, car par certains aspects il est archaïques (limite sur le nom des fichiers, pas de notion de sous-répertoire, etc.), par d'autres il est en avance (gestion des gros fichiers).

        Connaissant bien les deux mondes (z/OS et Unix/linux), je préfère faire de la prod' sous z/OS !

        Disclaimer: je ne code pas d'applis bancaires, mais des outils techniques pour les développeurs métier :-) Je sais c'est de la triche.

      • [^] # Re: c'est une expérience...

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

        C'est marrant car je trouve que l'éditeur de source Cobol a des similitudes avec vim.

        Le coup de mettre des "10i" dans la marge pour insérer 10 nouvelles lignes. Le coup des "dd" dans la marge pour effacer des lignes. On a l'impression que la marge de l'éditeur Cobol est le pendant du mode commande de VI :)

        Sinon pour illustrer ce journal, je vais parlé de mon cas. Je bosse dans l'assurance. Je suis principalement développeur J2EE (Java coté serveur) mais j'ai acquis quelques connaissances en COBOL tout simplement car j'ai travaillé sur des applications webs qui s'appuie sur des modules COBOL pour une partie du métier et l'accès aux données et que parfois il faut mettre la tête à l'extérieur de son univers pour trouver un bug. Je suis capable de lire du COBOL et de comprendre ce qu'il fait. J'ai même réalisés 2 modules COBOL tout cons qui tournent maintenant en production. J'ai aussi touché à Xpeditor pour le debug pas à pas.

        Cela ne me dérange pas d'aller mettre la tête dans du code COBOL pour chercher un bug éventuel. Je me suis aussi bien amusé en faisant mes premiers modules COBOL (plus par curiosité et défi). Par contre je me vois mal ne faire que ça. Ce n'est pas le langage qui rebute mais le fait que ce soit utilisé principalement pour manipuler des données. Cela va 2 secondes mais ça manque de fun.

        Par contre, je pense que le fait d'avoir la double compétence est un plus. Non seulement il y a beaucoup de banques et assurances qui ont des backoffice en COBOL et des frontoffice en Java, mais en plus il y en a qui veulent porter une partie des modules COBOL dans du Java. Donc savoir lire du COBOL est je pense un vrai plus.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # Histoire

    Posté par  . Évalué à 10.

    C'est un programmeur COBOL qui s'est fait des couilles en or au moment du passage à l'an 2000, à tel point qu'à sa mort, il a les moyens de se faire cryogéniser. Un beau jour, on le décongèle et on le ramène à la vie. Il demande pourquoi on l'a reveillé et on lui réponds : "On est en 9999 et vous connaissez le COBOL".

    • [^] # Re: Histoire

      Posté par  . Évalué à -6.

      :} c'est fort!! :}

      Ça vous tente de coder un WoW en Cobol :p

  • # Elément de réponse

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

    Un élément de réponse dans cette citation de John Krueger:

    Un ordinateur sans COBOL ni Fortran est comme un morceau de gâteau au chocolat sans ketchup ni moutarde.

  • # Cobol

    Posté par  . Évalué à 3.

    ça me rappel de vieux souvenir.
    J'en ai fait en IUT, puis en stage. (mais ça remonte à 6-7 ans )
    De mes souvenirs c'est très verbeux, descriptions des données utilisées dans le programme (en global), un calcul se fait à l'aide de la directive COMPUTE ( je crois ou alors c'était PERFORM me souviens plus), fallait commencer sur la 8eme colonne, pas dépasser la n°80, et on ne bossait que sur des entier (ou nombre à virgule fixe)

    Le langage est limité à un certain niveau d'imbrication (pour les boucle/subroutine) ne pas oublier qu'un '.' termine un bloc (si je me souviens bien)

    D'un autre coté, il n'y avait pas de limite sur la taille des nombres qu'on manipulait (enfin pas que je sache ), et un non informaticien peut lire la partie code (la partie déclaration ne représente aucun intérêt.

    Enfin j'ai trouver le langage assez lourd (pas à l'exécution, mais à la rédaction (car là on peut bien parler de rédaction)

    pour le cabal abject ou kobal .net je n'ai aucun avis.

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

    • [^] # Re: Cobol

      Posté par  . Évalué à 1.

      > Le langage est limité à un certain niveau d'imbrication (pour les boucle/subroutine)

      Ah en voilà une chouette mesure anti-goret ! Je vais faire une PEP là-dessus tiens ;)
      Quoi que les sapins de Noel sont de saison ...

      • [^] # Re: Cobol

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

        Dans le même genre :
        La ponctuation joue donc le rôle des parenthèses de Lisp. Mais un être humain n’a pas une pile de récursivité bien profonde : n’hésitez pas à faire des phrases courtes et évitez de mettre plusieurs idées dans une même phrase. Pensez au lecteur pour qui, de toutes façons, c’est une corvée de vous lire.
        Don Knuth

        Adhérer à l'April, ça vous tente ?

    • [^] # Re: Cobol

      Posté par  . Évalué à 1.

      Le Cobol est très normatif! Il peut être, comme le Pascal, un langage d'apprentissage de la bonne programmation. je veux dire à bien structurer les programmes.

  • # Far ouest

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

    Est-ce que le COBOL respecte les endiens?

    La gelée de coings est une chose à ne pas avaler de travers.

    • [^] # Re: Far ouest

      Posté par  . Évalué à 9.

      Tu veux savoir si COBOL marche avec Apache ?


      =====>[]

    • [^] # Re: Far ouest

      Posté par  . Évalué à 4.

      Oui, c'est la FORTRAN kill.

      (je sort pas, il caille)

    • [^] # Re: Far ouest

      Posté par  . Évalué à 5.

      Aveu de l'auteur du journal

      Dernièrement dans ma boîte, on m'a proposé de basculer au Cobol (pour des raisons que j'ignore) moi qui suis un fan de Java et surtout le langage C, le langage des dieux.

      Mieux que le COBOL ..... le PADBOL

  • # Vieux et moderne

    Posté par  . Évalué à 2.

    Pour replacer le COBOL dans l'histoire de l'informatique, rappelons qu'il a été inventé avant les circuits intégrés !

    Pour faire du COBOL de nos jours, je te conseille ce bouquin :
    http://thomas.walraet.net/blog/index.php/2005/03/31/34-cobol(...)

  • # Choses vues

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

    Je n'en n'ai jamais réellement fait, mais j'ai travaillé dans des équipes qui en faisaient, et ce qui m'avait frappé c'est le manque de passion des cobolistes...

    Mon premier boulot a consisté à écrire des routines de calcul scientifique en Fortran, et certains de mes sous-programmes devaient être appelés par des programmes en Cobol. Il fallait donc savoir faire la correspondance entre les différents types de paramètres, et là je me suis rendu compte que les développeurs Cobol ne connaissaient qu'une petite partie du langage qu'ils utilisaient depuis des années, et n'avaient jamais eu la curiosité de creuser un peu : ils n'utilisaient que deux types numériques, et ignoraient les autres.

    Comme dit dans un autre commentaire, c'est un langage très verbeux (rien que pour l'initialisation ça prend un gros paquet de lignes), mais en fait les codeurs tappent peu de choses : ils ont quelques programmes types qui remplissent un peu toujours les mêmes besoins, et ils les adaptent... C'est presque exclusivement utilisé dans des programmes de gestion, et ça ne m'avait pas paru passionnant !

    De plus - ça c'est peut-être amélioré depuis - mais comme les bases du langage dataient d'avant l'apparition courante des bases de données et des interfaces graphiques, l'accès aux SGBD et aux IHM n'était pas standardisé, et se faisait par des macros ou des appels à des routines propriétaires.

    • [^] # Re: Choses vues

      Posté par  . Évalué à 2.

      Tu es dans le vrai Th.Thomas. Le manque de passion des cobolistes n'est pas le cas de tout le monde. L'équipe que je viens d'intégrer, les dev sont vraiment très compétent et savent bien ce qu'ils font! Ils codent tout en respectant les normes...

    • [^] # Re: Choses vues

      Posté par  . Évalué à 4.

      Je comprend pas trop ton point de vue: tu dis que les programmeurs manquent de passion avec cobol puis ensuite tu décrits un langage chiant désuet au paradigmes antiques ne faisant appel qu'a des routines propriétaires... Moi je comprend leur manque de passion...

      Ce que j'aime dans l'informatique c'est cette évolution permanente, ces changements. Si je dois faire un truc dans un langage X tout en connaissant des solutions Y beaucoup plus agréables/adaptées je tu jure que ça me casses les c...

      • [^] # Re: Choses vues

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

        Je comprend pas trop ton point de vue: tu dis que les programmeurs manquent de passion avec cobol puis ensuite tu décrits un langage chiant désuet au paradigmes antiques ne faisant appel qu'a des routines propriétaires... Moi je comprend leur manque de passion...

        Je n'ai pas dit que je ne les comprenais pas ;-)

        Et je me rends compte que j'ai été imprécis : dans les autres langages comparables il n'y a pas non plus d'accès natif à l'IHM (en mode texte, bien sûr !) et aux SGBD. Ce que je voulais dire, c'est qu'à l'époque où l'on utilisait curses en C, il n'y avait rien de similaire en Cobol. Et on attendra demain vendredi pour parler d'ODBC...

    • [^] # Re: Choses vues

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

      je me suis rendu compte que les développeurs Cobol ne connaissaient qu'une petite partie du langage qu'ils utilisaient depuis des années, et n'avaient jamais eu la curiosité de creuser un peu : ils n'utilisaient que deux types numériques, et ignoraient les autres

      En fait, ceci est vrai avec n'importe quel langage. Je suis déjà tombé sur du code Java où tout était fait avec des String et des int et où le minimum de la conception objet était ignoré.

      J'ai aussi croisé des personnes qui sont développeurs mais qui n'ont aucunes idées des évolutions du monde informatique, de ce qui peut exister d'autre ou des façons simples ou correctes de faire les choses avec leur langage : ils s'en tamponnent tout simplement car ce ne sont pas des nerds comme nous :)

      Des fois je me demande s'ils n'ont pas raisons.....

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # publicité ?

    Posté par  (Mastodon) . Évalué à 2.

    C'est moi ou ce journal ressemble à une publicité déguisée pour essayer de relancer un marketing viral entamé sur 01 et zdnet ?

    • [^] # Re: publicité ?

      Posté par  . Évalué à 1.

      Non, ça ressemble à un journal qui parle d'un truc et qui est bien rédigé avec des sources pour que le lecteur ne s'ennuie pas :)

      Et accessoirement, C n'est pas le langage des dieux.

      Le langage des dieux, c'est le langage qui quand il compile, et bin ça marche !

      • [^] # Re: publicité ?

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

        OCaml ?

        • [^] # Re: publicité ?

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

          Hmmmm même si j'aime beaucoup tout ce qui est ML et dérivés, une définition du genre "quand on a réussi à compiler, ça marche" ça me fait beaucoup plus penser à Ada.

          • [^] # Re: publicité ?

            Posté par  . Évalué à 2.

            Jamais testé Ada, mais je pensais effectivement à OCaml (ou Scala :D) (j'imagine que Haskell doit rentrer dedans mais je connais pas du tout)

    • [^] # Re: publicité ?

      Posté par  . Évalué à 1.

      Non du tout PsychoFox, les sources ne sont là que pour appuyer mes propos. Je ne fais point de pub!!!

  • # Ceci dit ...

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

    à part qu'il y a des franc suisse à faire avec le cobol, aucun mot sur le plaisir qu'ont (ou pas) les gens à travailler avec.

    Ce ne serait pas amha un bon argument d'attirer les gens vers un langage juste pour une question de monnaie en délaissant la partie "plaisir intellectuel"...

    Je reviens plus tard, je dois poster un commentaire à propos du succès de Java...

    Adhérer à l'April, ça vous tente ?

  • # Troll d'un autre age...

    Posté par  . Évalué à 5.

    Le COBOL c'est null, le PL1 c'est super mieux, parcequ'on a des pointeurs et des procédure d'allocation mémoire pour faire exploser les programmes en 0C4.

    Je sais pas pourquoi IBM a pas encore sorti le PL1.net ;-)

    Avant de moinser renseignez-vous sur le PL1, c'est quasiement aussi courant que l COBOL ;-)

    • [^] # Re: Troll d'un autre age..

      Posté par  . Évalué à 2.

      Mmmhh on peut faire ça en COBOL aussi : SET ADDRESS OF...
      Le cobol est un langage conçu pour manipuler de grosses quantités de données. Il le fait bien. Son seul défaut, celui dont les banques / assurances aimeraient bien se débarrasser, est le coût des mainframe sous Z/OS.

      • [^] # Re: Troll d'un autre age..

        Posté par  . Évalué à 2.

        Et le PL1, il tourne sur quoi ? Si c'est pas un bon gros mainframe !
        C'est peut être plus utilisé dans l'industrie que dans la banque, mais pour te connecter à une base DL/I y'a pas mieux !

        Le PL1 a un énorme avantage, on peut déclaré des fonctions et des procédures avec des paramètres et les utiliser normalement.

        Et puis tu as ce type pointeur, le saint graal de la programmation ;-)

        Comment tu fait une liste chainée en cobol ?

  • # il parait qu'un programmeur

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

    écrit le même nombre de lignes de code par an, quelque soit le langage, alors, autant utiliser un autre langage que Cobol, un langage agile, osons le mot.

    Un programme Cobol de 100 lignes ne fait pas grand chose.

    Et sinon quelqu'un a parlé de PL1, et je note qu'on a injustement oublié un langage efficace: APL, avec peu de lignes, on fait plein de choses.
    Bon courage pour la maintenance :-)

    ウィズコロナ

    • [^] # Re: il parait qu'un programmeur

      Posté par  . Évalué à 1.

      Un programme Cobol de 100 lignes ne fait pas grand chose.

      Par contre, quelques programmes de quelques centaines de milliers de lignes (oui, en tout) font beaucoup de choses, et les font bien. La paie d'un paquet d'administrations et entreprises françaises et faite avec du COBOL.

  • # Le COBOL et ADA sont le cauchemar des Hackers bordéliques

    Posté par  . Évalué à 4.

    Le COBOL et ADA sont des langages de programmation conçu certes à des époques différentes sous l'égide de l'armée américaine. On y retrouve dans leur syntaxe un encadrement certain laissant peu de liberté aux programmeurs "créatifs" plus soucieux de la "beauté" du code que de sa lisibilité, fiabilité et facilité de maintenance.

    D'autre part ces contraintes syntaxiques nécessitent un apprentissage long et fastidieux ce qui est peu gouté par la masse des informaticiens bidouilleurs.

    Il est certain que les programmes qui furent conçus en COBOL ou ADA peuvent très bien être réécrit en C ou Java.

    La migration de programme de ADA en C est d'ailleurs possible. J'ai il n'y a pas si longtemps lui un article sur une telle migration faite par MTU (Société allemande produisant des moteurs à réaction). Cette migration était devenu nécessaire car pour une nouvelle plateforme, il n'existait pas de compilateur ADA.

    En pratique l'article décrit l'ampleur des tests et conventions supplémentaires pour atteindre le même niveau de sécurité et fiabilité offert par tout compilateur ADA lors de la réalisation de l'application en C. En fait même si le ton du rapport est optimiste, on se rend compte de l'ampleur des garde fous nécessaire pour éviter que le naturel des programmeurs en C ne prenne le dessus….

    L'article http://www.mtu.de/de/technologies/engineering_news/32715jung(...)

    • [^] # Re: Le COBOL et ADA sont le cauchemar des Hackers bordéliques

      Posté par  . Évalué à 3.

      J'étais justement entrain de discuter des propriété d'ada et de les comparer avec le DOT.net.

      En Ada, le typage est bien plus costaux, on peut très bien définir deux sous types du type entier par exemple nbcarrotte et nbnavet, et les occurrence de chacun des deux types ne pourront jamais être additionnés ou soustrait par exemple, sauf cast explicite.

      J'essayais de faire la même chose en C# mais ce n'est pas possible car les type objet du style System.Int16 sont marquée comme finaux et ne peuvent être dérivés.

      • [^] # Re: Le COBOL et ADA sont le cauchemar des Hackers bordéliques

        Posté par  . Évalué à 1.

        Si ta seule volonté est de ne pas pouvoir additionner des nombres dans des unités différentes, le système d'unités en F# y répond. Et il te permet même de faire bien plus :

        [<Measure>] type <km>
        [<Measure>] type <h>

        let dist = 10 <km>
        let duree = 2 <h>
        let vitesse(d:float<km>, t:float<h>) = d/t;

        Ce qui fait que vitesse renvoie son résultat en km/h tout seul comme un grand.

  • # double compétence

    Posté par  . Évalué à 2.

    > Est-ce vraiment bien d'avoir une double compétence nouvelles-tech / anciennes tech?

    J'ai travaillé dans plusieurs sites qui fonctionnaient avec
    - Mainframe Z/OS + DB2 et transactions Cobol
    - Java J2EE (appellant les transactions précitées).

    C'est très très répandu, et pas seulement dans les banques. De nombreux
    domaines traitant des volumes de données très importants ont des mainframe.
    Et avoir la "double compétence" est évidemment hyper utile et recherché.

    • [^] # Re: double compétence

      Posté par  . Évalué à 1.

      Je travaille dans le domaine bancaire et précisément sur un site fonctionnant sur ce modèle.
      Toutes les applications sont sur du mainframe Z/OS + DB2 et transactions IMS, mais la moitié utilisent une du java J2EE pour la partie présentation (et l'autre moitié des écrans 3270 mais qui sont justement en train d'être remplacés).

      Dans ce contexte j'adorerais disposer dans mon équipe de plus de monde ayant la double compétence. Malheureusement ça ne court pas les rues et il n'est pas évident de faire comprendre à ma hiérarchie qu'il serait rentable d'investir pour avoir plus de monde avec la double compétence (soit par formation interne, soit en étant prêt à payer plus pour attirer les bonnes personnes).

      Ceci dit sur le long terme il y a aussi des projets d'attaquer les bases DB2 directement depuis la couche J2EE sans passer par des serveurs écrits en cobol. Il ne resterait alors en cobol que les batchs de traitement. Mais on parle là d'une échéance de 5-10 ans.

      Un truc sur lequel je m'interroge souvent c'est si réellement il est justifié de conserver le mainframe tout court. Les performances sont-elles réellement à ce point meilleures pour justifier les inconvénients comme :
      - le coût du CPU facturé par IBM,
      - le système de fichier qui nécessite de déclarer la taille et le format des fichiers avant de les créer,
      - le coût élevé de mise en place de choses qu'on considère comme acquises sur micro comme la gestion en parallèle de plusieurs branches de développement (problème au niveau des outils de gestion de source disponible, des environnements à mettre en place, etc).

      Bon à coté c'est vrai qu'il y a certains avantages à passer par le cobol : l'injection de code SQL est impossible par exemple.

      • [^] # Re: double compétence

        Posté par  . Évalué à 1.

        Ca doit faire 20 ou 30 ans qu'on annonce la fin du Cobol et des mainframes, et pourtant... C'est d'une part parce qu'ils ont certains atouts, mais surtout parce que les décideurs dans une entreprise n'ont aucune envie de prendre le risque de changer quelquechose qui fonctionne.

        Ce qui au passage contredit l'image d'Epinal de l'entreprise qui innove, s'adapte etc. : les grosses entreprises sont surtout des mastodontes où personne n'a envie d'être celui qui a eu LA mauvaise idée.

  • # cobol

    Posté par  . Évalué à 2.

    Cobol reste très employé dans de nombreux secteur. Je travaille partiellement dessus depuis de nombreuses années et pense le connaître correctement.
    Le problème du Cobol est qu'il véhicule une image ringarde et que les éditeurs et la presse ne font probablement pas suffisamment pour casser cette image. Bien sûr, on peut toujours programmer comme grand-papa en Cobol, de sorte que des programmes vieux de 30 ans tournent encore sur des matériels et systèmes actuels. C'est sa force et sa faiblesse...

    Mais pour qui veut y regarder de plus près, on trouve tous les attributs d'un langage actuel :
    - structure de contrôle, blocs conditionnels,
    - typage,
    - fonctions, procédures, ...
    - orientation objet,
    - liens avec les bases de données,
    - etc...

    Il y a longtemps que le goto, les points pour terminer une instruction, le comptage des colonnes sont oubliés.
    Intégré avec un bon éditeur ou Eclipse et un plug-in, on trouve un environnement qui est au goût du jour. Certes, il reste verbeux mais ce n'est pas rédhibitoire.
    En fait, ce qui manque le plus se situe au niveau de l'interfaçage graphique. C'est un peu un point faible. .Net apporte cependant une solution élégante.

    Dans une entreprise, il n'est pas forcément nécessaire de réécrire du code qui tourne. Nous avons chez nous quelques programmes qui ont 25 ans et sont d'une fiabilité redoutable. Les nouveaux développements font appel aux outils du moment.

    Des outils open source seraient probablement le meilleur moyen de faire connaître ce langage.

    • [^] # Re: cobol

      Posté par  . Évalué à 1.

      > - orientation objet,

      !!!??

      • [^] # Re: cobol

        Posté par  . Évalué à 1.

        Mais oui, l'objet existe bel et bien en cobol. Et ça fonctionne correctement.
        Voilà bien une preuve de ce que j'avançais : il y a un énorme effort d'information à faire!

Suivre le flux des commentaires

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