In che modo le organizzazioni finanziarie pianificano il degrado di vecchi linguaggi di programmazione come COBOL? [chiuso]

I programmatori non sono la risorsa limitante. Imparare una nuova lingua è facile rispetto a tutto il dominio e le cose specifiche del programma che devi imparare quando inizi in una nuova azienda, e le persone si spostano continuamente in nuove società. Stai parlando una lingua con 300 parole chiave rispetto a un programma con centinaia di migliaia di funzioni. Non è nemmeno vicino.

L'hardware alla fine si logora, e se arriva un momento in cui non possono ottenere il supporto del compilatore per il nuovo hardware, allora migreranno verso una nuova lingua. Questi tipi di migrazione dell'hardware sono in genere pianificati con diversi anni di anticipo. Una volta ho lavorato a una grande riscrittura suggerita da un fornitore di nastri a matrice di punti che ha cessato l'attività. La mia azienda ha acquistato un po 'di stock di nastro per comprarci abbastanza tempo per la migrazione. "Fortunatamente" la vecchia lingua aveva un supporto sufficiente per passare al nuovo hardware in quel momento, ma la riscrittura era abbastanza ampia da consentirci di passare a una nuova lingua.

Divertente dovresti chiederlo.

Mio padre è un programmatore COBOL. Laureato al college, ha ottenuto un lavoro presso una grande compagnia di assicurazioni. Ha lavorato alla stessa app per tutta la sua carriera (lo stesso mainframe fisico per 30 anni dispari di quello). Ho trascorso gli ultimi 4 anni insegnando remotamente a una squadra di neo-laureati in India come scrivere COBOL. Si è ritirato l'anno scorso.

Non lo considererei un "piano" o una buona decisione commerciale a lungo termine. Ma le aziende non sono famose per prendere decisioni tecniche a lungo termine.

È ingenuo presumere che i linguaggi più moderni siano in qualche modo preferibili a quelli più vecchi per un determinato dominio problematico.

Al di là delle questioni di rischio e l'immenso costo associato a tale modernizzazione è il fatto che molti ambienti legacy hanno il loro ecosistema e si sono evoluti in modo simbiotico con esso. Queste soluzioni sono spesso il miglior elisir per un problema a cui hanno effettivamente contribuito.

IBM non si arrende su DB2 / RPG in qualunque momento presto. I file flat di COBOL non si estinguono durante la nostra vita. Questo è un fatto. E anche se potessimo rimuovere (inserire qui la tecnologia demonizzata) dovremmo affrontare un dominio problematico per il quale potremmo non disporre degli strumenti corretti.

È più semplice eseguire una piccola quantità di manutenzione su un sistema che funziona o riprogetta qualcosa che probabilmente non comprendiamo appieno?

Per meglio o peggio COBOL, VB6, RPG e simili non sono quasi morti.

Le lingue, come ad esempio COBOL, non richiedono hardware esotico. Le uniche risorse che potrebbero esaurirsi sono il personale. Ma finché ci sono soldi da guadagnare, le persone impareranno le competenze necessarie.

Alcune aziende oggi stanno riscrivendo i loro sistemi in lingue più di moda - ma, ehi, l'anno scorso ho ricevuto un'offerta da una banca che sembrava riscrivere da C ++ a Java ... Quindi, per rispondere "come si occuperanno di questo ?" Immagino che per ogni approccio immaginabile ci sia almeno una società che la mette in atto . Dalla formazione di nuovi ranghi di programmatori-archeologi alla riscrittura di tutto ancora e ancora.

In che modo le organizzazioni pianificano di sostituire le lingue morte? In modi che sono probabilmente segreti commerciali.

Quando ero l'ultimo a lavorare per una banca, stavano affrontando 3 problemi:

1. Avevano assunto un nuovo programmatore del sistema Core una volta negli ultimi 20 anni e tutti gli altri si erano ritirati
2. Il linguaggio era più morto di Cobol.
3. Il sistema principale era su un mainframe, che sono incredibilmente costosi da gestire, rispetto a un gruppo di poche decine di macchine commodity.

Ora ero al corrente del piano aziendale per gestirlo (quindi non posso rompere i suddetti segreti commerciali). Il mio team ha elaborato un piano per risolverlo e ne ha implementato la maggior parte.

Abbiamo creato uno strumento che traducesse dalla suddetta lingua morta, in Java. Lo strumento che abbiamo creato ha generato un java abbastanza terribile. Principalmente perché lavorare per non avere GOTOs, e anche per l'esistenza di Reentrant Functions, e alcuni altri capricci che non hanno fatto in lingue moderne. Il java che ha realizzato è stato orribile, ma ora potrebbe essere sostituito modulo dopo modulo, poiché era richiesta una funzionalità nuova / modificata. Lo strumento di traduzione è stato scritto in C #, facendo uso di ANTLR.

L'altro lato dello strumento era Java con implementazioni della maggior parte degli operatori e dei tipi di dati dalla lingua morta. Il che includeva la necessità di implementare un livello di memoria virtuale dal momento che a volte venivano utilizzati i join e i puntatori.

Dopo che per lo più abbiamo finito, siamo arrivati alla conclusione che sarebbe stato meglio non tradurre in Java, ma in C ++, perché il C ++ ha ancora molte di quelle funzionalità che non sono state introdotte nei linguaggi moderni. Java è stato originariamente scelto a causa della economicità delle macchine virtuali Java in alcuni particolari prodotti / architetture di cluster.

Quando me ne sono andato questo è stato per lo più fatto. Compilerebbe / tradurrà qualsiasi codice di esempio che potresti trovare per la lingua morta. Quello che non poteva fare era il livello del database. Che è stato gestito con 3 livelli di preelaborazione sul codice sorgente nella lingua morta, e che doveva essere sostituito con connessioni db remote invece di qualsiasi interfaccia che si usa su un mainframe per accedere al database su di esso.

Sono partito convinto che avrebbe funzionato. Ma non ho idea se è stato ritirato dal controllo di versione da quando ho smesso di lavorarci. Potrebbe essere lo stanno usando oggi.

Sospetto a lungo termine (che molti ora sono il passato), la più grande compagnia del gruppo bancario che li ha acquistati 6 mesi prima ho iniziato a svuotare completamente i sistemi IT e li costringi a utilizzare solo un sottile involucro di sistemi di società madri.