Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« L'Inforkéologie » ou l'art de travailler avec des langages obsolètes
Avez-vous travaillé sur un projet utilisant des technologies dépassées ?

Le , par deusyss

10PARTAGES

6  3 
L'Inforkéologie
l'art de travailler sur des langages obsolètes

L'inforkéologie est un terme que j'ai inventé avec des collègues. Il s'agit donc d'un néologisme. Il permet de désigner l'analyse, l'étude ou le travail sur des technologies obsolètes et/ou bâtardes.

Ce terme a vu le jour après un certain temps passé pour des clients sur des langages « périmés ». En effet, la technologie utilisée la plus récente datait de plus de 15 ans. Ne parlons même pas de la technologie la plus vieille.

Après de nombreuses discussions entre collègues, l'étymologie du terme a germé. Fort de constater que nous travaillions sur des langages, qui aux yeux de l'histoire informatique remontaient à la préhistoire, nous sommes partis sur l'idée que nous faisions de l'archéologie informatique. Le terme initial était alors né: inforchéologie.

Puis par la suite, nos périmètres ayant évolué chez nos clients respectifs, et étant amenés à travailler sur des langages maison dérivés de langages officiels, ne respectant aucune norme voire violant tout ou partie des anti-patterns, le terme a évolué peu à peu en inforkéologie.

Désormais, nous qualifions ainsi le fait de travailler sur des machines vieilles de plusieurs décennies, des langages maison plus ou moins absurdes, ou encore des SI complets maison, ne respectant aucune norme et ne disposant d'aucune documentation quelle qu'elle soit.

Et vous:
Vous sentez-vous l'âme d'un inforkéologue?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 13/01/2014 à 10:59
Ca me rappelle une blague :

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"
18  1 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 13/01/2014 à 11:36
inforkeologue... Rien que l'utilisation de la lettre k me laisse reveur...

Apres, un langage qui a plus de 15 ans et qui est encore utilise, pour moi, c'est surtout un gage de qualite.

Apres, je pense que tu t'es fourvoye en prenant 15 ans, car s'il est evident que C, Cobol, Smalltalk ou Fortran sont des langages vieux, je suis persuade que tu ne classe pas Java dedans, qui est pourtant ne en 1995, c'est a dire qu'il va feter ses 19 ans, tout comme JavaScript (truc hyper a la mode en ce moment).

D'ailleurs, si je regarde un peu plus loin :
  • C++, 1983
  • Perl, 1987
  • Python, 1991
  • Objective-C, 1983
  • R, 1993
  • ...


Dans les langages de moins de 15 ans, je ne trouve guere que les langages Microsoft (C# en 2000) ou les langages somme toute tres peu utilises, genre Go (2009) ou Scala (2003).

Est-ce que pour autant tous les gens qui developpent ou maintiennent du code dans ces langages sont des inforcheologues ? Je ne crois pas.
14  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 13/01/2014 à 9:59
Le hic est que certains systèmes titanesques ont été conçus dans les années 70/80 (je pense aux systèmes bancaires et assurances notamment où une grande partie est écrite en Cobol)
Ces systèmes sont le noyaux d'une activité économique et ils ont besoin d'être maintenus et maj.
Les changer est trop coûteux et très risqué car certaines connaissances se sont perdues et que ces systèmes sont tellement énormes et tentaculaires que plus personne ne s'y retrouve (en dresser la cartographie est un projet de plus d'une centaine de j/h à lui seul).
Je pense que les vielles technos ont encore de beaux jours devant elles.
Et puis, à partir du moment où un système est stable et fonctionne, il n'est pas nécessaire de le changer.
La nouveauté n'est pas synonyme de progrès.
9  0 
Avatar de dagor31
Membre régulier https://www.developpez.com
Le 20/01/2014 à 12:13
Bonjour,
Ben moi, j'ai commencé en Cobol ANS et en Basic, mais c'était en 1973 !
Puis j'ai écrit en 1978, tout un progiciel de remboursement de frais maladie pour une mutuelle, c'était en BAL sur un des premiers micro (que j'ai gardé quand la boite s'en est débarassé et qui marche !) qui était un micro français créé par R2E (racheté par BULL) et qui se nommait Mical9050 sous système Prologue avec un disque système de 5 Mo, passé par la suite à 20 Mo , une mémoire boosté à 512 Ko.
Il était doté d'une carte multifonction (genre SCSI) qui lui permettait de gérer 2 imprimantes à aiguilles TALLY dont une en 4 couleurs (j'ai été obligé d'écrire les drivers en assembleur !), il gérait aussi 2 unités de disque qui provenait d'un Mini 6 Bull qui comportaient chacune un disque dur fixe de 10 Mo et un amovile de 10 Mo (l'amovible devait mesurer 40 cm x 40 cm et 3 cm d'épaisseur, il gérait aussi une encodeuse à carte IBM370 qui était équipé d'un modem qui elle permetteit de créer des disquettes 8 '' destinées aux banques et en plus, il gérait 5 écrans asynchrones.
En 1984, on a ajouté une des première carte réseau qui lui permettait de discuter avec des PC qui géraient des applis minitel sous Système Prologue.
L'appli qui a fini sous ABAL (un peu plus puissant que BAL) représentait, avec les progs de reorg disques, de controle d'erreurs etc (car il fallait tout écrire) environ 600 programmes (extrement compacts mémoire oblige) et les opératrices tappaient environ 700 à mille décomptes / jour. On m'a demandé de maintenir ce logiciel qui a été jusqu'à gérer les tiers-payant ,et tout le bataclan jusqu'en 1999 car la machine ne passait pas l'an 2000.
Alors ! ça c'était de inforkeologie qui a duré, non ?
@+
YD
8  0 
Avatar de DotCertis
Membre actif https://www.developpez.com
Le 13/01/2014 à 11:54
J'ai été recruté en 2011 dans une SSII avec 11 autres personnes ( des ingénieurs généralistes) et nous avons tous eu une formation de 5 semaines sur du cobol ^^
N'ayant jamais vraiment étudié de langage de programmation je dois avouer avec le recul que c'est une très bonne porte d'entrée.

Et même en croyant ce langage mort dans une précédente mission qui porte sur le module FI de SAP dans un très grand nom du monde du transport, j'ai participé à un projet de refonte global du système financier. Et au cours de la phase d'études nous avons vu que 90 % des flux en entrée du module FI venait d'une appli monstrueuse (sorte d'ETL, broker, moulinette géante...) qui contenait plus de 30 ans de dév majoritairement en cobol mais faisant appel à des programmes qui étaient véritablement indispensable au bon fonctionnement écrit ... en assembleur et utilisant des bases DL1...

Finalement et bien que le projet était présenté comme "budget illimité" devant cette "monsturosité" (mais qui fonctionnait très bien) la décision a été de la conserver (avec quelques évolutions).

Et dernière anecdotes dans cette même boite sur un autre projet un appli cobol a été refaite en java et bim ! des perfs plombées de plus de 30 % et un retour arrière.

Bref ces technologies qui ont largement faits leur preuve ne sont peut être pas "sexys" du tout, mais elles restent bien souvent des références en robustesse et en performances
6  0 
Avatar de bbo08
Futur Membre du Club https://www.developpez.com
Le 21/01/2014 à 10:59
Bonjour à tous.
Ça me fait drôle de vous lire. Ça me ramène à un passé pas si lointain, hier ou peut-être avant-hier.
Ma spécialité est le développement dans l'embarqué, du µC 4 bits au µC 32 bits. J'ai échappé (?) aux µC 1 bit ou en tranches.

Je voudrais partager une petite bulle du passé. En 77/78, j'ai vu tourner un I4040, commencé à programmer en BASIC sur un calculateur industriel (GENERAL AUTOMATION) qu'il fallait booter à la main avec des interrupteurs en face avant et sauvegarder les sources sur des bandes perforées vomies par une télétype, écrit mes premiers code en assembleur I8085 sur papier et entrés via un clavier hexadécimal, puis développer sur des µC dont les fabricants ont disparus (MOSTEK ou RCA par exemple). J'ai connu les mémoires à tambour, à tores et à bulles,...

Dans les années 85 pour un projet de gestion d’énergie, je m’étais intéressé au FORTH. Le projet ne s'est pas fait et j'avais crû que le FORTH était passé dans les poubelles de l'Histoire. 15 ans après, je me suis retrouvé chez un client varois spécialisé dans le développement de cartes CPU à faire du FORTH pour de l'OPEN FIRMWARE.
Plus récemment, un client cherchait un 'vieux technicien' (dixit) pour déboguer un système sonar multi-DSP de première génération. Il ne voulait surtout pas entendre de jeunes ingénieurs fraichement sortis de l'école.

Le plus drôle actuellement pour moi est de parler de la préhistoire de l'informatique avec des 'petits jeunes'... qui ont eux aussi des trucs à nous apprendre. Grâce à l'un deux, j'ai découvert le PERL et ses scripts qui m'ont aidé à piloter des émulateurs de développement µC. Depuis un an, je pratique le TCL/TK pour des interfaces sous SCILAB. Depuis cet été, je découvre PYTHON pour le plaisir.

Je rejoins Dagor31 pour la soif d'apprendre...

En informatique, le passé n'est pas si vieux et le futur est en train de naître.

J’espère que dans une retraite pas si lointaine, avoir le temps et la vitalité de continuer à développer du code.

Cordialement, bbo08
5  0 
Avatar de sevyc64
Modérateur https://www.developpez.com
Le 13/01/2014 à 13:33
Prenons un langage "vieux" et éprouvé dont on connais tous les avantages, mais surtout aussi tous les défauts que l'on sait gérer, maitriser, contourner.
Prenons à l'inverse un langage plus moderne, tout jeune, tout génial et qui sent encore la peinture fraiche. C'est le super langage à la mode, mais peut-être encore bourré de failles et bugs, qui peut-être subira 4 ou 6 mises à jour dans les 6 mois à venir dont certaines en rupture de compatibilité parce qu'il n'est pas possible de faire autrement.

Maintenant vous êtes développeur/chef de projet/architecte/ce que vous voulez, sur un projet hautement sensible. Imaginons un projet dont la maintenance sera difficile voire impossible, un projet dont les arrêts de productions se chiffrerons en plusieurs millions d'euros et plus voire un abandon pur et simple du projet et pertes sèches ou pire des pertes humaines, un projet dont le taux de fiabilité doit être exagérément au delà du raisonnable. Je pourrais continuer longtemps !

Quel langage allez-vous choisir ?

Un projet comme ça, ça n'existe pas ?

Il s'en code tous les jours. On parlera d'une application bancaire, d'applications médicales, d'application industrielles que ce soit chimique, nucléaire ou autres. On peut citer aussi tout ce qui part dans l'espace, etc, etc...
4  0 
Avatar de seedbarrett
Membre actif https://www.developpez.com
Le 21/06/2016 à 14:06
Je rajoute ma patte à l'édifice, n'étant pour l'instant pas encore diplôme, c'est dire. Je travaille actuellement dans une PME qui produit -entre autre- des composants électronique. Je me suis retrouvé face à un vieux PC qui avait surement des milliers d'heures de fonctionnement pour piloter un four de production, tout ça sous OS/2. Et bien heureusement que j'étais déjà habitué à être pauvre avoir de vieilles machines, étant donné que personne dans l'entreprise ne savait comment s'y prendre (même l'informaticien à refusé tellement ça sentais mauvais cette histoire). Finalement j'ai découvert la joie de eComStation, qui gère l'USB en natif et l'installation sur CD, le port disquette étant utilisé pour la clef de sécurité.
A 23 ans, OS/2 c'est déjà de inforkéologie
4  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 13/01/2014 à 18:48
Pour moi il n'y a pas de "vieux langage fossile". Juste des cas particuliers, et les langages fait maison (ou pas "standard"/reconnu).

Cas particuliers :
  • Si je prends un exemple extrême comme l'assembleur, oui c'est un langage très bas niveau, mais c'est un peu la base de tout. D'ailleurs sans ce langage, pourrait-t-on avoir les autres ? Pour moi ce langage sert à faire les autres langages, sans plus, il n'est pas nécessaire d'être en quête de puissance en se lançant dans de l'assembleur.
  • Pour ce qui est de COBOL, ce n'est pas un langage fait par n'importe qui, certes c'est un langage qui n'a pas la même communauté que les autres sur internet et qui rebute les jeunes, mais c'est un langage qui a du support en entreprise et qui n'est pas très difficile quand on a les bons outils de développement.


Le vrai problème (selon moi) et sans entrer dans les détails :
  • Les langages ET frameworks faits maisons. Ces choses que vous ne trouverez nul part ailleurs.
  • Les vieux frameworks pourris (ex: Struts), alors qu'il y a mieux depuis.
3  0 
Avatar de SurferIX
Membre chevronné https://www.developpez.com
Le 16/01/2014 à 11:02
Moi je ne dirai qu'une chose : oui, c'est plein de trucs vieux, mais si on ne peut pas les changer, ceux qui sont compétents dans le domaine valent cher, très cher... cherchez les tarifs des spécialistes VAX, COBOL, Fortran etc. et comparez les avec les développeurs Php
3  0