 |
| Bellacosa Mainframe apresenta a guerra historica entre Dijkstra versus Cobol |
☕ Um Café no Bellacosa Mainframe
Dijkstra versus COBOL sem Mistérios
Quando um Cientista da Computação Declarou o Ensino de COBOL uma Ofensa Criminal… e o COBOL Continuou Pagando Salários, Aposentadorias e a Conta do Chá
Existe uma fotografia bastante conhecida nos corredores virtuais da Computação. Nela aparece Edsger W. Dijkstra, um dos maiores cientistas da área, acompanhado da seguinte declaração:
“O uso de COBOL aleija a mente; seu ensino deveria, portanto, ser considerado uma ofensa criminosa.”
É uma frase delicada, equilibrada e diplomática, comparável a entrar em uma reunião de programadores COBOL, subir na mesa, derrubar o café do gerente de produção e anunciar:
— Senhores, vocês não apenas escolheram a linguagem errada. Vocês são vítimas de um crime intelectual.
Depois disso, espera-se que alguém toque um sino, um cavaleiro atravesse a sala montado em um cavalo imaginário e o programa da folha de pagamento continue executando normalmente, porque ele está em produção desde 1978 e não tem tempo para discussões filosóficas.
A frase de Dijkstra tornou-se uma das provocações mais famosas da história da programação. É citada por professores, estudantes, desenvolvedores, arquitetos, influenciadores tecnológicos e pessoas que aprenderam Python na terça-feira e, na quinta, já estavam publicando no LinkedIn que o mainframe morreria até o final do mês.
Mas o que Dijkstra realmente queria dizer?
Ele estava completamente errado?
O COBOL realmente prejudica a mente?
Por que uma linguagem tão criticada continua sendo utilizada?
E, principalmente, o que um programador COBOL iniciante pode aprender com essa antiga batalha entre a elegância acadêmica e o sistema que precisa fechar a contabilidade antes das seis da manhã?
Prepare o café, verifique o JOB CLASS, coloque o capacete e não alimente os acadêmicos depois da meia-noite. Vamos entrar no tribunal mais estranho da história da Computação.
1. O acusado entra no tribunal
De um lado do salão está Edsger Wybe Dijkstra, matemático, cientista da computação, defensor da programação estruturada e vencedor do Prêmio Turing.
Do outro lado está o COBOL, vestindo um terno cinza, carregando uma pasta cheia de registros de tamanho fixo e murmurando:
IDENTIFICATION DIVISION.
PROGRAM-ID. REU-ABSOLVICAO.
O juiz pergunta:
— Nome?
— Common Business-Oriented Language.
— Profissão?
— Processamento comercial, financeiro, governamental, securitário e bancário.
— Idade?
— Prefiro não comentar.
— Acusação?
— Ter sobrevivido a todos os seus substitutos.
Na galeria, FORTRAN limpa os óculos. ALGOL observa com expressão superior. BASIC tenta entrar sem número de linha e é retirado por dois guardas. Java aparece quinze minutos atrasado porque ainda está inicializando a máquina virtual.
Para compreender o julgamento, precisamos conhecer o acusador.
 |
| Bellacosa Mainframe apresenta o professor Dijkstra |
2. Quem foi Dijkstra?
Dijkstra não era simplesmente um programador mal-humorado que encontrou um código COBOL sem comentários e decidiu declarar guerra à humanidade.
Ele foi um dos nomes fundamentais da Ciência da Computação.
Entre suas contribuições estão:
o algoritmo de caminho mínimo que leva seu nome;
estudos sobre concorrência;
semáforos para sincronização de processos;
exclusão mútua;
programação estruturada;
raciocínio formal sobre programas;
defesa da eliminação do uso indiscriminado de GOTO;
métodos para demonstrar a correção de algoritmos.
Para Dijkstra, programação não deveria ser uma arte mística praticada por pessoas que digitavam comandos até o computador parar de reclamar.
Programar deveria ser uma atividade intelectual rigorosa, próxima da Matemática.
O programa não deveria apenas “parecer funcionar”.
Deveria ser possível compreender por que ele funcionava, provar suas propriedades e demonstrar que determinadas condições sempre seriam respeitadas.
Essa ideia parece óbvia hoje, especialmente quando falamos de sistemas bancários, aeronáuticos, médicos ou industriais. Contudo, nos primeiros tempos da programação, muitos programas eram construídos de maneira altamente improvisada.
Era o glorioso período histórico conhecido como:
“Digite alguma coisa, execute, receba um erro, altere três instruções, execute novamente e diga ao gerente que estamos quase terminando.”
Essa metodologia continua viva em muitos departamentos, mas atualmente recebe nomes mais modernos e apresentações em PowerPoint.
3. Por que Dijkstra atacava o COBOL?
A crítica não surgiu apenas porque o COBOL era antigo, comercial ou muito utilizado por empresas.
Dijkstra acreditava que uma linguagem de programação influenciava a forma de pensar de quem a utilizava.
Esse é um ponto importante.
Uma linguagem não é apenas uma ferramenta para traduzir ordens humanas em instruções de máquina. Ela oferece conceitos, limitações, estruturas e caminhos mentais.
Quem programa em Assembly pensa muito sobre registradores, endereços e instruções.
Quem programa em Lisp tende a pensar em listas, funções e recursão.
Quem programa em SQL aprende a descrever o resultado desejado, deixando para o banco decidir como encontrá-lo.
Quem programa em Java frequentemente pensa em objetos, classes, interfaces e em como transformar uma soma de dois números em uma arquitetura com dezessete arquivos.
O COBOL, especialmente nas primeiras décadas, incentivava uma programação fortemente procedural, baseada em registros, arquivos, seções e parágrafos.
Um programa típico podia ter:
uma enorme DATA DIVISION;
centenas de campos;
dezenas ou centenas de parágrafos;
muitos saltos;
inúmeros indicadores;
estruturas pouco modulares;
regras de negócio espalhadas por diferentes pontos.
Dijkstra temia que o contato prolongado com esse modelo criasse maus hábitos intelectuais.
Em outras palavras, ele não estava afirmando apenas que determinados programas COBOL eram ruins. Ele sugeria que a própria linguagem treinava o programador a pensar de maneira inadequada.
Naturalmente, afirmou isso com a suavidade de um elefante tentando entrar em uma loja de porcelana utilizando patins.
4. A sintaxe semelhante ao inglês
Um dos objetivos originais do COBOL era permitir que programas comerciais fossem compreendidos com mais facilidade por pessoas próximas ao negócio.
Veja este exemplo:
IF SALDO-CLIENTE GREATER THAN LIMITE-CREDITO
MOVE 'S' TO CLIENTE-BLOQUEADO
ELSE
MOVE 'N' TO CLIENTE-BLOQUEADO
END-IF
Mesmo alguém sem grande experiência consegue perceber a intenção.
O saldo do cliente está sendo comparado com o limite de crédito. Dependendo do resultado, um indicador é alterado.
Essa legibilidade foi uma grande vantagem comercial.
Entretanto, para Dijkstra, a aparência de linguagem natural poderia criar uma falsa sensação de simplicidade.
O fato de uma instrução parecer inglês não significa que o programa inteiro seja simples.
Observe:
IF CLIENTE-ATIVO
IF SALDO-DEVEDOR
IF NOT ACORDO-VIGENTE
IF DIAS-ATRASO GREATER THAN 30
PERFORM BLOQUEAR-CONTA
END-IF
END-IF
END-IF
END-IF
A leitura ainda é possível, mas a complexidade cresce.
Agora imagine esse tipo de lógica repetido em milhares de linhas, com campos de nomes parecidos, regras alteradas durante quarenta anos e comentários escritos por alguém chamado Osvaldo que se aposentou antes da invenção do telefone celular.
A linguagem parece natural.
A regra de negócio, porém, pode ter a clareza de uma reunião parlamentar transmitida por rádio durante uma tempestade.
5. O problema não era apenas o COBOL
Aqui está uma curiosidade importante: Dijkstra criticava muitas coisas.
Ele criticou o uso indiscriminado de GOTO.
Criticou BASIC.
Criticou linguagens excessivamente permissivas.
Criticou práticas de desenvolvimento pouco rigorosas.
Provavelmente criticaria sua variável chamada X2-FLAG-AUX-FINAL-NOVO.
Talvez também criticasse o nome PROGRAMA-FINAL-V2-AGORA-VAI.
Dijkstra defendia que a dificuldade da programação deveria ser controlada por estruturas formais e raciocínio disciplinado.
Ele não estava interessado em saber se o programa “rodou duas vezes sem erro”.
Queria saber se havia razões sólidas para confiar nele.
Essa posição influenciou profundamente o desenvolvimento de linguagens modernas.
Hoje consideramos naturais conceitos como:
Muitas dessas ideias dialogam com o tipo de rigor defendido por Dijkstra.
6. Onde ele estava certo?
Seria confortável para a comunidade COBOL simplesmente dizer:
— Ele estava errado. Próximo assunto. Tragam os biscoitos.
Mas isso não seria intelectualmente honesto.
Dijkstra acertou em vários pontos.
6.1 Programas sem estrutura tornam-se perigosos
Considere este código:
IF ERRO-ARQUIVO
GO TO TRATA-ERRO.
PERFORM PROCESSA-REGISTRO.
IF FIM-ARQUIVO
GO TO FINALIZA.
GO TO LE-PROXIMO.
TRATA-ERRO.
DISPLAY 'ERRO'.
GO TO FINALIZA.
LE-PROXIMO.
READ ARQUIVO-ENTRADA
AT END
SET FIM-ARQUIVO TO TRUE
END-READ
GO TO PROCESSA.
PROCESSA.
PERFORM PROCESSA-REGISTRO
GO TO LE-PROXIMO.
FINALIZA.
CLOSE ARQUIVO-ENTRADA.
Esse exemplo é pequeno. Ainda assim, o fluxo exige que o leitor percorra visualmente vários pontos.
Agora imagine 50 mil linhas nesse estilo.
O resultado pode ser um labirinto.
O programa parece ter sido planejado por um arquiteto medieval especializado em construir corredores que terminam em paredes.
A programação estruturada propõe algo mais claro:
PERFORM UNTIL FIM-ARQUIVO
READ ARQUIVO-ENTRADA
AT END
SET FIM-ARQUIVO TO TRUE
NOT AT END
PERFORM PROCESSA-REGISTRO
END-READ
END-PERFORM
Agora o fluxo está concentrado.
Existe um início, uma condição e um fim.
Essa melhoria está alinhada com as preocupações de Dijkstra.
6.2 A linguagem pode reforçar maus hábitos
Uma linguagem que permite determinada prática não obriga o programador a utilizá-la.
Porém, quanto mais fácil é fazer algo ruim, maior é a chance de isso acontecer.
COBOL tradicional permitia programas gigantescos, campos globais e estruturas muito acopladas.
Se a equipe não aplicasse disciplina, o código poderia crescer como uma criatura de filme de ficção científica alimentada por alterações emergenciais.
Primeiro havia um programa de 500 linhas.
Depois veio uma nova regra tributária.
Depois um campo de controle.
Depois uma exceção para uma filial.
Depois uma exceção para a exceção.
Quando alguém percebeu, o programa tinha 80 mil linhas e exigia a leitura de três manuais, duas atas de reunião e um pergaminho descoberto atrás da impressora.
6.3 Legibilidade não é apenas usar palavras inglesas
Este código parece legível:
ADD VALOR-A TO VALOR-B GIVING VALOR-C
Mas nomes claros não bastam.
Precisamos conhecer:
o significado dos valores;
a unidade monetária;
a escala decimal;
a origem dos dados;
os limites;
as regras de arredondamento;
o comportamento em caso de excesso;
a responsabilidade daquela operação.
O código pode ser gramaticalmente bonito e conceitualmente obscuro.
Dijkstra tinha razão ao exigir precisão.
7. Onde ele exagerou?
A frase sobre “ofensa criminosa” era uma provocação retórica, não uma proposta para que professores de COBOL fossem algemados durante a aula.
Ainda assim, ela exagera porque avalia a linguagem principalmente sob uma perspectiva acadêmica.
Empresas não escolhem tecnologias apenas por elegância matemática.
Elas precisam resolver problemas concretos.
Um banco quer:
Uma seguradora não pode dizer ao cliente:
— Perdemos o cálculo da sua apólice, mas o novo sistema utiliza uma arquitetura muito elegante.
O cliente provavelmente responderá:
— Magnífico. Posso pagar o prêmio com elegância abstrata?
O COBOL foi criado para processamento comercial.
Possui características muito adequadas a esse domínio:
representação decimal;
descrição detalhada de registros;
tratamento de arquivos;
forte orientação a dados comerciais;
legibilidade relativa;
integração com ambientes transacionais;
excelente desempenho em processamento em lote;
estabilidade.
Ele não precisava vencer uma competição de pureza matemática.
Precisava fechar a folha de pagamento.
E fechou.
Por décadas.
8. O grande paradoxo
Dijkstra venceu muitas batalhas conceituais.
A programação estruturada tornou-se dominante.
O uso indiscriminado de GOTO diminuiu.
As linguagens incorporaram melhores mecanismos de abstração.
A Engenharia de Software passou a valorizar modularização, testes, contratos e validação.
Porém, o COBOL não desapareceu.
Ao contrário, incorporou várias dessas melhorias.
O COBOL moderno oferece recursos como:
EVALUATE TRUE
WHEN CLIENTE-VIP
PERFORM PROCESSA-VIP
WHEN CLIENTE-PREMIUM
PERFORM PROCESSA-PREMIUM
WHEN OTHER
PERFORM PROCESSA-PADRAO
END-EVALUATE
Também permite:
Assim, ocorreu algo quase britanicamente absurdo:
Dijkstra criticou o COBOL por suas limitações estruturais.
O COBOL absorveu muitas ideias da programação estruturada.
Depois continuou funcionando.
É como condenar um castelo medieval por não possuir eletricidade e, anos depois, descobrir que instalaram fibra óptica, elevadores e uma cafeteria no salão principal, mas mantiveram as muralhas porque ainda são bastante úteis contra invasores.
9. COBOL moderno não é COBOL de 1965
Muitos críticos imaginam que todos os programas COBOL atuais são escritos assim:
GO TO 1000-INICIO.
Em seguida, haveria:
GO TO 2000-MEIO.
E, por fim:
GO TO 3000-ALGUEM-SABE-O-QUE-ESTA-ACONTECENDO.
Esse tipo de código existiu e ainda pode existir em sistemas antigos. Porém, não representa obrigatoriamente a maneira moderna de programar em COBOL.
Um programa contemporâneo pode ser organizado de forma bastante clara:
IDENTIFICATION DIVISION.
PROGRAM-ID. CALCJURO.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-VALORES.
05 WS-CAPITAL PIC S9(9)V99 COMP-3.
05 WS-TAXA PIC S9(3)V9(6) COMP-3.
05 WS-JURO PIC S9(9)V99 COMP-3.
PROCEDURE DIVISION.
0000-PRINCIPAL.
PERFORM 1000-RECEBER-DADOS
PERFORM 2000-CALCULAR-JURO
PERFORM 3000-EXIBIR-RESULTADO
GOBACK
.
1000-RECEBER-DADOS.
MOVE 1000.00 TO WS-CAPITAL
MOVE 0.015 TO WS-TAXA
.
2000-CALCULAR-JURO.
COMPUTE WS-JURO ROUNDED =
WS-CAPITAL * WS-TAXA
.
3000-EXIBIR-RESULTADO.
DISPLAY 'JURO: ' WS-JURO
.
O fluxo é previsível.
Os dados estão organizados.
Cada parágrafo possui uma finalidade.
Não é necessário esconder um gnomo dentro da LINKAGE SECTION para compreender o programa.
10. Passo a passo para não “aleijar a mente”
Talvez a melhor resposta à provocação de Dijkstra não seja rejeitá-la, mas utilizá-la como alerta.
Você pode programar em COBOL aplicando rigor, estrutura e clareza.
Passo 1 — Entenda a regra antes de escrever código
Não comece pela PROCEDURE DIVISION.
Primeiro responda:
Qual problema será resolvido?
Quais dados entram?
Quais dados saem?
Quais regras devem ser respeitadas?
Quais erros podem ocorrer?
Quais limites existem?
Exemplo:
Calcular desconto para clientes, considerando categoria, valor da compra e campanhas vigentes.
Antes de codificar, escreva uma tabela:
| Categoria | Compra mínima | Desconto |
|---|
| Comum | 500,00 | 5% |
| Premium | 300,00 | 10% |
| VIP | qualquer valor | 15% |
Isso reduz ambiguidades.
Passo 2 — Modele os dados com precisão
Em COBOL, dados são fundamentais.
01 WS-COMPRA.
05 WS-VALOR-COMPRA PIC S9(7)V99 COMP-3.
05 WS-PERCENTUAL PIC S9(3)V99 COMP-3.
05 WS-VALOR-DESCONTO PIC S9(7)V99 COMP-3.
05 WS-VALOR-LIQUIDO PIC S9(7)V99 COMP-3.
Escolha corretamente:
tamanho;
sinal;
casas decimais;
formato;
uso computacional.
Não declare todos os valores como PIC X(100) e espere que o universo coopere.
O universo raramente coopera. O compilador, menos ainda.
Passo 3 — Use nomes que expliquem intenção
Evite:
01 WS-A PIC 9(5).
01 WS-B PIC 9(5).
01 WS-C PIC 9(5).
Prefira:
01 WS-QUANTIDADE-PARCELAS PIC 9(3).
01 WS-VALOR-PARCELA PIC 9(7)V99.
01 WS-VALOR-TOTAL PIC 9(9)V99.
Um bom nome evita comentários desnecessários.
WS-B exige explicação.
WS-VALOR-TOTAL-FATURA apresenta-se sozinho e provavelmente trouxe documentos.
Passo 4 — Divida o processamento
Organize o programa em etapas:
0000-PRINCIPAL.
PERFORM 1000-INICIALIZAR
PERFORM 2000-PROCESSAR
PERFORM 3000-FINALIZAR
GOBACK
.
Dentro de 2000-PROCESSAR, divida novamente conforme a necessidade.
Cada rotina deve representar uma ação reconhecível.
Evite parágrafos como:
8450-FAZ-COISAS.
Esse nome não explica nada e parece o título de um departamento governamental.
Passo 5 — Controle o fluxo
Prefira estruturas delimitadas:
IF VALOR-COMPRA GREATER THAN ZERO
PERFORM CALCULAR-DESCONTO
ELSE
MOVE 'VALOR INVALIDO' TO WS-MENSAGEM
END-IF
Use EVALUATE quando houver múltiplas condições claras:
EVALUATE CATEGORIA-CLIENTE
WHEN 'VIP'
MOVE 15 TO WS-PERCENTUAL
WHEN 'PREMIUM'
MOVE 10 TO WS-PERCENTUAL
WHEN 'COMUM'
MOVE 5 TO WS-PERCENTUAL
WHEN OTHER
MOVE ZERO TO WS-PERCENTUAL
END-EVALUATE
O objetivo é permitir que outro programador siga o fluxo sem precisar desenhar um mapa do tesouro.
Passo 6 — Trate erros explicitamente
READ ARQUIVO-CLIENTES
AT END
SET FIM-CLIENTES TO TRUE
NOT AT END
PERFORM VALIDAR-CLIENTE
END-READ
Para operações de arquivo, banco de dados ou serviços, sempre considere:
sucesso;
fim de dados;
ausência de registro;
duplicidade;
indisponibilidade;
dados inválidos;
falha técnica.
O erro que não foi tratado não desaparece.
Ele apenas aguarda a sexta-feira, às 17h43.
Passo 7 — Teste as fronteiras
Não teste apenas o caso feliz.
Teste:
valor zero;
valor negativo;
maior valor possível;
campo vazio;
cliente inexistente;
data inválida;
arquivo vazio;
registro duplicado;
limite decimal;
arredondamento;
overflow.
O caso feliz é educado e raramente quebra o programa.
Os casos de fronteira entram pela janela, bebem seu café e alteram a RETURN-CODE.
Passo 8 — Revise o código como lógica, não como literatura
Pergunte:
O fluxo é previsível?
As responsabilidades estão separadas?
Os nomes são claros?
As condições são compreensíveis?
Existem efeitos colaterais ocultos?
Um iniciante conseguiria acompanhar?
O programa depende de conhecimento tribal?
Se a resposta para a última pergunta for “sim, mas o Arnaldo conhece”, existe um risco.
Especialmente se Arnaldo estiver aposentado, morando em uma chácara e se recusar a atender chamadas relacionadas ao sistema de faturamento.
11. A verdadeira arma do COBOL
A maior força do COBOL não é sua aparência de inglês.
Também não é sua idade.
É sua relação com o negócio.
Programas COBOL costumam conter regras que representam décadas de decisões empresariais.
Uma linha aparentemente simples pode refletir:
legislação;
acordo sindical;
regra contábil;
política comercial;
decisão judicial;
contrato;
comportamento histórico;
exceção regional.
Por exemplo:
IF DATA-ADMISSAO LESS THAN DATA-LIMITE
PERFORM CALCULO-ANTIGO
ELSE
PERFORM CALCULO-NOVO
END-IF
Tecnicamente, é um IF.
Empresarialmente, pode representar uma mudança legal que afeta milhões de pessoas.
Essa é uma das razões pelas quais migrar sistemas legados é difícil.
Não basta traduzir sintaxe.
É necessário compreender o significado.
Você pode converter:
ADD A TO B
para:
b += a;
em poucos segundos.
Mas se ninguém souber o que A e B representam, você apenas transportou o mistério para outra linguagem.
Agora o mistério possui chaves, ponto e vírgula e uma dependência no Maven.
12. Curiosidades do campo de batalha
COBOL foi criado para durar?
Não exatamente da forma como durou.
Ele surgiu para padronizar o processamento de dados comerciais entre diferentes fabricantes.
Sua longevidade foi consequência de:
grande adoção;
volumes imensos de código;
estabilidade;
compatibilidade;
importância dos sistemas;
custo e risco de substituição.
Ser antigo significa ser ruim?
Não.
A roda é antiga.
A contabilidade é antiga.
O chá é antigo.
O Parlamento britânico é tão antigo que algumas de suas regras parecem ter sido compiladas em pergaminho.
Tecnologias devem ser avaliadas pelo contexto, não apenas pela data de nascimento.
COBOL não possui precisão?
Ao contrário.
COBOL é especialmente forte no processamento decimal, algo importante para sistemas financeiros.
Tipos como COMP-3 são amplamente utilizados para armazenar valores decimais com eficiência e precisão.
Todo código COBOL é legado?
Não.
Código legado não significa apenas código antigo.
É possível ter código Java criado no ano passado que ninguém entende, não possui testes e depende de uma biblioteca abandonada.
Esse sistema já nasceu legado.
É um bebê de seis meses usando chapéu, carregando uma bengala e reclamando dos jovens.
13. Easter eggs do Bellacosa Mainframe
Easter egg 1 — O COBOL já morreu muitas vezes
Desde os anos 1980, surgem previsões sobre o fim do COBOL.
A linguagem seria substituída por:
linguagens de quarta geração;
arquiteturas cliente-servidor;
Java;
pacotes ERP;
serviços web;
cloud;
microsserviços;
inteligência artificial;
algum produto apresentado por um consultor apontando para três nuvens e sete hexágonos.
O COBOL ouve calmamente, termina o processamento noturno e volta ao trabalho.
Easter egg 2 — O programa mais perigoso
O programa mais perigoso não é necessariamente o maior.
É aquele que todos consideram simples.
A equipe diz:
— Esse programa só move alguns campos.
Seis horas depois, descobre-se que ele também valida contratos, atualiza três arquivos, envia mensagem ao CICS, altera uma tabela DB2 e decide se o cliente poderá comprar uma geladeira.
Easter egg 3 — O comentário histórico
Em sistemas antigos, você pode encontrar comentários como:
* ALTERADO EM 1987 CONFORME SOLICITACAO DO SR. ROBERTO
Quem é Roberto?
Ninguém sabe.
O que ele solicitou?
Perdeu-se.
A alteração ainda é necessária?
Provavelmente.
Pode ser removida?
Somente se você deseja transformar a produção em um documentário sobre desastres.
Easter egg 4 — A variável imortal
Todo sistema possui uma variável que aparentemente não é utilizada.
01 WS-CONTROLE-ANTIGO PIC X.
Alguém tenta removê-la.
O programa compila.
Os testes passam.
Em produção, uma agência bancária em uma ilha remota deixa de processar transferências realizadas em anos bissextos.
A variável volta.
Ninguém mais toca nela.
14. O que um iniciante deve aprender com Dijkstra?
A pior reação seria rejeitar Dijkstra apenas porque ele atacou o COBOL.
A melhor reação é aprender com a crítica.
Um bom programador COBOL deve buscar:
Você não precisa abandonar COBOL para aplicar programação estruturada.
Ao contrário, pode utilizar conceitos modernos para melhorar sistemas COBOL.
A pergunta correta não é:
COBOL é uma linguagem boa ou ruim?
A pergunta correta é:
Este programa está organizado, compreensível, testável e seguro?
Uma linguagem não salva um projeto mal conduzido.
Também não condena automaticamente um projeto bem desenvolvido.
É possível escrever código excelente em COBOL.
É possível escrever código terrível em Rust, Java, Python, C# ou qualquer outra linguagem moderna.
Ferramentas influenciam nossas decisões, mas não substituem disciplina.
Um martelo pode construir uma casa.
Também pode quebrar uma janela.
Não culpamos o martelo, exceto quando precisamos preencher o relatório de incidente e o martelo não possui advogado.
15. Dijkstra venceu ou o COBOL venceu?
Ambos venceram.
Dijkstra venceu no campo das ideias.
Sua defesa da programação estruturada, do rigor e da clareza ajudou a transformar o desenvolvimento de software.
O COBOL venceu no campo operacional.
Demonstrou capacidade extraordinária de manter processos comerciais funcionando por décadas.
A vitória de um não exige a derrota do outro.
Na verdade, o COBOL moderno tornou-se melhor ao incorporar princípios defendidos por críticos como Dijkstra.
O programador COBOL atual pode trabalhar com:
O mainframe não está isolado em um castelo coberto por névoa.
Ele conversa com aplicações distribuídas, serviços, canais digitais, nuvens e sistemas móveis.
Às vezes conversa de maneira um pouco formal, porque foi educado nos anos 1960, mas conversa.
Conclusão — O crime que mantém o mundo funcionando
A frase de Dijkstra é brilhante como provocação e injusta como veredicto absoluto.
Ela nos obriga a refletir sobre como as linguagens moldam nossa forma de pensar.
Também alerta para os perigos de programas sem estrutura, saltos descontrolados, dados globais e falta de abstração.
Por outro lado, ignora ou subestima qualidades fundamentais do COBOL:
O verdadeiro problema nunca foi simplesmente utilizar COBOL.
O problema é utilizar qualquer linguagem sem disciplina.
Um programador pode escrever um programa COBOL claro, modular e seguro.
Outro pode criar um microsserviço moderno, empacotá-lo em um contêiner, executá-lo na nuvem e ainda assim produzir uma criatura incompreensível que consome memória, perde mensagens e envia ao cliente uma fatura correspondente ao consumo elétrico da Escócia.
Tecnologia moderna não garante pensamento moderno.
Ferramenta antiga não implica pensamento ultrapassado.
O iniciante COBOL deve conhecer a história, respeitar as críticas e evitar repetir os erros do passado. Deve compreender profundamente os dados, estruturar o processamento, tratar falhas, testar fronteiras e documentar as regras.
Talvez Dijkstra tenha exagerado ao chamar o ensino de COBOL de ofensa criminosa.
Porém, existe um crime real na programação:
entregar código que ninguém entende, ninguém consegue testar e todos têm medo de alterar.
Esse crime pode ser cometido em qualquer linguagem.
Inclusive na linguagem que substituiria o COBOL.
E agora, enquanto o júri discute o veredicto, o programa COBOL solicita licença para se retirar.
Ele precisa processar a folha de pagamento dos advogados, dos juízes, dos acadêmicos e provavelmente do próprio funcionário que publicou nas redes sociais que COBOL está morto.
IF COBOL-MORTO
DISPLAY 'NOTICIA NAO CONFIRMADA'
ELSE
PERFORM PROCESSAR-MUNDO
END-IF.
GOBACK.
O sino toca.
O cavaleiro passa novamente pelo corredor.
Alguém pergunta onde está o cavalo.
E o operador responde:
— O cavalo foi migrado para a nuvem. A produção, entretanto, continua no mainframe.
