skip to main | skip to sidebar
66 commenti

Cinquant’anni di COBOL

Il COBOL, quella "soluzione di breve durata" che resiste dopo 50 anni


L'articolo è stato aggiornato dopo la pubblicazione iniziale.

L'informatica è famosa per il ritmo frenetico con il quale si avvicendano i prodotti e arrivano le novità. C'è però una parte dell'informatica che va avanti praticamente invariata da cinquant'anni.

Si chiama COBOL: un linguaggio di programmazione, il cui nome fu coniato nel settembre del 1959, partendo dalle iniziali di Common Business-Oriented Language, da parte di un comitato delle grandi aziende informatiche dell'epoca (Burroughs Corp., IBM, Minneapolis-Honeywell, RCA, Sperry Rand, Sylvania Electric Products) e da alcune agenzie governative statunitensi.

Doveva essere una soluzione di breve durata per offrire un modo più semplice e intuitivo di scrivere programmi per computer, ma secondo le statistiche della società londinese Datamonitor, citate da The Register, nel mondo oggi sono ancora in funzione circa 200 miliardi di righe di istruzioni in COBOL, a cui se ne aggiungono 5 miliardi ogni anno, perché questo linguaggio viene usato ancor oggi da molti dei servizi che usiamo quotidianamente, senza che ce ne accorgiamo.

Ci sono stati molti altri linguaggi di programmazione che sono nati e morti o quasi scomparsi, come il MANTIS, il FORTRAN o Smalltalk, ma il COBOL resiste: secondo l'analisi della società MicroFocus, chi abita per esempio negli Stati Uniti dipende da sistemi basati su COBOL almeno 13 volte al giorno: per esempio per la gestione delle telefonate, per l'uso delle carte di credito, per le transazioni bancarie.

In altre parole, non tutto in informatica si butta via perché è passata la moda del momento. Sarà un caso che il COBOL fu creato in gran parte da una donna? La madre del COBOL fu infatti Grace Hopper (nella foto): un bel peperino, visto che era una matematica laureata a Yale, una ricercatrice informatica e anche ufficiale della Marina degli Stati Uniti, promossa poi al grado di contrammiraglio.

Fra gli altri suoi meriti storici, quello che per molti è il primo "bug" letterale della storia dell'informatica: il termine inglese bug era già in uso in altri campi almeno sin dai tempi di Edison per indicare un difetto di un circuito o di una macchina, ma i colleghi della Hopper trovarono un insetto vero e proprio (bug, in inglese, appunto) incastrato in un relé di uno dei computer dell'epoca (anno 1947) e lei lo appiccicò al registro di lavoro, annotando che si trattava del primo caso di vero e proprio bug trovato in un computer. Nella sua lunghissima carriera, Grace Hopper raccontò spesso l'episodio, rendendo popolare il termine bug anche fra gli informatici.
Invia un commento
I commenti non appaiono subito, devono essere tutti approvati da un moderatore. Lo so, è scomodo, ma è necessario per tenere lontani scocciatori, spammer, troll e stupidi: siate civili e verrete pubblicati qualunque sia la vostra opinione; gli incivili di qualsiasi orientamento non verranno pubblicati, se non per mostrare il loro squallore.
Inviando un commento date il vostro consenso alla sua pubblicazione, qui o altrove.
Maggiori informazioni riguardanti regole e utilizzo dei commenti sono reperibili nella sezione apposita.
NOTA BENE. L'area sottostante per l'invio dei commenti non è contenuta in questa pagina ma è un iframe, cioè una finestra su una pagina di Blogger esterna a questo blog. Ciò significa che dovete assicurarvi che non venga bloccata da estensioni del vostro browser (tipo quelle che eliminano le pubblicità) e/o da altri programmi di protezione antimalware (tipo Kaspersky). Inoltre è necessario che sia permesso accettare i cookie da terze parti (informativa sulla privacy a riguardo).
Commenti
Commenti (66)
Giusto un appunto: il FORTRAN è ancora vivissimo in ambito scientifico ed ingegneristico. Per di più ci si ostina ad utilizzare il FORTRAN77 o il FORTRAN90 invece delle versioni più recenti per poter riutilizzare l'enorme mole di librerie ottimizzate che esistono a giro.
Grace Hopper: congedata alla verde età di 80 anni dall'esercito. Che donna!
Io uso ancora sia il COBOL che
il FORTRAN e mi piacciano piu' del C o del Java
La storia dell'insetto appiccicato al foglio mi ricorda l'inizio di "Brazil" film capolavoro di Terry Gilliam, dove la presenza di un insetto causa un errore nella stampa di un nome e genera una catena di eventi surreali.
Per me un "linguaggio di programmazione" deve essere strutturato e procedurale. Il cobol è un'atrocità che deve essere cancellata dalla faccia della terra il più presto possibile. Non per niente Dijkstra diceva che insegnarlo a scuola (c'è chi lo fa tutt'ora) dovrebbe essere considerato un crimine.
ma il cobol non era quello del tipo
10: Fuck
20: Goto 10
?

in fin dei conti un parente stretto del basic...
Ho appena finito di scrivere un programma in Cobol, l'ho compilato con zero errori al 2° tentativo e adesso lo sto testando.

Lavoro con il cobol da quasi 25 anni ed è praticamente dal primo giorno di lavoro che sento qualcuno che mi dice che il Cobol era finito e che dovevo guardarmi intorno, ecc... ecc...

Vedo e prevedo di andarci in pensione con il Cobol :-)
L'episodio della tarma e` raccontato da G. Hopper stessa in

"Anecdotes," IEEE Annals of the History of Computing, vol. 3, no. 3, pp. 283-286, July-Sept. 1981, doi:10.1109/MAHC.1981.10032

Piccole osservazioni:

- Non e` il primo uso della parola "bug": il termine sembra fosse gia` in uso fra i tecnici dell'elettricita` dai tempi di Edison; in effetti l'appunto di Hopper e` "First actual case of bug being found".

- Secondo la Hopper l'appunto (con la tarma appiccicata) nel 1981 esisteva ancora ed era conservato Naval
Museum at the Naval Surface Weapons Center in
Dahlgren, Virginia (NSWC); Nel Jargon File, pero`, Eric Raymond
afferma:
"There has been a widespread myth that the original bug was moved to the Smithsonian, and an earlier version of this entry so asserted. A correspondent who thought to check discovered that the bug was not there. While investigating this in late 1990, your editor discovered that the NSWC still had the bug, but had unsuccessfully tried to get the Smithsonian to accept it - and that the present curator of their History of American Technology Museum didn't know this and agreed that it would make a worthwhile exhibit. It was moved to the Smithsonian in mid-1991, but due to space and money constraints has not yet been exhibited.

Sarebbe interessante scoprire qual e` la situazione attuale!
Paolo, Microfocus non è un'azienda di analisi (o almeno non solo).
E' un'azienda informatica che sviluppa compilatori e framework per il cobol. I suoi prodotti li ho visti in tantissime strutture in italia (settore bancario e assicurativo principalmente)
Posso solo confermare quanto detto sul FORTRAN. Sono ingegnere informatico (della vecchia guardia, lo ammetto) nonché meteorologo. Uso diversi linguaggi, ognuno con i suoi vantaggi, ma in campo scientifico nulla batte FORTRAN. In meteorologia la versione più diffusa è il FORTRAN90. A parte l'enorme disponibilità di librerie, il linguaggio ha il grande vantaggio di manipolare matrici nativanente.
http://www.pilloleinformatiche.it/pillole/152/il-bug-cos-e-da-dove-nasce/
che bello vedere un'esponente del mondo informatico femminile ... ultimamente mi fanno sentire un po' bistrattata i colleghi maschi, ma queste sono soddisfazioni! :D :D
Quoto J_B e Bison.
Per fare un esempio, le previsioni del tempo che leggete / vedete vengono in buona parte da modelli scritti in FORTRAN e attivamente sviluppati. C'è una implementazione anche recente (fortran 2003), quindi asserire che è morto mi pare sbagliato. Il calcolo numerico puro è una nicchia (secondo me neanche così piccola) di applicazioni FORTRAN belle vive.
gian
Etymology

The concept that software might contain errors dates back to 1842 in Ada Byron's notes on the analytical engine in which she speaks of the difficulty of preparing program 'cards' for Charles Babbage's Analytical engine:
“ ...an analyzing process must equally have been performed in order to furnish the Analytical Engine with the necessary operative data; and that herein may also lie a possible source of error. Granted that the actual mechanism is unerring in its processes, the cards may give it wrong orders. ”

Usage of the term "bug" to describe inexplicable defects has been a part of engineering jargon for many decades and predates computers and computer software; it may have originally been used in hardware engineering to describe mechanical malfunctions. For instance, Thomas Edison wrote the following words in a letter to an associate in 1878:
“ It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and [it is] then that 'Bugs' — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.[3] ”

Problems with radar electronics during World War II were referred to as bugs (or glitches), and there is additional evidence that the usage dates back much earlier.
Photo of what is possibly the first real bug found in a computer.

The invention of the term is often erroneously attributed to Grace Hopper, who publicized the cause of a malfunction in an early electromechanical computer.[4] A typical version of the story is given by this quote:
“ In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book September 9th 1945 [sic]. Stemming from the first bug, today we call errors or glitch's [sic] in a program a bug.[5] ”

Hopper was not actually the one who found the insect, as she readily acknowledged. And the date was September 9, but in 1947, not 1945.[6][7] The operators who did find it (including William "Bill" Burke, later of the Naval Weapons Laboratory, Dahlgren Va.),[8] were familiar with the engineering term and, amused, kept the insect with the notation "First actual case of bug being found." Hopper loved to recount the story.[9]
ha trovanto un "Bug" la signora "Hopper"?

era una predestinata! :-)))
In un vecchio spettacolo, quel caciarone di Beppe Grillo se la prendeva con la Hopper (arrivando addirittura a chiamarla "quella puttana vecchia"), ritenendola responsabile dell'imminente Millenium Bug, perchè aveva strutturato il COBOL in modo che i campi relativi agli anni nelle date fossero di 2 sole cifre O_o
@USAFREE

Mi sembrava fosse lei!!
Grillo si distingue sempre per la delicatezza dei modi e la profondità dell'analisi.
Consolati: sull'auto a idrogeno, sulle compagnie petrolilfere e sulla nazionale ghanese si era preparato meglio :D
@usa-free:
Ma la lunghezza dei campi non dipende dal tipo di variabile con cui li riempi?

Mai usato COBOL, ma nei primi anni 90 col DOS e il BASIC facevo delle belle cosine :D
@ usa-free

Grillo chi? Quello che ha una causa in corso con un'altra vecchiaccia, la Rita Levi Montalicini?
La Levi Montalcini non mi sembra tipo da farsi passare sotto il naso un'accusa del tipo "Il Nobel te lo ha comprato una casa farmaceutica".
@Mousse

Premetto che non conosco il COBOL e che qualsiasi affermazione andrebbe verificata, specialmente se la fa Beppe Grillo :D

Ma è pur vero che il millenium bug è stato reale, anche se non così catastrofico (anche perchè ci si è mossi per tempo).

Il problema è come un determinato sistema gestisce le date.

Molti vecchi sistemi, tra cui credo anche il COBOL, prevedevano che la variabile "anno" constasse di due sole cifre decimali, questo per risparmiare la (un tempo) preziosa e risicata memoria dei calcolatori.

Tanto le prime 2 cifre sarebbero state sempre "19".

Nessuno si sarebbe aspettato, nel 1959, che un linguaggio di programmazione contemporaneo sarebbe sopravvissuto sino al cambio di secolo.

Ecco perchè la Hopper non è stata nè ingenua nè puttana.

Il problema è che, dato il naturale meccanismo incrementale delle date, il sistema sarebbe passato da 31/12/1999 a 1/1/1900.
Tanto per cominciare col piede giusto, COBOL è l'acronimo di Compiles Only Because Of Luck. :D

In secondo luogo, mi pare disdicevole che nessuno abbia ricordato esplicitamente come, dal punto di vista della teoria dei linguaggi di programmazione e da quello pratico-applicativo, il pur giurassico COBOL rimane enormemente migliore dei vari orribili basic.

Connesso a tale linguaggio c'è infatti un aspetto di robustezza strutturale e mancanza di side effects poi divenuto tipico di molti HLL e ambienti RAD delle generazioni successive, che troppo spesso si dimentica di considerare: negli ambienti standard per i quali COBOL è stato ideato (tipicamente mainframe) è materialmente IMPOSSIBILE che un programmatore possa apportare involontariamente seri danni al sistema scrivendo in COBOL.
Si provi a dire lo stesso di linguaggi che consentono di utilizzare PEEK e POKE, per tacere della libertà quasi assoluta dell'Assembly, seguito a ruota dal C.

Naturalmente il "trascurabile" bug della STOP RUN in ambienti CICS e IMS, la cui esistenza non è invero molto nota, non costituisce un vero controesempio a tale paradigmatica robustezza.

Pur occupandomi da un quarto di secolo di un settore informatico che sta agli antipodi del mondo bancario-finanziario-assicurativo-PA al quale COBOL fa riferimento, non posso non rendere l'onore delle armi ai "colleghi" che, con diuturno sforzo e inappuntabile assiduità, utilizzano e mantengono da mezzo secolo decine di miliardi di LOC in COBOL, con tutta la fantasmagorica costosissima indistruttibile ferraglia che tipicamente si porta dietro.
@Leibniz Reloaded

Io ho una stima simile alla tua per i sistemi AS/400 :D
Brevemente sul FORTRAN: i linguaggi e, in misura minore, certi sistemi non "muoiono" realmente, proprio perché la conversione di montagne di codice legacy è antieconomica e time-consuming.

Tuttavia si deve ammettere che i noti ambienti di calcolo (non faccio nomi: li sappiamo tutti) dotati di linguaggi e interfacce propri, come pure gli stessi C++ e Python o i meno noti APL e J, hanno eroso negli ultimi dieci o quindici anni quote notevoli al bacino d'uso di FORTRAN nel calcolo numerico, in special modo per le nuove applicazioni.

Da qui a sostenere che il linguaggio sia "defunto" c'è comunque un passo notevole, sia ben chiaro. Tuttavia, diciamo che è un po' meno in auge rispetto al passato, soprattutto quando si decide per un nuovo progetto.
Forse un aspetto principale che differenzia i sistemi è l'approccio filosofico di base fra

"di default sei Dio"

e

"di default sei un operatore"

Non facciamo nomi, non facciamo nomi :D
..non è il COBOL a gestire gli anni con solo due cifre nelle date, ma è stata una scelta della maggior parte dei programmatori per risparmiare memoria. bisogna tener conto che fino a qualche anno fa i pc non avevano grandi risorse di ram.
Il Fortran è ancora usatissimo in ambito militare proprio per la mole di linee di codice che girano sui computer dei velivoli e che richiederebbero la ri-certificazione di tutto l'ambiente per poter essere migrate ad altri linguaggi. Inoltre la vita utile di un velivolo costato milirdi di dollari non rende praticabile una migrazione a metà vita utile...
Il problema del 2000 non era dovuto al linguaggio, infatti io che ci ho lavorato parecchio, vi posso dire che era in qualunque programma fatto in qualunque linguaggio, se l'anno veniva inserito in una variabile a 2 cifre il problema si presentava.

ciao
@libero @Alberto

se è come dite voi Grillo ha preso una cantonata.Il che ok non sarebbe una novità.Però mi fa pensare che fra tutti i programmatori uomini che ci sono a preso l'unica donna.
Il cobol un linguaggio da pensionare? Puo' essere, ma non tutti sanno che ne esiste una ben più moderna versione ad oggetti. si chiama ADD 1 TO COBOL GIVING COBOL...

(Ok, questa non è per tutti, e probabilmente chi la capirà vorrà uccidermi) ;-P
Un'altra importante caratteristica del COBOL e' che e' scritto ugualmente male per tutte le piattaforme
mi aggiungo anch'io.. purtroppo il FORTRAN è ben lungi dall'essere estinto. Anzi. In fluidinamica è molto molto molto usato. E a quanto leggo da Wikipedia, anche in numerosi altri campi.
anche lo Smalltalk è vivo e vegeto
Beh... a proposito di ForTran e fluidodinamica io per l'esame di "Tecnica aerospaziale" (ditemi voi che razza di nome per un esame di informatica!!!) avevo preparato giusto giusto in tale linguaggio un programmino che avevo battezzato "PSICOSI" ovvero Profilo Simmetrico Immerso in una Corrente Simulata :-)
Enrico
Errata corrige: SImulata
Enrico
PS ma i post non si possono correggere? Solo cancellare?
Solo cancellare. Bello il nome del programma, sul serio! :)
I miei due cent: ho lavorato per una dozzina di anni in cobol, partendo da programmi che esistevano fors'anche 10 anni prima che io iniziassi a lavorare: a tutt'oggi, sparse per l'Italia, ci sono forse un centinaio di aziende che adopera i programmi della software house (piccola, manco venti dipendenti) in cui lavoravo: dentro quei programmi resistono routine (l'interfaccia grafica esterna è stata più volte cambiata) che datano anche 25 anni. Ed è fondamentalmente questo che spinge ad utilizzare ancora il cobol, non dover riscrivere da zero programmi e strutture dati la cui parte batch è perfettamente funzionante.
***
Per quel che riguarda il discorso date, questi erano semplicementi campi numerici (non di tipo speciale DATE) sui quali si dovevano fare manualmente le operazioni di rovesciamento (le date sono utili "rovesciate" per gli ordinamenti nelle visualizzazioni e stampe), almeno sui cobol che adoperavo io con file di tipo proprietario. Risolvere il "millenium bug" sarebbe stato per noi un discreto lavoro (avevamo anche gli esercizi contabili e di magazzino di 2 cifre e digitando 00, invece di selezionare l'anno 2000, si usciva dal programma in cui si era) visto che sarebbe stato necessario rivedere tutte le maschere video ed i campi di appoggio dei programmi, così ne approfittammo per installare il "nuovo" programma che avevamo, scritto sempre in cobol ma in pratica con i batch della vecchia procedura, e per cambiare macchine vetuste di cui diventava ogni giorno più difficile trovare pezzi di ricambio.
***
Vorrei spezzare una lancia a favore del verboso e semplice cobol: già venti anni fa eravamo multipiattaforma, con sistemi proprietari (Honeywell) e distribuzioni UNIX e DOS. Poi passammo a versioni di cobol grafiche che, volendo, nulla avevano da invidiare al VisualBasic tanto in voga all'epoca. Chiaro che esistono linguaggi più potenti ed efficaci, ma fondamentalmente un gestionale deve funzionare..

Saluti
Riccardo
..beppe grillo di tanto in tanto spara minchiate..deve avere un problema al filtro.. :-))))
Beppe Grillo spara sempre minchiate, e questo offusca di molto le cose sensate e importanti che dice.

E' un caciarone! D'altronde prima faceva solo il comico :)
Non mi e' del tutto chiara l'ultima frase: in pratica lei fu la persona che trovo' l'insetto?
Nel COBOL i campi data non esistono, quindi la dimensione (2 cifre o 4 - PIC 9(4) PIC X(4) ) dipende solo dal programma, non dal linguaggio.
Il COBOL e' il linguaggio piu' implementato ( centinaia di sistemi diversi, e gira anche su linux ).
Qualsiasi linguaggio, viene poi compilato ed eseguito in 'linguaggio macchina' e quindi con 'salti', condizioni, if e quindi con istruzioni in tutto simili al COBOL.
La STRUCT del linguaggio C e' in tutto simile alla struttura dati del COBOL.
Tutti i linguaggi sono uguali, se sei in grado di programmare.
E pensare che la mia entrata professionale nel fantastico mondo dell'informatica è stata con il Cobol. C'ho lavorato per 5 anni fino a quando ho capito di essere una sega e sono diventato sistemista :-)

Ricordo pure il passaggio degli applicativi in ditta dal Cobol Microfocus per Dos al VisualBasic 3 con SQL. Tutti a dire, con SQL il Cobol è morto e questo nel 1995. Ed invece eccolo qui, ben lungi dal puzzare come cadavere.
Vogliamo parlare dell' RPG, sempre in continua evoluzione?
Questo commento è stato eliminato dall'autore.
E' morto il COBOL, viva il COBOL.

Avanti con Don Java Ing. SQL fu Pascal
Il motivo per cui tutt'ora molti istituti bancari, assicurativi, ecc., continuano ad usare il cobol è principalmente economico: la logica di business di molti processi funzionali è scolpita da decenni in milioni di righe di codice scritte con questo linguaggio e una loro sostituzione con strumenti più moderni è sicuramente costosa. Ecco il motivo per cui molte banche preferiscono acquistare framework scritti con linguaggi "moderni" che permettano l'integrazione con i processi scritti in cobol, dando vita a sistemi informatici dove infrastrutture web più o meno complesse continuano a sfruttare componenti scritti anni prima.
Giusto un appunto: il FORTRAN è ancora vivissimo in ambito scientifico ed ingegneristico.

Non so quanto sia vivo ma il mio professore di Antenne lo usa ancora per i software che tracciano i diagrammi di radiazione. Dice che il C proprio gli sta antipatico :D

Io ogni tanto smanetto con LabView che è un linguaggio di programmazione visuale. In sostanza vi costruite le funzioni usando dei blocchi base (p.es. crea array, inverti matrice, ecc.) che collegate con dei fili lungo cui corrono i dati.
Davvero utile se ci si vuole interfacciare con degli strumenti senza bestemmiare troppo.

In ogni caso, la palestra fatta sul C (o qualunque altro linguaggio testuale) è fondamentale in quanto ti plasma una forma mentis necessaria per programmare.
Io so che molte frese CNC usavano il Fortran, ma per quel poco che ne so é possibile che anche quelle piú moderne che hanno per sistema Windows98 or better facciano funzionare i programmi in Fortran.
Quando ho iniziato io (1975) a TS c'era pure una versione strutturata di cobol: STRUBOL. (altro che COBOL++, Reynor...)
Comunque il COBOL ha tutto quel che serve per scrivere programmi strutturati bene.
Per il FORTRAN: resiste grazie alle librerie di calcolo perallelo.
Per il resto: io sto usando xnec2c che è proprio figlio di un port di NEC da Fortran al C (nec -> 2 (to) C)
Per il resto leggete bene quel che diceva nickelworth: senza goto su può fare quassicosa ...anche programmazione spaghetti (aggiunta mia)

Giovanni - che la differenza la fa il programmatore, non il linguaggio
Scusate... ma sono solo io che non ci capisco NULLA di informatica?
@L'economa domestica.
No, non solo tu, anche moltissimi programmatori.
Solo che tu lo sai.

Giovanni - programmare non è importante, importante è vivere.

Ricchi prtemi e cotillon a chi indoviuna la scitazione
Grazie Giovanni, e pensa che le mie IMMENSE doti di utilizzatrice di excel mi fanno passare in ufficio per "Una che ci capisce di informatica".
Il mio livello prima dell'esame di informatica (giugno 2009)? Sapevo ordinare i dati!
Dopo l'esame? Saprei fare i conti in un condominio (maledetti millesimi)!
@L'economa Domestica: il fatto di non saper programmare non significa non si sappia di informatica. Come la medicina esistono molti campi, dalla programmazione alla sistemistica o all'usare le suite d'ufficio. Tanto per dire, conosco piuttosto bene gli Unix, ma di fronte ad excell uso sempre e solo quelle 3/4 funzioni. Percui tranquilla :-)
@usa-free.

Il cosiddetto Millenium bug non e' stato causato dal COBOL ma da chi, per risparmiare due byte disse: usate sei byte invece di otto, e qui parliamo di centinaia di migliaia di analisti e dirigenti del settore informatico.

E questo, unito al passaggio ai leuri, ha portato fra i tardi '90 ed il 2002 all'assunzione di una marea di personale per risolvere il problema MB ed il problema leuro.

Gente spesso senza esperienza informatica, realmente rubata all'agricoltura estensiva.

Poi, nel 2003-4, finita "l'emergenza", e' cominciata la crisi del settore informatico. E mi sono trovato disoccupato anche io.

@dadone

sono decenni che il firmware/software dei sistemi di avionica sono scritti in ADA.
Mi assoccio a chi ha detto che il fortran è ancora vivissimo e continuamente aggiornato.
Il fatto che però si utilizzino cose e concetti vecchi dipende da:
- a volte i concetti vecchi sono estremamente validi
- a volte i concetti nuovi sono migliori ma la gente è così pigra (a volte pure i costi ci si mettono in mezzo) che non ha proprio voglia di mettercisi

Ad ogni modo non solo il cobol ma è proprio la programmazione strutturata ad essere "sorpassata"

Buon compleanno cobol!!!
A proposito, un altro concetto che Santa Grace ha inventato e' stato quello del compilatore, perche' diceva che cosi' i matematici avrebbero potuto tornare a fare i matematici, senza perdere tempo a programmare manualmente i computer.

Si', certo...
Una cosa è certa, con COBOL dovevi sapere come disegnare BENE le basi di dati perché allora non c'era un motore SQL che ti risolve una query tra tabelle in un database progettato da cani, a scapito dell'efficienza (tanto i server sono potenti e velocissimi).Chi scrive è un programmatore COBOL e C++/C# da 25 anni.Alcuni commentatori dovrebbero imparare a scrivere meglio in italiano prima ancora che in C/VB/Java/ecc..
@ Barco
non è che senza cobol la buona programmazione sia roba superata. Sicuramente con strumenti meno potenti bisogna ingegnarsi molto di più ed essere molto sicuri di quello che si vuole fare. Mi è capitato di vedere codici scritti da "cani" sia in c++ sia in fortran; la differenza la fa il programmatore e, a volte, il tempo a disposizione.
Ciò non toglie che ci siano delle cose che hanno già avuto il loro momento di gloria.
Nessuno vorrebbe più andare con una ford t ma di sicuro fu una grande innovazione ...
Che il Cobol sarebbe morto lo si diceva davvero un sacco di anni fa.
Chi dice che un buon linguaggio deve essere strutturato e procedurale e afferma che il Cobol non lo sia, o non lo conosce o non ho capito cosa stia dicendo.

Vero è che ci sono miliardi di righe di codice scritte in cobol ma sarebbe come minimo non economico riscriverle, senza contare i rischi insiti in questo processo.
Inoltre i fatti dimostrano quanto sia problematica la gestione delle versioni, la sicurezza dell'arhitettura e in alcuni ambiti le performance dei sistemi scritti con linguaggi di nuova generazione
Ben vemgano ci mancherebbe, però ogni linguaggio ha il suo terreno ideale d'azione. Ho visto dei java batch arrancare pietosamente (ma anche migliorar discretamente se ottimizzati) e certo non possiamo gestire il click di un mouse con il cobol. Se l'architettura scelta prevede centralizzazione dei dati su mainframe, logiche di calcolo su mainframe (in cobol) e magari utilizzo di xml per il dialogo con il front-end (xml in cobol), direi che si possa tranquillamente pensare di festeggiare anche i 60 anni...Infine, seoondo me è sterile fare a gara a dire qual'è il linguaggio migliore.
Cosa interessante invece, oggi, è vedere quali previsioni furono totalmente errate, non solo doveva morire il cobol ma anche i sistemi host mainframe...
In COBOL ho imparato a programmare. Ho poi lavorato pochissimo con quel linguaggio, essendo passato quasi subito alla programmazione a oggetti. Però il primo linguaggio non si scorda mai... :)
il problema cobol/fortran e' un problema endemico dell'informatica - scienza in continua evoluzione - che si scontra con logiche di business, logiche economiche e di tempo.
Detta in breve: perche' cambiare un software che funziona per uno nuovo che potrebbe non funzionare o - peggio ancora - non funzionare solo in casi speciali.

A questo aggiungiamo ignoranti, commerciali abili quanto truffaldini ed ecco una splendida panoramica di cosa succede.

Cobol e Fortran resisteranno ancora per tanto tempo, ma la colpa non e' dei loro creatori ma piu' di chi ha basato tutta la sua infrastruttura su questi.. banche e eserciti giusto per citarne due di piccolini
Ho sistemato le varie inesattezze, grazie a tutti!
Ma è vero che la (bellissima IMHO) massima: "It's easier to ask forgiveness than it is to get permission" è di Grace Hopper?
Smalltalk morto??

European Smalltalk User Group, la conferenza del 2007 era a Lugano
http://www.esug.org/Conferences/2007

Azienda 100% Smalltalk a bioggio
http://www.lifeware.ch/

giusto per citare 2 esempi nel raggio di 3 km da casa tua...
Bridge,

grazie per le segnalazioni, ma bisogna vedere se queste due realtà locali sono significative rispetto alla diffusione mondiale di altri linguaggi.
@Paolo: beh chiaramente se facciamo il paragone tra linguaggi "specializzati" come Smalltalk, APL, COBOL e tanti altri che si usano per applicazioni particolari (bancarie, ad esempio) ed i più noti e blasonati C, PHP, Java o cheneso, questi ultimi sono "più diffusi". Ma forse sono più diffusi proprio per la loro natura maggiormente "generica"..