O COBOL foi um dos primeiros idiomas que aprendi - se você ignorar inúmeras versões do Basic, três ou quatro idiomas assembler e uma variante do Forth, foi nos meus cinco primeiros e aprendeu simultaneamente com o Pascal. Estou respondendo por experiência pessoal usando o idioma.
EDIT Devo dizer experiência antiga . Eu nunca usei o idioma depois do final dos anos 80, embora tenha comprado um livro novo (para substituir o antigo que joguei fora com nojo), para que eu tivesse algo a que me referir, para que minhas histórias de horror não fiquem muito distorcidas. Mas não tenho ideia de como a linguagem evoluiu nos últimos 20 anos.
Obviamente, para muitas pessoas, é exatamente essa visão "velha e ruim" que a jonsca já descreveu - e também muito mais uma coisa de atitudes passadas em terceira mão. Mas existem questões reais subjacentes a isso.
Ser muito prolixo é um problema real - há muita confusão na maneira de entender o código. Este é de longe o maior problema. Pessoas que olham para o MOVE, ADDe MULTIPLYetc declarações em horror tem uma visão um pouco exagerada a isso, é verdade - a COMPUTEdeclaração é mais perto das atribuições em outros idiomas. Mas ainda há muita confusão em todas essas divisões e seções. Uma das primeiras coisas que aprendi no COBOL foi sempre começar copiando um SKELETON.COB de página A4 padrão.
COBOL faz tem algumas características interessantes, mas essas características (por exemplo, a PICcoisa) tendem a ser coisas que são agora mais parte dos DBMS, em vez da linguagem de programação, e que me parece geralmente ser a melhor maneira de separar essas responsabilidades. Além disso, algumas bibliotecas em outros idiomas usam algo comparável a PIC(por exemplo, printf e scanf na biblioteca padrão C). Indiscutivelmente, o melhor foi mantido, mas o pior caiu.
Além disso, para cada recurso interessante, havia pelo menos um intolerável. Por exemplo, não importa o quão trivial seja um loop, você deve mover o corpo para um procedimento separado. As PERFORM ... UNTIL ...declarações e similares são declarações únicas - não estruturas de bloco. Em certo sentido, COBOL foi um gosto de programação estruturada de diante programação estruturada foi inventado - não era um GO TO, mas de uso foi desencorajado (pelo menos quando eu usei COBOL), mas looping em particular apenas não foi tratado muito bem.
De fato, a linguagem que usei após o COBOL que mais me lembrou foi o ... dBase. Como no Ashton-Tate dBase III +. Atualmente, é mais provável que as pessoas se lembrem de todos os clones que estão morrendo ou morrendo (Clipper, FoxPro etc.) que levaram ao nome genérico xBase - e ainda há um descendente vivo no xHarbour. O ponto é que essas eram linguagens de banco de dados, mas nada como SQL.
Mesmo assim, onde todo programa COBOL que opera em um banco de dados específico precisa incluir uma cópia da especificação desse banco de dados (e as cópias podem acabar inconsistentes), esse não é realmente o caso do xBase em que o banco de dados conhece sua própria estrutura.
Levando isso em consideração, então, o COBOL não é tão terrível se você o aceita pelo que é. Mas o que não é é uma linguagem para escrever estruturas de dados. É por isso que o COBOL sofreu muito nos tempos das guerras santas C vs. Pascal - os dois lados concordaram que o COBOL não era bom para reinventar a árvore binária mais uma vez.
Ah - e uma coisa que nunca esquecerei é como meu primeiro livro COBOL não descreveu o SORTcomando, dizendo que estava fora do escopo do livro - aparentemente, ou o autor não conseguiu lidar com a ideia de classificar ou considerou que era mais do que as pequenas mentes dos alunos da COBOL poderiam lidar [ver editar no final]. Esse tipo de coisa tornou muito difícil levar o COBOL a sério.
Um aspecto estranho disso foi a Programação Estruturada de Jackson, que eu também fui forçada a aprender na mesma época e especificamente para uso com o COBOL. Parte disso foi desenhar um diagrama de estrutura para a entrada, depois um diagrama de estrutura para a saída e, em seguida, desenhar o diagrama de estrutura intermediário para o código. A classificação era claramente um problema já resolvido - não era possível derivar um algoritmo de classificação dessa maneira. Portanto, era estranho que o livro de texto recomendado dissesse que todo o conceito de classificação estava além da minha mente minúscula, enquanto ao mesmo tempo aprendiam algo como uma dúzia de algoritmos de classificação diferentes e como implementá-los em Pascal.
Os problemas que o JSP pode lidar são provavelmente um bom guia para as coisas que o COBOL pode fazer relativamente bem. Mas, mesmo assim, isso não significa necessariamente que JSP ou COBOL são boas maneiras de lidar com esses problemas.
EDIT em 30 de julho de 2014
Acabei de ganhar uma reputação com isso, lembrando que está aqui. Por acaso, devido a uma coleção de livros antigos alimentada pela nostalgia, agora posso corrigir um ponto do SORTcomando WRT .
O livro que originalmente usei como texto recomendado ao aprender COBOL foi "Programação Metódica em COBOL", de Ray Welland. Isso não cobre o COBOL 85 (embora houvesse uma edição posterior "Programação Metódica no COBOL-85", que eu nunca vi).
kindall comenta abaixo que "Você deveria classificar os arquivos de entrada antes de lê-los ou classificar o arquivo de saída após gerá-lo, usando o utilitário de classificação que acompanha o sistema operacional". Da minha resposta, perdi o ponto "veio com o SO". Kindall estava sugerindo algo semelhante à filosofia AFAICT do Unix, com COBOL usado para os bits para os quais é bom, utilitários de SO, como um utilitário de classificação usado para outras coisas, e presumivelmente usando uma linguagem de lote / script / shell para colar os bits. Isso faz muito mais sentido em um mundo antigo, onde o software interativo era raro ou inexistente; portanto, você estaria enviando lotes de trabalho (daí a "linguagem do lote") de qualquer maneira.
O seguinte é citado na página 165-166 de "Programação Metódica no COBOL" ...
O uso de arquivos seriais ordenados implica que é necessário ter um meio de classificar registros dentro de um arquivo em alguma ordem especificada por chave. A maioria dos sistemas de computadores maiores possui um utilitário de classificação que classifica um arquivo de acordo com a posição, tipo e tamanho de cada um dos itens de dados que formam a chave.
Há também um recurso para classificar registros de dentro de um programa COBOL, mas isso está além do escopo deste livro por dois motivos:
(a) a interface para o sistema operacional geralmente é bastante complexa e varia de sistema para sistema,
(b) o módulo de classificação é uma parte opcional do ANS '74 COBOL e não pode ser implementado em sistemas COBOL para computadores menores.
Portanto, será assumido que existem recursos para classificar os arquivos em uma ordem especificada e o problema de atualizar esses arquivos será considerado.
Em resumo, kindall está correto - a suposição era de que geralmente a classificação seria feita fora do COBOL. Pode até haver uma justificativa real para excluir a classificação de uma linguagem de programação por volta de 1974 para computadores pequenos.
O que eu disse acima foi basicamente o que você obtém após cerca de 20 anos de não poder verificar fatos devido a jogar fora o livro.
Devo ainda salientar, no entanto, que estudei formalmente o COBOL a partir deste livro recomendado que cobria o padrão de 1974 (não o padrão de 1985) em 1988 e 1989. A terceira edição do "COBOL for Students" (Parkin, Yorke, Barnes) - a primeira edição que cobre o COBOL 85 - não foi publicada até 1990. Não tenho certeza, mas acho que a edição do COBOL 85 de "Programação Metódica" não foi publicada até 1994.
Mas isso não representa necessariamente o mundo da COBOL se arrastando - bem, não tanto assim. A adoção de novos padrões leva tempo para qualquer idioma, mesmo agora.