L'apprendimento di COBOL ha ancora senso?
L'apprendimento di COBOL ha ancora senso?
Risposte:
Non credo, a meno che tu non sia già nel mercato di nicchia in cui COBOL è ancora mantenuto.
Nooo, certo che no. COBOL è una lingua morta, dopo tutto. O è?
Il problema con questo punto di vista è che i programmatori in siti come questo di solito lavorano con aziende high-tech, veloci (e altrettanto veloci). Per loro COBOL è una lingua morta - non si vede da nessuna parte. Non è da un po 'di tempo ormai, è vero.
Ma COBOL non era pensato per loro. Nell'industria del software c'è molto di più. I computer non sono stati inventati per le persone con un bisogno irrazionale di aggiornare e sostituire sempre il vecchio con il nuovo. Sono stati realizzati per scopi commerciali.
Vuoi vedere COBOL? Vai a una società che elabora le buste paga o gestisce il trasporto di merci o la spedizione (come nelle navi) o gestisce il tuo conto bancario. Esiste un enorme sistema invisibile di codice là fuori che è praticamente invisibile agli utenti, e la maggior parte di loro non ci pensa mai, anche se lo incontrano in un modo o nell'altro ogni giorno (bancomat?)
No, non è morto. Ma è "eredità" di sicuro ... o è?
Ancora una volta, dipende da come lo guardi. Oggi molte persone useranno Java, C o qualsiasi altra cosa al posto di COBOL, riscrivendo da zero ... introducendo nuovi bug man mano che procedono, naturalmente. Ciò non significa che COBOL non abbia bug e stranezze. Lo fa, tanto quanto la lingua successiva. Certo che lo fa. Ma in "tempi COBOL", le aziende che prendevano gli errori più seriamente del solito (assicurazioni, banche) tendevano a produrre un codice di qualità superiore con gruppi di servizi di qualità speciale; oggi ci sono scadenze in cui tempo e budget vincono sempre sulla qualità. Inoltre, questi sistemi sono stati originariamente sviluppati per periodi più lunghi rispetto all'equivalente ora.
Se alcuni software funzionano da oltre 30 anni, dov'è l'incentivo a passare? Intere compagnie fallirono perché ignorarono il vecchio adagio di "se non è rotto, non aggiustarlo". Molti hanno cercato di riscrivere la cosa ... poi la prima riscrittura costava molto, poi la seconda costava ancora di più ... e nessuna di quelle nuove e migliorate è riuscita a sostituirla. Come ho già detto, questo settore è in rapida ascesa e tende anche a dimenticare rapidamente.
Negli anni '70 COBOL era morto o moriva presto, il C / C ++ avrebbe governato. Poi di nuovo nei primi anni '80 Pascal stava subentrando. Poi negli anni '90 era Java come THE Language ...
Pensa a Unisys Mapper, dBase, Clipper, Cold fusion ... le persone ricordano anche quelle? Ognuno di loro sarebbe diventato il becchino per COBOL.
Tenendo conto di ciò, e del fatto che è ottimo per l'elaborazione di elevati volumi di transazioni, elaborazione batch o elaborazione orientata ai record / transazioni e che si può compilare (senza errori) una subroutine scritta 30 anni come codice COBOL gestito e chiamare da un COBOL.NET gestito dovremmo desiderare di andare su Windows e .NET, ho difficoltà a trovare un sostituto adatto per esso. (Ho anche problemi a trovare una tecnologia Microsoft che è durata più di un decennio.)
Sì, il nuovo codice COBOL è stato scritto oggi. Uno deve solo sapere dove cercare.
Per quelli che ridono di COBOL, IMHO, è come ridere delle piramidi egiziane, sono lì da 5000 anni e saranno ancora lì nei prossimi 5000 anni, mentre gli alloggi del "ciao mondo" di oggi che richiedono 24 controlli per funzionare saranno eliminati, sostituito, dimenticato il mese prossimo.
Allora, dove sono tutti quei programmatori COBOL?
Ah, perché qui sta il problema. Il fatto è che molti di loro non hanno alcun background scientifico scientifico. Molti di loro non sono programmatori professionisti (come nei laureati di un programma CS / SE). Per la maggior parte, sono persone alla fine degli anni '30 -'50, provenienti da tutte le aree di competenza, formate interamente dall'azienda appositamente per quel lavoro. Quindi non sono "programmatori COBOL" - la formazione che hanno è specifica per l'azienda che promuove così fortemente dall'interno. E questo li rende praticamente invisibili.
Se riesci a vederti come programmatore COBOL, allora provaci. Ci sono ancora miliardi di righe scritte in COBOL che richiedono manutenzione.
In realtà, non esiste una conoscenza superflua, quindi amplia la conoscenza e le maggiori opportunità che avrai (avrai).
L'apprendimento ha senso?
Bene, è una nicchia e ci sono tonnellate di codice legacy funzionante che devono essere mantenute e non possono essere semplicemente riscritte. Quindi, sebbene non sia davvero un'opzione per le grandi masse di tutti i programmatori, è una prospettiva per un reddito costante per gli individui.
Tuttavia, se sei interessato a creare nuove soluzioni, piuttosto che migliorare lentamente quelle che esistono da decenni, COBOL probabilmente non è la lingua giusta.
Molte aziende europee fanno ancora molto affidamento sui mainframe che funzionano come i programmi z / vse e cobol. C'è una domanda per programmatori abili di cobol che nessuno pensa che il mercato si riempirà e che fa salire molto lo stipendio.
La domanda dovrebbe essere: "svilupperò mai qualcosa di nuovo usando cobol?" dato che praticamente tutto è manutenzione o variazioni di cose mission-critical esistenti.
Lavoravo per IBM dove ogni giorno venivano scritti i codici COBOL e PL / I. Anche da grandi aziende che si affidano ai mainframe IBM come molte banche che richiedono migliaia di transazioni al secondo, queste lingue sono ancora ampiamente utilizzate.
Se non vuoi lavorare in un posto come quello (ecco perché ho lavorato lì per 6 mesi), non pensare nemmeno di imparare quelle lingue.
Scriviamo il nuovo codice Cobol ogni giorno e siamo costantemente alla ricerca di nuovi programmatori. L'offerta è troppo piccola da queste parti.
Se vuoi avere un lavoro come programmatore COBOL, allora certo, vai avanti e imparalo.
Per qualsiasi altra ragione, come cercare di imparare qualcosa di utile che potrebbe aiutarti con le moderne tecniche di programmazione, no, non preoccuparti.
Nel 2000 ho letto una statistica secondo cui c'erano più righe di COBOL scritte di tutte le altre lingue messe insieme.
Aggiungete a ciò l'IBM garantisce che qualsiasi deck TEXT (codice oggetto), compilato su qualsiasi sistema MVS è eseguibile su tutti i loro sistemi MVS e avete la garanzia che ci sarà una programmazione COBOL finché il sole splenderà.
Posso dirti come l'ho "imparato":
ero impiegato a lavorarci, non avevo idea di cosa si trattasse e non ho avuto difficoltà a impararlo durante la notte.
Quindi, se ne hai bisogno, puoi impararlo. Non c'è bisogno di sovraccaricarti di conoscenze inutili. Non c'è nulla di interessante in esso o nei suoi impegni se non ne hai davvero bisogno pratico.
La risposta generica: apprendi i principi di codifica, non le loro implementazioni specifiche (come le lingue, ecc.)
Non ci passerei tempo.
Ad ogni modo, COBOL è la base di molti programmi applicativi legacy che sono fondamentali per diverse grandi aziende avviate 20-30 anni fa.
Quindi, se sei assunto per un'azienda che ha parte del suo core business in COBOL, ci sono possibilità che tu debba iniziare a impararlo.
Imparalo se ti piace, dopo tutto, sapere come funzionano le cose (o una volta funzionavano) non può essere una brutta cosa.
Tuttavia, raccomanderei di non enfatizzare troppo le tue abilità COBOL nel tuo curriculum.
In alcuni posti (ad esempio, nella Silicon Valley dove vivo) avere COBOL nel tuo curriculum sarà una responsabilità. Oh certo, potresti trovare un posto qua e là che ha bisogno della tua esperienza, e in quel caso vai avanti e pubblicizzalo solo in quei luoghi . Ma in generale, fatti un favore e dimentica di dire che conosci COBOL.
Quindi sì, imparalo se sei curioso, non dirlo a nessuno.
Forse non vale la pena dal punto di vista del mercato del lavoro, ma potresti volerlo dare un'occhiata solo per avere un'idea di come sono state fatte le cose "ai bei tempi". ^^
Da un punto di vista personale direi che ci sono cose migliori da imparare prima. Tuttavia, molte grandi aziende hanno investimenti molto ingenti nella loro base di codice COBOL che probabilmente non saranno mai in grado di lasciarsi alle spalle, creando un settore per i programmatori COBOL per mantenere la base di codice e scrivere nuovo codice. La società per cui lavoro è una grande società finanziaria e la nostra divisione tecnologica per gli sviluppatori è di circa il 30% COBOL, 40% Java e 30% C #.
Ho appena fatto una ricerca per "cobol" sul più grande sito web di lavoro in Australia. Ha restituito 87 risultati e (da una breve rassegna) sembrano principalmente posizioni di mantenimento legacy in banche e istituti finanziari. Per lo più decisamente meglio retribuito rispetto a lavori linguistici più "moderni", presumibilmente a causa della rarità dell'esperienza Cobol.
Quindi sì, sembra che Cobol varrebbe la pena di imparare se 1) non ti dispiace fare manutenzione legacy e 2) vuoi entrare in una nicchia che è ben pagata e probabilmente non molto competitiva poiché è qualcosa che poche persone stanno imparando più.
(Suppongo che il mercato Cobol sarebbe simile nella maggior parte delle economie del Primo Mondo, ma potrebbe essere sbagliato?)
Pensa ai tipi di domini problematici in cui vuoi lavorare. In genere quei domini hanno un set di lingue che vengono generalmente utilizzate per lo scopo. Se COBOL corrisponde a quello, vai avanti.
Non è possibile che io tocchi né cobol né i domini problematici che lo usano pesantemente con un palo da 10 piedi. Preferirei capovolgere gli hamburger.
Considera anche se il linguaggio offre qualche bonus / miglioramento alla tua abilità / concetti di programmazione. Non riesco a pensare a niente che COBOL possa fare / implementare / funzionalità che non è fatto meglio o che può essere dimostrato meglio in un'altra lingua.
Tu e gli altri potreste sentirvi diversamente.
Ci sono ancora molti sistemi legacy là fuori scritti in COBOL. Sia che tu voglia mantenerli o portarli su altri linguaggi di programmazione, vale comunque la pena imparare COBOL.
Qualunque cosa sia, una certa conoscenza in più linguaggi di programmazione sarà un vantaggio perché la conoscenza che hai ti consente di scegliere un linguaggio di programmazione o un approccio per le diverse esigenze del progetto. Puoi usare le tue conoscenze nei linguaggi di programmazione per costruire codici migliori, più puliti ed efficienti ed evitare insidie.