A parte il software legacy, ci sono motivi per usare COBOL?

È quasi sempre un lascito. 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 di COBOL è così scarsa da poter ricavare una notevole quantità di denaro per l'abilità specializzata (simile a uno sviluppatore Foxpro ora). Ci sono poche o nessuna ragioni per mantenere una app COBOL in giro, ma sfortunatamente il ragionamento comune è quando l'app COBOL è già sul posto, affidabile e strettamente accoppiata con altri sistemi dove è quasi impossibile sostituirla. Questo ragionamento è esattamente il motivo per cui dovrebbe essere sostituito prima che arrivi ad una situazione in cui l'unico hardware che esegue l'app deve essere costruito su misura da parti Ebay degli anni 80/90.

COBOL is still (heavily?) used for financial computing.

È?

Dipende da ciò che chiami calcolo finanziario. Se chiami tutto il codice gestito dagli istituti finanziari sì, probabilmente lo è. La maggior parte ha regole aziendali scritte negli anni '60 e '70. Il rischio + costo di aggiornare sistemi come questo in un nuovo ambiente non vale la pena. Dubito che ci sia qualcuno là fuori che scrive un nuovo codice COBOL. Esistono oggi compilatori COBOL che si integrano nello stack .NET, ad esempio. Spesso ci sono strumenti per integrare e sfruttare applicazioni legacy in moderni stack di software, ma questi strumenti sono spesso sconosciuti a 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, lungo alcuni linguaggi di nicchia come k, un derivato dell'APL.

chiediti cosa intendevi per "La maggior parte dei programmatori". Lavoro in un grande negozio di informatica sullo stesso piano dei programmatori di cobol, programmatori Java, programmatori .NET (in singolare), programmatori VB di 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 alla guida di un camion. Contrariamente alla concezione popolare negli Stati Uniti, continua ad essere scritto molto cobol, solo la maggior parte è in India, dove ogni giorno cominciano a funzionare nuovi programmatori Cobol.

Penso che la ragione per cui non ci siano troppi nuovi sistemi netti in Cobol è perché il tipo di sistemi per cui cobol è adatto (elaborazione di file di grandi volumi) sono già tutti scritti. In questi giorni sono state create pochissime nuove grandi aziende. E quelli che lo fanno potrebbero essere esternalizzare cose come buste paga e benefici per le aziende che gestiscono sistemi legacy cobol.

Per la maggior parte, COBOL ora utilizza legacy. La base di utenti si sta lentamente riducendo per attrito, dal momento che nessuna nuova applicazione viene scritta e quelle vecchie lentamente, ma sicuramente, sono eliminate.

La maggior parte dei sistemi COBOL che potrebbero essere sostituiti rapidamente ed economicamente, sono già stati sostituiti. Quelli che non lo sono, continuano a diventare sempre più costosi da riparare o sostituire, ma sono meno costosi e meno costosi da mantenere rispetto ai sistemi più recenti - funzionano bene su hardware scadente, obsoleto e, dopo molti anni di servizio, non sono più più a lungo mostra nuovi bug. La maggior parte degli errori sono stati risolti o hanno tradizioni di lunga data che si adattano come un aggiramento. Generalmente la manutenzione è stata ridotta a uno o due dipendenti specializzati, i quali, dopo aver lavorato a lungo sul sistema, lo conoscono più intimamente di quanto si possa immaginare.

Anche da un punto di vista tecnico, di solito ci sono alcune buone ragioni per mantenere i vecchi sistemi in giro. Sono relativamente stabili, sono stati per lo più risolti da bug e sono ben conosciuti dall'utente finale.

Vedrai comunque che il sistema verrà sostituito. In genere questa mossa deriva dal lato commerciale delle cose:

• Gli utenti del sistema attuale vengono sostituiti da utenti più giovani, che non possono essere convinti di imparare come utilizzare l'interfaccia arcaica
• La compagnia non può trovare nessuno da assumere per mantenere il sistema, con uno stipendio che non è scandaloso rispetto alla retribuzione degli altri impiegati
• Qualcuno con un budget elevato diventa imbarazzato per scoprire che un sistema principale per la società è in esecuzione su hardware che può essere sostituito da un VM su un laptop
• Arriva un nuovo sistema di merci, che è davvero molto economico per iniziare a utilizzare
• L'azienda che utilizza i vecchi sistemi viene acquisita, fallisce o in altro modo si arresta realmente esistente
• Un bit cruciale di funzionalità nuove e urgentemente richieste, non può essere fatto a buon mercato per interagire con il sistema legacy

Una parte considerevole del codice core in PeopleSoft è scritta in COBOL.

Con 20 anni di esperienza COBOL, su tre diversi mainframe, è mio modesto parere che ci siano pochi veri programmatori COBOL e invece ci sono programmatori IBM, programmatori Sperry (Unisys 2200), programmatori Burroughs (Unisys MCP) e Tandem ( Programmatori HP NonStop). In una dimostrazione di rispetto a loro, devo anche menzionare la presenza di programmatori HP 3000, programmatori BULL e programmatori DEC.

Il COBOL funziona su grandi scatole di ferro, per la maggior parte. Forse gli unici veri programmatori COBOL, secondo i miei stessi standard, sono quelli che scrivono COBOL su una scatola UNIX. Wow, ne parlerò.

Poiché l'hardware è il pezzo centrale, la maggior parte dei programmatori che scrivono COBOL si identificano con l'hardware su cui viene eseguito il codice che scrivono. Nel corso degli anni, ascoltando altri programmatori che mi hanno parlato dei meriti di Sperry, Burroughs o Tandem, mi sono chiesto spesso che tipo di guerra sarebbe scaturita se li avessi radunati e li avessi messi insieme in una stanza senza poterli lasciare concordato su una piattaforma hardware per tutto il COBOL. Non ho menzionato le altre piattaforme perché non ho mai lavorato su di esse.

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 hardware-centrale di COBOL, questo è molto comprensibile, per tutte le piattaforme hardware.

Poiché COBOL è solitamente legato a un hardware molto costoso, purché quel pezzo di hardware esegua i programmi COBOL compilati su di esso, non c'è una strong volontà di migrare da COBOL per motivi di migrazione. Tuttavia, con l'invecchiamento della popolazione dei programmatori COBOL, la migrazione è inevitabile.

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

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