Por que o desprezo por COBOL? [fechadas]

Quando as pessoas mencionam COBOL, geralmente elas encontram um bufo ou um gemido. Não sei muito sobre o COBOL, mas já vi alguns programas escritos nele. Eu posso ver que é prolixo, e para olhos não iniciados como os meus, ininteligível. Mas, realmente, não são todas as linguagens de programação completas para um leigo?

Entendo que funciona, funciona bem e ainda é amplamente utilizado nas indústrias para as quais foi projetado. Não são essas as características de uma boa linguagem? O que há de tão ruim no COBOL?

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.

Tendo passado a maior parte do dia escrevendo alguns COBOL, acho que posso dar alguma contribuição atual.

Primeiro as coisas ruins: -

• Nenhuma chamada de função. O COBOL moderno possui algumas funções integradas, mas é um trabalho sério de engenharia escrever o seu próprio.
• Nenhuma verificação de tipo nas chamadas de sub-rotina. Você pode passar (ou não passar) qualquer coisa em uma chamada de sub-rotina, a sub-rotina chamada assumirá alegremente que possui os parâmetros corretos e, não há como detectar parâmetros ausentes ou inválidos.
• Sem bibliotecas. Nenhum zero zilch. Nenhuma biblioteca padrão, nenhuma biblioteca facilmente disponível amplamente utilizada. Você acaba codificando tarefas comuns no local de trabalho repetidamente.
• Tudo é implementado como uma palavra-chave. Como os autores da linguagem não têm o conceito de biblioteca, todos os novos recursos acabam sendo implementados com novas palavras-chave, por exemplo, suporte a PARSE e RENDER for XML.

Os incompreendidos, ou seja, aquelas críticas comumente levantadas contra a querida linguagem antiga, que são inválidas ou irrelevantes.

• Verbosidade. Então você digita alguns caracteres extras! Não é um problema sério. Em muitos casos, o COBOL é menos detalhado do que o Java.

• "ARQUIVOS DE COBOL" Você vê esse termo muito polêmico. Não existe tal coisa que o COBOL pode lidar com praticamente qualquer formato de arquivo e qualquer organização de arquivos.

• Sem multi-threading. Nos ambientes em que o COBOL prospera, o multi-threading geralmente é deixado para contêineres de aplicativos como CICS ou IMS, que são bons nisso, em vez de programadores que tendem a ser ruins.

E as coisas boas - alguns aspectos do COBOL são superiores a outros idiomas: -

• Estruturas de dados. COBOL possui uma sintaxe concisa e flexível para definir estruturas de dados complexas e tipos de dados ímpares.
• Aritmética decimal. Possui suporte nativo para aritmética decimal, isto é, aritmética, conforme entendido pelos contadores, com arredondamento adequado etc.
• Movendo-se com o Times. Alguns aspectos do COBOL são surpreendentemente modernos. Suporte XML integrado, suporte à programação OO, capacidade de usar classes Java etc.
• Integração com DB2, CICS etc. Isso se aplica apenas ao mainframe COBOL da IBM (mas esse é de longe o maior pedaço de COBOL ainda em execução), mas a integração com DB2, CICS e outros ambientes de mainframe facilita a codificação de coisas como backup de banco de dados serviços da web do que em qualquer outro ambiente.
• Manuseio de tela. O manuseio de tela padrão implementado no AS / 400 e no MicroFocus Cobol é excelente.
• Atuação. Por muitos anos, os compiladores COBOL produzem executáveis ​​de alto desempenho. Somente C nativo e Assembler nativo venceram COBOL em um mainframe IBM.

Então, apesar de tudo, está indo muito bem para algo que foi criado por um comitê na década de 1950. Se um aplicativo existente for implementado no COBOL e executar o trabalho, não há motivo para reescrevê-lo. No entanto, a menos que haja uma boa razão, não vejo justificativa para novos projetos usarem o COBOL.

Provavelmente isso se deve a Djikstra. Djikstra afirmou que "o uso de COBOL prejudica a mente; seu ensino deve, portanto, ser considerado uma ofensa criminal". Cobol era visto como ingênuo, desestruturado e detalhado. Com a capacidade de alterar o código automaticamente (uma prática desencorajada mesmo entre os programadores da cobol), era visto como bastante difícil de depurar ou seguir também.

Há também a questão da grande incompatibilidade entre as versões.

Eu sugeriria a leitura da seção de crítica e defesa na Wikipedia para o idioma - http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

É idade e verbosidade são tipicamente as coisas que fazem as pessoas gemerem sobre isso.

Lembro-me de que o principal objetivo da IBM ao projetar o COBOL era que "deveria permitir que um gerente de banco escrevesse um programa". Obviamente, esse objetivo teve um efeito profundo na maneira como a linguagem foi projetada e agora evoluiu.

Aparentemente, há mais COBOL na natureza do que em qualquer outro idioma. No entanto, depois de trabalhar em TI por quase 20 anos (15 no setor bancário), nunca encontrei um único sistema implementado nele.

O que há de tão ruim no COBOL?

Nada.

Eu acho que as pessoas têm uma noção preconcebida de que o velho é ruim, "o mais novo é o melhor". Ainda está em uso, e tenho certeza de que haverá trabalho de manutenção suficiente no código para mais um meio século.

Em 1997, o Grupo Gartner relatou que 80% dos negócios mundiais rodavam em COBOL com mais de 200 bilhões de linhas de código existentes e com uma estimativa de 5 bilhões de linhas de novo código anualmente. (via wikipedia )

Na codificação, é preciso sempre selecionar a melhor ferramenta para o trabalho e, com certos setores que são casados ​​com determinado hardware, a linguagem é ótima. Nunca trabalhei no setor bancário, onde ouvi dizer que era popular, mas a resposta de Sean indica que esse não é o caso.

Se houver um problema com o código legado parecer antigo, contanto que você possa colocar uma interface do usuário ou uma interface da Web na frente dele, a maioria dos usuários nem saberá a diferença.

As pessoas não gostam do COBOL porque ele tem aplicação limitada. Foi projetado para sistemas comerciais, financeiros e administrativos para empresas e governos.

O que todos estes têm em comum? Dados. Muitos e muitos dados.

Adivinha quem foi projetado para processar dados e ter muitos arquivos no café da manhã? Você pode dizer COmmon Business-Oriented Language ?

Há 50 anos, o COBOL era a melhor coisa para grandes organizações com muitos dados para gerenciar. Hoje existem maneiras melhores de gerenciar um grande volume de dados, para que o COBOL não seja mais relevante. Ou é?

Vamos considerar governos. Quais dados o governo precisa rastrear? IDs de pessoas, certidões de nascimento, registros médicos, impostos (oh ... sim ... impostos) etc. etc. E eles devem manter essas informações indefinidamente, hoje e há 50 anos também.

As pessoas também mencionaram bancos em algumas das respostas e, de fato, os bancos são usuários pesados ​​do COBOL. Por quê? porque, diferentemente de outros tipos de empresas, os bancos geralmente têm um histórico. Alguns existem por centenas de anos ( como este, por exemplo ).

Isso significa que alguns dados de 50 anos ainda devem estar aqui conosco, hoje, 7 de outubro de 2011. Agora temos SQL Server e C # ou Oracle e Java, mas há 50 anos havia COBOL e arquivos.

Com o passar do tempo, os dados para governos e bancos aumentaram cada vez mais e ficou cada vez mais caro migrar os sistemas. O que significa que eles devem permanecer no COBOL e ser constantemente mantidos e evoluídos à medida que os negócios evoluem. Alguns bancos estão migrando lentamente, enquanto outros apenas colocam uma interface Web2.0 agradável na frente do mainframe (c # e Java são os mais usados). Você pode dizer código legado? (COBOL anda de mãos dadas com o código legado (extremo), alguns que foram tocados por muitas pessoas ao longo de décadas de existência - outra coisa que os programadores não gostam: D).

E agora você tem um nicho de atividade. O COBOL agora tem aplicativos limitados e sua experiência é afetada .

E as pessoas que entram no COBOL acabam descobrindo que você faz a mesma coisa repetidas vezes, ano após ano após ano, e quando acordam, não são mais competitivas no mercado porque agora as pessoas querem PHP, Java, C # , REST, jQuery e apenas bancos procuram pessoas COBOL.

Nesse ponto, a demanda é menor que a oferta e quem não faz o corte deve passar para outra coisa. E eles devem começar como juniores, já que o COBOL realmente prejudica a mente (acredite que não copiar e colar é o principal estilo de desenvolvimento do COBOL e é responsável por sua grande produtividade) e agora eles amaldiçoam o dia em que pegaram o COBOL e não Não perca nenhuma ocasião para contar suas histórias de horror sobre isso :). Mas você pode contar essas histórias sobre qualquer linguagem antiga de peido que não esteja mais em demanda atualmente, mas você é a pessoa infeliz que está presa a ela. O bem ...

PS e COBOL é ruim por todos os outros motivos mencionados pelos outros :)

PS2. In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.Realmente? E como o dia mediu isso? Eles foram fazer todas as empresas da palavra e perguntaram quantas linhas de COBOL elas tinham ou o que?

Dois recursos.

• A declaração ALTER é pura maldade. Embora raramente usado em aplicativos COBOL mais modernos, era muito usado nos "tempos antigos" porque era mais eficiente que a estrutura equivalente "IF-GOTO". Quando os computadores tinham apenas 32K de RAM, cada instrução era importante. Ele modificou uma instrução GOTO para ter um destino diferente.

  Isso tornou alguns códigos opacos porque o próprio código era com estado.

• A cláusula REDEFINES em uma estrutura de dados (como unionem C) é um problema perpétuo. O termo "união livre" - isto é, estruturas de dados sobrepostas sem um discriminador - é uma maneira de resumir o problema. Dois aliases REDEFINES não podem ser trivialmente distinguidos pelos dados; somente uma leitura extensa da lógica do programa poderia determinar o significado das duas interpretações alternativas dos bytes.

  Isso tornou muitas estruturas de dados opacas porque os dados não podem ser entendidos sem o código.

A legibilidade da sintaxe do tipo inglês foi derrotada por essas duas construções.

[Os moderadores foram avisados ​​de que respostas curtas desconsideram sua pergunta importante e interessante. Se você achar isso desdenhoso, poderá pedir detalhes. Ou sinalize para que os moderadores possam excluí-lo.]

Programei em COBOL por vários bons anos. Sua sintaxe é simples em comparação com os idiomas atuais e você não precisa de muita teoria para aprender a seguir em frente. O COBOL funcionou muito bem com o CICS da IBM (um sistema de gerenciamento de transações on-line) e o programador precisa fazer anotações no código para dimensionar o número de aplicativos de usuários de 1 a vários milhares. O CICS forneceu uma GUI baseada em caracteres que funcionava com uma tela como uma unidade de exibição (sem janelas). Você pode exibir gráficos usando (GDDM da IBM) no mainframe. O COBOL pode conversar com arquivos indexados (VSAM e ISAM), bem como com o DB2 (relacional baseado em SQL) e também com o IMS. O COBOL / CICS é um ambiente muito robusto e você pode aprendê-lo em poucas semanas. Isso significa que você se concentra nos negócios e não na tecnologia; portanto, você trabalha 7 das 8 horas em codificação e não aprende MVM, JavaScript e similares.

O problema do COBOL é o marketing ruim que leva à falta de interesse de terceiros em desenvolver ferramentas e ambientes de programação para ele. Além disso, sua falta de suporte à interface semelhante ao Windows causou um declínio na popularidade após 1993. O custo do mainframe levou os clientes a procurar alternativas e compiladores para COBOL estavam disponíveis no UNIX e no DOS. A linguagem C atraiu muita luz, pois era mais portátil e tinha acesso direto às funções do sistema operacional, algo que COBOL tinha muito pouco.

Idiomas como VB, DBase, FoxPro e Clipper tinham melhores maneiras de acessar 'bancos de dados' no PC do que o COBOL comparável no DOS, então o COBOL perdeu. O CICS não ficou barato no DOS ou UNIX por um longo tempo, portanto, seu valor não estava presente nesses ambientes.

Hoje, o COBOL é suportado pelo .NET, mas acho que ele perdeu a batalha em todas as plataformas, exceto no mainframe (e possivelmente no AS / 400), onde ainda existe por causa do grande número de aplicativos de missão crítica totalmente dependentes de isto.

Heh, eu fui para a faculdade no início dos anos 80, e as pessoas desprezavam o COBOL naquela época. Eu acho que o maior problema é a sua verbosidade - um simples "Olá, mundo!" em COBOL é provavelmente mais de cinquenta linhas, 95% das quais são necessárias. Não é apenas uma linguagem muito elegante ou atraente. Ele também foi projetado para lidar com os problemas de ontem e não se presta a paradigmas de desenvolvimento desenvolvidos depois de 1970. É uma linguagem muito boa para geração de relatórios - desde que seus relatórios sejam infinitas colunas de números com cabeçalhos e rodapés. Se você quiser colocar um gráfico ou um logotipo em algum lugar, esqueça. Acho que ainda é o idioma mais rápido para tarefas do tipo "processamento de dados" (pegue um arquivo de formato fixo com transações ATM de 5 milhões de dólares e faça um simples ajuste de saldo para cada um), mas quantos desenvolvedores fazem mais esse tipo de coisa? E muitos sistemas usam XML ou JSON hoje em dia, eu odiaria pensar em tentar analisar algo assim com COBOL (na verdade, eu odiaria pensar em analisar em geral em COBOL!)