Discussion :

[ec]

Ce qui compte c'est de connaître les statistiques d'utilisation des langages à différentes date et de voir les évolutions ... ça fait plus de 20 ans que j'entends parler de la disparition du Cobol ...

A propos les hiéroglyphes sont-ils morts ?

[ztor1]

Bonjour,

Qui va disparaître dans les prochaines années ?

Et avec certitude ?

Ben ça ...

Dice, un cabinet basé à New York qui présente les tendances en matière d’emploi dans les nouvelles technologies

@+

[Invité]

Pour le COBOL, mon domaine , la question est de savoir par quoi le remplacer ?
Combien de lignes de codes à traduire et dans quoi ? Pour quel coût ? Quelle durée ? Pour quels risquent systémiques ?
Sur Mainframe, il reste l'idéal mais les outils sont obsolètes, et il lui manque une franche modernisation,
amorcée avec Language Environment. Sans oublier XML (y compris dans les ordres SQL)...
Il manque des choses plus modernes mais courantes dans les langages plus récents.
TSO est resté à l'interface texte 24 lignes de 80 colonnes (ou 132 au mieux).
On peut utiliser Rational Developper for Z/OS très coûteux, on bien Cobol-IT Developer Studio.
Là, on aura déjà une bonne modernisation de l'environnement de travail.
Le langage n'est pas tout...

[Demi Humain]

Bonjour,

Depuis le début de ma carrière, 30 ans d'expérience en informatique de gestion dans le Mainframe, j'entends dire que le COBOL va disparaître.
Maintenant, le COBOL a rejoint les autres langages sur Eclipse avec sa propre "perspective" de développement et je continue encore à former des programmeurs COBOL.
Dès qu'il s'agit de traiter des gros volumes d'information on ne fait pas mieux que le Mainframe et ses outils :-)
Je ne vois pas là un langage qui se meurt ;-)

[devEric69]

Comme tous les langages ont été cités, il ne reste plus qu'à écrire la nouvelle grammaire du futur langage élu, celui qui ne disparaîtra jamais !

[tontonCD]

Dommage pour Objective-C, qui est très semblable au C (a->b(c) devient [a b:c]), et comme lui très proche du processeur, j'entends par là que l'on sait avec de l'expérience comment une ligne va être transformée par la compilation. On peut écrire du code optimal. Peut-être que la puissance des machines rend ceci obsolète ?

[foetus]

Dommage pour Objective-C, qui est très semblable au C

Pour être précis , c'est une surcouche objet au langage C comme le C++ mais plus récente (1983 et 1979 pour l'autre).
Les fonctionnalités les plus remarquables sont le compteur de référence (qui a évolué avec ARC) et le duck typing ("If it walks like a duck and it quacks like a duck, then it must be a duck", lien wiki en anglais)

Et le petit truc en + , c'est qu'il existe le langage Objective-C++ (on mixe le C++ avec l'Objective-C et ceci juste en précisant des fichiers .mm)

[Hervé Autret]

Exemple de boucle en C qui ne fonctionne correctement QUE sur µP 8 bits :

unsigned char i=0;
 do {
  i-=4;
  printf("%d %d %d %d\n",i,i+1,i+2,i+3);
 } while(i!=0);

Si c'est une blague, lapin compris.

C'est bien supposé écrire 256 nombres répartis comme suit ? :
252 253 254 255
... [62 lignes]
0 1 2 3

Passque ça marche très bien sur AMD (Phenom), Intel (core2, Xeon), avec tcc, clang et gcc, sous Linux et MSYS même, quant au dernier.

[Steinvikel]

@CaptainDangeax --> Exemple de boucle en C qui ne fonctionne correctement QUE sur µP 8 bits

Qu'il fonctionne ou non sur du matériel, cela ne dépend-t-il pas du compilateur uniquement ? (en dehors des comportement non défini par la norme du langage)
Quel comportement du code précédent est sensé ne pas être bien reproduit ?

[walfrat]

Chez moi j'ai un projet COBOL qui a migrer vers une solution Java spécifique. J'ai un autre projet qui n'est pas en COBOL mais en Java avec un framework particulier : chaque classe Java ne peut utiliser que le classpath du serveur, il ne peut même pas appeler une classe dans le même package, pour le faire, il faut utiliser un mécanisme de procédure framework où tu passes les paramètres en HashMap. De plus, au runtime, la définition des classes sont stockées en binaire dans une base de données relationnelle et le classpath va donc les chercher dans la base. En bref faute de savoir quoi faire de développeur COBOL, certain on fait un framework limitant le langage au strict minimum (fichier, sql, contrôle IHM) plutôt que de faire monter leur développeur en compétence.

Y'a aussi de l'ADA qui traine quelque part

[IronChef]

R why ? Je bosse pour une banque britannique et on vient d’installer R sur notre serveur Linux. D’autres ont lancé des projets R shiny j’ai du mal à croire que seuls les universitaires l’utilise

[Hervé Autret]

Bonjour,,

Je me réponds à moi-même, la complétion de mes tests ayant dépassé les3 jours recevables.

Si c'est une blague, lapin compris.

C'est bien supposé écrire 256 nombres répartis comme suit ? :
252 253 254 255
... [62 lignes]
0 1 2 3

Passque ça marche très bien sur AMD (Phenom), Intel (core2, Xeon), avec tcc, clang et gcc, sous Linux et MSYS même, quant au dernier.

Sans prétendre ne pas lâcher l'affaire, mais Savapatarder : un Sasfépu (Celeron) et un SafféMintnan (ARMv7) exécutent correctement la boucle.

Je persiste : lapin compris la blague.
--
Hervé

[el_slapper]

Chez moi j'ai un projet COBOL qui a migrer vers une solution Java spécifique. J'ai un autre projet qui n'est pas en COBOL mais en Java avec un framework particulier : chaque classe Java ne peut utiliser que le classpath du serveur, il ne peut même pas appeler une classe dans le même package, pour le faire, il faut utiliser un mécanisme de procédure framework où tu passes les paramètres en HashMap. De plus, au runtime, la définition des classes sont stockées en binaire dans une base de données relationnelle et le classpath va donc les chercher dans la base. En bref faute de savoir quoi faire de développeur COBOL, certain on fait un framework limitant le langage au strict minimum (fichier, sql, contrôle IHM) plutôt que de faire monter leur développeur en compétence.

Y'a aussi de l'ADA qui traine quelque part

On appelle ça du JOBOL. C'est du Java d'un point de vue strictement technique, mais d'un point de vue philosophique, c'est juste du cobol. En bref, on bazarde tous les avantages du Cobol pour ne garder que les inconvénients - avec tous les inconvénients du java en prime.

[Escapetiger]

(.../...)
Surtout pour le C qui fêtera bientôt son demi-siècle parmi les langages les plus utilisés, ce qui est une éternité à l'échelle de l'Histoire de l'Informatique. Ce n'est pas pour rien s'il a traversé autant d'époques. Rust peut le rendre moins populaire car Mozilla s'est posé les bonnes questions quand ils l'ont conçu, mais le C demeurera éternel et de nombreux programmes en C tourneront encore dans 100 ans contrairement à COBOL, Objective-C, Kotlin et Fortran.

A Cobol programmer made so much money doing Y2K remediation that he was able to have himself cryogenically frozen when he died. One day in the future, he was unexpectedly resurrected.

When he asked why he was unfrozen, he was told:

"It's the year 9999 - and you know Cobol"