Por que o desprezo por COBOL? [fechadas]


52

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?


8
O COBOL é bom para manipular bancos de dados hierárquicos ou arquivos simples e enviar dados para grandes relatórios somente de texto em uma impressora matricial gigante. Hoje em dia, a maioria dos dados está em RDBMSs e a maioria dos gerentes gosta de relatórios bonitos. COBOL simplesmente não lida com isso tão bem.
Pdr7

11
@ Steve314: Sim! Essa! Exceto que os nossos eram Line Matrix, e eu não tinha tomado café hoje de manhã quando escrevi isso. - en.wikipedia.org/wiki/Line_matrix_printer
pdr

3
Sem destacar o COBOL, se você pesquisar um pouco, acho que notará que muitas linguagens específicas de domínio não são muito populares aqui (para dizer o mínimo); COBOL, Fortran, VB6, MATLAB ... todas muito boas linguagens, apenas não boas para o ensino de ciências da computação e suas abstrações.
Rook

4
@Rook - todos realmente contam como idiomas específicos do domínio? Até o MATLAB, IIRC, ainda é capaz de programação de uso geral. Eu pensei que o DSL se aplicava principalmente a coisas como yacc, lex etc. - idiomas que são realmente capazes de uma tarefa bastante estreita, levando ao outro nome comum "little languages". Nunca me ocorreu que COBOL, Fortran ou VB pudessem ser chamados de domínio específico. É claro que cada um deles costuma ser usado em campos específicos, mas eu pensei que eles ainda eram considerados linguagens de uso geral.
precisa saber é o seguinte

11
@ Steve314 - Sim, bem - podemos dizer que existem dois lados. Diz-se o dom.spec. uns são apenas aqueles que você mencionou, o outro tem uma visão mais geral e conta também na que mencionei, mantendo-os na categoria de uso geral. Mas praticamente, onde quer que você mencione engenharia e ciência. comp. você receberá Fortran ou MATLAB, empresa ... COBOL ... usará a terminologia que lhe parecer mais lógica. Eu uso este porque acho que ele se encaixa com a maioria das pessoas. De qualquer forma, eles recebem uma boa parte de críticas por algum motivo da comunidade cs em geral.
Rook

Respostas:


68

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.


5
+1 por realmente saber do que você está falando. Gostaria de poder lhe dar mais um +1 para JSP. Você já usou o "Delta"? Era um gerador Cobol, de forma que você podia escrever seu JSP no código, em um estilo semelhante às definições de memória (01 - 03 - 05) e depois escrever seu Cobol nas lacunas. Divertido e frustrante como o inferno.
Pdr7

3
Página da Wikipedia em JSP - en.wikipedia.org/wiki/Jackson_Structured_Programming . Quando eu aprendi, tudo foi feito no papel.
Steve314

11
A razão pela qual a classificação foi tratada como um problema resolvido é que era. Pela minha lembrança, o COBOL realmente desencorajou ter mais de um ou dois registros na memória de cada vez (o registro atual e talvez o anterior). 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.
Kindall

11
Fiz alguns COBOL por alguns anos (para referência, tenho apenas 26 anos) e posso esclarecer uma coisa para você. Você não precisa mais definir parágrafos para cada loop, agora pode incorporá-lo PERFORM UNTILaos END-PERFORMblocos. Eu realmente odeio saber isso.
AgentConundrum

11
@NealB Eu estava apenas esclarecendo o ponto, pois ele admite que sua experiência está desatualizada, mesmo para os padrões da COBOL. Entendo o COBOL85, mas há muitos códigos antigos por aí que foram iniciados antes da sua existência ou foram escritos por pessoas com a cabeça presa em uma versão anterior. Você realmente não pode supor que uma base de código tenha até 85 padrões, mas mesmo se for, ainda é uma linguagem desconfortável. Programadores mais antigos estão se aposentando mais rapidamente do que estão sendo substituídos, e muito poucos novos programadores desejam trabalhar no COBOL. Eu sei que não gostaria de tocar nas coisas novamente.
AgentConundrum

43

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.


2
Na minha resposta, digo que COBOL é ruim para estruturas de dados. Existe alguma diferença no que significa "estrutura de dados"? Talvez as ferramentas de layout de registro sejam excelentes, mas o COBOL ainda é o idioma errado para árvores binárias etc.? Ou talvez minha experiência com COBOL tenha sido muito antiga ou limitada? Pergunta-chave - o COBOL possui indicadores? (O preocupante é que um rápido Google sugere que sim, embora meu livro antigo sugira que não). Eu odiaria para retrair uma resposta que ganhou todas aquelas lindas Rep-pontos para mim, mas se eu estiver errado ...
Steve314

3
Há uma desvantagem na aritmética decimal: você precisa dizer exatamente quantos dígitos deseja. Lembro-me de encontrar bugs quando tínhamos poucos 9s na PICcláusula em algum programa dentro de um grupo.
David Thornley

2
Minha impressão (não informada) é que o COBOL é particularmente bom em lidar com dados em registros rígidos e de tamanho fixo. Talvez não seja tão bom em estruturas de dados dinâmicas. Corrija-me se eu estiver errado.
Barry Brown

@ Steve314 - sim, os ponteiros surgiram por volta de 1985, mas eram um pouco ruins porque você só podia configurá-los para coisas na seção de ligação. Versões posteriores permitiam apontar para qualquer coisa.
James Anderson

11
Estruturas @ - embora não esteja de acordo com os padrões Python em termos de hashes e árvores, etc. É tão bom quanto C ou Java - exceto que não é tão bom quanto um C ++ plus Boost ou Java e a Biblioteca de coleções. Mais uma vez, a falha em apreciar o valor das bibliotecas e funções padrão prejudicou a linguagem ao longo de sua longa vida.
James Anderson

27

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


20
Um dia eles descobrirão um cofre cheio de código escrito por Dijkstra nos idiomas que ele denunciou.
jonsca

7
@ jonsca - você ficará surpreso com o que fará por dinheiro.
JeffO 07/10

3
As versões incompatíveis eram IIRC bastante comuns até pelo menos os anos 70, e mesmo nos anos 80 havia o Basic. Dijkstra provavelmente estava argumentando com base em um problema mencionado na minha resposta - o COBOL não é bom para (ou deve ser bom para) a codificação da estrutura de dados. Portanto, para um valor específico de "ensinar programação" ou "ensinar ciência da computação", o COBOL é realmente um veneno. É claro que, uma vez que o COBOL não se destina a isso, é uma afirmação bastante injusta - mas, novamente, IIRC, o contexto era que algumas pessoas estavam tentando ensinar essas coisas usando o COBOL.
precisa saber é o seguinte

2
Dijkstra <- um homem que falava demais ...
Rook

3
@Danny: COBOL foi desprezado bem antes Dijkstra escreveu que a linha em 1975.
John R. Strohm

9

É 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.


Ouvi alguém mencionar transações bancárias de passagem, que é a única razão pela qual a incluí, mas certamente aceitarei sua palavra sobre a de outra pessoa.
jonsca

4
Trabalhei por 20 anos no setor bancário, quase todo no COBOL. Bancos diferentes fizeram coisas de maneiras diferentes, suponho.
TrueDub 7/10/11

Conheço pelo menos um sistema ERP importante que possui (ou tinha até 2007) muito COBOL nele.
Alan B

2
Não foi a IBM que projetou o COBOL. Os principais instigadores foram a Marinha dos EUA e o UNIVAC.
James Anderson

8
"o principal objetivo da IBM ao projetar o COBOL era que" deveria permitir que um gerente de banco escrevesse um programa "." Uma meta nobre, embora a grande maioria dos gerentes que conheço nem possa me escrever literatura simples para um site, muito menos escrever COBOL.
Maple_shaft

8

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.


11
Idiomas são para usuários?
JeffO 07/10

16
"Linhas de código" não é uma boa medida entre idiomas. COBOL é notoriamente detalhado. Esses 5 bilhões de linhas de código anualmente são provavelmente equivalente a dezessete regex'es;)
MSalters

3
Às vezes, o COBOL é a ferramenta certa para o trabalho - muitas vezes não é. A parte difícil é fazer com que as pessoas reconheçam a diferença.
TrueDub 7/10/11

11
É verdade, @TrueDub. Minha frase soou um pouco exagerada, mas não era para ser.
jonsca

3
@TrueDub: Se COBOL é a ferramenta certa para um trabalho, eu não quero fazer esse trabalho, desde que eu tenha alternativas. Existem empregos muito mais interessantes pelos quais posso ser bem pago.
precisa

5

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?


4

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.]


Não me lembro de nenhum desses - ou repressão, ou nunca os aprendi. Uma pesquisa rápida me diz que eu certamente concordo que isso ALTERé mau, mas esse recurso raramente é usado, por isso nunca é um motivo para odiar o COBOL. Eu não tenho tanta certeza REDEFINES, no entanto. Compará-lo com o unionque me faz pensar um pouco mais gentilmente com ele - mas talvez o que há de bom em uma linguagem de manipulação de estrutura de dados e quebra de bits de baixo nível possa não ser uma ótima idéia no processamento de dados.
precisa saber é o seguinte

Às vezes, suas respostas me parecem desdenhosas, mas essa é apenas inútil. Não sei se você está tentando ajudar aqui, mas está fazendo mal ou se está apenas conversando consigo mesmo. Eu poderia perguntar o que você quer dizer com "puro mal", mas a beleza das boas respostas acima é que não preciso iniciar uma conversa para aprender alguma coisa.
Eric Wilson

@ EricWilson: Obrigado por descartar minha resposta tão completamente. Isso me ajudou a entender o que mais precisava ser adicionado.
S.Lott

11
@ Eric - o problema ALTERé que ele redireciona o gotos. Primeiro, isso significa que você está usando gotos - em si, não acho que isso seja ruim, mas na maioria dos idiomas é algo incomum em casos especiais. Segundo, isso significa que os gotos vão para outro lugar que não onde eles dizem que vão - e isso é aterrorizante. Não estou realmente convencido de que este seja um código auto-modificável, mas é descrito como era para onde eu olhava, e pensar nele como modificar alvos de instruções de salto no assembler explica o porquê.
precisa saber é o seguinte

@ S.Lott Obrigado por suas adições (você também @ Steve314), aprendi algo interessante e invertei meu voto.
Eric Wilson

3

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.


"A falta de suporte para o Windows como interface" .... que sobre netcobol.com/products/Fujitsu-NetCOBOL-for-.NET/overview
JoelFan

@JoelFan obrigado pelo seu comentário. Você está certo de que hoje existem ferramentas melhores para o COBOL, mas acho que todas chegaram tarde demais. Meu argumento sobre a falta de suporte à interface do Windows foi no início dos anos 90, onde apenas a Micro Focus era o único player no mercado.
NoChance

2

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!)


11
"Hello World" leva quantas linhas ?. Analisando / gerando XML - agora está embutido na linguagem. Talvez você deva estar atualizando sua base de conhecimento. Esta resposta pertence à era dos anos 60 do COBOL.
NealB 17/10

Interessante. Não tenho trabalhado com COBOL há quase uma década, mas na última vez em que o vi foi escrito exatamente como eu me lembrava, DIVISÃO DE IDENTIFICAÇÃO, SEÇÃO DE ARMAZENAMENTO DE TRABALHO e tudo. Eu acho que todos esses "comentários obrigatórios" (AUTOR, DATA-ESCRITO, COMPUTADOR POR FONTE, COMPUTADOR POR OBJETO) são opcionais agora. A análise de XML não parece tão impressionante - você precisa estruturar a divisão de dados para refletir a estrutura do arquivo, não há processamento no estilo SAX ou DOM. É bom saber que está lá, no entanto.
TMN
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.