Oltre al software legacy, ci sono ragioni per usare COBOL?

COBOL è ancora (pesantemente?) Utilizzato per il calcolo finanziario. È una lingua vecchia e la maggior parte dei programmatori di AFAIK odiano o almeno non amano COBOL. Ciò pone una domanda: è l'unica ragione per cui COBOL viene ancora utilizzato dal software legacy o presenta vantaggi reali rispetto ad altri linguaggi di programmazione?

Solo curioso.

Ora è per lo più ereditato. Molti sistemi aziendali critici sono ancora in COBOL semplicemente per il fatto che sono così grandi e integrati che il costo della riscrittura non sembra valerne la pena. Scrivere un nuovo sistema in COBOL probabilmente non è più fattibile, poiché la maggior parte degli sviluppatori COBOL è così scarsa che può guadagnare una notevole quantità di denaro per l'abilità specializzata (simile a uno sviluppatore Foxpro ora). Ci sono pochi o nessun motivo per mantenere un'app COBOL in circolazione, ma sfortunatamente il ragionamento comune è quando l'app COBOL è già attiva, affidabile e strettamente accoppiata con altri sistemi in cui è quasi impossibile sostituirla. Questo ragionamento è esattamente il motivo per cui dovrebbe essere sostituito prima che arrivi a una situazione in cui l'unico hardware che esegue l'app deve essere personalizzato partendo da parti Ebay degli anni '80 / '90.

COBOL è ancora (pesantemente?) Utilizzato per il calcolo finanziario.

È?

Dipende da ciò che chiami informatica finanziaria. Se si chiama tutto il codice gestito da istituti finanziari sì, probabilmente lo è. Molti hanno regole commerciali scritte negli anni '60 e '70. Il rischio + costo di aggiornare sistemi come questo in un nuovo ambiente non ne vale la pena. Dubito che ci sia qualcuno là fuori a scrivere un nuovo codice COBOL. Oggi ci sono compilatori COBOL che si integrano nello stack .NET, ad esempio. Spesso ci sono strumenti per integrare e sfruttare le applicazioni legacy in stack software moderni, ma quegli strumenti sono spesso sconosciuti alle persone che non devono usarli, dal momento che è un mercato molto di nicchia.

Ora, se chiami il calcolo finanziario qualcosa di più simile al software per la finanza quantitativa, non ho mai sentito parlare di qualcuno che usa COBOL. Il C ++ è molto più comune, in alcuni linguaggi di nicchia come k, un derivato APL.

COBOL ora vede principalmente l'uso legacy. La sua base di utenti sta lentamente diminuendo per logoramento, poiché non vengono scritte nuove applicazioni e quelle vecchie lentamente, ma sicuramente vengono gradualmente eliminate.

La maggior parte dei sistemi COBOL che potrebbero essere sostituiti rapidamente ed economicamente, sono già stati sostituiti. Quelli che non sono, continuano a diventare sempre più costosi da riparare o sostituire, ma sempre più economici da mantenere rispetto ai sistemi più recenti: funzionano bene su hardware scaduto e poco costoso e, dopo molti anni di servizio, non sono più mostrando più eventuali nuovi bug. La maggior parte dei bug sono stati corretti o hanno tradizioni di lunga data che si adattano come soluzioni alternative. In genere, la manutenzione è stata ridotta a uno o due dipendenti specializzati che, dopo aver lavorato a lungo sul sistema, lo conoscono più intimamente di quanto si possa immaginare.

Anche dal punto di vista tecnico, di solito ci sono alcuni validi motivi per mantenere in circolazione i vecchi sistemi. Sono relativamente stabili, sono stati per lo più corretti da errori e sono ben conosciuti / compresi dall'utente finale.

Tuttavia, vedrai che il sistema verrà eventualmente sostituito. In genere questa mossa viene dal lato commerciale delle cose:

• Gli utenti del sistema attuale vengono sostituiti da utenti più giovani, che non possono essere convinti di imparare a utilizzare l'interfaccia arcaica
• La società non riesce a trovare nessuno da assumere per mantenere il sistema, con uno stipendio che non è scandaloso rispetto alla retribuzione degli altri dipendenti
• Qualcuno con un budget elevato diventa imbarazzato nello scoprire che un sistema centrale per l'azienda è in esecuzione su hardware che può essere sostituito da un VM su un laptop
• Arriva un nuovo sistema di merci, che è davvero economico da usare
• La società che utilizza i sistemi più vecchi viene acquisita, fallisce o smette di esistere realmente
• Un pezzo cruciale di nuove funzionalità, urgentemente richieste, non può essere fatto a buon mercato per interagire con il sistema legacy

mi chiedo cosa intendevi per "la maggior parte dei programmatori". Lavoro in un grande negozio IT sullo stesso piano di programmatori cobol, programmatori Java, programmatori .NET (in singolare), programmatori VB vecchio stile. Non c'è odio o antipatia. cobol è un linguaggio come qualsiasi altro linguaggio di programmazione - le persone che programmano in cobol lo fanno perché è un lavoro per loro non diverso dalla programmazione in java o dalla guida di un camion. Contrariamente alla concezione popolare negli Stati Uniti, ci sono molti cobol che continuano a essere scritti, solo la maggior parte è in India dove ogni giorno nuovi programmatori Cobol iniziano a lavorare.

Penso che il motivo per cui non sono stati scritti troppi nuovi sistemi netti in Cobol è perché il tipo di sistemi a cui cobol è adatto (elaborazione di file di grandi volumi) sono già tutti scritti. Oggigiorno vengono create pochissime nuove grandi società. E quelli che lo fanno potrebbero esternalizzare cose come buste paga e benefici per le aziende che gestiscono sistemi cobol legacy.

Gran parte del codice principale in PeopleSoft è scritto in COBOL.

Con 20 anni di esperienza COBOL, su tre diversi mainframe, è mia umile opinione che ci sono pochi veri programmatori COBOL e invece ci sono programmatori IBM, programmatori Sperry (Unisys 2200), programmatori Burroughs (Unisys MCP) e Tandem (HP NonStop) programmatori. A dimostrazione del loro rispetto, devo anche menzionare la presenza di programmatori HP 3000, programmatori BULL e programmatori DEC.

COBOL funziona su grandi scatole di ferro, per la maggior parte. Forse i soli veri programmatori COBOL, secondo i miei standard, sono quelli che scrivono COBOL su una scatola UNIX. Wow, ho intenzione di sentirlo.

Poiché l'hardware è l'elemento centrale, la maggior parte dei programmatori che scrivono COBOL si identificano dall'hardware su cui viene eseguito il codice che scrivono. Nel corso degli anni, ascoltando altri programmatori che mi raccontano i meriti di Sperry, Burroughs o Tandem, mi sono spesso chiesto quale tipo di guerra sarebbe seguito se dovessi radunarli e metterli in una stanza insieme incapaci di andarmene finché concordato una piattaforma hardware per tutti COBOL. Non ho menzionato le altre piattaforme perché non ci ho mai lavorato.

Ho incontrato e parlato con molti programmatori IBM e si riferiranno a se stessi come programmatori COBOL. Tuttavia, se li coinvolge in una conversazione, iniziano rapidamente a fare riferimento a procedure e strumenti specifici di IBM. Data la natura incentrata sull'hardware di COBOL, questo è molto comprensibile, per tutte le piattaforme hardware.

Poiché COBOL è generalmente legato a un componente hardware molto costoso, purché tale componente hardware esegua i programmi COBOL compilati su di esso, non vi è alcun forte desiderio di migrare da COBOL per motivi di migrazione. Tuttavia, con l'invecchiamento della popolazione di programmatori COBOL, la migrazione è inevitabile.

Poiché tutte le grandi scatole di ferro che eseguono COBOL eseguiranno anche Java, Java è il percorso naturale di migrazione da COBOL. Il codice può essere convertito, in particolare ora in un'economia in ribasso, per un prezzo piuttosto economico. Una volta che non c'è COBOL, solo Java, su quel grosso e costoso pezzo di hardware, qualcuno in alto nell'organizzazione inizierà a chiedersi se è possibile spostare il codice Java su un altro pezzo di hardware molto meno costoso.

I programmatori IBM, Sperry, Burroughs e Tandem lo sanno, quindi probabilmente non offriranno MAI l'idea. Per alcuni sarebbe un sacrilegio.