COBOL è stata una delle prime lingue che ho imparato - se ignori innumerevoli versioni di Basic, tre o quattro lingue assembler e una variante di Forth, allora era tra le mie prime cinque e imparavo in concomitanza con Pascal. IOW, sto rispondendo per esperienza personale usando la lingua.
EDIT Dovrei dire esperienza antica . Non ho mai usato la lingua dopo la fine degli anni '80, anche se ho comprato un nuovo libro (per sostituire quello vecchio che ho gettato via con disgusto) in modo da avere qualcosa a cui fare riferimento in modo che le mie storie dell'orrore non fossero troppo distorte. Ma non ho idea di come la lingua si sia evoluta negli ultimi 20 anni.
Ovviamente, per molte persone, è solo quella visione del "vecchio è cattivo" che jonsca ha già descritto - e anche molto di più una cosa di terza mano per gli atteggiamenti pass-down. Ma ci sono problemi reali alla base di ciò.
Essere troppo prolisso è un vero problema - c'è troppa confusione nel modo di comprendere il codice. Questo è di gran lunga il problema più grande. Le persone che guardano il MOVE, ADDe MULTIPLYle dichiarazioni ecc in orrore hanno una visione un po 'esagerata di questo, vero - l' COMPUTEaffermazione è più vicino alle assegnazioni in altre lingue. Ma c'è ancora molto disordine in tutte quelle divisioni e sezioni. Una delle prime cose che ho imparato in COBOL è stata quella di iniziare sempre copiando una pagina standard di SKELETON.COB lunga A4.
COBOL ha alcune caratteristiche interessanti, ma quelle caratteristiche (ad esempio, la PICcosa) tendono ad essere le cose che sono ora più parte dei DBMS, piuttosto che il linguaggio di programmazione, e che mi sembra di solito essere un modo migliore per separare tali responsabilità. Inoltre, alcune librerie in altre lingue usano qualcosa di paragonabile a PIC(ad esempio printf e scanf nella libreria standard C). Probabilmente, il meglio è stato mantenuto, ma il peggio è caduto.
Inoltre, per ogni bella caratteristica, ce n'era almeno una intollerabile. Ad esempio, non importa quanto un loop sia banale, devi spostare il corpo in una procedura separata. Le PERFORM ... UNTIL ...dichiarazioni e simili sono dichiarazioni singole, non strutture a blocchi. In un certo senso, COBOL è stato un assaggio della programmazione strutturata da prima programmazione strutturata è stato inventato - c'è stato un GO TO, ma il suo impiego è stato scoraggiato (almeno quando ho usato COBOL), ma il ciclo, in particolare, proprio non era gestito molto bene.
In effetti, il linguaggio che ho usato dopo COBOL che mi ha ricordato di più era ... dBase. Come in Ashton-Tate dBase III +. In questi giorni, le persone hanno maggiori probabilità di ricordare tutti i cloni ora morti o morenti (Clipper, FoxPro ecc.) Che hanno portato al nome generico xBase - e c'è ancora un discendente vivente in xHarbour. Il punto è che questi erano linguaggi di database, ma niente come SQL.
Anche allora, dove ogni programma COBOL che opera su un particolare database deve includere una copia delle specifiche di quel database (e le copie potrebbero risultare incoerenti), non è proprio il caso di xBase in cui il database conosce la propria struttura.
Tenendo conto di ciò, quindi, COBOL non è così terribile se lo accetti per quello che è. Ma ciò che non è è un linguaggio per scrivere strutture di dati. Il che potrebbe essere il motivo per cui COBOL ha sofferto molto ai tempi delle guerre sante C vs Pascal - entrambe le parti potevano concordare sul fatto che COBOL non era utile per reinventare nuovamente l'albero binario.
Oh - e una cosa che non dimenticherò mai è come il mio primo libro di testo COBOL non descrisse il SORTcomando, dicendo che era al di fuori dello scopo del libro - apparentemente, o l'autore non poteva far fronte all'idea di smistamento, o lo considerava più di quello che le piccole menti degli studenti COBOL potevano affrontare [vedi modifica alla fine]. Questo genere di cose ha reso molto difficile prendere sul serio COBOL.
Un aspetto strano di questo è stato Jackson Structured Programming, che sono stato costretto a imparare nello stesso momento e in particolare per l'uso con COBOL. Parte di questo era disegnare un diagramma di struttura per l'input, quindi un diagramma di struttura per l'output, quindi disegnare il diagramma di struttura intermedio per il codice. Si prevedeva chiaramente che l'ordinamento rappresentava un problema già risolto: in questo modo non si poteva derivare un algoritmo di ordinamento. Quindi era strano dire dal libro di testo raccomandato che l'intero concetto di smistamento andava oltre la mia piccola piccola mente, mentre allo stesso tempo veniva insegnato qualcosa come una dozzina di algoritmi di smistamento diversi e come implementarli in Pascal.
I problemi che JSP può gestire sono probabilmente una buona guida per le cose che COBOL può fare relativamente bene. Ma anche allora, ciò non significa necessariamente che sia JSP che COBOL siano buoni modi per gestire questi problemi.
EDIT il 30 luglio 2014
Ho appena ricevuto un impulso di reputazione da questo, ricordandomi che è qui. Come succede, a causa della raccolta di libri antichi alimentati dalla nostalgia, ora posso correggere un punto WRT il SORTcomando.
Il libro che ho usato originariamente come testo raccomandato durante l'apprendimento di COBOL era "Programmazione metodica in COBOL" di Ray Welland. Questo non riguarda COBOL 85 (sebbene ci sia stata un'edizione successiva "Programmazione metodica in COBOL-85" che non ho ancora visto).
di seguito alcuni commenti che "Avresti dovuto ordinare i file di input prima di leggerli o ordinare il file di output dopo averlo generato, utilizzando l'utilità di ordinamento fornita con il sistema operativo". Dalla mia risposta, mi mancava il punto "arrivato con il sistema operativo". Kindall stava suggerendo qualcosa di simile alla filosofia Unix AFAICT, con COBOL usato per i bit per cui è buono, utilità del sistema operativo come un'utilità di ordinamento utilizzata per alcune altre cose e presumibilmente usando un linguaggio batch / scripting / shell per incollare i bit insieme. Ciò ha molto più senso in un mondo antico in cui i software interattivi erano rari o inesistenti, quindi invieresti comunque lotti di lavoro (quindi "linguaggio batch").
Quanto segue è citato da pagina 165-166 di "Programmazione metodica in COBOL" ...
L'uso dei file seriali ordinati implica che è necessario disporre di un mezzo per ordinare i record all'interno di un file in un ordine specificato in base alla chiave. La maggior parte dei sistemi di computer più grandi ha un'utilità di ordinamento che ordinerà un file in base alla posizione, al tipo e alla dimensione di ciascuno degli elementi di dati che formano la chiave.
C'è anche una possibilità per ordinare i record all'interno di un programma COBOL ma questo va oltre lo scopo di questo libro per due motivi:
a) l'interfaccia con il sistema operativo è spesso piuttosto complessa e varia da sistema a sistema,
(b) il modulo di ordinamento è una parte facoltativa di ANS '74 COBOL e non può essere implementato nei sistemi COBOL per computer più piccoli.
Pertanto si supporrà che esistano strutture per l'ordinamento dei file in un ordine specificato e verrà preso in considerazione il problema dell'aggiornamento di tali file.
In breve, kindall è corretto - il presupposto era che di solito l'ordinamento sarebbe stato fatto al di fuori di COBOL. Potrebbe esserci stata una vera giustificazione per escludere l'ordinamento da un linguaggio di programmazione intorno al 1974 per i piccoli computer.
Quello che ho detto sopra era fondamentalmente quello che ottieni dopo circa 20 anni di non essere in grado di controllare i fatti a causa del buttare via il libro.
Devo comunque sottolineare che ho studiato formalmente COBOL da questo libro raccomandato che copriva lo standard del 1974 (non lo standard del 1985) nel 1988 e nel 1989. La terza edizione di "COBOL for Students" (Parkin, Yorke, Barnes) - la prima edizione di COBOL 85 - non è stata pubblicata fino al 1990. Non ne sono certa, ma penso che l'edizione COBOL 85 di "Metodologia di programmazione" non sia stata pubblicata fino al 1994.
Ma ciò non rappresenta necessariamente il mondo COBOL che trascina i suoi piedi - beh, comunque non molto. L'adozione di nuovi standard richiede tempo per qualsiasi lingua, anche ora.